BYOC (Bring Your Own Cloud) è il modello di hosting del 2026 che stavo aspettando. Nella mia esperienza di sysadmin, ho visto troppe organizzazioni intrappolate nei servizi proprietari di AWS o Azure, pagando il prezzo della dipendenza dal vendor. Quando ho iniziato a esplorare il deployment di WordPress su Kubernetes gestito autonomamente, però, ho scoperto un’alternativa che cambia il gioco: deployare WordPress su infrastruttura che controlli davvero, con costi trasparenti e la libertà di migrare quando vuoi.
Questo articolo è il risultato di sei mesi di test su EKS, AKS e piattaforme BYOC come Northflank e Porter. Ti mostro come ho configurato WordPress su Kubernetes nei tuoi account AWS/Azure, mantenendo totale autonomia operativa senza sacrificare scalabilità o affidabilità.
Perché BYOC Kubernetes per WordPress nel 2026?
La domanda che mi vengono posta spesso è: “Dario, perché complicarsi la vita con Kubernetes quando Plesk gestisce tutto?” La risposta è sfumata. Kubernetes non è per tutti, ma per chi ha necessità di:
- Multi-tenant scalability – diversi siti WordPress su unica infrastruttura, isolati per sicurezza
- Cost optimization cross-cloud – sfruttare reserved instances AWS, spot instances, managed databases Azure senza lock-in
- Infrastructure-as-Code governance – versionare l’intera config via Git, audit trail completo
- Escape hatch da vendor lock-in – migrare tra provider mantenendo lo stesso stack
Vendor lock-in inflates multi-cloud costs by 20–30% through proprietary APIs, egress fees, and retraining overhead. Con BYOC Kubernetes, quei costi spariscono perché il tuo stack gira su Kubernetes conformant, non su Lambda, DynamoDB o servizi proprietari.
BYOC vs Managed Kubernetes: La Differenza Fondamentale
Ho perso settimane a confondere i termini. Ecco la chiarezza che mi è servita:
- Managed Kubernetes (EKS, AKS) – AWS/Azure gestisce il control plane, tu gestisci i nodi. Facile all’inizio, ma bloccato nel loro ecosistema.
- BYOC Kubernetes – Una piattaforma (Northflank, Porter, DevPanel) deploya il control plane e lo stack completo inside your AWS/Azure account, in VPC che controlli. Tu mantengo l’infrastruttura, loro l’orchestration layer.
In a true BYOC architecture, the vendor manages the control plane (the UI and orchestration), but the data plane is completely embedded inside your corporate cloud account (AWS, Azure, DigitalOcean). Questo significa: nessun vendor access ai tuoi dati, nessuna trasmissione cross-account, full audit trail nel tuo cloud.
Architettura Reference: WordPress su BYOC Kubernetes 2026
La mia configurazione di produzione usa questa stack:
- Compute: EKS cluster (3 nodi t3.medium on-demand + 5 spot nodes) o AKS (Standard tier, KEDA for HPA)
- Container Registry: ECR (AWS) o ACR (Azure) – immagini WordPress custom via Buildpacks
- Database: RDS MySQL Managed (AWS) o Azure Database for MySQL Flexible – NOT inside K8s (PersistentVolume MySQL in K8s è un disastro in production)
- Storage: EFS (AWS) o Azure Files via NFS CSI – persistent volumes per wp-content, uploads
- Secrets: AWS Secrets Manager (IRSA pod auth) o Azure Key Vault (workload identity) – zero credentials in YAML
- Ingress: ALB Controller (AWS) / Application Gateway (Azure) – L7 routing, WAF, SSL termination
- Observability: Prometheus + Grafana (self-hosted) o CloudWatch/Monitor nativo
La ragione per managed database esterno è critica: ho imparato sulla pelle che StatefulSet MySQL + PersistentVolumeClaim dentro K8s è bellissimo in linea di principio, ma in production regala incubi su backups, failover, replica lag. Con backup immutable e point-in-time recovery gestiti dal provider, dormi meglio.
Step-by-Step: Deployment WordPress su EKS con Terraform + Helm
1. Provisioning Cluster EKS via Terraform
Primo file: eks_cluster.tf
terraform
resource “aws_eks_cluster” “wordpress_cluster” {
name = “wordpress-prod-cluster”
role_arn = aws_iam_role.eks_cluster_role.arn
version = “1.30”
vpc_config {
subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_b.id]
endpoint_private_access = true
endpoint_public_access = true
public_access_cidrs = [“0.0.0.0/0”] # ristretto in prod
}
enabled_cluster_log_types = [“api”, “audit”, “authenticator”, “controllerManager”, “scheduler”]
tags = {
Environment = “production”
ManagedBy = “Terraform”
}
}
resource “aws_eks_node_group” “wordpress_on_demand” {
cluster_name = aws_eks_cluster.wordpress_cluster.name
node_group_name = “wordpress-on-demand”
node_role_arn = aws_iam_role.eks_node_role.arn
subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_b.id]
scaling_config {
desired_size = 3
max_size = 5
min_size = 1
}
instance_types = [“t3.medium”]
disk_size = 50
labels = {
Environment = “production”
WorkloadType = “web”
}
tags = {
Name = “wordpress-nodes”
}
}
Una volta up, verifico cluster status:
aws eks describe-cluster --name wordpress-prod-cluster --region eu-west-1
2. Installare ALB Ingress Controller
Critical: senza ALB controller, i tuoi WordPress pods restano inaccessibili. Helm chart semplifica:
helm repo add eks https://aws.github.io/eks-charts
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=wordpress-prod-cluster --set serviceAccount.create=true
Verifica con: kubectl get deployment -n kube-system | grep alb
3. Helm Chart WordPress + MySQL
Non scrivo YAML da zero – uso Bitnami WordPress Helm chart (aggiornato gennaio 2026):
helm repo add bitnami https://charts.bitnami.com/bitnami
helm pull bitnami/wordpress --untar
Il file values personalizzato (values-prod.yaml):
yaml
replicaCount: 3
image:
repository: bitnami/wordpress
tag: "6.4.3" # sempre fissa una versione stabile
pullPolicy: IfNotPresent
service:
type: ClusterIP # l'ALB controller farà da ingress
port: 8080
ingress:
enabled: true
className: "alb"
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
cert-manager.io/cluster-issuer: "letsencrypt-prod"
hosts:
- host: tuosite.com
paths:
- path: /
pathType: Prefix
tls:
- secretName: wordpress-tls
hosts:
- tuosite.com
externalDatabase:
type: mysql
host: "wp-db.c5f2k8j.eu-west-1.rds.amazonaws.com" # RDS endpoint
user: wpuser
password: "" # da AWS Secrets Manager
persistence:
enabled: true
size: 50Gi
storageClassName: efs-sc # definisci uno storage class EFS
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "1Gi"
cpu: "500m"
autoscaling:
enabled: true
minReplicas: 3
maxReplicas: 10
targetCPUUtilizationPercentage: 70
Deploy:
helm install wordpress bitnami/wordpress -f values-prod.yaml -n wordpress --create-namespace
4. Gestire Secrets Sicuri con AWS Secrets Manager + IRSA
Non voglio credenziali DB in valori Helm. AWS Secrets Manager + IAM Roles for Service Accounts (IRSA) è la pattern corretta.
Crea il secret:
aws secretsmanager create-secret --name wordpress-db-password --secret-string '{"username":"wpuser","password":"SuperSecure123!"}' --region eu-west-1
Poi crea una ServiceAccount con IAM role:
yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: wordpress-sa
namespace: wordpress
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/wordpress-secrets-role
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress
namespace: wordpress
spec:
template:
spec:
serviceAccountName: wordpress-sa
containers:
- name: wordpress
env:
- name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: wordpress-db-secret
key: password
La ragione per cui evito WORDPRESS_DB_PASSWORD in plaintext: l’audit log di Kubernetes cattura ogni variabile d’ambiente. Con Secrets Manager + IRSA, nessun secret transita in etcd.
Cost Optimization: Come Ho Ridotto la Spesa del 35%
Quando ho avviato il primo cluster, la fattura era terribile: €1.200/mese per 3 siti WordPress. Ecco cosa ho fatto:
1. Rightsizing Pod Requests/Limits
Errore iniziale: requests: 1CPU, 1Gi RAM per ogni WordPress pod. Risultato: 3 nodi t3.large in perpetuo.
Ho installato Kubecost, il più adottato open-source Kubernetes cost monitoring tool, spesso usato come entry point per Kubernetes FinOps. Rivelazione shock: ogni pod usava in media 80mCPU, 250Mi RAM. Ho aggiornato:
requests:
memory: "256Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "250m"
Risultato: 3 nodi t3.medium bastano (€120/mese vs €240/mese).
2. Spot Instances per Non-Critical Workloads
Spot instances remain one of the most powerful ways to cut compute cost in 2026, especially for stateless, interruptible, or queue-driven workloads. They can slash costs materially, but they demand architecture discipline. The winning pattern is to use spot selectively, not everywhere.
Ho creato un secondo node group spot (t3a.large): WordPress è stateless? Sì. Posso tollerare 2 minuti di downtime su failover? Sì. Quindi:
terraform
resource "aws_eks_node_group" "wordpress_spot" {
cluster_name = aws_eks_cluster.wordpress_cluster.name
node_group_name = "wordpress-spot"
node_role_arn = aws_iam_role.eks_node_role.arn
subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_b.id]
scaling_config {
desired_size = 2
max_size = 4
min_size = 0
}
instance_types = ["t3a.large", "t3.large", "m5.large"] # diversifica per evitare tutte interrotte insieme
capacity_type = "SPOT"
taints = [
{
key = "spot"
value = "true"
effect = "NoSchedule"
}
labels = {
WorkloadType = "spot"
}
tags = {
Name = "wordpress-spot-nodes"
}
}
E nel Helm chart, tolero il taint:
yaml
tolerations:
- key: "spot"
operator: "Equal"
value: "true"
effect: "NoSchedule"
nodeSelector:
WorkloadType: "spot"
Risultato: spot instances costano ~€0.05/ora vs €0.10/ora on-demand. Con 2 nodi spot, risparmio €70/mese.
3. Consolidare il Multi-Tenant su Namespaces
Gestire 3 siti WordPress separati con 3 cluster è costoso. Invece:
- Namespace
wordpress-client-a(3 replicas) - Namespace
wordpress-client-b(2 replicas) - Namespace
wordpress-staging(1 replica, auto-scale a 0 di notte)
ResourceQuota impedisce overallocation:
yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: client-a-quota
namespace: wordpress-client-a
spec:
hard:
requests.memory: "2Gi"
requests.cpu: "2"
pods: "10"
Con questa segregazione, il team A non può crashare il sito del team B. Costa uguale, ma è isolato.
Migrare da Managed Kubernetes a BYOC: La Strategia
Se sei già su EKS standard e vuoi usare BYOC (es. Northflank), ecco il mio playbook di migrazione (ho testato su 2 cluster production):
Fase 1: Preparazione (1 settimana)
- Export delle Helm charts attuali:
helm get values wordpress -n wordpress > current-values.yaml - Backup DB:
mysqldump -u wpuser -p wordpress > backup.sql(esportato su S3) - Verifica dei Persistent Volumes: quali dati inside cluster, quali external
Fase 2: Setup Nuovo Environment (1 settimana)
- Se scegli BYOC via Northflank, connetti il tuo account AWS/Azure alla loro UI
- Loro provisionano il control plane nel tuo VPC (in una subnet dedicata)
- Tu resti con full access via kubectl
Fase 3: Deploy via Helm su BYOC (2-3 giorni)
Esatto stesso Helm chart di prima. Niente cambia a livello di applicazione:
helm install wordpress bitnami/wordpress -f values-prod.yaml -n wordpress --create-namespace --kubeconfig ~/.kube/byoc-config
Fase 4: Migrate dei Dati (1-2 giorni)
- Restaura DB da backup:
mysql -u wpuser -p wordpress < backup.sql - Sync wp-content via rsync/s3sync in EFS nuovo (via bastion pod)
- Test: apri il sito, verifica media, login, plugin
Fase 5: DNS Cutover + Monitoring (1 giorno)
- Update DNS A record a nuovo ALB IP
- Monitora 48h: latency, error rates, database connections
- Se tutto stabile: decommission cluster vecchio
Tempo totale: 10-14 giorni. Downtime: 15 minuti (cutover DNS).
Errori che Ho Fatto (e Tu Puoi Evitare)
Errore 1: PersistentVolume MySQL Inside K8s
All’inizio, ho deployato MySQL StatefulSet dentro Kubernetes. Disastro. Quando il nodo falliva, il PVC entrava in Terminating loop. Ho perso 4 ore a pulire Finalizers. Lezione: stateful services outside K8s. RDS/Azure Database cost poco in più e ti salva dal trauma.
Errore 2: Non Monitorare i Costi In Tempo Reale
Quando lanciato il primo staging cluster, l’ho dimenticato online per 3 mesi. Fattura: €340. Con Kubecost + Slack alerts, adesso sono avvertito se spending supera budget.
Errore 3: Assumere Che Ogni Pod Necessiti HA
Ho deployato WordPress con replicas: 5 ‘per sicurezza’. Con multi-cloud load-balancing tra EKS/AKS, però, 3 pod-replica è il sweet spot. Oltre, è spreco.
FAQ
BYOC Kubernetes è la scelta giusta per il mio WordPress?
BYOC Kubernetes ha senso se: (1) gestisci 5+ siti WordPress, (2) hai team DevOps interno, (3) vuoi portabilità cross-cloud, (4) compliance richiede data residency nel tuo account. Se hai un sito, Plesk o managed hosting è più semplice. Se hai 50 siti, Kubernetes è obbligatorio.
EKS vs AKS per WordPress? Quale scegliere?
With Azure Kubernetes Service (AKS), Microsoft takes care of the control plane for you. You do not pay for it separately, and getting a basic cluster running does not take long. For teams that are just getting started with managed Kubernetes or want to move fast, that matters. Se sei on Azure con Active Directory, AKS è naturale. Se sei on AWS con IAM, EKS. Se no lock-in: BYOC con Northflank elimina la scelta.
Come evito il vendor lock-in con BYOC?
Standardize on Kubernetes, Terraform, and open data formats (Parquet, PostgreSQL) for portability. Use abstraction layers like Crossplane and service meshes to isolate cloud-specific code. Praticamente: usa PostgreSQL, non DynamoDB. Helm charts, non AWS CloudFormation. Prometheus, non CloudWatch native. Se devi migrare da AWS ad Azure, il tuo Helm chart gira uguale.
Quanto costa deployare WordPress su BYOC Kubernetes?
Base case (3 siti, 3 nodi t3.medium + 2 spot): ~€280/mese compute + €150/mese managed DB + €50/mese storage + €60/mese data transfer = €540/mese infrastructure. Più fees di piattaforma BYOC (Northflank ~€300/mese base). Total: ~€840/mese per 3 siti production-grade, multi-tenant, auto-scaling. Singolo sito managed hosting? €50-100/mese. Conclusion: non è cheap, ma per scale grande (10+ siti) è ROI positivo.
Posso migrare dal mio Plesk su VPS a BYOC Kubernetes?
Sì, ma richiede un reboot architetturale. Plesk gestisce la configurazione di sistema (PHP, SSL, backups). Su Kubernetes, tutto deve essere declarative (Helm, YAML, Secrets). Se hai competenze DevOps, la migration è fattibile (2-3 settimane per site). Se non hai tempo, resta su Plesk e aggiungi Kubernetes solo per new greenfield projects.
Quali tools di monitoring consigli per Kubernetes WordPress?
Stack di base: Prometheus (metriche K8s) + Grafana (visualization) + Loki (log aggregation). Commerciale: Datadog (everything-in-one, costoso). Open-source: Kubecost, now an IBM company, is a Kubernetes-native cost monitoring and optimization tool that provides real-time visibility into cloud spending. It helps teams monitor, allocate, and optimize their Kubernetes expenses across clusters and cloud providers. Io uso Prometheus + Grafana + Kubecost: setup una volta, poi auto-scale in base a SLA.
Conclusione: WordPress su BYOC Kubernetes 2026 È Maturo
Quando ho iniziato con Kubernetes nel 2020, era Wild West – documentazione sparsa, tool instabili, DevOps stress costante. Nel 2026, il panorama è stabile. BYOC into AWS / GCP / Azure with no markup on the underlying compute, build pipelines, preview environments, jobs and workflows, GPU support, addons (Postgres, Redis, etc.) è realtà operativa.
La mia raccomandazione finale: se gestisci WordPress enterprise-scale, riduci costi del 20-30%, evita vendor lock-in, e vuoi infrastruttura che porti con te se cambi provider – BYOC Kubernetes è ora il percorso giusto. Non è facile come Plesk, ma una volta setup, è indistruttibile.
Leggi anche la mia guida su Sovereign Cloud vs Hyperscaler se stai valutando data residency per compliance. E se stai ottimizzando AI workload on Kubernetes, non perderti Plesk Automation Framework per AI orchestration.
Domande? Condividi i tuoi setup BYOC nei commenti – amo sentire come altri sistemisti affrontano container orchestration in production.