Pod

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:

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:

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:

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:

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

El contingut d'aquest lloc web té llicència CC BY-NC-ND 4.0.