Gestire risorse AWS con kubectl: quando ha senso ACK

Hai un cluster Kubernetes in produzione. Deployment, CRD, controller, il ciclo GitOps già rodato. Poi devi creare una tabella DynamoDB, o un bucket S3, e finisci in un secondo mondo: Terraform, o la console AWS, o CloudFormation. State separato, pipeline separata, competenze diverse per lo stesso team.

Qui entra in gioco AWS Controllers for Kubernetes (ACK), che prova a chiudere questo scarto: risorse AWS gestite con lo stesso modello dichiarativo, gli stessi manifest, lo stesso kubectl apply che usi già per il resto.

Come funziona ACK

ACK installa, per ogni servizio AWS che vuoi gestire, un controller e un set di CRD. Vuoi una tabella DynamoDB? Applichi una risorsa Table nel namespace che preferisci. Il controller legge lo spec, chiama l’API AWS per creare la tabella reale, e scrive lo stato osservato (ARN, stato di sincronizzazione, eventuali errori) in status.conditions sullo stesso oggetto.

apiVersion: dynamodb.services.k8s.aws/v1alpha1
kind: Table
metadata:
  name: orders
spec:
  tableName: orders
  attributeDefinitions:
    - attributeName: id
      attributeType: S
  keySchema:
    - attributeName: id
      keyType: HASH
  billingMode: PAY_PER_REQUEST

Nessuna sintassi nuova da imparare, nessun tool aggiuntivo nella pipeline: è YAML Kubernetes, punto.

Il reconcile loop non è specifico di Kubernetes

La parte concettualmente interessante non è ACK in sé, è il meccanismo sotto: il reconcile loop. Il controller osserva continuamente lo stato desiderato (lo spec che hai applicato) contro lo stato reale (quello che AWS riporta), e corregge la differenza. Se qualcuno cancella la tabella a mano dalla console, alla prossima reconciliation il controller la ricrea. Se cambi lo spec, il controller propaga la modifica.

È lo stesso pattern che usi già per un Deployment: non dici a Kubernetes “crea tre pod”, dici “voglio che esistano tre pod di questo tipo”, e qualcosa continua a verificarlo nel tempo. ACK applica lo stesso modello a un dominio diverso: non pod e servizi, ma tabelle DynamoDB e bucket S3. Il control plane di Kubernetes diventa un control plane generico per qualsiasi risorsa che qualcuno ha scritto un controller a reconciliare, dentro o fuori dal cluster.

Quando ha senso

Ha senso se il team vive già dentro Kubernetes e vuole un solo modello mentale, un solo strumento di audit (kubectl get, kubectl describe), una sola pipeline GitOps per applicazione e infrastruttura collegata. Ha senso se le risorse AWS create sono legate al ciclo di vita di un’applicazione che gira nello stesso cluster: un bucket per un servizio, una coda per un altro, provisionati e distrutti insieme al namespace dell’app.

Non ha senso se l’infrastruttura AWS è ampia, condivisa tra molti team, e già gestita bene con Terraform: a quel punto non si risolve un problema, lo si sposta su uno strumento diverso, con lo state ora distribuito su CRD invece che centralizzato in un backend Terraform. E non ha senso se il team non lavora già con Kubernetes: introdurre un cluster solo per gestire risorse AWS è una complessità enorme per un beneficio che Terraform offre già, senza il costo operativo di un control plane in più da mantenere.

ACK non sostituisce l’Infrastructure as Code. È un’opzione in più, buona per una forma specifica di team e di architettura, non un default.

Documentazione e repository del progetto: https://github.com/aws-controllers-k8s