Kubernetes executa pods, que són grups de contenidors que sempre s'executen junts al mateix node i al mateix espai de noms.
Introducció
De la mateixa manera que Compose ens permet executar un grup de contenidors estretament relacionats, kubernetes utilitza pods.
La majoria de pods només tenen un contenidor, però un contenidor sempre s’ha d’executar dins d’un pod.
Minikube
Minikube és una eina que et permet utilitzar Kubernetes en un únic node per realitzar proves o com a entorn de desenvolupament.
Crea una màquina Linux i instal·la Docker
connect-wsl k8s -new
install-docker
Instal·la l’última versió estable de minikube utilitzant el paquet Debian:
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
sudo dpkg -i minikube_latest_amd64.deb
Configura minikube perquè tingui més “potència”:
$ minikube config set cpus 8
$ minikube config set memory 8096
$ minikube config view
- cpus: 8
- memory: 8096
Inicia el clúster:
$ minikube start
😄 minikube v1.35.0 on Ubuntu 24.04 (amd64)
✨ Automatically selected the docker driver. Other choices: none, ssh
❌ Exiting due to MK_USAGE: Docker has only 7777MB memory but you specified 8096MB
Com t’has excedit amb la memòria (potser no 😅), modifica la configuració corresponent:
~$ minikube config set memory 6144
❗ These changes will take effect upon a minikube delete and then a minikube start
Som-hi 🚀:
$ minikube start
😄 minikube v1.35.0 on Ubuntu 24.04 (amd64)
✨ Using the docker driver based on existing profile
👍 Starting "minikube" primary control-plane node in "minikube" cluster
...
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
Al principi, és possible que alguns serveis, com el proveïdor d’emmagatzematge, encara no estiguin en estat d’execució. Aquesta és una situació normal durant l’activació del clúster i es resoldrà per si sola en uns moments.
Comprova l’estat del clúster:
$ minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
Pots comprovar que estem utilitzant el driver docker:
$ minikube profile list
|----------|-----------|---------|--------------|------|---------|--------|-------|----------------|--------------------|
| Profile | VM Driver | Runtime | IP | Port | Version | Status | Nodes | Active Profile | Active Kubecontext |
|----------|-----------|---------|--------------|------|---------|--------|-------|----------------|--------------------|
| minikube | docker | docker | 192.168.49.2 | 8443 | v1.32.0 | OK | 1 | * | * |
|----------|-----------|---------|--------------|------|---------|--------|-------|----------------|--------------------|
Pots aturar el clúster amb la comanda stop
:
$ minikube stop
✋ Stopping node "minikube" ...
🛑 Powering off "minikube" via SSH ...
🛑 1 node stopped.
I també, pots esborrar el clúster amb la comanda delete
(no cal que ho provis 🙄):
$ minikube delete
🔥 Deleting "minikube" in docker ...
🔥 Deleting container "minikube" ...
🔥 Removing /home/box/.minikube/machines/minikube ...
💀 Removed all traces of the "minikube" cluster.
I si ets una mica curiós, hauries de ser-ho 🧐, pots entrar dins de la màquina virtual Minikube:
$ minikube ssh
En aquest cas és “docker”, però podria ser una màquina virtual de veritat.
$ minikube ssh
docker@minikube:~$ exit
logout
Com a administrador has de dominar el clúster des del shell, però a vegades és útil un entorn gràfic.
Obre un nou terminal, i executa:
$ minikube dashboard
🤔 Verifying dashboard health ...
🚀 Launching proxy ...
🤔 Verifying proxy health ...
🎉 Opening http://127.0.0.1:42919/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ in your default browser...
👉 http://127.0.0.1:42919/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/
Fes clic a l’enllaç que t’indica 👉.
Important El port és dinàmic, per tant, fes clic a l’enllaç del teu shell, no al de la documentació! 🫡
kubectl
Instal·la kubectl
:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
Habilita l’autocompletat de kubectl (et permet utilitzar la tecla tab per completar les comandes):
echo 'source <(kubectl completion bash)' >>~/.bashrc
source ~/.bashrc
Amb kubectl
pots controlar un clúster kubernetes mitjançant peticions REST al servidor API que s’executa al node “master”.
Per exemple, pots obtenir la informació del clúster:
$ kubectl cluster-info
Kubernetes control plane is running at https://127.0.0.1:32781
CoreDNS is running at https://127.0.0.1:32781/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Pots veure que el clúster està actiu i diferents URLs de diversos components de kubernetes.
A continuació mira quants nodes formen part del clúster:
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 28m v1.32.0
Com era d’esperar només hi ha un node, que és “minikube”.
Amb la comanda kubectl get
pots obtenir una llista de diferents tipus d’objectes “kubernetes” (en el nostre exemple has demanat una llista de tots els objectes de tipus “node”).
Si vols obtenir detalls addicionals d’un objecte pots utilitzar la comanda describe
amb el tipus d’objecte i nom de l’objecte.
Per exemple, obtén els detalls de l’objecte “minikube” de tipus “node”:
$ kubectl describe node minikube
Name: minikube
Roles: control-plane
...
La descripció mostra l’estat del node, les dades de CPU i memòria, informació del sistema, els contenidors que s’estan executant dins del node, i molta més informació.
Pod
La forma més habitual i senzilla és executar un pod amb un sol contenidor.
A continuació executa un pod amb un únic contenidor apache:
$ kubectl run apache --image=httpd
pod/apache created
Amb la comanda get
pots veure tots els pods que estan desplegats al clúster:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
apache 1/1 Running 0 17s
Si vols pots obtenir una descripció d’un contenidor amb la comanda describe
:
$ kubectl describe pod apache
...
IP: 10.244.0.13
IPs:
IP: 10.244.0.13
Containers:
apache:
Container ID: docker://ce53a65a3e96949e84ca92e7019eab5cbfdeff2ca0cfa7dff25c8718477b70b2
Image: httpd
Image ID: docker-pullable://httpd@sha256:437b9f7d469dd606fa6d2a5f9a3be55fe3af7e0c66e0329da8c14b291ae0d31c
Port: <none>
Host Port: <none>
State: Running
Started: Sat, 01 Feb 2025 22:19:29 +0100
Ready: True
...
Pots veure que el pod té la IP 10.244.0.13
i un contenidor “apache”.
També pots executar una comanda en un contenidor de la mateixa manera que ho fas amb docker:
$ kubectl exec apache -- ls htdocs
index.html
Com el pod només té un contenidor no cal especificar el contenidor, però si no fos així has d’especificar el contenidor amb l’argument : -c
$ kubectl exec apache -c apache -- ls htdocs
index.html
Executa bash al contenidor “apache” en un terminal interactiu:
$ kubectl exec -it apache -- bash
root@apache:/usr/local/apache2#
IP
La IP d’un pod és interna al clúster, la comparteixen tots els contenidors del pod, i canvia cada cop que es crea el pod.
Elimina el pod “apache” i torna a crear el pod:
$ kubectl delete pod apache
pod "apache" deleted
$ kubectl run apache --image=httpd
pod/apache created
Mira l’adreça IP del pod amb el flag : -o wide
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
apache 1/1 Running 0 5m28s 10.244.0.14 minikube <none> <none>
Si només vols l’adreça IP, pots utilitzar una “plantilla Go” per formatar la informació del Pod i retornar només l’adreça IP del Pod.
$ kubectl get pod nginx-w29j2 -o=jsonpath='{.status.podIP}'
10.244.0.14
Si executes curl
pots veure que no tens accés a aquesta IP:
$ curl -m 2 10.244.0.14
curl: (28) Connection timed out after 2037 milliseconds
Però si entres dins del clúster, tens accés al servidor “apache”:
$ minikube ssh
docker@minikube:~$ curl 10.244.0.14
<html><body><h1>It works!</h1></body></html>
docker@minikube:~$ exit
logout
Com hem explicat al principi, la IP és interna del clúster, el que vol dir que qualsevol pod pot utilitzar aquesta IP perquè comparteixen la mateixa xarxa.
Crea un pod “nginx” i crea una sessió interactiva:
$ kubectl run nginx --image=nginx
pod/nginx created
box@k8s:~$ kubectl exec -it nginx -- bash
root@nginx:/#
Verifica que des del contenidor “nginx” tens accés al contenidor “apache”:
$ curl 10.244.0.14
<html><body><h1>It works!</h1></body></html>
Una altra manera de connectar-se a un pod per fer proves, o per “debugging”, és mitjançant un port forwarding:
$ kubectl port-forward apache 8000:80
Forwarding from 127.0.0.1:8000 -> 80
Forwarding from [::1]:8000 -> 80
Ara et pots connectar directament des del navegador: http://localhost:8000/.
A Servei aprendràs com exposar un pod a l’exterior mitjançant la configuració de serveis.
Descriptor
De la mateixa manera que a Compose utilitzes un fitxer yaml per definir una composició de contenidors, amb kubernetes també pots utilitzar un fitxer yaml per definir un pod.
A continuació mira la definició del pod que està en execució en format yaml:
$ kubectl get pod apache -o yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2025-02-01T21:19:23Z"
labels:
run: apache
name: apache
namespace: default
resourceVersion: "3554"
uid: c58a72ec-83c7-4d4e-b49e-3413a72a2a2c
spec:
containers:
- image: httpd
imagePullPolicy: Always
name: apache
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: kube-api-access-gjqjw
readOnly: true
...
Pot semblar molt complicat al principi, però a mesura que aprenguis els conceptes bàsics i aprenguis a distingir les parts importants del que són detalls menors veuràs que és molt fàcil d’entendre.
A més, per definir un pod no necessites escriure tot això.
A continuació desplegaràs un pod amb MongoDB
Crea un fitxer mongodb.yaml
apiVersion: v1
kind: Pod
metadata:
name: mongodb
spec:
containers:
- image: mongo
name: mongodb
ports:
- containerPort: 27017
protocol: TCP
Pots veure que en la definició d’un pod:
-
metadata
inclou el nom, l’espai de noms, etiquetes i altra informació sobre el pod. -
spec
inclou la descripció dels continguts del pod, com són els contenidors, volums i altres dades. -
status
inclou la informació sobre l’execució del pod, per la qual cosa no forma part del fitxer de definició.
Pots consultar per a què serveix cada entrada del fitxer amb la comanda explain
.
Important! El port és només descriptiu, perquè tu o qualsevol altre sàpiga quins ports utilitza el contenidor.
Per exemple:
$ kubectl explain pod.spec
KIND: Pod
VERSION: v1
FIELD: spec <PodSpec>
...
Utilitza la comanda create
per crear un pod a partir d’un fitxer yaml:
$ kubectl create -f mongodb.yaml
pod/mongodb created
Pots veure que ara tens dos pods:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
apache 1/1 Running 0 41m
mongodb 1/1 Running 0 54s
Connecta’t a la base de dades mongodb des de l’exterior amb mongosh
:
Obre un altre terminal i fes un port forward:
$ kubectl port-forward mongodb 27017:27017
Forwarding from 127.0.0.1:27017 -> 27017
Forwarding from [::1]:27017 -> 27017
Connecta’t amb mongosh
:
$ docker run --rm -it --network host mongo mongosh
Current Mongosh Log ID: 679ea6b415ca11579ae94969
Connecting to: mongodb://127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&appName=mongosh+2.3.4
Using MongoDB: 8.0.4
Using Mongosh: 2.3.4
...
test>
Logs
Les aplicacions que s’executen en contenidors normalment no escriuen els “logs” en fitxers, sinó que els envien a la sortida estàndard, de tal manera que els usuaris poden accedir a aquesta informació d’una manera simple i estàndard.
D’aquesta forma, Docker redirigeix aquests “streams” a fitxers que et permeten accedir als “logs” dels contenidors a través de Docker de forma homogènia.
Pots utilitzar kubectl
per accedir a aquests logs, per exemple els d’Apache:
$ kubectl logs apache
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.244.0.4. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.244.0.4. Set the 'ServerName' directive globally to suppress this message
[Sat Feb 01 21:19:29.784649 2025] [mpm_event:notice] [pid 1:tid 1] AH00489: Apache/2.4.63 (Unix) configured -- resuming normal operations
[Sat Feb 01 21:19:29.785020 2025] [core:notice] [pid 1:tid 1] AH00094: Command line: 'httpd -D FOREGROUND'
10.244.0.1 - - [01/Feb/2025:21:22:34 +0000] "GET / HTTP/1.1" 200 45
127.0.0.1 - - [01/Feb/2025:21:34:38 +0000] "GET / HTTP/1.1" 200 45
127.0.0.1 - - [01/Feb/2025:21:34:38 +0000] "GET /favicon.ico HTTP/1.1" 404 196
Ten en cuenta que cuando borras un pod ya no tienes acceso a los logs de los contenedores de ese pod.
$ kubectl delete pod apache
pod "apache" deleted
$ kubectl logs apache
error: error from server (NotFound): pods "apache" not found in namespace "default"
Si vols conservar els logs dels pods fins i tot després que siguin eliminats, has d’implementar un registre centralitzat que guardi els logs de tot el clúster.
Etiquetes
Un clúster kubernetes està pensat per desplegar centenars i milers de pods.
Per sort, pots posar etiquetes als pods per organitzar i posar ordre.
De fet, pots etiquetar qualsevol mena d’objecte kubernetes.
Crea un pod amb un contenidor nginx:
$ kubectl run nginx --image nginx
pod/nginx created
A continuació anem a etiquetar els tres pods amb una etiqueta type
:
$ kubectl label pod apache type=web
pod/apache labeled
$ ...
Per defecte la comanda kubectl get pods
no mostra les etiquetes, però pots fer que es mostrin amb el paràmetre : --show-labels
$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
apache 1/1 Running 0 17m run=apache,type=web
mongodb 1/1 Running 0 5m3s type=db
nginx 1/1 Running 0 8h run=nginx,type=web
Pots veure que a més de la nostra etiqueta, els pods apache
i nginx
tenen l’etiqueta run
perquè no els has creat a partir d’un fitxer sinó directament amb kubectl run
.
A més de l’etiqueta type
, afegeix l’etiqueta env
per indicar si un pod s’executa en entorn de producció o depuració:
$ kubectl label pod mongodb env=prod
pod/mongodb labeled
...
En lloc de veure totes les etiquetes amb , podem seleccionar les etiquetes que volem veure amb el flag , de manera que cada etiqueta es desplega en la seva pròpia columna: --show-labels``-L
$ kubectl get pods -L type,env
NAME READY STATUS RESTARTS AGE TYPE ENV
apache 1/1 Running 0 29m web prod
mongodb 1/1 Running 0 16m db prod
nginx 1/1 Running 0 8h web debug
Per modificar una etiqueta necessites utilitzar el flag , per evitar una modificació accidental: --overwrite
$ kubectl label pod nginx env=test
error: 'env' already has a value (debug), and --overwrite is false
$ kubectl label pod nginx env=test --overwrite
pod/nginx labeled
Pots veure que és fàcil afegir etiquetes als recursos i modificar-les.
A Replicació veuràs una de les utilitats més importants que tenen.
De moment ens limitarem a filtrar recursos mitjançant un selector d’etiquetes.
Per veure tots els pods que estan en entorn de producció (etiquetats amb env=prod
), fes el següent:
$ kubectl get pods -l env=prod
NAME READY STATUS RESTARTS AGE
apache 1/1 Running 0 41m
mongodb 1/1 Running 0 28m
Per tenir una llista de tots els pods que tenen l’etiqueta run
, sense importar el valor de l’etiqueta:
$ kubectl get pods -l run
NAME READY STATUS RESTARTS AGE
apache 1/1 Running 0 43m
nginx 1/1 Running 0 8h
I aquells que no tenen l’etiqueta run
:
$ kubectl get pods -l '!run'
NAME READY STATUS RESTARTS AGE
mongodb 1/1 Running 0 31m
Observació. Has d’utilitzar cometes simples al voltant de perquè el shell no avaluï el signe d’exclamació. !run
També pots incloure diversos criteris separats per coma:
$ kubectl get pods -l env=prod,type=web
NAME READY STATUS RESTARTS AGE
apache 1/1 Running 0 47m
Espai de noms
Kubernetes utilitza diferents espais de noms per agrupar i separar recursos.
En un espai de noms el nom del recurs ha de ser únic, però pot haver-hi recursos amb el mateix nom en diferents espais de noms.
Mira els espais de nom que hi ha al teu clúster:
$ kubectl get namespaces
NAME STATUS AGE
default Active 21h
kube-node-lease Active 21h
kube-public Active 21h
kube-system Active 21h
Fins ara has utilitzat l’espai de noms default
, que és el que s’utilitza per defecte amb kubectl
.
Mira els pods que hi ha a l’espai de noms : kube-system
$ kubectl get pods --namespace kube-system
NAME READY STATUS RESTARTS AGE
coredns-668d6bf9bc-qbhmr 1/1 Running 1 (9h ago) 21h
etcd-minikube 1/1 Running 1 (9h ago) 21h
kube-apiserver-minikube 1/1 Running 1 (9h ago) 21h
kube-controller-manager-minikube 1/1 Running 1 (9h ago) 21h
kube-proxy-x7ghr 1/1 Running 1 (9h ago) 21h
kube-scheduler-minikube 1/1 Running 1 (9h ago) 21h
storage-provisioner 1/1 Running 3 (9h ago) 21h
Consell. Pots utilitzar -n
en lloc de --namespace
.
En altres activitats aprendràs sobre aquests pods, però a partir del nom kube-system
pots intuir que es tracta de pods relacionats amb el sistema d’execució de kubernetes.
Un espai de noms és com qualsevol altre recurs, i el podem crear amb un fitxer yaml:
apiVersion: v1
kind: Namespace
metadata:
name: xtec
Utilitza kubectl
per enviar el fitxer al servidor API kubernetes:
$ kubectl create -f namespace.yaml
namespace/xtec created
Com pots haver endevinat també el pots crear directament per línia d’ordres:
$ kubectl create namespace keko
namespace/keko created
A continuació crea un servidor caddy amb el nom “caddy” a l’espai de noms xtec
:
$ kubectl run caddy --image=caddy -n xtec
pod/caddy created
Pots veure que no apareix a l’espai de noms default
:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
apache 1/1 Running 0 72m
mongodb 1/1 Running 0 59m
nginx 1/1 Running 0 9h
Però sí a l’espai de noms xtec
:
$ kubectl get pods -n xtec
NAME READY STATUS RESTARTS AGE
caddy 1/1 Running 0 76s
Fes un “port forward”:
$ kubectl port-forward caddy 3000:80 -n xtec
Forwarding from 127.0.0.1:3000 -> 80
Forwarding from [::1]:3000 -> 80
Handling connection for 3000
Pots veure el servidor caddy funcionant: http://localhost:3000/.
Encara que els pods s’executin en espais separats, es poden comunicar entre ells en funció del tipus de solució de xarxa que s’hagi desplegat al clúster.
El nostre “minikube” utilitza una solució simple com pots veure a continuació:
$ kubectl get pod -o wide | grep apache
apache 1/1 Running 0 84m 10.244.0.16 minikube <none> <none>
$ kubectl exec -it caddy -n xtec -- sh
/srv $ apk add curl
OK: 13 MiB in 30 packages
/srv $ curl 10.244.0.16
<html><body><h1>It works!</h1></body></html>
Gestionar pods
A diferència de docker, amb kubernetes no pots aturar contenidors, només pots crear o eliminar pods.
Pots eliminar un pod pel seu nom:
$ kubectl delete pod mongodb
pod "mongodb" deleted
O eliminar un conjunt de pods mitjançant un selector d’etiquetes:
$ kubectl delete pod -l type=web
pod "apache" deleted
pod "nginx" deleted
Fins i tot pots eliminar tot un espai de noms (incloent tots els recursos):
$ kubectl delete ns xtec
namespace "xtec" deleted