Categoria: PaaS i contenidors
Kubernetes gestionat en el vostre proveïdor: EKS, GKE, AKS, Hetzner o servidors propis
El vostre clúster de Kubernetes, en el proveïdor que ja feu servir, amb algú que l'actualitza a temps, sap restaurar-lo i vigila el que costa.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
En resum
Kubernetes gestionat, en el nostre cas, és l'administració del vostre clúster de Kubernetes al vostre propi compte: EKS, GKE, AKS, DOKS, OVH, Hetzner o servidors propis. Ens ocupem de les actualitzacions de versió i de nodes, els add-ons, l'ingress i els certificats, l'autoescalat, el desplegament per GitOps, l'observabilitat, les còpies amb Velero i la seua restauració provada, els costos i la seguretat.
De què ens encarreguem en el vostre clúster?
Un clúster de Kubernetes no s’acaba el dia que es crea. Cada pocs mesos hi ha versió nova, els add-ons caduquen, els certificats es renoven i la despesa creix sense que ningú ho decidisca. Això és el que mantenim:
Versions i nodes
Actualitzem el pla de control, renovem els grups de nodes i retirem les API que desapareixen abans que trenquen un desplegament.
Add-ons
CNI, CSI, CoreDNS, metrics-server, cert-manager i el controlador d’ingress, en versions compatibles amb el clúster.
Ingress i certificats
Entrada de trànsit, certificats que es renoven sols i registres DNS gestionats des del clúster.
Autoescalat
HPA per als pods i Cluster Autoscaler o Karpenter per als nodes, amb peticions de recursos realistes.
GitOps
Argo CD o Flux: cada canvi entra pel repositori i es pot revertir.
Observabilitat
Prometheus, Grafana i registres centralitzats, amb alertes que porten el seu runbook.
Còpies
Velero amb els recursos i els volums fora del clúster, i una restauració que hem provat.
Costos
Ajust de la mida de nodes i càrregues, neteja de recursos orfes i revisió del trànsit d’eixida.
Seguretat
RBAC, polítiques de xarxa i admissió de pods, que detallem en el bastionatge de Kubernetes.
Pla de control gestionat o clúster propi?
La primera decisió és qui manté l’API i etcd. En EKS, GKE, AKS, DOKS i OVH ho fa el proveïdor; amb k3s, Talos o kubeadm a Hetzner o en els vostres servidors, ho fem nosaltres. Si us interessa Hetzner en concret, ho expliquem a Kubernetes a Hetzner. Cap opció no és millor en abstracte:
| Criteri | Pla de control gestionat (EKS, GKE, AKS, DOKS, OVH) | Autogestionat (k3s, Talos, kubeadm a Hetzner o en servidors propis) |
|---|---|---|
| Qui manté l’API i etcd | El proveïdor | Nosaltres, amb còpies d’etcd i alta disponibilitat |
| Cost d’infraestructura | Més alt, sobretot en trànsit i serveis afegits | Més baix, amb més feina d’operació |
| Integració amb el núvol | Profunda: identitats, balancejadors, volums | La que donen el CCM i el CSI del proveïdor, o cap en servidors propis |
| Ritme de versions | El marca el calendari de suport del proveïdor | El marqueu vosaltres, sense deixar-lo caducar |
| Quan el recomanem | Ja sou en aquest núvol, o necessiteu els seus serveis gestionats | Càrregues estables, cost ajustat o dades que s’han de quedar en les vostres màquines |
Quins problemes trobem en heretar un clúster?
- Versions a la deriva: el pla de control en una versió, els nodes dues per darrere i els add-ons sense tocar des que es van instal·lar.
- Actualitzacions ajornades: ningú no s’atreveix a actualitzar perquè l’última vegada es va trencar alguna cosa, i el clúster s’acosta a la fi del suport.
- Despesa que creix sola: nodes grans mig buits, entorns de prova encesos de nit i volums de pods que ja no existeixen.
- Sense runbooks: les alertes sonen, però no hi ha escrit què cal fer, i només una persona sap com es va muntar.
- Còpies sense provar: Velero instal·lat, però ningú no ha restaurat mai un espai de noms complet.
- Canvis a mà: el que hi ha en el clúster ja no coincideix amb el repositori.
Com fem una actualització de versió?
Kubernetes només admet una diferència limitada de versions entre l’API i els kubelets dels nodes, i el pla de control es puja d’una versió menor en una versió menor. Per això treballem sempre amb el mateix procediment:
Revisió
Busquem les API obsoletes que fan servir els vostres manifests i charts, i comprovem quina versió de cada add-on admet la versió de destí.
Assaig
Actualitzem primer un clúster de proves o de preproducció amb les mateixes càrregues.
Pla de control
Pugem una versió menor, i només una, en la finestra acordada amb vosaltres.
Nodes
Renovem els grups de nodes buidant-los d’un en un, respectant els pressupostos d’interrupció de cada aplicació.
Comprovació
Revisem alertes, desplegaments i certificats, i deixem anotat què ha canviat i què queda per a la següent.
Com sabem que les còpies serveixen?
Una còpia de Kubernetes que no s’ha restaurat mai és una suposició. Configurem Velero perquè guarde els recursos i els volums en un emmagatzematge d’objectes d’un altre compte o d’un altre proveïdor, i cada cert temps restaurem un espai de noms complet en un clúster a part per a comprovar que les aplicacions arrenquen amb les seues dades. Les bases de dades amb moltes dades les preferim amb el seu propi sistema de còpies, com expliquem en PostgreSQL gestionat.
I si volem canviar de proveïdor?
Moure un clúster entre EKS, GKE, AKS o un altre proveïdor és sobretot una feina d’inventari. El que cal traduir són les peces pròpies de cada núvol: classes d’emmagatzematge, anotacions dels balancejadors, identitats de les càrregues, secrets i bases de dades gestionades. Amb el clúster en GitOps, el nou s’alça en paral·lel des del mateix repositori, les dades es mouen amb Velero o amb replicació i el trànsit canvia servei a servei. Abans de començar comparem costos amb les vostres factures reals en migracions i costos cloud.
Com és el suport dia a dia?
Cada mes rebeu un informe amb versions, incidències, despesa i l’última restauració de prova. Si busqueu alguna cosa més àmplia que el clúster, ho integrem en l’SRE com a servei.
On ho muntem?
Al vostre compte, al proveïdor que ja feu servir o al que encaixe millor. Si les dades s'han de quedar a la UE, Hetzner i OVHcloud són les opcions europees.
Proveïdors on ho muntem
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Hetzner
- Servidor propi
| Proveïdor | Com ho muntem | A tindre en compte |
|---|---|---|
| AWS | EKS amb grups de nodes gestionats o Karpenter, AWS Load Balancer Controller, EBS CSI i permisos per pod amb IAM. | Les versions d'EKS tenen data de fi del suport estàndard; passada aquesta data, el suport ampliat es cobra a part. |
| Google Cloud | GKE Standard o Autopilot, amb el canal de versions triat i finestres de manteniment definides. | Google actualitza el pla de control pel seu compte: l'important és que el canal i les finestres encaixen amb els vostres desplegaments. |
| Azure | AKS amb grups de nodes de sistema i d'usuari, actualització automàtica configurada i identitat de càrregues amb Microsoft Entra ID. | Convé separar els grups de nodes per a poder renovar els d'aplicació sense tocar els de sistema. |
| DigitalOcean | DOKS amb autoescalat de nodes, balancejadors i volums de DigitalOcean. | |
| OVH | Managed Kubernetes Service d'OVHcloud, amb nodes de Public Cloud i emmagatzematge en bloc. | |
| Hetzner | Sense Kubernetes gestionat: muntem el pla de control amb k3s, Talos o kubeadm, integrat amb els balancejadors i volums de Hetzner. | Menys cost d'infraestructura a canvi d'operar també el pla de control. |
| Servidor propi | k3s, Talos o kubeadm en els vostres servidors o en màquines virtuals, amb balancejador i emmagatzematge propis. | El maquinari, la xarxa i l'emmagatzematge persistent passen a formar part de la feina. |
Què inclou
- Inventari del clúster: versió, add-ons, càrregues, permisos i el que no està en codi.
- Calendari d'actualitzacions de Kubernetes, dels nodes i dels add-ons, sense saltar-se versions menors.
- Ingress, certificats automàtics i DNS extern revisats i al repositori.
- Autoescalat de pods i de nodes amb peticions i límits ajustats al consum real.
- Desplegament per GitOps amb Argo CD o Flux, amb l'estat del clúster a Git.
- Mètriques, registres i alertes del clúster i de les aplicacions, amb runbooks per a cada alerta.
- Còpies amb Velero fora del clúster i una restauració de prova documentada.
- Revisió de costos: nodes sobredimensionats, volums orfes, balancejadors oblidats i trànsit.
Preguntes freqüents
Si ja paguem EKS, GKE o AKS, què ens queda per gestionar?
Quasi tot el que no és el pla de control: els nodes, els add-ons, l'ingress, els certificats, les còpies, els permisos, les alertes i la despesa. El proveïdor manté l'API i etcd; el que corre al damunt continua sent vostre.
Cada quant cal actualitzar Kubernetes?
Kubernetes publica una versió menor aproximadament cada quatre mesos i manté pegats per a les tres més recents. A la pràctica, un clúster de producció necessita una actualització planificada dues o tres vegades l'any per a no quedar-se fora de suport.
Treballeu al nostre compte o al vostre?
Al vostre. El clúster, la facturació i el codi són vostres; hi entrem amb accessos nominals que podeu revocar. Si un dia deixem de treballar junts, tot continua funcionant i està documentat.
Val la pena Kubernetes per al nostre equip?
Si teniu poques aplicacions i ningú que l'opere, sovint no. Un PaaS autoallotjat o uns servidors ben gestionats cobreixen molts casos amb menys peces. Us ho diem abans de muntar res.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Documentació oficial consultada
Les dades tècniques d'aquesta pàgina es basen en:
- Kubernetes: política de diferència de versions entre components (Version Skew Policy)
- Velero: referència de restauració (documentació oficial)
Revisat el