Diferencias

Muestra las diferencias entre dos versiones de la página.

--- kubernetes [2025/06/03 22:20]
fmolinuevo [Introducción a Kubernetes en Debian 12 con Docker]
+++ kubernetes [2025/08/26 15:04] (actual)
fmolinuevo [Configuración de parámetros pysctl requeridos (net.bridge.bridge-nf-call-iptables, net.ipv4.ip_forward)]
@@ Línea 3: / Línea 3: @@
 ===== Introducción a Kubernetes =====
-Kubernetes es una plataforma de código abierto diseñada para la automatización del despliegue, escalado y gestión de aplicaciones en contenedores. Su arquitectura permite agrupar de manera inteligente los contenedores que componen una aplicación en unidades lógicas, facilitando su gestión y descubrimiento. Un clúster de Kubernetes se compone fundamentalmente de un Plano de Control y uno o más Nodos Trabajadores. El Plano de Control es responsable del estado global del clúster y de la orquestación, albergando componentes como el Servidor API, etcd, el Planificador (Scheduler) y el Gestor de Controladores (Controller Manager). Por otro lado, los Nodos Trabajadores son las máquinas donde se ejecutan las cargas de trabajo de las aplicaciones, cada uno con un Kubelet, Kube-proxy y un tiempo de ejecución de contenedores.
+Kubernetes es una plataforma de código abierto diseñada para la automatización del despliegue, escalado y gestión de aplicaciones en contenedores. Su arquitectura permite agrupar de manera inteligente los contenedores que componen una aplicación en unidades lógicas, facilitando su gestión y descubrimiento. Un clúster de Kubernetes se compone fundamentalmente de un Control Plane y uno o más Nodos Worker. El Plano de Control es responsable del estado global del clúster y de la orquestación, albergando componentes como el Servidor API, etcd, el Planificador (Scheduler) y el Gestor de Controladores (Controller Manager). Por otro lado, los Nodos Worker son las máquinas donde se ejecutan las cargas de trabajo de las aplicaciones, cada uno con un Kubelet, Kube-proxy y un tiempo de ejecución de contenedores.
 Es fundamental aclarar el papel de Docker en las configuraciones modernas de Kubernetes. Desde la versión 1.22, Kubernetes ya no utiliza directamente Docker Engine como su tiempo de ejecución de contenedores principal. En su lugar, Kubernetes interactúa con tiempos de ejecución de contenedores que cumplen con la Container Runtime Interface (CRI). Docker Engine, de hecho, incluye containerd, que es un tiempo de ejecución robusto, estándar de la industria y compatible con CRI. Por lo tanto, al instalar Docker Engine, se instala efectivamente containerd, que es el componente que Kubernetes utilizará para gestionar los contenedores. Esta distinción es vital para comprender la arquitectura subyacente y para una resolución de problemas efectiva.
 La razón detrás de esta aclaración radica en la evolución de Kubernetes. Originalmente, Docker Engine era el tiempo de ejecución predeterminado, pero la tendencia en el desarrollo de Kubernetes ha sido hacia una CRI estandarizada, que abstrae los motores de contenedores específicos. Esto significa que, si bien las herramientas de Docker (como docker build para crear imágenes) siguen siendo muy relevantes, el componente de tiempo de ejecución dentro de Kubernetes es containerd. Esta distinción es crucial para una configuración correcta y estable, ya que gestiona las expectativas del usuario y evita posibles confusiones durante la resolución de problemas; por ejemplo, por qué docker ps podría no mostrar directamente los pods gestionados por Kubernetes.
+Desarrollada por Google, permite orquestar contenedores en múltiples hosts. Con Kubernetes, se puede configurar el balanceo de carga entre contenedores y ejecutar varios contenedores en múltiples sistemas.
+Es compatible con servidores físicos locales, OpenStack, y nubes públicas como Google, Azure, AWS, y otras.
 ===== Características =====
@@ Línea 31: / Línea 35: @@
 //Figura 2. Componentes de un cluster Kubernetes//
-===== I. Requisitos del Sistema y Preparación Inicial =====
+===== I. Requisitos del sistema y preparación inicial =====
@@ Línea 39: / Línea 43: @@
 La elección del hardware es un factor crítico que influye directamente en la estabilidad y el rendimiento del clúster de Kubernetes.
-==== Requisitos Mínimos para un Nodo de Kubernetes (Control plane o Worker) ====
+==== Requisitos mínimos para un nodo de Kubernetes (Control plane y Worker) ====
   * RAM: Se requieren 2 GB o más de RAM por máquina. Una cantidad inferior dejará muy poco espacio para las aplicaciones, lo que conducirá a una degradación significativa del rendimiento
@@ Línea 46: / Línea 50: @@
   * Identificadores: Cada nodo debe poseer un nombre de host, dirección MAC y product_uuid únicos
-==== Especificaciones Recomendadas para Clústeres Pequeños (por ejemplo, Desarrollo/Pruebas) ====
+==== Especificaciones recomendadas para clústeres pequeños (por ejemplo, Desarrollo/Pruebas) ====
-  * Nodo Maestro: Se recomienda priorizar al menos 8 GB de RAM y una CPU de múltiples núcleos. Esto asegura operaciones más fluidas del plano de control, especialmente para etcd
+  * Nodo Master: Se recomienda priorizar al menos 8 GB de RAM y una CPU de múltiples núcleos. Esto asegura operaciones más fluidas del plano de control, especialmente para etcd
   * Nodo Worker: Se aconsejan al menos 4 GB o más de RAM por nodo worker
   * Almacenamiento: Aunque un SSD SATA de 120 GB es suficiente para un pequeño clúster de prueba de Kubernetes, un SSD NVMe con mayores IOPS es fuertemente recomendado para un mejor rendimiento de etcd y una mayor capacidad de respuesta general del plano de control. El rendimiento de etcd es crucial para la estabilidad del clúster
@@ Línea 60: / Línea 64: @@
 ^ Categoría ^ Requisito Mínimo (Por Nodo) ^ Recomendado (Para Clústeres Pequeños) ^ Notas/Consideraciones ^
 | CPU | 2 CPUs o más (Plano de Control) | Multi-núcleo | - |
-| RAM | 2 GB o más | 8 GB+ (Maestro), 4 GB+ (Worker) | Menos RAM dejará poco espacio para las aplicaciones |
+| RAM | 2 GB o más | 8 GB+ (Master), 4 GB+ (Worker) | Menos RAM dejará poco espacio para las aplicaciones |
-| Almacenamiento | Suficiente para SO y contenedores | SSD NVMe (para etcd en Maestro) | Un SSD SATA de 120 GB es suficiente para pruebas |
+| Almacenamiento | Suficiente para SO y contenedores | SSD NVMe (para etcd en Master) | Un SSD SATA de 120 GB es suficiente para pruebas |
 | Red | Conectividad de red completa | Gigabit Ethernet | Red pública o privada |
 | Sistema Operativo | Linux compatible (Debian-based) | Debian 12 | - |
 | Identificadores | Nombre de host, MAC, product_uuid únicos | - | - |
-==== Actualización de Debian 12 e Instalación de Paquetes Esenciales ====
+==== Actualización de Debian 12 e instalación de paquetes esenciales ====
 Antes de iniciar cualquier instalación significativa, es una práctica fundamental asegurar que el sistema Debian 12 esté completamente actualizado. Este paso refresca las listas de paquetes y actualiza los paquetes existentes, mitigando posibles conflictos de dependencias o vulnerabilidades de seguridad.
@@ Línea 72: / Línea 76: @@
   apt update && apt upgrade
-Posteriormente, se instalan los paquetes de dependencia necesarios tanto para Docker como para Kubernetes. Estos incluyen ca-certificates (para verificar conexiones SSL/TLS), curl (para transferir datos con URLs, utilizado para descargar claves GPG), gnupg (para gestionar claves GPG) y apt-transport-https (para permitir que apt obtenga paquetes a través de HTTPS).
+Posteriormente, se instalan los paquetes de dependencia necesarios tanto para Docker como para Kubernetes. Estos incluyen ca-certificates (para verificar conexiones SSL/TLS), curl (para transferir datos con URLs, utilizado para descargar claves GPG), gnupg (para gestionar claves GPG) y apt-transport-https (para permitir que apt obtenga paquetes a través de HTTPS). Y también los utilitarios que precisemos.
-  apt install ca-certificates curl gnupg apt-transport-https -y
+  apt install mc screen rsync iptraf ccze zsh htop gnupg curl apt-transport-https ca-certificates software-properties-common
 Este paso inicial es crucial porque establece una base estable y segura para la compleja instalación de Kubernetes. Al asegurar que todos los paquetes estén actualizados y que las herramientas necesarias para la gestión de repositorios y claves GPG estén presentes, se previenen de manera proactiva muchos problemas comunes relacionados con dependencias y versiones de software.
@@ Línea 99: / Línea 103: @@
 La salida debería mostrar overlay y br_netfilter listados. La necesidad explícita de estos módulos del kernel subraya la profunda integración de Kubernetes con la pila de red del kernel de Linux. Un fallo en la carga de br_netfilter en particular es una causa común de problemas de red fundamentales dentro del clúster, impidiendo que los pods se comuniquen entre sí o con servicios externos. Esto a menudo se manifiesta como errores CrashLoopBackOff para pods críticos del kube-system (por ejemplo, pods de plugins CNI, CoreDNS), lo que hace que el clúster no sea funcional y sea difícil de diagnosticar sin un conocimiento previo de este prerrequisito.
-==== Configuración de Parámetros Sysctl Requeridos (net.bridge.bridge-nf-call-iptables, net.ipv4.ip_forward) ====
+==== Configuración de parámetros sysctl requeridos (net.bridge.bridge-nf-call-iptables, net.ipv4.ip_forward) ====
 Kubernetes requiere que se configuren parámetros sysctl específicos del kernel para un enrutamiento de paquetes de red y una funcionalidad de iptables adecuados dentro del clúster.
@@ Línea 132: / Línea 136: @@
   ufw reload
-==== Deshabilitar permanentemente del swap ====
+==== Deshabilitación permanente del swap ====
 La documentación de Kubernetes establece explícitamente que la memoria de intercambio (swap) debe estar deshabilitada. Esto se debe a que el planificador de Kubernetes y kubelet no pueden contabilizar de manera fiable el uso de la memoria de intercambio, lo que lleva a un comportamiento impredecible de los pods, a la inanición de recursos y, potencialmente, a errores de CrashLoopBackOff para cargas de trabajo críticas. Dejar el swap habilitado puede resultar en problemas de rendimiento desconocidos y comprometer la capacidad del planificador para tomar decisiones óptimas de ubicación.
@@ Línea 191: / Línea 195: @@
 Este paso instala directamente containerd.io, que, como se aclaró en la introducción, es el tiempo de ejecución real compatible con CRI que utilizará Kubernetes. Esto alinea el proceso de instalación con la arquitectura moderna de Kubernetes.
-==== Verificación de la Instalación de Docker y Gestión del Servicio Docker ====
+==== Verificación de la instalación de Docker y gestión del servicio Docker ====
 Después de la instalación, es importante verificar que Docker Engine esté correctamente instalado y operativo.
@@ Línea 211: / Línea 215: @@
 Estos pasos son verificaciones estándar posteriores a la instalación y prácticas de gestión de servicios. Aseguran que Docker no solo esté instalado, sino también en ejecución y configurado para persistir después de los reinicios, lo cual es fundamental para un entorno Kubernetes estable.
-==== Adición de usuario sin privilegios al grupo Docker (opcional pero recomendado) ====
+==== Adición de usuario sin privilegios al grupo docker (opcional pero recomendado) ====
 Por defecto, interactuar con el demonio de Docker requiere privilegios sudo. Para simplificar las operaciones diarias y evitar tener que escribir constantemente sudo antes de los comandos de Docker, es altamente recomendable añadir al usuario no root al grupo docker.
@@ Línea 225: / Línea 229: @@
 Este paso mejora significativamente la experiencia del usuario al permitir la interacción directa con Docker sin privilegios elevados. Aunque es opcional, es una mejora común en la calidad de vida para desarrolladores y administradores que trabajan frecuentemente con contenedores, y también una buena práctica de seguridad para evitar el acceso constante como root.
-===== III. Configuración del Tiempo de Ejecución de Contenedores y Kubelet para Kubernetes =====
+===== III. Configuración del tiempo de ejecución de contenedores y kubelet para Kubernetes =====
 La correcta configuración de los controladores de cgroup es un aspecto crítico para la estabilidad de un clúster de Kubernetes.
@@ Línea 282: / Línea 286: @@
 Aunque el comportamiento predeterminado de kubeadm para el controlador cgroup de kubelet simplifica la configuración inicial para las versiones más recientes, definir explícitamente cgroupDriver: systemd en un archivo kubeadm-config.yaml eleva la configuración de una dependencia implícita de los valores predeterminados a una infraestructura como código explícita y controlada por versiones. Este enfoque proactivo mejora la claridad de la configuración, asegura la coherencia en los despliegues y actúa como una salvaguarda contra posibles cambios o regresiones no deseados durante futuras actualizaciones de Kubernetes, lo cual es un aspecto clave de una gestión robusta del sistema.
-===== IV. Instalación de Componentes de Kubernetes (kubeadm, kubelet, kubectl) =====
+===== IV. Instalación de componentes de Kubernetes (kubeadm, kubelet, kubectl) =====
 Los componentes principales de Kubernetes son esenciales para la gestión del clúster.
@@ Línea 320: / Línea 324: @@
 Este paso instala los componentes centrales que permiten la creación del clúster, la gestión de nodos y la interacción del usuario con Kubernetes. Sin estos, un clúster de Kubernetes no puede formarse ni gestionarse.
-==== Retención de Versiones de Paquetes para Prevenir Actualizaciones Accidentales ====
+==== Retención de versiones de paquetes para prevenir actualizaciones accidentales ====
 Una vez que kubeadm, kubelet y kubectl están instalados, es críticamente importante "retener" sus versiones. Kubernetes tiene políticas estrictas de desviación de versiones (por ejemplo, kubelet no debe tener más de dos versiones menores de antigüedad o ser más reciente que el kube-apiserver, y kubectl debe estar dentro de una versión menor). Una actualización apt upgrade accidental podría actualizar estos paquetes a versiones incompatibles, lo que llevaría a la inestabilidad del clúster, fallos de comunicación o incluso un colapso completo del clúster. La retención asegura que las versiones permanezcan fijas, evitando interrupciones no deseadas.
@@ Línea 330: / Línea 334: @@
 Este paso es vital para la estabilidad y el mantenimiento a largo plazo del clúster de Kubernetes. Al "retener" las versiones de estos componentes críticos, se previene que las actualizaciones automáticas o accidentales de paquetes rompan la compatibilidad del clúster, lo que podría resultar en fallos operacionales significativos y difíciles de diagnosticar.
-===== V. Inicialización del Plano de Control de Kubernetes (Nodo Maestro) =====
+===== V. Inicialización del Control Plane de Kubernetes (Nodo Master) =====
 La inicialización del plano de control es el primer paso para establecer el clúster de Kubernetes.
@@ Línea 347: / Línea 351: @@
 ==== Inicialización del Plano de Control con kubeadm init ====
-El comando kubeadm init es el encargado de arrancar el nodo maestro del clúster de Kubernetes. Realiza una serie de verificaciones previas para validar el estado del sistema y luego procede a configurar los componentes del plano de control, generar certificados y establecer la configuración inicial del clúster.
+El comando kubeadm init es el encargado de arrancar el nodo Master del clúster de Kubernetes. Realiza una serie de verificaciones previas para validar el estado del sistema y luego procede a configurar los componentes del plano de control, generar certificados y establecer la configuración inicial del clúster.
-Para inicializar el plano de control, se utiliza el siguiente comando. Se debe reemplazar <dirección_ip_del_servidor_api> con la dirección IP de la máquina donde se está instalando el nodo maestro. El pod-network-cidr debe coincidir con el rango elegido para el plugin CNI que se instalará posteriormente. Si el swap no se deshabilitó previamente, se puede añadir --ignore-preflight-errors=Swap para continuar, aunque no es lo recomendado :
+Para inicializar el plano de control, se utiliza el siguiente comando. Se debe reemplazar <dirección_ip_del_servidor_api> con la dirección IP de la máquina donde se está instalando el nodo Master. El pod-network-cidr debe coincidir con el rango elegido para el plugin CNI que se instalará posteriormente. Si el swap no se deshabilitó previamente, se puede añadir --ignore-preflight-errors=Swap para continuar, aunque no es lo recomendado :
   kubeadm init --apiserver-advertise-address <dirección_ip_del_servidor_api> --pod-network-cidr <su_pod_network_cidr>
@@ Línea 357: / Línea 361: @@
   kubeadm init --apiserver-advertise-address 192.168.1.100 --pod-network-cidr 10.244.0.0/16
-La salida de este comando proporcionará información crucial, incluyendo los pasos para configurar kubectl y el comando kubeadm join necesario para que los nodos trabajadores se unan al clúster. Es vital guardar esta salida, ya que contiene el token y el hash del certificado CA necesarios para la unión de nodos.
+La salida de este comando proporcionará información crucial, incluyendo los pasos para configurar kubectl y el comando kubeadm join necesario para que los nodos worker se unan al clúster. Es vital guardar esta salida, ya que contiene el token y el hash del certificado CA necesarios para la unión de nodos.
 ==== Configuración del acceso a kubectl para usuarios no privilegiados ====
@@ Línea 379: / Línea 383: @@
 ==== Eliminación del taint del nodo Master (opcional para clústeres de un solo nodo) ====
-Por defecto, kubeadm aplica un "taint" al nodo maestro (node-role.kubernetes.io/control-plane:NoSchedule). Este taint evita que los pods de carga de trabajo se programen en el nodo maestro, reservándolo para los componentes del plano de control. En un clúster de producción con múltiples nodos trabajadores, esto es deseable. Sin embargo, para un clúster de un solo nodo (donde el nodo maestro también actuará como nodo trabajador), este taint debe eliminarse para permitir que las cargas de trabajo se ejecuten en él.
+Por defecto, kubeadm aplica un "taint" al nodo Master (node-role.kubernetes.io/control-plane:NoSchedule). Este taint evita que los pods de carga de trabajo se programen en el nodo Master, reservándolo para los componentes del plano de control. En un clúster de producción con múltiples nodos Worker, esto es deseable. Sin embargo, para un clúster de un solo nodo (donde el nodo Master también actuará como nodo Worker), este taint debe eliminarse para permitir que las cargas de trabajo se ejecuten en él.
-Para eliminar el taint del nodo maestro, se utiliza el siguiente comando (reemplazando <nombre_del_nodo_maestro> con el nombre real del nodo, que se puede obtener con kubectl get nodes):
+Para eliminar el taint del nodo Master, se utiliza el siguiente comando (reemplazando <nombre_del_nodo_master> con el nombre real del nodo, que se puede obtener con kubectl get nodes):
-  kubectl taint nodes <nombre_del_nodo_maestro> node-role.kubernetes.io/control-plane:NoSchedule-
+  kubectl taint nodes <nombre_del_nodo_master> node-role.kubernetes.io/control-plane:NoSchedule-
-Este paso es opcional y depende del diseño del clúster. Si se planea tener un clúster con nodos trabajadores dedicados, este paso no es necesario.
+Este paso es opcional y depende del diseño del clúster. Si se planea tener un clúster con nodos Worker dedicados, este paso no es necesario.
 ===== VI. Instalación de un plugin de Container Network Interface (CNI) =====
@@ Línea 440: / Línea 444: @@
 kube-system   calico-node-txngh   1/1     Running   0          54s
-===== VII. Verificación del Estado y Salud del Clúster =====
+===== VII. Verificación del estado y salud del clúster =====
 Una vez que todos los componentes están instalados, es fundamental verificar la salud y el estado operativo del clúster de Kubernetes.
@@ Línea 506: / Línea 510: @@
 Para futuras implementaciones y entornos de producción, se recomienda considerar las siguientes acciones:
-  * Clústeres Multi-Nodo: Para alta disponibilidad y escalabilidad, se debe planificar la adición de nodos trabajadores al clúster utilizando el comando kubeadm join generado durante la inicialización del maestro.
+  * Clústeres Multi-Nodo: Para alta disponibilidad y escalabilidad, se debe planificar la adición de nodos Worker al clúster utilizando el comando kubeadm join generado durante la inicialización del Master.
   * Almacenamiento Persistente: Para cargas de trabajo con estado, es esencial configurar soluciones de almacenamiento persistente (por ejemplo, volúmenes persistentes con un aprovisionador de almacenamiento) para asegurar que los datos no se pierdan si los pods se reinician o se mueven.
   * Monitoreo y Logging: Implementar soluciones robustas de monitoreo (como Prometheus y Grafana) y logging centralizado (como ELK Stack o Loki) es crucial para la observabilidad del clúster y la resolución proactiva de problemas.

AXR Informática: documentación

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página