Com implementar microserveis amb Docker i Kubernetes

En els últims anys, la combinació de microserveis, Docker i Kubernetes sha convertit en lestàndard de facto per desplegar aplicacions modernes, escalables i fàcils de mantenir. Cada cop més empreses estan deixant enrere les aplicacions monolítiques per apostar per arquitectures distribuïdes que s'adapten millor a entorns canviants ia estratègies DevOps.

Si et preguntes com implementar microserveis amb Docker i Kubernetes a la pràctica, aquest contingut et vindrà com a anell al dit: repassarem els conceptes clau, els avantatges i desafiaments, com crear contenidors, com orquestrar-los en un clúster i quins passos seguir per instal·lar-los a Windows y Linux, a més d'una sèrie de consells per fer-los servir amb cap en entorns reals.

Què és una arquitectura de microserveis i en què es diferencia d'un monòlit

Una arquitectura de microserveis es basa en dividir una aplicació en múltiples serveis petits, autònoms i desplegables de forma independent, cadascun centrat en una funcionalitat concreta (usuaris, pagaments, catàleg, comandes, etc.), que es comuniquen principalment mitjançant APIs lleugeres (HTTP/REST, gRPC, missatgeria, etc.).

En una aplicació monolítica, en canvi, tota la lògica de negoci, la capa de presentació i l'accés a dades estan empaquetats en un únic bloc de desplegament; qualsevol canvi requereix recompilar, testejar i desplegar tot el sistema, cosa que complica l'evolució i eleva el risc d'introduir errors en producció.

Amb microserveis, cada servei disposa del seu propi cicle de vida: es pot desenvolupar, provar, desplegar, escalar i versionar de manera independent. Això permet que múltiples equips treballin en paral·lel, simplifiquen l'adopció de noves tecnologies i faciliten la integració amb pràctiques de CI/CD.

A més, aquesta arquitectura introdueix el concepte de escalabilitat independent per component: en lloc d'escalar tota una aplicació monolítica per suportar més càrrega en un mòdul concret, només s'escalen els microserveis que realment ho necessiten, optimitzant millor els recursos d'infraestructura.

Avantatges i desafiaments reals dels microserveis

Passar a microserveis no és només una moda: aporta beneficis tangibles en escalabilitat, resiliència i velocitat de desplegament, però també introdueix una complexitat operativa que cal saber gestionar.

Entre els avantatges més destacats hi ha la escalabilitat independent de cada servei: si, per exemple, el mòdul de pagaments rep més trànsit que el d'administració, podeu incrementar únicament les rèpliques del microservei de pagaments, sense tocar la resta de l'aplicació ni desaprofitar recursos.

També es guanya molt a desplegament continu i lliuraments freqüents. En aïllar cada servei, és possible alliberar noves versions de manera incremental, sense haver de parar ni tornar a desplegar tota l'aplicació, reduint finestres de manteniment i millorant el time-to-market.

Un altre punt clau és la resiliència i tolerància a fallades: quan es dissenya correctament, la caiguda d'un microservei no hauria de tombar completament el sistema. Amb patrons com timeouts, reintents i circuit breakers, la resta de serveis poden continuar responent, limitant l'impacte dels errors.

A més, els microserveis permeten flexibilitat tecnològica: cada equip pot triar el llenguatge, framework o base de dades més apropiat per al seu servei, sempre que respecti els contractes de comunicació i les polítiques globals de la plataforma.

A la cara B de la moneda trobem la complexitat operativa i d'observabilitat. Gestionar dotzenes o centenars de serveis implica bregar amb xarxes distribuïdes, traces entre serveis, logging centralitzat, seguretat, versionat d'APIs i consistència de dades, cosa que exigeix ​​eines avançades i processos madurs.

També es complica la gestió de la comunicació entre serveis: cal dissenyar bé com s'intercanvien dades, com es gestionen les fallades, com es manegen latències i com s'evita que una dependència lenta arrossegui la resta del sistema. Les proves i la depuració deixen de ser trivials, perquè no es testeja un únic bloc, sinó un conjunt de serveis interconnectats.

Contenidors: la base per executar microserveis de forma aïllada

La tecnologia de contenidors ha esdevingut el suport ideal per a microserveis perquè permet empaquetar una aplicació i totes les seves dependències en una unitat estandarditzada i portable. En lloc d'instal·lar llibreries, runtimes i eines a cada servidor, tot viatja dins del contenidor.

Un contenidor és, en essència, una forma lleugera de virtualització a nivell de sistema operatiu: comparteix el nucli del host però executa processos en espais de noms aïllats (namespaces) i amb recursos limitats per cgroups, cosa que fa que arrenquin ràpid i consumeixin menys que una màquina virtual.

Entre les seves propietats clau destaquen el aïllament, la portabilitat, la lleugeresa i la modularitat; cada microservei executant-se al seu propi contenidor es torna més fàcil de desplegar, parar, actualitzar o replicar, encaixant de meravella amb els principis de les arquitectures distribuïdes.

Comparats amb les màquines virtuals per a producció, els contenidors no necessiten un sistema operatiu complet per instància, sinó que comparteixen el del host. Això redueix dràsticament la mida de les imatges i el temps de arrencada, permetent aixecar o destruir contenidors en segons.

Docker: la plataforma de referència per contenir microserveis

Docker és l'eina més popular per treballar amb contenidors, perquè facilita la creació, l'empaquetatge, la distribució i l'execució d'aplicacions contenidoritzades tant en entorns de desenvolupament com en proves i producció.

La seva idea central és empaquetar el programari a imatges Docker, que són artefactes immutables que inclouen el codi de l'aplicació, les llibreries que necessita, eines del sistema i configuracions bàsiques. A partir d'aquestes imatges es creen contenidors en execució, que són instàncies aïllades basades en aquesta imatge.

La construcció d'imatges es defineix en un Dockerfile, un fitxer de text on s'indiquen instruccions com la imatge base, el directori de treball, quins fitxers copiar, quines dependències instal·lar, quins ports exposar i quina comanda llançar en iniciar el contenidor.

Imagina que tens una API escrita a Node.js. Podries crear un Dockerfile similar al següent, on es parteix d'una imatge oficial de Node, es copien els fitxers, s'instal·len les dependències i es defineix l'ordre d'arrencada:

FROM node:14
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD

Aquest fitxer indica que l'aplicació s'executarà al directori /app dins del contenidor, que s'instal·laran les dependències amb npm, que s'exposarà el port 3000 i que, en arrencar el contenidor, s'executarà NPM start.

Per construir i llançar aquest contenidor, només caldria executar des de la carpeta del projecte construcció docker i després corredera, mapejant els ports per poder accedir des del host, o per a aplicacions multicontenidor usa docker-compose:

docker build -t mi-app .
docker run -p 3000:3000 mi-app

Gràcies a aquest model, el clàssic problema de “a la meva màquina funciona” es redueix al mínim, perquè l'entorn d'execució viatja amb l'aplicació. A més, Docker s'integra molt bé amb sistemes de CI/CD, registres privats i eines d'orquestració com Kubernetes.

Components clau a Docker i el seu paper en microserveis

En un desplegament típic, parlem d'un Docker Host, que és el sistema (físic o virtual) on s'instal·la Docker; sobre ell corre el docker cerca, el dimoni que gestiona imatges, xarxes, volums i el cicle de vida dels contenidors.

Els contenidors contenen la aplicació i les seves dependències empaquetades en una imatge, de manera que qualsevol servidor amb Docker pot executar aquesta imatge de manera consistent. Aquesta consistència és crucial quan es tenen molts microserveis desplegats en diversos entorns (desenvolupament, QA, producció, etc.).

Entre els avantatges més interessants de Docker hi ha la portabilitat entre entorns, l'automatització de desplegaments, la modularitat de processos i el suport per a capes i control de versions a les imatges, el que facilita revertir canvis i optimitzar el emmagatzematge.

Kubernetes: l'orquestrador per governar centenars de contenidors

Quan passes d'uns quants contenidors a dotzenes o centenars d'ells, administrar-los a mà es converteix en una bogeria. Aquí entra en joc Kubernetes, una plataforma open source dissenyada per orquestrar contenidors a gran escala.

Kubernetes automatitza tasques crítiques com el desplegament, l'escalat, la recuperació davant de fallades, la configuració de xarxa i l'emmagatzematge de les aplicacions contenidoritzades. Està pensat per funcionar en núvols públics, privats, entorns híbrids i fins i tot on-premises.

El seu focus és gestionar clústers compostos per diversos nodes (màquines) on s'executen els contenidors. Lobjectiu és garantir que les aplicacions estiguin sempre a l'estat desitjat: nombre de rèpliques, versions desplegades, recursos assignats i connectivitat entre serveis.

Elements fonamentals de Kubernetes

La unitat més petita a Kubernetes és el Beina, que representa una o més instàncies de contenidors que s'han d'executar juntes (per exemple, un contenidor d'aplicació i un de sidecar per a logging). Els Pods són efímers: es creen, destrueixen i reemplacen segons les necessitats del clúster.

Per exposar els teus Pods, Kubernetes ofereix el recurs servei, que actua com a capa d'abstracció de xarxa. Un Service agrupa un conjunt de Pods i proporciona una IP estable, un nom DNS i balanceig de càrrega intern, de manera que els clients no necessiten conèixer els detalls de cada Pod.

El recurs Desplegament s'utilitza per definir com s'han de desplegar i actualitzar els Pods: quantes rèpliques, quina imatge fer servir, quines etiquetes aplicar i quina estratègia d'actualització seguir. Kubernetes s'encarrega de mantenir sempre el número desitjat de Pods en execució i de realitzar rolling updates o rollbacks quan canvies la configuració.

També hi ha recursos com ConfigMap i Secret, que permeten externalitzar la configuració i emmagatzemar dades sensibles (contrasenyes, tokens, claus API) sense haver d'empaquetar-les dins de les imatges. Això facilita molt la gestió segura de la configuració a diferents entorns.

Com s'organitza un clúster de Kubernetes

El “cap” del clúster és el Control Plane de Kubernetes, que agrupa diversos components responsables d'orquestrar tot el sistema. Entre ells hi ha el API Server, que és la porta d'entrada per administrar el clúster; qualsevol acció (crear un Deployment, llistar Pods, modificar un Service) passa per aquesta API.

El Programador s'encarrega de decidir a quin node s'executa cada Pod, tenint en compte recursos disponibles, afinitats i restriccions; mentre que el Gestor del controlador vigila l'estat del clúster i llança accions perquè la realitat coincideixi amb el que has declarat als manifestos (per exemple, crear nous Pods si n'hi ha menys dels que has demanat).

L'emmagatzematge de l'estat es delega a etc., una base de dades distribuïda que desa la configuració i la informació de tots els recursos del clúster. D'altra banda, a cada node treballador s'executen processos com el kubelet (agent que comunica el node amb l'API Server), el kube-proxy (que gestiona el trànsit de xarxa i el balanceig) i el runtime de contenidors (Docker, containerd, CRI-O, etc.).

Desplegament de microserveis a Kubernetes amb arxius YAML

Per desplegar un microservei a Kubernetes, el més habitual és descriure'l amb un manifest YAML, on defineixes el Deployment (plantilla de Pods, imatge, ports, nombre de rèpliques, etiquetes) i el Service corresponent per exposar-lo dins o fora del clúster.

Un exemple bàsic de Deployment per a una aplicació anomenada “mi-app” podria ser una cosa així, on es defineixen tres rèpliques i el port 3000 com a port del contenidor:

apiVersion: apps/v1
kind: Deployment
metadata:
name: mi-app
spec:
replicas: 3
selector:
matchLabels:
app: mi-app
template:
metadata:
labels:
app: mi-app
spec:
containers:
- name: mi-app
image: mi-app:latest
ports:
- containerPort: 3000

Aquest manifest indica que el clúster ha de mantenir tres Pods en execució amb la imatge “el meu-app:latest”, tots etiquetats amb app=el meu-app, de manera que un Service pugui localitzar-los i distribuir trànsit entre ells. La lògica d'escalat, actualitzacions i substitució de Pods en cas de fallada la gestiona Kubernetes automàticament.

Al costat dels Deployments és habitual definir Serveis de tipus ClusterIP, NodePort o LoadBalancer, segons si el microservei ha de ser accessible només dins del clúster, des dels nodes o des d'Internet. Tota aquesta configuració es versiona en repositoris, integrant-se naturalment amb pipelins de CI/CD.

Escalat, actualitzacions i autoreparació a Kubernetes

Un dels grans motius per utilitzar Kubernetes és la seva capacitat per escalar i actualitzar microserveis sense aturar l'aplicació. Pots canviar el nombre de rèpliques al manifest (o amb una ordre de kubectl) i el clúster s'encarregarà de crear o eliminar Pods fins a assolir el valor desitjat.

Aquest escalat pot ser manual o automàtic, usant recursos com el Horitzontal Pod Autoscaler (HPA), que ajusta dinàmicament les rèpliques en funció de mètriques com CPU o memòria. Així, en moments d'alta demanda, s'incrementa la capacitat i quan baixa la càrrega s'alliberen recursos.

Pel que fa a les actualitzacions, Kubernetes implementa rolling updates per defecte: va creant Pods amb la nova versió i eliminant els de l'anterior de manera progressiva, sense fer un tall brusc. Si alguna cosa surt malament, un retrocés us permet recuperar ràpidament la versió prèvia.

Una altra funcionalitat crítica és la autoreparació: si un contenidor o un Pod mor, Kubernetes ho recrea automàticament; si un node deixa de respondre, els Pods afectes es reprogramen en altres nodes disponibles, mantenint laplicació operativa.

Monitorització i observabilitat de microserveis a Kubernetes

Per operar correctament un entorn de microserveis, no n'hi ha prou amb desplegar i escalar: necessites visibilitat en temps real del rendiment i de l'estat dels serveis. A Kubernetes és molt habitual integrar eines com Prometheus per recopilar mètriques i Grafana per visualitzar-les.

Prometheus s'encarrega de “raspar” mètriques dels Pods, nodes i components del clúster, emmagatzemar-les i permetre definir alertes sobre elles; combinat amb Grafana, pots crear panells on vigilar consum de CPU, memòria, errors HTTP, latències, nombre de rèpliques o estat dels nodes de manera molt clara.

A més, kubectl ofereix ordres per inspeccionar l'estat de Deployments, Services, Pods i altres recursos, veure logs, descriure esdeveniments o accedir a contenidors per depurar. Tot això forma part d'una estratègia d'observabilitat que, a microserveis, no és opcional si vols dormir tranquil.

Relació entre microserveis, Docker i Kubernetes

Microserveis, Docker i Kubernetes encaixen com a peces d'un mateix puzle: larquitectura de microserveis defineix com dissenyes laplicació, Docker sencarrega de empaquetar i executar cada servei i Kubernetes orquestra tots aquests contenidors en un clúster.

Cada microservei s'encapsula a una imatge de Docker que inclou el vostre codi i dependències, el que garanteix que es comporti igual al portàtil del desenvolupador, en un entorn de proves o en producció al núvol. Aquest empaquetat uniforme és vital per a la filosofia DevOps.

Per la seva banda, Kubernetes actua com orquestrador de contenidors: decideix quantes instàncies de cada microservei han d'estar corrent, on s'ubiquen, com es balanceja el trànsit cap a elles, com es recuperen davant de fallades i com escalen quan augmenta o disminueix la demanda.

En una aplicació d'e-commerce, per exemple, podries tenir microserveis d'autenticació, catàleg, carret i pagaments, cadascun amb la seva imatge Docker i el seu Deployment a Kubernetes. D'aquesta manera, pots escalar el catàleg en campanyes massives o els pagaments en moments crítics sense tocar la resta, i orquestrar el seu cicle de vida complet des de pipelins de CI/CD fins al monitoratge post-producció.

Instal·lació de Docker i Kubernetes a Windows

Si treballes amb Windows, la manera més còmoda de començar és instal·lar escriptori docker, que inclou el motor de Docker i eines addicionals, i fins i tot opcions per habilitar Kubernetes integrat a la teva màquina.

El procés típic passa per descarregar Docker Desktop des de la web oficial, executar l'instal·lador (Docker Desktop Installer.exe) i seguir l'assistent. Durant la instal·lació, es pot triar entre utilitzar Hyper-V o WSL 2 com a tecnologia de virtualització; si només n'hi ha una de disponible, és la que s'usarà.

Després del reinici del sistema, en obrir Docker Desktop s'inicialitza l'entorn de contenidors; si la virtualització no estava activada, el mateix instal·lador sol oferir habilitar-la automàticament. A partir d'aquí podeu llançar contenidors, per exemple, de Nginx o de les vostres pròpies aplicacions.

Per utilitzar Kubernetes a Windows, és important comptar primer amb Docker i amb les capacitats de virtualització activades. Després, podeu habilitar Kubernetes des de Docker Desktop o bé instal·lar i configurar kubectl per gestionar clústers externs i, si escau, desplegar el dashboard de Kubernetes mitjançant un manifest remot.

Un cop configurat, podràs accedir al dashboard a través d'un servidor intermediari local, utilitzant un token d'autenticació generat amb kubectl i apuntant, per exemple, al fitxer de configuració .kube/config per gestionar l'accés al clúster des del navegador.

Instal·lació de Docker i Kubernetes a Linux

En sistemes Linux, com Ubuntu, la instal·lació de Docker sol ser força directa: els paquets s'actualitzen, s'instal·la el motor Docker i es comprova que l'entorn funciona correctament executant un contenidor de prova.

Els passos típics inclouen actualitzar el sistema amb apt-get update i apt-get upgrade, eliminar possibles versions prèvies de Docker Desktop si n'hi hagués i, a continuació, instal·lar docker-ce, docker-ce-cli, containerd.io i el plugin de docker-compose des dels repositoris oficials o especificant la versió desitjada.

Per verificar que tot està en ordre, sol llançar-se un contenidor de “hello-world” que descarrega una imatge mínima i l'executa. Si el missatge es mostra correctament, tens Docker operatiu per començar a contenir els teus microserveis.

Pel que fa a Kubernetes, a Linux es pot instal·lar utilitzant eines com kubeadm. El flux típic passa per afegir la clau del repositori de Kubernetes, configurar el fitxer de llista de paquets, instal·lar kubeadm i comprovar-ne la versió.

Després s'inicialitza el clúster al node mestre amb kubeadm init (indicant el rang de xarxa per als Pods), es recupera la comanda de join perquè els nodes treballadors s'uneixin al clúster i es configura l'accés local creant el directori $HOME/.kube, copiant l'admin.conf i ajustant els permisos.

Amb això, tindràs un clúster bàsic llest per desplegar microserveis contenidoritzats, instal·lar una xarxa de Pods (Flannel, Calico, etc.) i començar a treballar amb Deployments, Services i la resta de recursos de Kubernetes.

Bones pràctiques i recomanacions per fer servir Docker i Kubernetes

Per aprofitar al màxim aquests entorns, convé seguir una sèrie de bones pràctiques amb Docker, començant per utilitzar imatges oficials o de confiança, ja sigui des de Docker Hub o des de repositoris privats verificats, per reduir riscos de seguretat.

És molt recomanable optimitzar la mida de les imatges utilitzant imatges base lleugeres, multi-stage builds i eliminant arxius temporals o artefactes innecessaris. Imatges més petites es descarreguen més ràpid i agiliten els desplegaments a Kubernetes.

Un altre punt clau és utilitzar volums per a la persistència de dades, en lloc de guardar informació dins dels contenidors, de manera que la pèrdua o recreació d'un contenidor no impliqui perdre dades importants.

Limitar els recursos assignats a cada contenidor (CPU, memòria, I/O) ajuda a evitar que un únic servei acapari el host i degrade a la resta. A més, cal monitoritzar contenidors amb eines com docker stats o solucions més avançades per mantenir el control en producció.

Amb Kubernetes és essencial abans de saltar a producció. Dominar l'arquitectura del clúster i els seus components redueix molts mals de cap.

També és bona idea automatitzar al màxim: utilitzar controladors de replicació, autoscalers i Jobs per a càrregues batch; aprofitar les capacitats de rolling updates i rollbacks; i definir manifestos declaratius versionats en repositoris Git.

La seguretat ha d'estar sempre damunt la taula: restringir accessos a l'API Server, gestionar credencials mitjançant Secrets, xifrar dades en trànsit i en repòs, aplicar pegats amb regularitat i definir polítiques de xarxa que limitin la comunicació entre serveis segons el principi de mínim privilegi.

Finalment, és indispensable comptar amb bons sistemes de monitorització i logging centralitzat, així com amb entorns de preproducció on provar canvis de forma exhaustiva abans de portar-los al clúster de producció, reduint riscos i sorpreses desagradables.

Tot aquest ecosistema de microserveis, contenidors Docker i orquestració amb Kubernetes et permet construir sistemes molt més flexibles, escalables i resilients que els monòlits tradicionals; combinant una arquitectura ben pensada, eines adequades i bones pràctiques de DevOps, podeu desplegar aplicacions que s'adaptin sense problema als canvis de càrrega, que es recuperin de fallades amb rapidesa i que resultin més senzilles d'evolucionar al llarg del temps.