Ahora cada vez es más fácil configurar un clúster para instalar Kubernetes desde cero. Existen varias herramientas que facilitan la instalación.
Hay que tener en cuenta que Kubernetes históricamente fue entregado a la CNCF (Cloud Native Computing Foundation) como tecnología semilla, y puesto que Kubernetes viene sin algunos controladores en los binarios, disponemos de servicios gestionados por los proveedores de cloud públicos, para la instalación y gestión de forma más sencilla de Kubernetes.
Para mayor eficiencia y menor complejidad, podemos delegar parte de la gestión de Kubernetes a un Cloud Provider, utilizando los servicios gestionados comentados anteriormente, si disponemos de un equipo experto, se puede instalar Kubernetes on-premise o en hiper virtualizadores para tener un control total del clúster.
Pasos para instalar Kubernetes on-premise en 5 minutos
Paso 0: Prerequisitos
Necesitamos tres máquinas, la primera actuará como master, y el resto como workers, con los siguientes prerrequisitos:
- Sistema Operativo: Ubuntu o CentOS, para esta guia utilizaremos Ubuntu 24.04 LTS.
- Hardware: Un mínimo 2 CPUs y 2 GB de memoria en cada nodo.
- Red: Direcciones MAC y hostnames únicos para los nodos.
Debemos configurar todos los nodos con los módulos del kernel adecuados, y la configuración adecuada para utilizar la red de Kubernetes. Este es el código:
# Deshabilitar la swap para evitar problemas con kubelet
sudo swapoff -a
sudo sed -i ‘/ swap / s/^\(.*\)$/#\1/g’ /etc/fstab
# Cargar los módulos de kernel necesarios
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# Configurar de red para kubernetes
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF
sudo sysctl –system
Paso 1: Instalación de componentes
Instalamos en todas las máquinas del clúster los paquetes necesarios para desplegar el plano de control que son:
- kubeadm
- kubectl
- Docker (containerd)
Nota: En esta guía utilizaremos la versión 1.35, la última versión estable de Kubernetes
Código Containerd
# Instalar containerd
sudo apt-get update
sudo apt-get install -y containerd
# Configurar containerd para utilizar SystemdCgroup
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml > /dev/null
sudo sed -i ‘s/SystemdCgroup = false/SystemdCgroup = true/g’ /etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl enable containerd
Código Kubeadm y kubectl
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gpg
# Descargar la key pública para la última versión
sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.35/deb/Release.key | sudo gpg –dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
# Repositorio kubernetes
echo ‘deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /’ | sudo tee /etc/apt/sources.list.d/kubernetes.list
# Instalar los componentes
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
Paso 2: Inicializar el cluster
Ahora deberíamos tener las tres máquinas listas para instalar Kubernetes.
En el master, ejecutamos:
kubeadm init –pod-network-cidr 192.168.0.0/16
Éste nos devolverá el comando a ejecutar en los workers, similar al siguiente, con los valores de las variables correspondientes:
sudo kubeadm join <MASTER_IP>:6443 –token <TOKEN> \
–discovery-token-ca-cert-hash sha256:<HASH>
Ejecutamos el comando anterior en los dos nodos y ya tendríamos el clúster inicializado.
Sin embargo, quedaría un paso para que el clúster sea completamente funcional.
Paso 3: Instalación red interna
Los pods no pueden comunicarse entre ellos si el clúster no dispone de una Container Network Interface (CNI) instalada. Utilizaremos Calico, el estándar definido para on-premise.
Ejecutaremos el siguiente comando en el master:
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/tigera-operator.yaml
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/custom-resources.yaml
Y… voilà! Ya tenemos un clúster de Kubernetes completamente funcional:
kubectl get no
NAME STATUS ROLES AGE VERSION
k8s-master Ready control-plane 10m v1.35.0
k8s-worker-1 Ready <none> 5m42s v1.35.0
k8s-worker-2 Ready <none> 5m38s v1.35.0
Desplegar Kubernetes en AWS (EKS)
Mediante la herramienta eksctl, podemos desplegar un clúster y su configuración, desde la línea de comandos, de forma sencilla y granular.
Paso 0: Prerrequisitos
Cuenta de AWS con la API de EKS habilitada.
Paso 1: Instalación de eksctl
# Descargar la última versión de eksctl
curl –silent –location «https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz» | tar xz -C /tmp
# Mover el binario
sudo mv /tmp/eksctl /usr/local/bin
eksctl version
Paso 2: Configuración del clúster
Crearemos un YAML de ejemplo con la configuración del clúster, customizable según las necesidades:
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: prod-cluster
region: us-east-1
version: «1.35»
# Habilitar IAM OIDC provider (add-ons)
iam:
withOIDC: true
managedNodeGroups:
– name: general-purpose
instanceType: m6i.large
minSize: 2
maxSize: 5
desiredCapacity: 2
volumeSize: 50
spot: true
labels:
role: worker
tags:
nodegroup-role: worker
# Add-ons recomendados
addons:
– name: vpc-cni
– name: coredns
– name: kube-proxy
– name: aws-ebs-csi-driver
Paso 3: Crear el clúster
Utilizamos el archivo de configuración creado anteriormente para desplegar el nuevo clúster:
eksctl create cluster -f cluster.yaml
Paso 4: accesos
El comando actualiza de forma directa el archivo ~/.kube/config de tu ordenador local, por lo que se puede comprobar directamente el acceso al clúster:
kubectl get nodes
Comprobamos que el clúster está correctamente creado desde la consola de AWS:
Desplegar Kubernetes en GCP (GKE)
Paso 0: Prerrequisitos
Cuenta de GCP con la API de GKE habilitada.
Paso 1: Instalación de gcloud cli
Instalaremos la herramienta gcloud cli para usar la línea de comandos de google cloud.
gcloud components update
gcloud components install gke-gcloud-auth-plugin
# Autenticación
gcloud auth login
gcloud config set project <YOUR_PROJECT_ID>
Paso 2: Creación del clúster
gcloud container clusters create my-standard-cluster \
–region us-central1 \
–num-nodes 1 \
–enable-autoscaling \
–min-nodes 1 \
–max-nodes 5 \
–machine-type e2-standard-4 \
–release-channel stable
Paso 3: Creación del grupo de nodos adicional
gcloud container node-pools create high-memory-pool \
–cluster=my-standard-cluster \
–region=us-central1 \
–machine-type=e2-highmem-4 \
–num-nodes=3 \
–enable-autoscaling \
–min-nodes=1 \
–max-nodes=10 \
–node-labels=env=production,workload=heavy
Paso 4: Accesos
Comprobamos que podemos acceder correctamente al nuevo clúster creado y vemos sus componentes específicos.
# Credenciales
gcloud container clusters get-credentials my-standard-cluster –region us-central1
# Verificar la conexión
kubectl get nodes
Comprobamos que el clúster esté creado correctamente desde la consola de GCP:
¿Puedo migrar mi plataforma a Kubernetes?
Uno de los mayores obstáculos para que una aplicación corra en Kubernetes es el desconocimiento de la tecnología, y la complejidad que puede derivar de este desconocimiento.
Muchos técnicos creen que su aplicación no es apta para correr en Kubernetes porque no utilizan una arquitectura orientada a microservicios.
Y, si bien es cierto que una arquitectura de microservicios es más eficiente y adecuada para correr en Kubernetes, es posible migrar una aplicación monolítica al mismo, para disponer de los muchos beneficios que aporta, como alta disponibilidad, tolerancia ante errores, escalabilidad, gestión de credenciales sensibles, seguridad mejorada, control de cambios entre las versiones…
Para muchas empresas, que disponen de aplicaciones con arquitectura monolítica, migrar a un modelo de microservicios no es algo que esté planeado a corto plazo.
Ahora, esa decisión estratégica no debería impedir que la empresa integre Kubernetes como plataforma para su aplicación, porque aunque no goce de las ventajas que proporciona una arquitectura de microservicios, sí puede aprovechar las múltiples ventajas comentadas anteriormente.
Como conclusión, toda aplicación es apta para correr en Kubernetes, aunque pueden presentarse casos de uso en los que esta opción no es la más adecuada, por ejemplo:
- Bases de datos (cargas de trabajo estáticas)
- Gestión de caché (redis, memcached…)
- Aplicaciones sencillas con criticidad baja y/o necesidad de escalabilidad
En estos casos lo más aconsejable es definir los siguientes componentes, o bien en un servicio gestionado de tu proveedor cloud, para las bases de datos y gestión de caché, y máquinas o una solución serverless para las aplicaciones.
En ACKstorm, somos Managed Service Provider (MSP) y Premier Partner de GCP y AWS. ¡Escríbenos! Estaremos encantados de ayudarte.