Panoramica offline

Stessi tool del lab, tre differenze:

1. Supply chain: ogni immagine, chart e modello arriva dal registry interno.
2. LLM in-cluster: Ollama (CPU o GPU) o vLLM (GPU) in un namespace dedicato ai-llm.
3. Perimetro: agenti con RBAC read-only, NetworkPolicy che isolano l’LLM, nessun egress.

registry.internal è un segnaposto per il tuo registry (Harbor, Quay, MSR, Nexus).

Artefatti

Artefatto	Origine (lato connesso)	Forma offline	Pagina
Immagine Ollama	docker.io/ollama/ollama	immagine mirrorata, digest fissato	Mirror
Immagine vLLM	docker.io/vllm/vllm-openai	immagine mirrorata	vLLM
Model fetcher	build interna (UBI + oras)	immagine interna	Modello OCI
Modello	Ollama store o GGUF/safetensors HF	artefatto OCI	Modello OCI
k8sgpt operator + runtime	charts.k8sgpt.ai, ghcr.io/k8sgpt-ai/*	chart .tgz + immagini	k8sgpt offline
HolmesGPT	chart Robusta + immagine	chart .tgz + immagine	HolmesGPT offline
Monitoring	già presente (OCP monitoring, kube-prometheus-stack)	—	OpenShift

Sequenza

1. Mirror di immagini e chart.
2. Modello nel registry come artefatto OCI.
3. Namespace ai-llm con LLM, PVC, Service, NetworkPolicy.
4. Namespace e RBAC read-only per i tool.
5. k8sgpt operator puntato all’LLM interno.
6. HolmesGPT (servizio e/o CronJob sugli alert).
7. Test con un namespace di prova (riusa shop-demo.yaml con immagini mirrorate).

Prerequisiti

kubectl auth can-i create namespace

kubectl get storageclass

kubectl get nodes -L node-role.kubernetes.io/worker,nvidia.com/gpu.present

kubectl describe node <worker> | grep -A6 Allocatable