Creado cluster real con VMs y kubeadm

Lo primero que tenemos que hacer es crear 3 maquinas virtuales en linux e instalar:

• Docker
• kubectl
• kubeadm
• kubelet

Las virtuales funcionarian bien con:

• 3GB RAM
• 20 HDD
• 2 PROCESADORES

Pero si te sobra mejor porque sino es un poco lento.

Deshabilitamos el swap con:

swapon -s 
swapoff -a

Para que los cambios sean permamentes tenes que comentar todos los espacios de swap en etc/fstab

Creando cluster

Una vez tengamos la VM lista con todo instalado creamo el cluster, el cual usara como plugin de red a Calico, el cual es un CIDR.Googlealo.

Pero antes tenemos que instalar cri-dockerd que nos ayudara a que docker sea nuestro runtime container y se comunique con kubernetes.

Que es cri-dockerd

• cri-dockerd es un adaptador que permite que Kubernetes se comunique con Docker como su runtime de contenedores. Específicamente, este adaptador traduce las llamadas de la API CRI de Kubernetes para que Docker pueda manejarlas.

• A partir de Kubernetes 1.24, Docker ya no es compatible directamente como runtime de contenedores. En su lugar, se recomienda usar un runtime compatible con CRI, como containerd o cri-dockerd.

Instalando cri-dockerd

Esta es su web oficial y aca descargamos la version correspondiente a nuestro linux.

Una vez instalado podemso ejecutar el comando que creara nuestro cluster.

Pero antes selucionemos un error.

Solucion al error CRI al lanzar kubeadm init --pod-network-cidr=10.146.0.0/16 --cri-socket=unix:///var/run/cri-dockerd.sock

Este es un error común cuando ejecutas el comando kubeadm init mientras el CRI es usado por Containerd. En la mayoría de los casos tiene que ver con el archivo config.toml. Para solucionar esto debes borrar el archivo config.toml y reiniciar el servicio de Containerd.

sudo rm /etc/containerd/config.toml
sudo systemctl restart Containerd
sudo kubeadm init --pod-network-cidr=10.146.0.0/16 --cri-socket=unix:///var/run/cri-dockerd.sock

Creando finalmente el cluster

kubeadm init --pod-network-cidr=10.146.0.0/16 --cri-socket=unix:///var/run/cri-dockerd.sock

Es importante que —pod-network-cidr=10.146.0.0/16 no se choque con nuestra red de la pc fisica, ni de ningun otro dispotivo en la red. Por ejemplo si tu pc esta en 192.168.0.0 tenes que poner cualquier otro rango.

Una vez termine el proceso de kubeadm veremos algo como esto:

kubeadm join 192.168.0.13:6443 --token twsbtz.h8lvicoz4a4fredv \
	--discovery-token-ca-cert-hash sha256:71f0b39d6bd9e5737a8305abb816587c840e663a29399df343a4913cad8f33fb --cri-socket=unix:///var/run/cri-dockerd.sock

Esto debemos guardarlo ya que lo usaremos despues para conectar los nodos a este cluster.

Para comenzar a usar el nuevo cluster hacemos :

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Ahora tenemos que configurar el plugin de Netowork Calico.

1.kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.2/manifests/tigera-operator.yaml

Ahora instalamso los custom resourcse es clave descargarlos primero con wget y modificar la ip que tiene dentro para que coincida con la quen pusismos a nuestros pods.

wget https://raw.githubusercontent.com/projectcalico/calico/v3.28.2/manifests/custom-resources.yaml

Abrimos el archivo con el editor que mas nos guste, y donde dice cidr ponemos la ip que elegimos par los pods 10.146.0.0/16

Ahora ejecutamos manualmente:

kubectl apply -f custom-resources.yml

Luego vemos como se crean con :

watch kubectl get pods -n calico-system

Permitir que un Master ejecute pods

Por defecto, en Kubernetes, los nodos maestros (control plane) no ejecutan pods de usuario. Esto es para mantener el plano de control separado de las cargas de trabajo y garantizar la estabilidad y el rendimiento del clúster. Sin embargo, es posible configurar un nodo maestro para que también ejecute pods si así lo deseas, especialmente en entornos de desarrollo o en clústeres pequeños donde no quieres o no puedes agregar nodos de trabajo (workers).

Lo recomendable es lanzar los pods solo en los workers. Pero en ese caso haremos que el master tambien pueda hacerlo.

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

Agregando NODO al cluster

Podemos usar el que nos dio kubeadm cuando creamos el cluster:

kubeadm join 192.168.0.13:6443 --token twsbtz.h8lvicoz4a4fredv \
	--discovery-token-ca-cert-hash sha256:71f0b39d6bd9e5737a8305abb816587c840e663a29399df343a4913cad8f33fb --cri-socket=unix:///var/run/cri-dockerd.sock

Pero si lo perdimos podemos generar uno nuevo asi :

kubeadm  token create --print-join-command

Con ese nuevo join que nos da, lo guardamos.

Ahora creamos otra virtual la cual tiene que tener:

• kubeadm
• kubectl
• docker
• kubelet
• cri-dockerd

Y hacer esto :

sudo rm /etc/containerd/config.toml
sudo systemctl restart containerd

Tambien es importante que el hostname sea diferente al del nodo maestro(control plane) esto puede pasar si es que clonaste la maquina virtual.

Otra cosa importante es que en el nodo maestro tengamos abierto el puerto 6443.

sudo apt install ufw 
sudo ufw allow 6443

Si previamente ejecutaste el join y fallo, la momento de volver a intentarlo tenes que:

sudo rm -f /etc/kubernetes/kubelet.conf
sudo rm -rf /etc/kubernetes/pki/ca.crt

Ahora ejecutas

kubeadm join 192.168.0.13:6443 --token twsbtz.h8lvicoz4a4fredv \
	--discovery-token-ca-cert-hash sha256:71f0b39d6bd9e5737a8305abb816587c840e663a29399df343a4913cad8f33fb --cri-socket=unix:///var/run/cri-dockerd.sock

Si todo salio todo bien, vamos al maestro y tiramos :

kubectl get nodes y deberiamos ver que se agrego uno nuevo.

NAME              STATUS   ROLES           AGE    VERSION
debiank8s-node1   Ready    <none>          84s    v1.31.1
debiank8s1        Ready    control-plane   133m   v1.31.1

Inicializando pods

Vamos al control-plane y ejecutamos

kubectl create deployment apache --replicas 3 --image=httpd

Si ahora hacemos:

kubectl get pods -o wide

Veremos en que nodos se desplegaron los pods. Como previametente hicimos un Taint en el master, este tambien puede llegar a tener uno de los pods. Pero si no lo hubieramos hecho este no contrendria nunca a un pod.

Procesos y ficheros generados con el cluster

En un nodo del control plane (o master en versiones anteriores) de Kubernetes, el directorio /etc/kubernetes/ contiene una serie de archivos y directorios importantes relacionados con la configuración y gestión del clúster. Estos archivos son esenciales para el funcionamiento del control plane y sus componentes.

Aquí están los archivos y subdirectorios más comunes que encontrarás en /etc/kubernetes/:

1. /etc/kubernetes/manifests/

• Este directorio contiene los manifiestos estáticos que Kubernetes utiliza para desplegar y gestionar automáticamente los componentes críticos del control plane. Estos manifiestos son administrados directamente por el kubelet y suelen incluir:
  • kube-apiserver.yaml: Manifiesto del servidor API de Kubernetes.
  • etcd.yaml: Manifiesto del almacenamiento de claves-valor etcd, que guarda el estado del clúster.
  • kube-scheduler.yaml: Manifiesto del planificador de Kubernetes, que decide en qué nodos se ejecutarán los pods.
  • kube-controller-manager.yaml: Manifiesto del controlador principal, que se encarga de la mayoría de las operaciones de control (replicasets, endpoints, etc.).

2. /etc/kubernetes/pki/

• Este directorio contiene los certificados y claves utilizadas para la autenticación y autorización entre los componentes del control plane. Algunos de los archivos que puedes encontrar aquí incluyen:
  • ca.crt: Certificado de la autoridad certificadora (CA).
  • apiserver.crt y apiserver.key: Certificados y claves para el servidor API.
  • etcd.crt y etcd.key: Certificados y claves para el almacenamiento etcd.
  • front-proxy-client.crt y front-proxy-client.key: Certificados y claves utilizados para la autenticación de proxy inverso.

3. /etc/kubernetes/admin.conf

• Este archivo es el kubeconfig utilizado por el administrador para interactuar con el clúster de Kubernetes a través de kubectl. Proporciona las credenciales y detalles del servidor API para administrar el clúster.

4. /etc/kubernetes/kubelet.conf

• Este archivo es el kubeconfig utilizado por el kubelet (el agente que corre en cada nodo) para autenticarse ante el servidor API. Contiene información como la dirección del API y las credenciales necesarias.

5. /etc/kubernetes/controller-manager.conf

• Este archivo es el kubeconfig utilizado por el controller-manager, un componente del control plane que gestiona controladores que aseguran que el estado deseado del clúster se mantenga.

6. /etc/kubernetes/scheduler.conf

• Este archivo es el kubeconfig utilizado por el kube-scheduler, que es responsable de asignar pods a los nodos adecuados.

Otros posibles ficheros o directorios:

• /etc/kubernetes/cloud-config: Archivo opcional que contiene la configuración del proveedor de nube si se está utilizando uno.

• /etc/kubernetes/bootstrap-kubelet.conf: Archivo usado durante el proceso de arranque inicial del kubelet antes de que se autentique completamente ante el servidor API.

Resumen de los ficheros clave:

Estos archivos son esenciales para que el control plane funcione correctamente y mantenga la seguridad y conectividad dentro del clúster de Kubernetes.