{"id":2219,"date":"2026-06-09T10:37:44","date_gmt":"2026-06-09T08:37:44","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/plesk-kubernetes-gpu-sharing-resource-quotas-cost-attribution-2026\/"},"modified":"2026-06-09T10:37:44","modified_gmt":"2026-06-09T08:37:44","slug":"plesk-kubernetes-gpu-sharing-resource-quotas-cost-attribution-2026","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/plesk-kubernetes-gpu-sharing-resource-quotas-cost-attribution-2026\/","title":{"rendered":"Plesk Kubernetes Integration e Container Orchestration 2026: La Mia Guida GPU Sharing, Resource Quotas Multi-Tenant e Cost Attribution su Cluster Distribuiti"},"content":{"rendered":"

In questa guida tecnica vi mostro come implementare Plesk<\/strong> con Kubernetes<\/strong> per gestire carichi AI moderni su infrastrutture distribuite. Nel mio ruolo di System Administrator, ho dovuto affrontare una sfida crescente: come massimizzare l’utilizzo delle GPU costose in ambienti multi-tenant senza compromettere l’isolamento tra i clienti?<\/p>\n

Il 2026 ha portato una vera trasformazione nell’orchestrazione dei container. Plesk ha iniziato a supportare meglio i carichi AI-native<\/a>, ma coordinare questo con Kubernetes introduce complessit\u00e0: GPU sharing, resource quotas dinamiche e attribuzione dei costi su cluster ibridi. Vi condivido le soluzioni testate in produzione.<\/p>\n

Perch\u00e9 Plesk + Kubernetes per AI Workloads?<\/h2>\n

Plesk tradizionalmente eccelle nella gestione semplificata dei VPS e delle applicazioni web. Con l’hardening delle API<\/a>, Plesk pu\u00f2 ora orchestrare container complessi mantenendo controllo centralizzato. Kubernetes, dal canto suo, offre l’orchestrazione di cui hanno bisogno i carichi AI moderni.<\/p>\n

All’inizio la combinazione non funzionava perch\u00e9 Plesk non espone nativamente i controller di Kubernetes. La soluzione? Usare Plesk come control plane di gestione, con Kubernetes come strato di orchestrazione sottostante. I carichi agentic AI richiedono isolamento rigoroso<\/a>, e questa architettura lo garantisce.<\/p>\n

GPU Sharing: MIG e Time-Slicing nel Mio Setup<\/h2>\n

La sfida principale: le GPU sono costose e spesso sottoutilizzate. In un dataset di cluster, la media di utilizzo GPU \u00e8 del 5%, con un gap fino a 10x rispetto a una configurazione ottimale<\/cite>. Con clienti multi-tenant, non posso permettere che un singolo workload blocchi un’intera A100 o H100.<\/p>\n

Ho implementato due strategie:<\/strong><\/p>\n

1. Multi-Instance GPU (MIG)<\/h3>\n

MIG partisce una GPU fisica in istanze isolate con compute cores e memoria dedicati; con un singolo GPU si possono eseguire fino a 7 workload indipendentemente<\/cite>. Nel mio ambiente Kubernetes su Plesk, ho configurato MIG per workload di inference AI multi-tenant.<\/p>\n

Ecco il manifest YAML che uso:<\/p>\n

apiVersion: v1\nkind: Pod\nmetadata:\n  name: inference-tenant-a\n  namespace: tenant-a\nspec:\n  containers:\n  - name: llm-inference\n    image: nvidia\/cuda:12.2-runtime\n    resources:\n      limits:\n        nvidia.com\/gpu: \"1\"  # Richiede un'istanza MIG GPU\n      requests:\n        nvidia.com\/gpu: \"1\"\n    env:\n    - name: NVIDIA_DRIVER_CAPABILITIES\n      value: \"compute,utility\"\n    - name: NVIDIA_VISIBLE_DEVICES\n      value: \"GPU-4a5b6c7d\"  # Identificativo dell'istanza MIG\n<\/code><\/pre>\n
MIG garantisce isolamento hardware totale: se un tenant ha un OOM kill, non impatta i pod nel MIG slice adiacente. Perfetto per clienti enterprise che non tollerano “noisy neighbor”.<\/p>\n
2. GPU Time-Slicing<\/h3>\n
GPU time-slicing usa l’NVIDIA GPU Operator per creare repliche logiche di un dispositivo; l’attivit\u00e0 su ogni replica esegue sulla stessa GPU fisica, con il tempo di compute diviso equamente<\/cite>. \u00c8 ideale per training leggeri o workload batch dove l’isolamento assoluto non \u00e8 critico.<\/p>\n
L’ho configurato cos\u00ec nel mio cluster:<\/p>\n
# Installo NVIDIA GPU Operator\nhelm repo add nvidia https:\/\/helm.nvidia.com\/nvidia\nhelm install gpu-operator nvidia\/gpu-operator \n  --namespace gpu-operator-system \n  --create-namespace\n\n# Configuro time-slicing nel ConfigMap del cluster policy\nkubectl patch clusterpolicy cluster-policy \n  -n gpu-operator-system \n  --type merge \n  -p '{\"spec\":{\"driver\":{\"enabled\":true},\"toolkit\":{\"enabled\":true},\"devicePlugin\":{\"config\":{\"any\":{\"replicas\":4}}}}}'\n<\/code><\/pre>\n
Con 4 repliche, uno stesso GPU serve 4 pod contemporaneamente. Il trade-off? Context switching pi\u00f9 frequente e latenza leggermente superiore, ma il costo operativo scende del 70% nel mio scenario.<\/p>\n
Resource Quotas Multi-Tenant: Evitare il “Noisy Neighbor”<\/h2>\n
Avevo un cliente che, durante un training incauto di una rete neurale, ha esaurito tutta la memoria disponibile. Senza resource quotas, ci\u00f2 avrebbe affamato 20 altri clienti. Resource quotas impediscono a un tenant di consumare tutte le risorse del cluster, impostando limiti su CPU, memoria e numero di pod per namespace<\/cite>.<\/p>\n
Ecco come ho configurato le quote per Plesk\/Kubernetes:<\/strong><\/p>\n
apiVersion: v1\nkind: Namespace\nmetadata:\n  name: tenant-premium\n  labels:\n    tenant-tier: premium\n---\napiVersion: v1\nkind: ResourceQuota\nmetadata:\n  name: premium-quota\n  namespace: tenant-premium\nspec:\n  hard:\n    # Limiti di compute\n    requests.cpu: \"32\"\n    limits.cpu: \"64\"\n    requests.memory: \"256Gi\"\n    limits.memory: \"512Gi\"\n    \n    # Limiti GPU\n    requests.nvidia.com\/gpu: \"4\"\n    limits.nvidia.com\/gpu: \"8\"\n    \n    # Limiti di oggetti\n    pods: \"500\"\n    services: \"50\"\n    persistentvolumeclaims: \"20\"\n    secrets: \"100\"\n    configmaps: \"100\"\n    \n    # Limiti su risorse costose\n    services.loadbalancers: \"2\"\n    services.nodeports: \"5\"\n---\napiVersion: v1\nkind: LimitRange\nmetadata:\n  name: premium-limits\n  namespace: tenant-premium\nspec:\n  limits:\n  - type: Pod\n    max:\n      cpu: \"16\"\n      memory: \"64Gi\"\n      nvidia.com\/gpu: \"2\"\n    min:\n      cpu: \"100m\"\n      memory: \"128Mi\"\n      nvidia.com\/gpu: \"0\"  # GPU opzionale\n  - type: Container\n    default:\n      cpu: \"500m\"\n      memory: \"512Mi\"\n    request:\n      cpu: \"250m\"\n      memory: \"256Mi\"\n<\/code><\/pre>\n
In questo setup:<\/p>\n