--- title: "Kubernetes per applicativi PHP: dal manifest all'autoscaling" description: "Mettere un applicativo PHP su Kubernetes: il manifest completo, lo scaling automatico dei pod, K3s per iniziare e i tre errori che si pagano in produzione." canonical: "https://www.mauriziofonte.it/blog/post/kubernetes-orchestrazione-container-vantaggi-azienda.html" author: "Maurizio Fonte" date: "2025-05-22T08:11:41+02:00" modified: "2026-04-14T17:48:55+02:00" section: "Container & Orchestration" tags: ["Container & Orchestration", "Consulenza IT"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) [Consulenza IT](https://www.mauriziofonte.it/blog/cat/consulenza_it.html) # [Kubernetes per applicativi PHP: dal manifest all'autoscaling](https://www.mauriziofonte.it/blog/post/kubernetes-orchestrazione-container-vantaggi-azienda.html) Giovedì 22 Mag 2025, alle 08:11 ![Kubernetes per applicativi PHP: dal manifest all'autoscaling](https://www.mauriziofonte.it/image/001240200-kubernetes-orchestrazione-container-vantaggi-azienda.jpg) In un progetto per un'azienda del settore servizi digitali, la piattaforma web gestiva picchi di traffico imprevedibili - campagne marketing che raddoppiavano le richieste in poche ore, poi settimane di traffico regolare. L'infrastruttura era un singolo server con Docker Compose: quando il traffico cresceva, l'unica opzione era fare upgrade manuale del server, operazione che richiedeva downtime e non era reversibile nei periodi di basso traffico. Dopo la migrazione a un cluster Kubernetes su tre nodi, la piattaforma scala automaticamente i pod PHP-FPM da 2 a 12 in base al carico, e riduce a 2 quando il traffico cala - il tutto senza intervento umano, senza downtime e con costi infrastrutturali proporzionali all'uso reale. ## Cos'è Kubernetes e quali primitive mette a disposizione [Kubernetes](https://kubernetes.io/) è una piattaforma open source per l'orchestrazione dei container: automatizza il deployment, lo scaling e la gestione delle applicazioni containerizzate su cluster di server. Originariamente sviluppato da Google e ora mantenuto dalla Cloud Native Computing Foundation (CNCF), Kubernetes è diventato lo standard de facto per l'infrastruttura cloud-native - il [CNCF Annual Survey 2024](https://www.cncf.io/reports/cncf-annual-survey-2024/) riporta che l'80% delle organizzazioni usa Kubernetes in produzione, con un ulteriore 13% in fase di piloting. Se la domanda che ti sei fatto è **se** adottare l'orchestrazione, la risposta non sta in questo articolo: l'ho scritta in [Kubernetes per PMI: quando ha senso e come iniziare senza bruciare il budget](https://www.mauriziofonte.it/blog/post/kubernetes-pmi-quando-ha-senso-come-iniziare-senza-bruciare-budget.html), dove il criterio è esplicito e la risposta più frequente è "non ancora". Qui la decisione è data per presa, e si vede come si mette in piedi la cosa. Docker Compose è sufficiente per applicativi con 1-5 servizi su un singolo server, senza necessità di auto-scaling o alta disponibilità. Kubernetes diventa necessario quando servono: scalabilità orizzontale automatica (aggiungere o rimuovere istanze in base al traffico), alta disponibilità multi-nodo (se un server muore, l'applicativo continua a funzionare sugli altri), rolling update a zero-downtime (aggiornamenti graduali senza interruzione del servizio), o gestione di più applicativi sullo stesso cluster con isolamento delle risorse. La [sicurezza dei container Docker](https://www.mauriziofonte.it/blog/post/docker-container-security-laravel-symfony-hardening-pmi-best-practices.html) resta fondamentale indipendentemente dalla scelta di orchestrazione. ## I concetti fondamentali di Kubernetes Per capire Kubernetes è necessario comprendere le sue primitive fondamentali, ciascuna con un ruolo specifico nell'architettura. Il **Pod** è l'unità base: uno o più container che condividono rete e storage. Per un applicativo PHP, un pod tipico contiene un container Nginx e un container PHP-FPM che comunicano via socket. Il **Deployment** dichiara lo stato desiderato - quanti replica di un pod devono essere attivi - e Kubernetes si occupa di mantenerlo: se un pod crasha, viene ricreato automaticamente. Il **Service** fornisce un endpoint di rete stabile per accedere ai pod, indipendentemente da quale nodo li ospita. L'**Ingress** gestisce il routing HTTP/HTTPS dall'esterno, con virtual host, TLS termination e path-based routing. I **ConfigMap** e i **Secret** esternalizzano la configurazione e le credenziali, separandole dal codice dell'applicativo. L'**HPA** (Horizontal Pod Autoscaler) è la primitiva che implementa lo scaling automatico: monitora metriche come CPU e memoria dei pod, e aggiunge o rimuove repliche per mantenere l'utilizzo entro soglie definite. Ecco una configurazione completa per un applicativo PHP: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: app-php spec: replicas: 2 selector: matchLabels: app: gestionale template: metadata: labels: app: gestionale spec: containers: - name: php-fpm image: registry.example.com/gestionale:1.4.2 resources: requests: cpu: 250m memory: 256Mi limits: cpu: 1000m memory: 512Mi envFrom: - configMapRef: name: app-config - secretRef: name: app-secrets readinessProbe: httpGet: path: /health port: 9000 initialDelaySeconds: 5 periodSeconds: 10 --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: app-php-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: app-php minReplicas: 2 maxReplicas: 12 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 ``` Questo manifest definisce un deployment con 2 repliche minime, un HPA che scala fino a 12 repliche quando l'utilizzo CPU medio supera il 70%, resource request e limit per garantire la schedulazione corretta, e un readiness probe che impedisce di inoltrare traffico a pod non ancora pronti. ## K3s: Kubernetes leggero per le PMI Kubernetes "full" richiede un'infrastruttura significativa per il control plane. [K3s](https://k3s.io/), sviluppato da SUSE (ex Rancher Labs), è una distribuzione Kubernetes certificata che riduce drasticamente la complessità operativa: un singolo binario sotto i 100MB, requisiti minimi di 512MB RAM e 1 CPU, installazione in 30 secondi, piena compatibilità con l'API Kubernetes standard. K3s usa SQLite come datastore di default (con opzione per etcd, MySQL o PostgreSQL), include Traefik come Ingress controller e CoreDNS, e supporta architetture ARM - perfetto per ambienti edge e single-node. Per una PMI che vuole i benefici dell'orchestrazione senza la complessità operativa di un cluster Kubernetes enterprise, K3s su tre VPS Hetzner (ad esempio 3× CX41 con 4 vCPU e 16GB RAM ciascuno, per circa 48 euro al mese totali) offre alta disponibilità, auto-scaling e rolling update a un costo infrastrutturale contenuto. Le alternative managed includono DigitalOcean Kubernetes (DOKS, control plane gratuito, nodi da 12 dollari/mese) e OVHcloud Managed Kubernetes (control plane gratuito con SLA 99.99%, senza costi di egress). ## Helm: il package manager che semplifica i deployment Gestire decine di manifest YAML per ogni applicativo è tedioso e soggetto a errori. [Helm](https://helm.sh/) è il package manager per Kubernetes: raggruppa tutti i manifest (Deployment, Service, ConfigMap, Secret, Ingress, HPA) in un chart versionato e parametrizzato. Un `helm install gestionale ./chart` deploya l'intero stack in un comando, con valori personalizzabili per ogni ambiente (staging, produzione). L'81% delle organizzazioni che usano Kubernetes adotta Helm, secondo il CNCF Survey 2024. ## Errori da evitare nell'adozione di Kubernetes L'errore più frequente che osservo nelle PMI è adottare Kubernetes quando Docker Compose sarebbe sufficiente. Kubernetes aggiunge complessità operativa reale - networking, storage, RBAC, monitoring del cluster - che ha senso solo se i benefici (scaling, HA, multi-tenancy) sono effettivamente necessari. Un gestionale con 50 utenti interni su un singolo server non ha bisogno di Kubernetes. Il secondo errore è non definire resource request e limit sui pod. Senza limit, un singolo pod con un memory leak può consumare tutta la RAM del nodo, causando l'eviction di altri pod. Senza request, lo scheduler non può distribuire i pod in modo efficiente sui nodi. Il terzo è trascurare la sicurezza del cluster: RBAC non configurato, Secret non crittografati, immagini non scannerizzate per vulnerabilità, pod che girano come root. La sicurezza in Kubernetes è un tema a sé - Network Policies, Pod Security Standards, e image scanning devono essere parte del setup iniziale, non un afterthought. Kubernetes non è una bacchetta magica - è uno strumento potente che risolve problemi specifici di scalabilità, disponibilità e gestione multi-applicativo. Per una PMI, la decisione corretta dipende dal contesto: Docker Compose per lo stack semplice, K3s per il primo passo verso l'orchestrazione, Kubernetes managed per la crescita strutturata. L'adozione di [tecnologie open source](https://www.mauriziofonte.it/blog/post/open-source-azienda-scelta-strategica-competitivita.html) e l'automazione del rilascio con [pipeline CI/CD](https://www.mauriziofonte.it/blog/post/cicd-automazione-rilascio-software-vantaggi-azienda.html) sono i prerequisiti naturali di questo percorso. Per conoscere il mio approccio e le competenze specifiche su infrastrutture cloud-native, visita [la mia pagina professionale](https://www.mauriziofonte.it/pages/about). Se stai valutando l'adozione di Kubernetes o vuoi ottimizzare un cluster esistente, [contattami per una consulenza dedicata](https://www.mauriziofonte.it/pages/contattami) - partiamo dall'analisi delle tue reali esigenze operative. Dall'articolo al lavoro vero Se questo server lo devi tenere in piedi tu Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino. [Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteCI/CD: come l'automazione del rilascio software accelera il tuo business e previene errori21 Mag 2025](https://www.mauriziofonte.it/blog/post/cicd-automazione-rilascio-software-vantaggi-azienda.html)[Articolo successivo »Hardening dei server: come proteggere la tua azienda da attacchi informatici devastanti22 Mag 2025](https://www.mauriziofonte.it/blog/post/hardening-server-protezione-attacchi-informatici.html) ### Articoli correlati a Kubernetes per applicativi PHP: dal manifest all'autoscaling - [Kubernetes su Hetzner Cloud: setup economico per startup e PMI italiane](https://www.mauriziofonte.it/blog/post/kubernetes-hetzner-cloud-setup-economico-startup-pmi.html) I managed Kubernetes dei grandi cloud presentano un conto a tre cifre al mese prima ancora che il primo container giri. Su Hetzner Cloud, con · 1 Ottobre 2025 ![Kubernetes su Hetzner Cloud: setup economico per startup e PMI italiane](https://www.mauriziofonte.it/image/002390070-kubernetes-hetzner-cloud-setup-economico-startup-pmi.jpg) - [Kubernetes per PMI: quando ha senso e come iniziare senza bruciare il budget](https://www.mauriziofonte.it/blog/post/kubernetes-pmi-quando-ha-senso-come-iniziare-senza-bruciare-budget.html) Kubernetes è potente e, per la maggior parte delle PMI, prematuro. Quando ha davvero senso adottarlo più team, scaling imprevedibile, deploy · 5 Agosto 2026 ![Kubernetes per PMI: quando ha senso e come iniziare senza bruciare il budget](https://www.mauriziofonte.it/image/005010070-kubernetes-pmi-quando-ha-senso-come-iniziare-senza-bruciare-budget.jpg) - [Digital Ocean Droplets per Laravel: sizing corretto e autoscaling senza Kubernetes](https://www.mauriziofonte.it/blog/post/digital-ocean-droplets-laravel-sizing-autoscaling-senza-kubernetes.html) Un'agenzia romana mi ha chiamato con un problema classico: il loro gestionale Laravel andava in palla ogni primo del mese per il picco di fatturazione. · 17 Settembre 2025 ![Digital Ocean Droplets per Laravel: sizing corretto e autoscaling senza Kubernetes](https://www.mauriziofonte.it/image/003290070-digital-ocean-droplets-laravel-sizing-autoscaling-senza-kubernetes.jpg) - [Aggiornamento automatico dei container Docker in produzione senza downtime](https://www.mauriziofonte.it/blog/post/aggiornamento-automatico-container-docker-produzione-zero-downtime.html) Il 60 degli incidenti di sicurezza che gestisco derivano da software non aggiornato. Ho implementato un sistema di aggiornamento automatico dei · 5 Gennaio 2026 ![Aggiornamento automatico dei container Docker in produzione senza downtime](https://www.mauriziofonte.it/image/002920070-aggiornamento-automatico-container-docker-produzione-zero-downtime.jpg) - [Service mesh con Istio per microservizi PHP: osservabilità e sicurezza senza codice applicativo](https://www.mauriziofonte.it/blog/post/service-mesh-istio-microservizi-php-osservabilita-sicurezza.html) Quando hai dieci microservizi che si parlano tra loro, la gestione della sicurezza e dell'osservabilità a livello applicativo diventa insostenibile. · 13 Febbraio 2026 ![Service mesh con Istio per microservizi PHP: osservabilità e sicurezza senza codice applicativo](https://www.mauriziofonte.it/image/002890070-service-mesh-istio-microservizi-php-osservabilita-sicurezza.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Kubernetes per applicativi PHP: dal manifest all'autoscaling", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/kubernetes-orchestrazione-container-vantaggi-azienda.html Pubblicato: 2025-05-22 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.