LLM Kubernetes su Minikube

LLM Kubernetes su Minikube

LLM Kubernetes su Minikube: costruisci il tuo agente AI locale

Se sei uno sviluppatore software o un ingegnere informatico con una discreta esperienza con i container e l’orchestrazione, probabilmente hai già sentito parlare di Kubernetes e dei Large Language Models (LLM). Ma hai mai pensato di farli lavorare insieme, in locale, sul tuo laptop, senza dipendere da servizi cloud costosi? In questo articolo ti mostriamo come costruire un agente AI locale che interagisce con Kubernetes tramite linguaggio naturale, usando Ollama, Minikube e una Minimal API in .NET.

Indice dei contenuti – LLM Kubernetes su Minikube

1. Cosa sono gli LLM e perché integrarli con Kubernetes

2. Prerequisiti e setup dell’ambiente

3. Avviare Minikube con risorse adeguate

4. Deployare Ollama su Minikube

5. Costruire la Minimal API .NET come agente orchestratore

6. JSON Prompting e deserializzazione C#

7. Operazioni Kubernetes in linguaggio naturale: esempi pratici

8. Best practice, pro e contro

9. Conclusioni e formazione continua

1. Cosa sono gli LLM e perché integrarli con Kubernetes

Un Large Language Model (LLM) è un modello di intelligenza artificiale addestrato su enormi quantità di testo, capace di comprendere e generare linguaggio naturale con un’accuratezza sorprendente. Strumenti come Llama 3.1, Mistral e Gemma 3 sono oggi disponibili gratuitamente e girano in locale grazie a runtime come Ollama.

Kubernetes, d’altra parte, è lo standard de facto per l’orchestrazione di container in produzione. Gestire un cluster Kubernetes, anche solo in sviluppo, richiede la conoscenza di decine di comandi kubectl, manifest YAML e concetti come Deployment, Pod, Service e Namespace.

L’idea alla base di questo progetto è semplice quanto potente: lasciare che un LLM traduca il linguaggio naturale in azioni reali su Kubernetes. Scrivi “scala il deployment a 5 repliche” e l’agente lo fa davvero. Nessuna Cloud API, nessun costo per token: tutto gira in locale sul tuo hardware.

Nel 2026 il caso per eseguire LLM in locale è più forte che mai: un modello Llama 3.1 8B su Ollama costa esattamente 0€ per token, gira completamente offline e mantiene ogni byte di dati sul tuo hardware.

2. Prerequisiti e setup dell’ambiente – LLM Kubernetes su Minikube

Prima di iniziare, assicurati di avere installato e funzionante:

  • Minikube
  • kubectl — client CLI per Kubernetes
  • Ollama — runtime locale per LLM open-source (versione 0.13.x+)
  • .NET 8 SDK o superiore — per la Minimal API
  • Docker — driver consigliato per Minikube su Linux/Mac

Secondo la documentazione ufficiale di Minikube, i requisiti minimi di sistema sono: almeno 2 CPU, 2 GB di RAM libera e 20 GB di spazio su disco. Per i workload LLM, questi valori vanno alzati significativamente.

3. Avviare Minikube con risorse adeguate

I modelli LLM sono workload intensivi. Per questa ragione è necessario avviare Minikube con risorse generose — almeno 4 CPU e 8 GB di RAM. Esegui:

minikube start --cpus=4 --memory=8192 --nodes=3

Questo crea un cluster a 3 nodi, distribuendo il carico in modo più realistico. Verifica che i nodi siano attivi:

kubectl get nodes

L’output atteso sarà simile a:

NAME            STATUS   ROLES           AGE   VERSION

minikube        Ready    control-plane   1m    v1.32.x

minikube-m02    Ready    <none>          1m    v1.32.x

minikube-m03    Ready    <none>          1m    v1.32.x

Come consiglia TheLinuxCode nel suo Minikube Playbook 2026, in ambienti Linux è preferibile il driver Docker per la sua velocità di avvio e facilità di integrazione con le immagini locali.

4. Deployare Ollama su Minikube

Ollama è disponibile come immagine container ufficiale. Creiamo prima il namespace dedicato, poi il Deployment e il Service:

kubectl create namespace ollama

Ecco il manifest YAML completo per il Deployment con PersistentVolumeClaim (così i modelli non vengono persi al riavvio del Pod):

apiVersion: apps/v1

kind: Deployment

metadata:

  name: ollama

  namespace: ollama

spec:

  replicas: 1

  selector:

    matchLabels:

      app: ollama

  template:

    metadata:

      labels:

        app: ollama

    spec:

      containers:

      - name: ollama

        image: ollama/ollama:latest

        ports:

        - containerPort: 11434

        resources:

          requests:

            memory: "4Gi"

            cpu: "2"

          limits:

            memory: "8Gi"

            cpu: "4"

Applica il manifest e crea anche il Service ClusterIP sulla porta 11434:

kubectl apply -f ollama-deployment.yaml

Una volta che il Pod è Running, accedi al container e scarica il modello scelto — in questo caso llama3.2 (~2 GB):

kubectl exec -it -n ollama <nome-pod> -- ollama pull llama3.2

Puoi verificare il funzionamento dell’API REST con un port-forward e una chiamata curl:

kubectl port-forward svc/ollama -n ollama 11434:11434

curl http://localhost:11434/api/generate \

  -d '{"model": "llama3.2", "prompt": "Cosa fa un Deployment Kubernetes?", "stream": false}'

5. Costruire la Minimal API .NET come agente orchestratore

Il cuore dell’architettura è una Minimal API .NET che funge da agente: riceve richieste in linguaggio naturale, le invia all’LLM, interpreta la risposta e la traduce in chiamate all’API di Kubernetes.

Crea il progetto:

dotnet new webapi -n KubernetesLlmAgent --use-minimal-apis

cd KubernetesLlmAgent

dotnet add package KubernetesClient

Struttura base del Program.cs con il service di Ollama registrato nel Dependency Injection container:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHttpClient<IOllamaService, OllamaService>(c => {

    c.BaseAddress = new Uri("http://localhost:11434");

});

builder.Services.AddSingleton<IKubernetesService, KubernetesService>();

var app = builder.Build();

app.MapPost("/agent", async (AgentRequest req,

    IOllamaService ollama, IKubernetesService k8s) => {

    var instruction = await ollama.TranslateAsync(req.Prompt);

    var result = await k8s.ExecuteAsync(instruction);

    return Results.Ok(result);

});

app.Run();

6. JSON Prompting e deserializzazione C#

Una delle sfide principali nell’integrazione LLM-Kubernetes è ottenere risposte strutturate e affidabili dall’LLM. La tecnica del JSON Prompting consiste nell’istruire esplicitamente il modello a rispondere solo con JSON valido, facilmente deserializzabile.

Esempio di system prompt efficace:

Sei un assistente Kubernetes. Rispondi SOLO con un oggetto JSON valido con questa struttura:

{

  "action": "scale" | "get_pods" | "get_logs",

  "namespace": "<namespace>",

  "deployment": "<nome deployment>",

  "replicas": <numero>

}

Non aggiungere testo prima o dopo il JSON.

In C#, la deserializzazione è diretta:

var json = await ollamaResponse.Content.ReadAsStringAsync();

var instruction = JsonSerializer.Deserialize<K8sInstruction>(json,

    new JsonSerializerOptions { PropertyNameCaseInsensitive = true });

7. Operazioni Kubernetes in linguaggio naturale: esempi pratici – LLM Kubernetes su Minikube

Ecco i tre casi d’uso principali implementati nel progetto di Giovanni Pace:

7.1 Creare un Deployment

Input utente: “Crea un deployment nginx con 2 repliche nel namespace default”

L’agente invia il prompt all’LLM, ottiene il JSON con i parametri, e usa KubernetesClient per applicare il Deployment via API server. Zero kubectl, zero YAML scritto a mano.

7.2 Scalare le repliche

Input utente: “Porta il deployment web-app a 5 repliche”

// KubernetesService.ScaleAsync

var patch = new V1Scale {

    Spec = new V1ScaleSpec { Replicas = instruction.Replicas }

};

await _client.ReplaceNamespacedDeploymentScaleAsync(

    patch, instruction.Deployment, instruction.Namespace);

7.3 Leggere i log di un Pod

Input utente: “Mostrami i log del pod crashed-pod-xyz nel namespace staging”

L’agente identifica il Pod corretto tramite l’LLM e richiama ReadNamespacedPodLogAsync, restituendo i log direttamente all’utente. Particolarmente utile in contesti di troubleshooting rapido.

Come dimostrato su Kubezilla, l’API REST di Ollama è compatibile anche con lo standard OpenAI, permettendo di riutilizzare librerie client esistenti.

8. Best practice, pro e contro

Pro

  • Privacy e sicurezza totale: i dati non escono mai dalla macchina locale, fondamentale per ambienti con dati sensibili o NDA
  • Costo zero per token: nessuna chiamata API fatturata, ideale per team che sviluppano e iterano su prompt in modo intensivo
  • Portabilità: l’intero stack gira su qualsiasi laptop con 8+ GB di RAM, senza dipendere da Internet o da account cloud
  • Flessibilità dei modelli: Ollama supporta decine di modelli (Llama 3.x, Mistral, Gemma 3, Qwen3) intercambiabili senza modificare il codice
  • Curva di apprendimento produttiva: lavorare localmente permette di sperimentare liberamente con prompt e logica senza costi o rischi

Contro

  • Consumo di risorse elevato: i modelli LLM richiedono almeno 4-8 GB di RAM dedicati, su macchine con poca memoria le prestazioni degradano sensibilmente
  • Latenza superiore rispetto al cloud: senza GPU dedicata, l’inferenza su CPU è più lenta rispetto alle API cloud ottimizzate
  • Gestione della sicurezza K8s a carico dello sviluppatore: come evidenziato da Cloudsmith (feb. 2026), l’LLM non deve avere accesso illimitato al cluster, serve un layer di policy che validi le istruzioni prima dell’esecuzione
  • Dimensione dei modelli: scaricare modelli da 2-8 GB richiede storage e banda adeguati; modelli > 13B necessitano di 16+ GB di RAM
  • Affidabilità del JSON Prompting: i modelli più piccoli possono occasionalmente produrre JSON malformato, è indispensabile implementare validazione e retry logic

Best practice operative

  • Valida sempre il JSON restituito dall’LLM prima di passarlo al client Kubernetes
  • Usa un namespace dedicato per Ollama e limita i permessi RBAC dell’agente al minimo necessario
  • Implementa un rate limiter e un audit log per tracciare le operazioni eseguite dall’agente
  • Per ambienti multi-modello, considera l’Ollama Operator per Kubernetes (GitHub: nekomeowww/ollama-operator) che gestisce modelli come risorse CRD native
  • In produzione, usa PersistentVolumeClaim per i modelli: eviterai di ri-scaricare gigabyte a ogni riavvio del Pod

9. Conclusioni: formazione continua nell’era dell’AI generativa

L’integrazione tra LLM e Kubernetes rappresenta uno dei fronti più interessanti dell’ingegneria del software nel 2026. La possibilità di controllare un cluster Kubernetes in linguaggio naturale, senza dover ricordare ogni parametro kubectl, senza dipendere da API cloud costose, cambia concretamente il modo in cui i team DevOps lavorano ogni giorno.

Quello che abbiamo spiegato sopra dimostra che tutto ciò non è fantascienza: con strumenti open-source come Ollama e Minikube, e un po’ di .NET, uno sviluppatore con media esperienza può costruire un agente funzionante in poche ore.

Il mercato dello sviluppo software è però in continua e rapida evoluzione: nuovi modelli LLM vengono rilasciati ogni mese, Kubernetes si aggiorna regolarmente, e le best practice di sicurezza per i sistemi AI cambiano di pari passo con le nuove minacce. In questo scenario, l’unico modo per mantenere il proprio team realmente competitivo è investire nella formazione continua dei propri sviluppatori. Non basta leggere articoli: serve pratica guidata, esempi concreti e aggiornamento costante.

Per questo motivo ti consigliamo due percorsi formativi specifici disponibili su Innovaformazione:

  • Corso Sviluppo applicazioni LLM: progettato per sviluppatori che vogliono passare dalla teoria alla pratica nella costruzione di applicazioni basate su Large Language Models, con esempi reali, architetture agentiche e integrazione con API.
  • Corsi AI Generativa: un catalogo completo di percorsi sull’intelligenza artificiale generativa: dal prompt engineering all’AI applicata allo sviluppo software, pensato per sviluppatori e ingegneri informatici che vogliono restare aggiornati.

Tutti i percorsi Innovaformazione sono erogabili anche tramite Fondimpresa, il fondo paritetico interprofessionale per la formazione continua dei dipendenti delle aziende aderenti a Confindustria. Questo significa che la tua azienda può finanziare la formazione dei propri sviluppatori senza costi diretti, attingendo al conto formazione aziendale o tramite piani formativi condivisi. È un’opportunità concreta che molte aziende non sfruttano ancora appieno.

Vuoi saperne di più? Contattaci per informazioni e un preventivo personalizzato:

Email: info@innovaformazione.net

Telefono: 347 101 2275 — Dario Carrassi

Sito: innovaformazione.net

Per altri articoli tecnici consigliamo di navigare sul nostro blog QUI.

(fonte) (fonte) (fonte) (fonte)

Ti potrebbe interessare

Articoli correlati