Kubernetes es un sistema de código libre para la automatización del despliegue, ajuste de escala y manejo de aplicaciones en contenedores que fue originalmente diseñado por Google y donado a la Cloud Native Computing Foundation (parte de la Linux Foundation). Soporta diferentes entornos para la ejecución de contenedores, incluido Docker y su misión es la orquestación de dichos contenedores.
- **servidor API** - Es un componente central y sirve a la API de Kubernetes utilizando JSON sobre HTTP, que proveen la interfaz interna y externa de Kubernetes.
- **Planificador** - Es el componente enchufable que selecciona sobre qué nodo deberá correr un pod sin planificar basado en la disponibilidad de recursos.
- **Administrador de controlador** - Es el proceso sobre el cual el núcleo de los controladores Kubernetes como DaemonSet y Replication se ejecuta.
- **Nodo** *(esclavo o worker)* - Es la máquina física (o virtual) donde los contenedores (flujos de trabajos) son desplegados.
- **Kubelet** - Es responsable por el estado de ejecución de cada nodo, es decir, asegurar que todos los contenedores en el nodo se encuentran saludables.
- **kube proxy** - Reenvía el tráfico al pod donde tiene que ir.
- **cloud controler manager** - Es el encargado de conectarse a la API del cloud. <u>Es la diferencia con otros orquestadores</u>. Permite correr los contenedores y hacer funciones extras que no estén instaladas en nuestro espacio.
- **cAdvisor** - Es un agente que monitorea y recoge métricas de utilización de recursos y rendimiento como CPU, memoria, uso de archivos y red de los contenedores en cada nodo.
No es buena idea correr tráfico de clusterización en equipos personales.
Los **Pods** son los contenedores de Kubernetes (puede tener varios contenedores). La unidad mínima de computación. Comparte una única IP. Generalmente por cada pod correrá un contenedor, pero puede darse las circunstancias de que sea preferente correr varios contenedores en un pod.
Ponemos `--cliente=true` porque si no se intentaría conectar a un clúster kubernetes y trataría de descargar la versión kubernetes del clúster. Para un formato más legible controlamos la salida con `--output=yaml|json]`
También podemos instalar minikube https://minikube.sigs.k8s.io/docs/ que instala todos los componentes de kubernetes en una MV y además tiene una serie de plugins para darle funcionalidades con una serie de paquetes precinfigurados.
Para conectar kubectl con el cluster de kubernetes se debe desarcargar el fichero *kubeconfig* que es donde están declarados los contextos de kubernetes. Es una combinación de la url del servidor con las credenciales de lo que se haya instalado.
*Con minikube no tendríamos que hacer nada porque se configura automáticamente.*
kubectl controla el gestor de clústeres de Kubernetes.
Encontrará más información en: https://kubernetes.io/docs/reference/kubectl/
Comandos básicos (principiante):
create Crear un recurso desde un archivo o desde stdin
expose Tomar un controlador de replicación, servicio, despliegue o pod y exponerlo como un nuevo servicio Kubernetes
run Ejecutar una imagen particular en el cluster
set Establecer características específicas en los objetos
Comandos básicos (Intermedio):
explain Obtener la documentación de un recurso
get Mostrar uno o varios recursos
edit Editar un recurso en el servidor
delete Eliminar recursos por nombres de archivo, stdin, recursos y nombres, o por recursos y selector de etiqueta
Comandos de despliegue:
rollout Gestionar el despliegue de un recurso
scale Establecer un nuevo tamaño para un despliegue, conjunto de réplicas o controlador de replicación
autoscale Escala automáticamente un despliegue, un conjunto de réplicas, un conjunto con estado o un controlador de replicación
Comandos de gestión del clúster:
certificate Modificar los recursos del certificado.
cluster-info Mostrar información del cluster
top Mostrar el uso de recursos (CPU/memoria)
cordon Marcar un nodo como no programable
uncordon Marcar el nodo como programable
drain Drenar el nodo en preparación para el mantenimiento
taint Actualizar los taints de uno o más nodos
Comandos de solución de problemas y depuración:
describe Mostrar los detalles de un recurso específico o de un grupo de recursos
logs Imprimir los registros de un contenedor en un pod
attach Adjuntar a un contenedor en ejecución
exec Ejecutar un comando en un contenedor
port-forward Reenviar uno o más puertos locales a un pod
proxy Ejecutar un proxy al servidor de la API de Kubernetes
cp Copiar archivos y directorios hacia y desde los contenedores
auth Inspeccionar la autorización
debug Crear sesiones de depuración para la resolución de problemas de cargas de trabajo y nodos
Comandos avanzados:
diff Comparar una versión en vivo contra una versión aplicada
apply Aplicar una configuración a un recurso por nombre de archivo o stdin
patch Actualizar los campos de un recurso
replace Reemplazar un recurso por nombre de archivo o stdin
wait Experimental: Esperar una condición específica en uno o varios recursos
kustomize Construir un objetivo de kustomize a partir de un directorio o una URL.
Settings Commands:
label Actualizar las etiquetas de un recurso
annotate Actualiza las anotaciones de un recurso
completion Imprimir el código de finalización del shell para el shell especificado (bash, zsh, fish o powershell)
Otros Comandos:
alpha Comandos para funciones en alpha
api-resources Imprime los recursos de la API soportados en el servidor
api-versions Imprime las versiones de la API admitidas en el servidor, en forma de "grupo/versión"
config Modifica los archivos kubeconfig
plugin Proporciona utilidades para interactuar con los plugins
version Imprime la información de la versión del cliente y del servidor
Uso:
kubectl [flags] [options]
Utilice "kubectl <command> --help" para obtener más información sobre un determinado comando.
Utilice "kubectl options" para obtener una lista de opciones globales de la línea de comandos (se aplica a todos los comandos).
```
Una herramienta gráfica para kubectl es *[lens](https://k8slens.dev/)*., Muestra los contenedores de una manera clara y también tiene gráficas (memoria, CPU, etc).
Para mostrar los contextos que están en el fichero kubeconfig o el archivo de configuración de kubectl
```
kubectl config get-contexts
```
Para mostrar los namespaces:
```
kubectl get ns
```
Con el clúster recien creado aparecerán los namespaces por defecto que vienen con cualquier clúster.
Para ver los pods que están corriendo
```
kubectl -n kube-system get pods
```
`kube-system` es un namespace que utiliza kubernetes para correr los pods de sistema.
Tomando un ejemplo, `do-node-agent-9rt5c` es un agente que corre DigitalOcean en sus nodos para hacer algún tipo de recolección de datos o monitoreo. El final alfanumérico es porque ha sido generado por el template de pods *deployment*, todos los pods tendrá ese hash en el nombre.
La segunda columna indica el número de pods activos y los que existen. El estado, está claro, después están las columnas de los reinicios efectuados y la de el tiempo que lleva arrancado.
Con la opción `-o wide` mostrará un poco más de información.
Vamos a probar lo que dicen de kubernetes de que si se borra un pod se creará uno nuevo.
```
kubectl -n kube-system delete pod do-node-agent-9rt5c
```
Inmediatamente muestro los pods y se puede ver como lo está creando de nuevo.
El pod es nuevo, tiene otro hash. Así que esto asegura que siempre estén el mismo número de pods.
Ahora utilizaremos un manifiesto de un pod del [pelado Nerd](https://github.com/pablokbs/peladonerd/tree/master/kubernetes/35) llamado [01-pod.ymal](yaml-del-pelado/01-pod.yaml)
Otro manifiesto de un pod del [pelado Nerd](https://github.com/pablokbs/peladonerd/tree/master/kubernetes/35) llamado [02-pod.ymal](yaml-del-pelado/02-pod.yaml) es lo mismo pero con más opciones.
cpu: "200m" # son milicores, cada core tiene 1000 milicores
limits:
memory: "128Mi"
cpu: "500m"
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 15
periodSeconds: 20
ports:
- containerPort: 80
```
En este tenemos más especificaciones:
- *Variables de entorno* como clave-valor. Con `DD_AGENT_HOST` podemos pasar el valor de otro sitio gracias a *[Downward](https://kubernetes.io/docs/concepts/workloads/pods/downward-api/)* de kubernetes, que son valores que se pueden heredar, en este caso indicamos la ip del host donde va a correr este pod: `status.hostIP`.
- Se indican los recursos que se garantizan por contenedor con `requests` y los limites con `limits`. Los límites provocan que el kernel de Linux haga CPU Throttling, es decir, ahorcará el proceso hasta que use la velocidad límite y si no lo matará y esto hará que se cree otro pod.
- *ReadinessProbe* es una forma de explicarle a kubernetes de que el pod está preparado para recibir tráfico. Kubernetes comprueba la raíz esperando un status code 200.
- *livenessProbe* es una forma de explicarle a kubernetes de que el pod está vivo y no quieres que lo mate. Kubernetes comprueba el socker del puerto 80 de que está vivo.
- Por último tenemos el *puerto* que queremos poner.
Pero para trabajar con kubernetes, no deberíamos levantar el recurso mínimo como son los pods, es mejor aprocechar la capacidad de orquestación de la herramienta y levantar deployment. Lo encontraremos en otro manifiesto de un deployment del [pelado Nerd](https://github.com/pablokbs/peladonerd/tree/master/kubernetes/35) llamado [04-deployment.yaml](yaml-del-pelado/04-deployment.yaml).
`daemonset` es otra forma de deployment un pod pero en este caso será un pod en cada uno de los nodos existente. No indicas las réplicas por eso. Sirve, por ejemplo, para despliegues de servicios de monitoreo. De nuevo, vamos a un manifiesto de un daemonset del [pelado Nerd](https://github.com/pablokbs/peladonerd/tree/master/kubernetes/35) llamado [03-daemonset.yaml](yaml-del-pelado/03-daemonset.yaml).
`statefulset` podemos crear pods con volumenes que estarán atados. Es la manera de que los datos sean persistentes, como en Docker. Sirve, por ejemplo, para las BBDD. El manifiesto de statefulset del [pelado Nerd](https://github.com/pablokbs/peladonerd/tree/master/kubernetes/35) llamado [05-statefulset.yaml](yaml-del-pelado/05-statefulset.yaml).
```
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: my-csi-app-set
spec:
selector:
matchLabels:
app: mypod
serviceName: "my-frontend"
replicas: 1
template:
metadata:
labels:
app: mypod
spec:
containers:
- name: my-frontend
image: busybox
args:
- sleep
- infinity
volumeMounts:
- mountPath: "/data"
name: csi-pvc
volumeClaimTemplates:
- metadata:
name: csi-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: do-block-storage
```
Dentro de `volumeClaimTemplates` se le dan las especificaciones al volumen y, en concreto, `storageClassName: do-block-storage` es un driver que permite construir un volumen digital en DigitalOcean. Cuando se aplique este manifiesto se creará automáticamente el volumen de 5 Gb y se conectará al clúster de kubernetes.
En la parte superior salen todas las descripciones habituales. Más abajo aparecen los eventos del pod.
En los eventos se puede ver como intentó crear un pvc (PersistentVolumeClaims). Es un pedido desde kubernetes al proveedor. Se pueden ver con el siguiente comando.
```
kubectl get pvc
```
Podemos pedir el `describe` del pvc
```
kubectl describe pvc csi-pvc-my-csi-app-set-0
```
Vewremos sus descripción y los eventos.
Si vamos al dashboard de DigitalOCean podremos ver en volumenes el recien creado.
Ahora si miramos los statefilsets y borramos por su nombre, el volumen quedará.
```
kubectl get statefulsets
```
```
kubectl delete sts [nombre-del-statefulsets]
```
Tendremos que borrar expresamente el volumen si nos queremos deshacer de él.
```
kubectl delete pvc csi-pvc-my-csi-app-set-0
```
### Manifiesto cluster ip
Antes de aplicar el manifiesto, unas explicaciones aclaratorias.
#### Pod Networking
**calico** es un agente que corre en cada nodo que crea rutas IPs para enrutar entre cada uno de los nodos.
**etcd** es la BBDD de kubernetes donde se guardan los estados.
#### Kube-proxy
Los servicios en Kubernetes son una forma de poder contactar entre aaplicaciones, ya sea desde dentro del clúster entre pods o desde fuera. Hay 3 tipos:
- **Clúster IP** - Una especie de load balancer entre pods
- **Node Port** - crea un puerto en cada nodo que crea el servicio entre los pods que se configuren. Lo encontrarán `kube-proxy`.
- **Load Balancer** - Crea un balancedor de carga en el proveedor de cloud para redireccionar el tráfico a los pods.
Ahora vamos a aplicar el fichero yaml [06-randompod.yaml](yaml-del-pelado/06-randompod.yaml) que lo que hará es levantar un ubuntu sleep. Podremos entrar a este pod para acceder al resto.
```
apiVersion: v1
kind: Pod
metadata:
name: ubuntu
spec:
containers:
- name: ubuntu
image: ubuntu
args:
- sleep
- infinity
```
```
kubectl apply -f kubernetes/35/06-randompod.yaml
```
El resto será el fichero yaml [07-hello-deployment-svc-clusterIP.yaml](yaml-del-pelado/07-hello-deployment-svc-clusterIP.yaml)
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello
spec:
replicas: 3
selector:
matchLabels:
role: hello
template:
metadata:
labels:
role: hello
spec:
containers:
- name: hello
image: gcr.io/google-samples/hello-app:1.0
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: hello
spec:
ports:
- port: 8080
targetPort: 8080
selector:
role: hello
```
Para verlo todo solicitaremos que lo muestre con el siguiente comando
```
kubectl get all
```
Podemos ver las IPs de los clústers pero no las de los pods. Pero podemos pedir un describe del servicio para más detalles.
```
kubectl describe svc hello
```
Los `Endpoints` son las IPs de cada uno de los pods.
Tamnbién se pueden ver con un get pods detallado.
```
kubectl get pods -o wide
```
Si matamos un pod, automáticamente se volverá a crear y será balanceado por el servicio.
Para poder hacer ping tengo que instalar un ubuntu con iputils: https://hub.docker.com/r/mmoy/ubuntu-netutils/
Lo cambio en el manifiesto quedando así
```
apiVersion: v1
kind: Pod
metadata:
name: ubuntu
spec:
containers:
- name: ubuntu
image: mmoy/ubuntu-netutils
args:
- sleep
- infinity
```
Ahora ya puedo hacer las comprobaciones desde el pod ubuntu con ping y curl para ver como balancea la carga.
### Manifiesto nodeport
Borramos el anterior `hello` y vamos a aplicar el manifiesto [08-hello-deployment-svc-nodePort.yaml](yaml-del-pelado/08-hello-deployment-svc-nodePort.yaml) del Pelado.
El manifiesto es el siguiente
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello
spec:
replicas: 3
selector:
matchLabels:
role: hello
template:
metadata:
labels:
role: hello
spec:
containers:
- name: hello
image: gcr.io/google-samples/hello-app:1.0
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: hello
spec:
type: NodePort
ports:
- port: 8080
targetPort: 8080
nodePort: 30000
selector:
role: hello
```
En el anterior manifiesto no se especifico el tipo porque por defecto es de cluster ip. En cambio, en este se puede ver `type: NodePort`. Le podemos especificar el puerto de cada nodo para llegar al servicio: `nodePort: 30000`.
Si mostramos los nodos detalladamente podremos ver las IPs de los nodos, si hacemos curl a la IP con el puerto especificado podremos ver el balanceo de carga.
Hace lo mismo que el cluster ip pero desde fuera, exponiendo el puerto al mundo.
### Manifiesto load balancer
En esta ocasión utilizaremos el documento [09-hello-deployment-svc-loadBalancer.yaml](yaml-del-pelado/09-hello-deployment-svc-loadBalancer.yaml) del querido Pelado.
Es el siguiente
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello
spec:
replicas: 3
selector:
matchLabels:
role: hello
template:
metadata:
labels:
role: hello
spec:
containers:
- name: hello
image: gcr.io/google-samples/hello-app:1.0
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: hello
spec:
type: LoadBalancer
ports:
- port: 8080
targetPort: 8080
selector:
role: hello
```
En este enseguida hemos visto que el tipo de servicio es `LoadBalancer`.
Nos aseguramos que borramos el anterior nodeport y aplicamos este
En esta ocasión, el servicio está `<pending>` ya que lo tiene que desplegar DigitalOcean y suele tardar un ratito.
Es mejor hacer este tipo que nodeport, ya que nodeport está atado en cada nodo. En cambio, con loadbalancer siempre es la misma IP.
Si vamos al dashboard de DigitalOcean podremos ver el balanceador.
Una vez desplegado ya tendremos nuestra ip y podremos comprobarla como balancea con curl.
### Manifiesto versiones e ingress
Utilizaremos el fichero yaml [10-hello-v1-v2-deployment-svc.yaml](yaml-del-pelado/10-hello-v1-v2-deployment-svc.yaml) del Pelado.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-v1
spec:
replicas: 3
selector:
matchLabels:
role: hello-v1
template:
metadata:
labels:
role: hello-v1
spec:
containers:
- name: hello-v1
image: gcr.io/google-samples/hello-app:1.0
ports:
- containerPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-v2
spec:
replicas: 3
selector:
matchLabels:
role: hello-v2
template:
metadata:
labels:
role: hello-v2
spec:
containers:
- name: hello-v2
image: gcr.io/google-samples/hello-app:2.0
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: hello-v1
spec:
ports:
- port: 8080
targetPort: 8080
selector:
role: hello-v1
---
apiVersion: v1
kind: Service
metadata:
name: hello-v2
spec:
ports:
- port: 8080
targetPort: 8080
selector:
role: hello-v2
```
Tendremos 2 versiones de la aplicación y un servicio por cada uno. Se puede ver cuando aplicamos.
Con un `get all` podemos ver que tenemos 6 pods, 3 por cada versión, y un servicio por versión.
`Ingress` es un tipo de recurso que nos permite crear accesos a nuestro servicio basados en el path. Kubernetes hace un deploy de un controlador nginx que va a leer las configuraciones de Ingress y se va a autoconfigurar para enviar el tráfico a donde tenga que hacerlo.
No todos los proveedores de cloud tienen instalado nginx, con lo que en algunos hay que instalarlo. Una opción para instalarlo es utilizar la herramienta [helm](https://helm.sh/)
En DigitalOcean, en la pestaña de marketplace del dashboard del clúster podremos ver aplicaciones a instalar, entre la que está nginx.
Para instalarlo simplemente tenemos que darle al botón.
El controlador de nginx ingress creará un namespace, podremos verlo con `get ns` y si mostramos los pods filtrando por este namespaces veremos los que corren bajo nginx.
Ingress tiene muchas posibilidades, es importante darle un vistazo a su documentación: https://kubernetes.io/docs/concepts/services-networking/ingress/
Ahora aplicamos el fichero yaml [11-hello-ingress.yaml](yaml-del-pelado/11-hello-ingress.yaml) de Mr. Pelado.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: hello-app
spec:
rules:
- http:
paths:
- path: /v1
pathType: Prefix
backend:
service:
name: hello-v1
port:
number: 8080
- path: /v2
pathType: Prefix
backend:
service:
name: hello-v2
port:
number: 8080
```
Podemos mostrar los recursos ingress con el siguiente comando
```
kubectl get ing
```
Para hacernos una idea podemos ver este diagrama de ejemplo de la documentación de Digital Ocean, buenísimos documentando.
- name: PLAYER_INITIAL_LIVES # Nombre de la variable
valueFrom:
configMapKeyRef:
name: game-demo # El confimap desde donde vienen los valores
key: player_initial_lives # La key que vamos a usar
- name: UI_PROPERTIES_FILE_NAME
valueFrom:
configMapKeyRef:
name: game-demo
key: ui_properties_file_name
volumeMounts:
- name: config
mountPath: "/config"
readOnly: true
volumes:
- name: config
configMap:
name: game-demo # el nombre del configmap que queremos montar
items: # Un arreglo de keys del configmap para crear como archivos
- key: "game.properties"
path: "game.properties"
- key: "user-interface.properties"
path: "user-interface.properties"
```
En este archivo se puede ver como se define la variable de entorno `PLAYER_INITIAL_LIVES` pero el valor se lo asignaremos con el fichero `configmap` con la especificación `valueFrom`. En `configMapKeyRef` tendremos el `name` de la configmap de donde vienen los valores y la `key`que vamos a utilizar.
Además, se va a montar un volumen con `volumeMounts` donde se generarán archivos basados en el `configmap`, indicando el `name`, el path donde se ubicará con `mountPath` y le decimos que sea de solo lectura con `readOnly: true`, es decir, que desde el pod no lo podré modificar. Más abajo se define el volumen para poderlo crear y se indican los `items` para indicar los nombres de los ficheros (`key`) y su ubicación (`path`).
Los `secret` son muy parecidos a los configmap, la diferencia es que el contenido estaŕa codificado en base64. No es seguro, no es un cifrado es una codificación. A simple vista no se puede leer pero los pods si que pueden hacerlo.
Para probarlo utilizaremos otro pod nginx, también del Pelado Nerd, llamado [15-pod-secret.yaml](yaml-del-pelado/15-pod-secret.yaml)
```
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:alpine
env:
- name: MI_VARIABLE
value: "pelado"
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: db-credentials
key: username
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: db-credentials
key: password
ports:
- containerPort: 80
```
En las variables `env` tendremos el usuario y el password de mysql con los `name` MYSQL_USER y MYSQL_PASSWORD que cogerán el valor con `secretKeyRef` de db-credentials, que es el nombre del secret del manifiesto anterior.
Esta no es una buena práctica para gestionar secrets.
</span>
[KubeSealed](https://github.com/bitnami-labs/sealed-secrets) es un controlador de kubernetes que cifra las credenciales utilizando un certificado.
### manifiesto kustomization
`kustomization` es una forma de manejar manifiestos más fácilmente. Nos permite con un cliente embebido a kubectl generar manifiestos.
Utilizaremos el fichero del Pelado Nerd [kustomization.yaml](yaml-del-pelado/kustomization.yaml)
```
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
commonLabels:
app: ejemplo
resources:
- 15-pod-secret.yaml
secretGenerator:
- name: db-credentials
literals:
- username=admin
- password=secr3tpassw0rd!
images:
- name: nginx
newTag: latest
```
Con una especie de plugins podremos, por ejemplo:
- Taguear todos los manifiestos. (`commonLabels`).
- Generar un secret (En el yaml no se siguen buenas prácticas para los secret) (`secretGenerator`).
- Cambiar una imagen (`images`)
Primero instalaremos los paquetes necesarios para que funcione.
```
sudo apt update && sudo snap install kustomize
```
Luego tendremos que construir el archivo con el comando, que leerá el archivo `kustomization.yaml` y hará lo que tenga que hacer.
```
kustomize build .
```
En concreto, creará el secreto basado en el literal del fichero yaml y creo el pod que se indico en `resource`. Además metió la label en la metadata y cambio la imagen por `nginx:latest`.
Podemos borrar el pod y volver a correr el mismo comando kustomize con una tubería.
```
kustomize build . | kubectl apply -f -
```
Se puede ver que ha cambiado el hash de los `name`
Si cambiamos algo del fichero yaml y volvemos a correr el comando kustomize, volverá a cambiar el hash. Guarda versiones.
### stern
`stern` es una utilidad súper simple que permite especificar tanto el id del pod como el id del contenedor como expresiones regulares. Cualquier coincidencia será seguida y la salida es multiplexada, prefijada con el id del pod y el id del contenedor, y codificada por colores para el consumo humano
Esta guía ha sido creada a partir de multitud de tutoriales que he hecho, son mis apuntes personales. Pero quiero hacer una especial mención a [Pelado Nerd](https://www.youtube.com/c/PeladoNerd), espero que la guía sea como el Pelado manda.
