> For the complete documentation index, see [llms.txt](https://docs.plenit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.plenit.com/support/tutorials/linux/how-to-set-up-kubernetes.md).
# Cómo montar un entorno de Kubernetes en Plenit
Sigue leyendo si quieres descubrir **cómo montar un entorno de Kubernetes en Plenit** y sacarle todo su jugo.
Desde que Google liberó el proyecto de Kubernetes hace casi 10 años (2014), esta tecnología ha ido adquiriendo más y más notoriedad, hasta que se ha hecho un **elemento imprescindible** en la gestión de microservicios.
Kubernetes es una **plataforma extensible, portable y flexible** basada en open software (código abierto) que nos permite administrar cargas de trabajo de distintos tamaños y que incluye el tamaño variable, permitiendo desplegar todo tipo de servicios, facilitando entre otras cosas la automatización y la respuesta a picos de trabajo y otros tipos de cargas de trabajo cambiantes.
La forma de operación de Kubernetes hace que sea una plataforma ideal para gestión basada en PaaS (Plataformas como Servicio) o IaaS (Infraestructura como Servicio).
### **¿Cómo montar un entorno de Kubernetes en Plenit?**
#### **Pre-requisitos y recomendaciones:**
Para completar de forma satisfactoria este tutorial y poder **montar un entorno de Kubernetes en Plenit** será necesario:
* Por un lado, estar \*\*dado de alta en la Plataforma Plenit \*\*con una organización y estar registrado en la misma tras \*\*hacer \*\*[**Log-in**](https://admin.jotelulu.com/){target="\_blank" rel="noopener"}.
* Por otro lado, [**haber dado de alta una suscripción de Servidores**](https://jotelulu.com/soporte/tutoriales/como-desplegar-servidor){target="\_blank" rel="noopener"}**\[.]**
* Tener tres\*\* servidores\*\* Ubuntu 22.04 desplegados dentro de la suscripción.
```{=html}
```
* * kubernetes-nacho-1 = Máster.
* kubernetes-nacho-2 = Worker 1.
* kubernetes-nacho-3 = Worker 2.
```{=html}
```
* Un usuario con \*\*privilegios de administrador \*\*o bien a través de "root" o mediante el comando "sudo".
* Según las especificaciones de Kubernetes, las máquinas virtuales provisionadas deben tener al menos 2GB de RAM, 2 CPUs y al menos 20GB de disco duro para poder trabajar, aunque en función del uso que se les vaya a dar puede ser necesario incrementar estos requerimientos.
####
#### **Paso 1. Preparando la máquina antes del despliegue de Kubernetes**
Lo primero que se deberá hacer **antes de empezar con el despliegue** de Kubernetes es **actualizar los paquetes y la distribución** para asegurarnos de que contamos con los paquetes más actualizados y las últimas fuentes actualizadas.
Para ello se deben **lanzar los siguientes comandos**.
\_# sudo apt update
## sudo apt upgrade\_
Recordemos que **el comando "sudo"** se usa en las **distribuciones Ubuntu** para **lanzar los comandos con una elevación de privilegios**. Sería algo así como un "Super User Do" (Hacer como Super Usuario), es el equivalente a un "RunAs" en entornos de Microsoft.
Paso 1. Lanzamos la actualización de los paquetes y de la distribución
Uno de los puntos que **debemos controlar** cuando trabajemos con Kubernetes es el uso de la **memoria de intercambio o SWAP**. En ocasiones se han producido problemas durante el escalado de los PODS, ya que el sistema no los gestiona correctamente en caso de tener activa la SWAP del sistema.
Para evitar comportamientos erráticos, la mejor opción es **deshabilitar dicha opción** usando el comando "swapoff".
*# sudo swapoff -a*
Para **comprobar si se ha deshabilitado,** se pueden usar varios métodos.
\_# free -h
## swapon -s
## cat /proc/swaps\_
Para que **no se active en el reinicio** y no se pueda usar de ninguna manera **se debe eliminar de la tabla de sistemas de ficheros**, o sea de **"/etc/fstab"** por lo que se debe editar y comentar las líneas donde aparezca la palabra "swap".
*# sudo vim /etc/fstab*
Una vez hecho se pueda **hacer la consulta** con un "cat" (si eres un defensor de los gatos puedes usar cualquier otro comando de visualización) para ver si está correctamente salvado.
*# cat /etc/fstab*
Este proceso de limpieza del fichero "/etc/fstab" también podríamos hacerlo mediante el siguiente comando:
*# sudo sed -i '/ swap / s/^/#/' /etc/fstab*
Este comando basado en "sed" busca la cadena "swap", sin aplicar tipado y hace sitúa una almohadilla "#" que es el símbolo usado para comentar texto.
Paso 1. Deshabilitamos la SWAP para que no haya problemas con los PODS de Kubernetes
Es posible que se desee **cambiar el nombre de la máquina** para identificarlo dentro de nuestra red o por cualquier otro propósito. Este proceso se puede realizar antes de todo el proceso de levantar los Kubernetes, motivo por el que lo comentamos antes de empezar con la operativa en sí.
Se **consulta el nombre** actual mediante el **comando "hostname"**, aunque realmente debería ser visible como parte del prompt de Bash.
*# hostname*
A continuación, para **cambiar el nombre de la máquina** se lanza el comando "sudo hostnamectl set-hostname" seguido por el nuevo nombre y se lanza el comando "exec bash" para que los cambios tomen efecto.
Un ejemplo de todo esto podría ser:
\_# sudo hostnamectl set-hostname
## exec bash\_
Donde:
* \*\*\*\*: Será el nombre que reciba la máquina desde ese momento.
Un ejemplo podría ser:
\_# sudo hostnamectl set-hostname kubernetes-nacho-1
## exec bash\_
Donde:
* "kubernetes-nacho-1" será el nombre que reciba la máquina desde ese momento.
Paso 1. Cambiamos el nombre de la máquina para identificarla en la red como servidor de Kubernetes
El siguiente paso es **configurar el kernel** (núcleo del sistema) con unos **parámetros adicionales para** que **Kubernetes** pueda trabajar correctamente.
Para ello se debe **editar el fichero "/etc/sysctl.conf"** ejecutando los siguientes comandos:
*# sudo tee /etc/modules-load.d/containerd.conf <*\
\&#xNAN;*/etc/containerd/config.toml».*
Después de ejecutar estos comandos, se deberá **modificar el archivo "config.toml"** para localizar la entrada que establece «SystemdCgroup = false" y **cambia su valor «SystemdCgroup = true"**.
*# sudo sed -i 's/ SystemdCgroup = false/ SystemdCgroup = true/' /etc/containerd/config.toml*
Para terminar esta parte se deben **reiniciar los servicios de "contenedord" y "kubelet"** ya que de esta manera se releerá la configuración y se guardaran los cambios.
\_# sudo systemctl restart containerd.service
## sudo systemctl restart kubelet.service\_
Lo normal es que se quiera **iniciar Kubernetes** y por tanto el servicio Kubelet **cada vez que se inicie la máquina,** por lo que se deberá ejecutar el siguiente comando:
*# sudo systemctl enable kubelet.service.*
\\
Paso 2. Preparamos el sistema para el uso de Containered
El siguiente paso es **arrancar el clúster de Kubernetes** en el nodo maestro, con lo que cuando se arranque un plano de control de Kubernetes mediante kubeadm, se implementarán distintos componentes para administrar y orquestar el clúster.
Con el siguiente comando se **descargarán las imágenes de los componentes** (kube-apiserver, kube-controller-manager, kube-scheduler, etcd, kube-proxy).
*# sudo kubeadm config images pull*
Inicializamos el nodo maestro pasándole "--pod-network-cidr" con el rango de direcciones IP que tenemos resevados para la red de POD.
*# sudo kubeadm init --pod-network-cidr=10.0.0.0/16*
\\
Paso 2. Arrancamos el clúster de Kubernetes
En este punto se va a **configurar kubectl,** que es la herramienta con la que se debe administrar el clúster de Kubernetes. Para ello se debe empezar por **crear el el directorio .kube** en el HOME y copiar la configuración de administración del clúster.
\_# mkdir -p $HOME/.kube
## sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config\_
Tras esto se deberá **cambiar la propiedad del archivo** de configuración que se ha copiado para **darle permiso al usuario** para hacer uso del archivo de configuración.
*# sudo chown $(id -u):$(id -g) $HOME/.kube/config*
A continuación se van a **configurar tanto kubectl como Calico,** que serán necesarios para la operación de nuestro servicio de Kubernetes. Para ello será necesario **ejecutar los siguientes comandos en el nodo máster** de manera que se implemente el operador Calico.
*# kubectl create -f* [*https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml*](https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml)
\\
Paso 2. Configuramos Kubctl y Calico en nuestra Ubuntu
El siguiente paso que se debe dar es el de **descargar el archivo de recursos** personalizados para **Calico,** que contiene distintas configuraciones necesarias para el uso de este servicio.
*# curl* [*https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml*](https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml) *-O*
\\
Paso 2. Descargamos los recursos de Calico y configuramos el CDIR de nuestro clúster de Kubernetes
En este punto se debe **modificar el CIDR en el fichero de configuración "custom-resources.yaml"** para que los recursos coincidan con la red de POD que se va a provisionar en nuestro caso.
*# sed -i 's/cidr: 192.168.0.0/16/cidr: 10.0.0.0/16/g' custom-resources.yaml*
En este momento **se le dice a kubectl que lea el contenido del archivo "custom-resources.yaml"** y que **cree los recursos** definidos en ese archivo, para lo que se debe lanzar el siguiente comando:
*# kubectl create -f custom-resources.yaml*
\\
Paso 2. Configuramos el CDIR de nuestro clúster de Kubernetes
Con esto ya debería estar todo configurado dentro de nuestro máster, por lo que pasamos a configurar los workers.
#### **Paso 3. Añadir workers al clúster de Kubernetes**
Ahora que se tiene configurado el nodo máster de nuestro clúster de Kubernetes es tiempo de **agregar los nodos workers al clúster que serán los que realicen el trabajo real**, dejando al máster la tarea de coordinar.
Cuando se inicie el Kubeadm del nodo máster se proporcionará un token que será usado para la adición de esos nodos de trabajo, que serán añadidos mediante el comando "kubeadm join".
\*# sudo kubeadm join :\ --token \ --discovery-token-ca-cert-hash \*
Donde:
* \*\*\*\*: Dirección IP del nodo máster del clúster de Kubernetes.
* \*\*\*\*: Puerto de comunicación, normalmente el "6443".
* \*\*\*\*: Pasamos el token de validación.
* \*\*\*\*: Pasamos el HASH del token para poder hacer las comprobaciones matemáticas.
Con esto ya habríamos sumado los workers a la estructura de Kubernetes y podremos empezar a operar la plataforma.
**NOTA:** *En caso de encontrar algún problema durante este procedimiento, se puede consultar la* [*ayuda a la instalación de Kubernetes*](https://kubernetes.io/es/docs/tasks/tools/included/install-kubectl-linux/){target="*blank" rel="noopener"}*.\_
### **Conclusiones:**
Como puedes ver, **montar un entorno de Kubernetes en Plenit** es algo muy sencillo de hacer siguiendo los pasos que hemos descrito.
En este caso hemos visto cómo desplegar el servicio de Kubernetes en nuestros servidores GNU/Linux, **Ubuntu 22.04** (la última versión disponible a esta fecha) pero puede usarse el mismo procedimiento para otras versiones aplicando ligeros cambios.
Puedes revisar otros tutoriales y artículos relacionados con esta tecnología, de GNU/Linux u otras tecnologías revisando nuestro [blog](https://jotelulu.com/blog/){target="\_blank" rel="noopener"}.
¡Gracias por acompañarnos!
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.plenit.com/support/tutorials/linux/how-to-set-up-kubernetes.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
