Kubernetes en Español | K8s Blog - Casti

  🎯 Introducción En un clúster de Kubernetes, la mayoría de los certificados generados por kubeadm tienen una validez de un año . Para evitar interrupciones en los componentes críticos, es fundamental revisar periódicamente su vigencia y saber cómo renovarlos correctamente. En este artículo aprenderás: Cómo comprobar la expiración de los certificados Cómo renovarlos automáticamente con kubeadm Cómo simular una renovación manual con openssl Cómo aplicar los cambios reiniciando los componentes afectados 🕵️‍♂️ Comprobación del estado de los certificados Kubernetes ofrece una herramienta integrada para revisar los certificados del clúster: kubeadm certs check-expiration Este comando muestra información clave: Fecha de expiración Tipo de certificado Ruta en el sistema 📌 Salida de ejemplo: CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY apiserver Jan 06 , 2026 19 :56 UTC 330d ...

                                                     Kubernetes utiliza certificados TLS (X.509) para cifrar la comunicación entre sus componentes y autenticar identidades (usuarios, nodos, API Server, etc.). Estos certificados son generados y gestionados automáticamente cuando se instala un clúster con kubeadm . En este artículo, veremos dónde se almacenan los certificados , cuál es su estructura y cómo inspeccionarlos fácilmente, una habilidad muy útil para el examen CKA. Cuando creas un clúster con kubeadm , los certificados se generan por defecto en el directorio: /etc/ kubernetes /pki/ Puedes ver su contenido con: ls -l /etc/kubernetes/pki/ También hay certificados en: /etc/kubernetes/ (ahí verás admin.conf , kubelet.conf , etc., que incluyen certificados embebidos, como veremos más abajo). 🧱 Estructura de los ce...

📝 Enunciado: Estás administrando un clúster Kubernetes y necesitas validar, gestionar y reemplazar un certificado TLS caducado del kube-apiserver . Además, debes revisar la autoridad certificadora (CA) utilizada por el clúster y entender el flujo de validación de certificados. 🎯 Objetivos: 🔹 Paso 1: Localiza y examina el certificado TLS usado por el kube-apiserver . 🔹 Paso 2: Comprueba su fecha de expiración y emisor. 🔹 Paso 3: Renueva el certificado manualmente usando openssl (simulación), firmándolo con la CA del clúster. 🔹 Paso 4: Reemplaza el certificado antiguo por el nuevo y reinicia el componente. 🔹 Paso 5: Verifica que el API Server vuelve a estar operativo y el nuevo certificado está en uso. 📦 Datos del entorno: El certificado del API server está en: /etc/ kubernetes /pki/ apiserver.crt La clave privada está en: /etc/ kubernetes /pki/ apiserver.key La CA que firma los certificados está en: /etc/ kubernetes /pki/ ca.crt /etc/ kubernetes /pki/ ca.ke...

  ✅ Solución paso a paso: TLS Bootstrapping manual 🔹 Paso 1: Generar un token bootstrap en el nodo controlplane kubeadm token create --ttl 2h \ --description "Token para worker1 TLS Bootstrapping" Resultado esperado: a1b2c3.d4e5f6g7h8i9j0kl Apunta ese token, lo necesitarás en worker1 . 🔹 Paso 2: Crear el ClusterRoleBinding necesario kubectl create clusterrolebinding kubelet-bootstrap \ --clusterrole=system:node-bootstrapper \ --group=system:bootstrappers Esto permite que los nodos que se unan con ese token puedan solicitar certificados al API Server. 🔹 Paso 3: En el nodo worker1 , configurar el kubelet con el token Primero, aseguramos que el kubelet esté habilitado y configurado. a) Crea el archivo /etc/kubernetes/bootstrap-kubeconfig KUBE_API_SERVER= "https://<IP o nombre del master>:6443" TOKEN= "<tu-token-generado-en-el-paso-1>" kubectl config set-cluster bootstrap \ --server= ${KUBE_API_SERVER} \ --insecure-skip-tls-ve...

 📝 Enunciado: Has recibido acceso a un nodo llamado worker1 que necesita unirse al clúster controlplane . Para este ejercicio, debes configurar correctamente el TLS Bootstrapping del kubelet en worker1 . 🎯 Tareas: 🔹 Paso 1: En el nodo controlplane , genera un token de bootstrap válido que permita a worker1 solicitar un certificado. 🔹 Paso 2: Crea el ClusterRoleBinding necesario para que los nodos nuevos (grupo system:bootstrappers ) puedan solicitar certificados al API Server. 🔹 Paso 3: Desde worker1 , realiza el join al clúster utilizando el token generado. Asegúrate de que el kubelet se inicie automáticamente. 🔹 Paso 4: Verifica desde el nodo controlplane que se ha generado una CSR (Certificate Signing Request) por parte de worker1 . 🔹 Paso 5: Aprueba manualmente la CSR. 🔹 Paso 6: Confirma que el nodo worker1 aparece en el clúster y está en estado Ready . 💡 Tips: Solo puedes utilizar herramientas ya instaladas: kubeadm , kubectl , kubelet , y la...

                                                       Uno de los conceptos que a menudo pasan desapercibidos en la administración de Kubernetes —pero que resultan clave tanto en entornos reales como en el examen CKA— es el TLS Bootstrapping . En este artículo entenderás qué es, cómo funciona, qué lo diferencia del kubeadm join tradicional y cómo puede aparecer en el examen. ¿Qué es TLS Bootstrapping? TLS Bootstrapping es el proceso por el cual el kubelet , el agente que corre en cada nodo, obtiene automáticamente un certificado TLS firmado por el clúster para autenticarse con el kube-apiserver . En otras palabras: permite que un nuevo nodo se una de forma segura al clúster sin necesidad de copiar manualmente los certificados. ¿Por qué es necesario? Cuando añades un nuevo nodo worker, su kubelet necesita autentic...

                                Solución Ejercicio 1, CKA. Bloque 1. Cluster Architecture, Installation & Configuration En este post encontrarás la solución detallada al primer ejercicio simulado del bloque 1 del CKA. Vamos paso a paso: 🔹 Paso 1: Inicialización del clúster Ejecutamos el siguiente comando para inicializar el clúster: kubeadm init --pod-network-cidr=10.244.0.0/16  Este comando cumple con los siguientes requisitos del enunciado: El nombre del nodo se mantiene (es el hostname actual del sistema) Los manifiestos estáticos del plano de control se colocan automáticamente en /etc/kubernetes/manifests , su ubicación por defecto Paso 2: Configurar kubectl como root Una vez finalizado kubeadm init , seguimos las instrucciones sugeridas por su salida para configurar kubectl : mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config s...

                                                       Ejercicio Simulado CKA. 1. Bloque 1 : Cluster Architecture, Installation & Configuration 📝 Enunciado: Has recibido un entorno con un nodo recién instalado llamado controlplane . Necesitas configurar el plano de control de Kubernetes utilizando kubeadm . Completa los siguientes pasos: 🔹 Paso 1 : Inicializa el clúster con kubeadm con las siguientes condiciones: El pod network CIDR debe ser 10.244.0.0/16 El nombre del nodo debe mantenerse como está Debes asegurarte de que los manifiestos estáticos de los componentes del plano de control queden en el directorio por defecto. 🔹 Paso 2 : Una vez inicializado, configura kubectl para que puedas usarlo como usuario root . 🔹 Paso 3 : Revisa que los siguientes componentes estén corriendo como pods en el name...

 Pongo aquí mi experiencia por si le sirve a alguien más. Durante la configuración de mi entorno de pruebas, ejecuté el clásico comando para instalar la red de pods Flannel: kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml Todo parecía correcto, y la salida confirmaba que se habían creado los recursos: namespace/kube-flannel created ... daemonset.apps/kube-flannel-ds created Pero al verificar los pods con: kubectl get pods -n kube-system -l app=flannel Obtuve: No resources found in kube-system namespace. Tras analizarlo me di cuenta que Flannel ya no se instala en kube-system Descubrí que la versión actual del manifiesto de Flannel ya no se despliega en kube-system , sino en un nuevo namespace llamado kube-flannel . Al ejecutar: kubectl get pods -n kube-flannel Pude ver que el pod kube-flannel-ds estaba en ejecución: NAME READY STATUS RESTARTS AGE kube-flannel-ds-qlz9r 1/1 Runnin...

                                                              En este artículo aprenderás a inicializar correctamente un clúster Kubernetes desde cero usando kubeadm, tal como lo podrías encontrar en el examen CKA (Certified Kubernetes Administrator). Asumimos que partes desde un nodo limpio con kubeadm, kubelet y kubectl ya instalados , y que el sistema tiene swap deshabilitado y está preparado para iniciar el plano de control.  Paso 1: Inicializar el plano de control: Ejecuta el siguiente comando para iniciar el clúster con un rango de red de pods compatible con Flannel: kubeadm init --pod-network-cidr=10.244.0.0/16 --pod-network-cidr define el rango de IPs que usarán los pods. Si usarás Calico, puedes usar 192.168.0.0/16 en su lugar. Paso 2: Configurar kubectl para el usuario...

📘 Domina los comandos --help y el uso de less en el examen CKA Durante el examen CKA (Certified Kubernetes Administrator) , uno de los recursos más potentes y completamente permitidos es el uso del --help en los comandos de Kubernetes. Además, puedes combinarlo con el paginador less para buscar y navegar fácilmente entre opciones. ✅ ¿Está permitido usar --help ? Sí, está 100% permitido . Puedes usar el --help de cualquier comando disponible en el entorno del examen: kubectl --help kubeadm init --help kubelet --help kubectl explain pod.spec.containers Estos comandos muestran la ayuda y las opciones disponibles directamente desde el sistema, sin necesidad de ir a la documentación. 🔍 ¿Cómo usar less para buscar rápidamente? Cuando la salida del comando es larga, puedes usar | less para verla de forma paginada y navegar más cómodamente. kubeadm init --help | less Una vez dentro de less , puedes buscar cualquier texto escribiendo /texto . Por ejemplo: /pod-networ...

Kubernetes (K8s) es un sistema de orquestación de contenedores de código abierto que automatiza la implementación, el escalado y la gestión de aplicaciones en contenedores. Diseñado para facilitar el desarrollo de aplicaciones en un entorno cloud-native , Kubernetes ofrece agilidad y resiliencia. ¿Qué es Kubernetes y sus Componentes Clave? Kubernetes se basa en el concepto de cluster , que es un conjunto de máquinas (nodos) que trabajan juntas para ejecutar cargas de trabajo en contenedores. Este cluster es gestionado por un control plane , un conjunto de componentes que supervisan su funcionamiento. Componentes Principales de un Cluster Kubernetes: Nodos: Son las máquinas de trabajo donde se ejecutan los contenedores. Cada nodo cuenta con: kubelet: Un agente que se ejecuta en cada nodo y es responsable de gestionar los contenedores que se ejecutan en él. kube-proxy: Un proxy de red que se ejecuta en cada nodo y es responsable de enrutar el tráfico hacia los contenedores. C...

  El CNI se centra en establecer la conectividad básica para los Pods y garantizar que puedan comunicarse entre ellos y con el mundo exterior, mientras que el kube-proxy gestiona el tráfico a nivel de servicio y balanceo de carga , redirigiendo las solicitudes hacia los Pods correctos. Relación entre ellos CNI configura la conectividad básica para que los Pods puedan comunicarse. kube-proxy utiliza esta conectividad para gestionar el tráfico hacia y desde los Pods, asegurando el balanceo y redirección de tráfico a nivel de servicio. Ambos son esenciales, pero tienen funciones distintas. El CNI actúa a nivel de red básica y el kube-proxy opera en una capa lógica superior, gestionando cómo se distribuye el tráfico dentro del clúster. Funciones del kube-proxy Gestión del tráfico a nivel de servicio: Redirige el tráfico entrante dirigido a un Servicio Kubernetes ( ClusterIP , NodePort , LoadBalancer ) hacia los Pods backend. Creación de reglas de red: Configura reglas de red (iptabl...

Crear y gestionar Secrets en Kubernetes es un aspecto fundamental cuando trabajamos con información sensible, como credenciales o claves de API. A continuación, explico cómo se puede crear un Secret y algunas prácticas importantes al respecto. Ejemplo práctico En este ejercicio práctico, vamos a trabajar con un objeto Secret en Kubernetes: Creación del Secret a partir de un manifiesto YAML : Lo primero que haremos será crear un Secret utilizando un manifiesto YAML. Este procedimiento es similar a lo que hemos hecho anteriormente para otros objetos como ConfigMaps. En este paso, también verificaremos el estado del Secret y cómo recuperarlo de Kubernetes. Esta verificación es útil si queremos revisar el estado actual del objeto para recrearlo o modificarlo más adelante. Durante este proceso, también decodificamos el payload que está codificado en base64, para ver los valores clave que almacena. Comando de creación de un Secret: kubectl create secret generic mysecret --from-literal=use...