Transfórmate en un Power User!

  En este artículo, profundizaremos en el uso de los Persistent Volume Claims (PVC) en Kubernetes y veremos cómo se configuran mediante ejemplos prácticos. A través de estos ejemplos, aprenderás a manejar volúmenes de almacenamiento para cargas de trabajo persistentes, tanto de forma estática como dinámica. ¿Qué es un Persistent Volume Claim (PVC)? Un PVC (Persistent Volume Claim) es un recurso que define las características del almacenamiento que una aplicación necesita, como el tamaño, el modo de acceso y, opcionalmente, una clase de almacenamiento específica. Kubernetes se encarga de asignar automáticamente un PVC con un Persistent Volume (PV) que cumpla con esos requisitos. Ejemplo Básico de PVC Un manifiesto básico para crear un PVC que solicita 10Mi de almacenamiento con acceso exclusivo (ReadWriteOnce): apiVersion: v1 kind: PersistentVolumeClaim metadata: name: cka-simple-pvc spec: storageClassName: "" # Configura como vacío para evitar usar StorageCla

 En Kubernetes, además de poder crear volúmenes persistentes de manera estática, también existe la capacidad de aprovisionar dinámicamente volúmenes mediante el uso de StorageClass . Estas clases permiten definir perfiles de almacenamiento, proporcionando un mecanismo flexible y escalable para satisfacer las necesidades específicas de las cargas de trabajo. ¿Qué es una StorageClass? Una StorageClass en Kubernetes es un recurso que describe cómo debe gestionarse el almacenamiento dinámico en el clúster. Define un conjunto de parámetros que determinan el tipo de almacenamiento, sus características, el aprovisionador que se utilizará y cómo se manejarán los volúmenes cuando ya no sean necesarios. Esto facilita la creación automatizada de volúmenes sin necesidad de intervención manual del administrador. Ejemplo de StorageClass A continuación, presentamos un manifiesto YAML para crear una StorageClass en Kubernetes que aprovisiona volúmenes de almacenamiento utilizando Amazon Elastic Bloc

En este artículo vamos a profundizar en cómo Kubernetes maneja el almacenamiento y cómo puedes usar diferentes tipos de volúmenes, tanto persistentes como efímeros, según tus necesidades. Además, aprenderemos a configurar Persistent Volumes (PV) y Persistent Volume Claims (PVC) para administrar el almacenamiento de forma eficiente. Visión general del almacenamiento en Kubernetes Kubernetes maneja el almacenamiento utilizando volúmenes , que pueden ser discos o subdirectorios compartidos entre los pods. Estos volúmenes se dividen principalmente en dos tipos: Volúmenes Persistentes (Persistent Volumes) : Estos sobreviven a los ciclos de vida del pod, es decir, permanecen disponibles incluso después de que el pod haya sido reiniciado o eliminado. Son esenciales para aplicaciones que requieren almacenamiento de datos permanente, como bases de datos. Volúmenes Efímeros (Ephemeral Volumes) : Estos volúmenes solo existen durante la vida del pod y se eliminan cuando el pod es terminado. Son ú

  El almacenamiento en Kubernetes es uno de los pilares fundamentales para asegurar la persistencia de los datos y su correcta gestión en aplicaciones distribuidas. A medida que las aplicaciones modernas requieren mayor resiliencia y escalabilidad, es crucial entender cómo Kubernetes maneja y abstrae los recursos de almacenamiento para poder integrarlos de manera eficiente en los clústeres. En este bloque, vamos a sumergirnos en los conceptos y prácticas clave de almacenamiento en Kubernetes , enfocándonos en los volúmenes efímeros y persistentes, las clases de almacenamiento (Storage Classes) y las reclamaciones de volúmenes persistentes (PVC). Estos son los componentes esenciales que permiten a Kubernetes separar las preocupaciones de almacenamiento del ciclo de vida de los pods, proporcionando flexibilidad y persistencia de datos a largo plazo. Temas que abordaremos Volúmenes Efímeros Exploraremos los volúmenes efímeros, los cuales son creados y eliminados junto con el pod. Este ti

El servicio SSH (Secure Shell) es una herramienta fundamental para acceder de forma remota a servidores Linux de manera segura. En este artículo, te guiaré paso a paso para verificar que el servicio SSH esté instalado y en funcionamiento en distribuciones basadas en Debian/Ubuntu y RedHat/CentOS/Fedora .  En mi caso lo uso habitualmente para iniciar máquinas virtuales (Virtualbox) sin pantalla y acceder a ellas, en remoto, mediante SSH. 1. ¿Qué es el servicio SSH? SSH permite la administración remota de sistemas Linux a través de una conexión cifrada, lo que asegura que la información transmitida no sea interceptada ni manipulada. Es utilizado por administradores de sistemas para gestionar servidores de manera eficiente desde cualquier lugar. 2. Verificar si el servicio SSH está instalado En distribuciones basadas en Debian/Ubuntu: Primero, asegúrate de que los paquetes del sistema estén actualizados: sudo apt update Luego, instala el servidor SSH si no lo tienes instalado. El paque

 El Período de Gracia de Terminación ( Termination Grace Period ) en Kubernetes es el tiempo que Kubernetes le otorga a un pod antes de ser finalizado por completo. Cuando un pod es marcado para ser eliminado (por ejemplo, cuando se realiza un escalado hacia abajo o un kubectl delete pod ), Kubernetes le da al contenedor un tiempo para que realice una terminación ordenada, en lugar de finalizarlo de inmediato. Detalles del proceso de terminación: Señal SIGTERM : Cuando un pod es eliminado, Kubernetes envía primero una señal SIGTERM a los procesos dentro del contenedor. Esta señal permite a las aplicaciones manejar su propia finalización, cerrando conexiones abiertas, liberando recursos, y guardando datos si es necesario. Período de Gracia : El período de gracia es el tiempo que Kubernetes espera para que el contenedor finalice de manera ordenada. En tu caso, el período de gracia es de 30 segundos . Señal SIGKILL : Si después del período de gracia el pod no ha terminado, Kubernetes e

El desarrollo y la automatización están avanzando rápidamente con herramientas como Bolt.NEW y Auto-GPT , ambas destacadas por su capacidad para simplificar y automatizar procesos que antes requerían intervención humana.  Bolt.NEW: Desarrollo de Aplicaciones en un Solo Prompt.   Bolt.NEW permite la creación de aplicaciones completas a partir de un único prompt . Con esta herramienta, los desarrolladores pueden describir su aplicación, y la plataforma automáticamente genera bases de datos, lógica de negocio, y la interfaz de usuario sin necesidad de codificación manual. Paso a Paso: El Prompt : La magia comienza introduciendo un prompt detallado que describe la funcionalidad de la aplicación. Aquí, Bolt.NEW toma el control y se encarga del resto. Generación Automática : Bolt.NEW analiza el prompt y automáticamente genera la estructura de la aplicación, crea las bases de datos necesarias y establece la lógica detrás de la funcionalidad principal. Puedes incluso especificar detalles c

Con el comando kubectl get , puedes obtener una lista de los diferentes recursos que están corriendo en tu clúster de Kubernetes:  PODS : kubectl get pods Obtiene una lista de los pods en el namespace actual. DEPLOYMENTS : kubectl get deployments Muestra los deployments que están corriendo en tu clúster. SERVICES : kubectl get services Obtiene una lista de los servicios expuestos en el clúster. REPLICASETS : kubectl get replicasets Muestra los ReplicaSets asociados a tus deployments. NAMESPACES : kubectl get namespaces Muestra una lista de los namespaces en el clúster. NODES : kubectl get nodes Lista los nodos que componen el clúster. CONFIGMAPS : kubectl get configmaps Obtiene una lista de los ConfigMaps que están disponibles. SECRETS : kubectl get secrets Muestra todos los secretos disponibles. EVENTS : kubectl get events Lista los eventos del clúster. DAEMONSETS :      kubectl get daemonsets         Muestra los DaemonSets corriendo en tu clúster. STATEFULSETS :      kubectl get stat

 Cuando hablamos de Recursos API para Cargas de Trabajo  (Workloads) en Kubernetes, nos referimos a los recursos que interactúan con la API RESTful de Kubernetes . Esta API es el núcleo que gestiona todo en el clúster de Kubernetes, permitiendo a los usuarios, aplicaciones, y controladores internos realizar acciones sobre los componentes de Kubernetes a través de solicitudes HTTP. Los Recursos API son las entidades que defines y administras en Kubernetes para gestionar y orquestar las aplicaciones y servicios. Ejemplos de estos recursos API incluyen Pods , Deployments , ReplicaSets , Services , Ingress , entre otros. Estos recursos son gestionados mediante interacciones con la API RESTful de Kubernetes a través de comandos como kubectl o directamente enviando solicitudes HTTP al servidor API. Por qué se llaman Recursos API El término "Recursos API" hace referencia a: RESTful API : Kubernetes utiliza un modelo RESTful, donde los recursos son accesibles mediante un conjunto

En el mundo de la virtualización y la infraestructura moderna, los términos máquinas virtuales y contenedores son fundamentales. Aunque ambos permiten aislar aplicaciones, tienen enfoques y características muy distintos que los hacen adecuados para diferentes escenarios. En este artículo, exploraremos sus diferencias, sus ventajas y desventajas, y cómo elegir la mejor opción para tus necesidades. ¿Qué es una Máquina Virtual? Una máquina virtual (VM) es una emulación completa de un sistema operativo que se ejecuta sobre un hipervisor. El hipervisor es una capa de software que permite ejecutar múltiples máquinas virtuales sobre el mismo hardware físico. Las VMs incluyen su propio sistema operativo, lo que significa que cada una tiene una copia completa de este, junto con todos los recursos virtualizados (CPU, memoria, almacenamiento, etc.). Ejemplo de uso de máquinas virtuales : Imagina que tienes un servidor físico con 16 GB de RAM y 8 núcleos de CPU. Podrías crear dos máquinas virtu

  El uso de Ingress en Kubernetes es una práctica esencial para gestionar el acceso a los servicios de una forma centralizada y eficiente. Los recursos Ingress permiten definir reglas para enrutar el tráfico HTTP y HTTPS hacia los servicios internos, proporcionando una manera de exponer múltiples servicios a través de un único punto de entrada. 1. Creación de Recursos de Ingress Los recursos de Ingress se pueden crear utilizando el comando kubectl create ingress , especificando reglas que indican cómo redirigir el tráfico hacia los servicios correspondientes. Esto es particularmente útil cuando se quiere exponer varios servicios en rutas específicas. Ejemplos de creación de Ingress: $ kubectl create ingress ingress-a --rule=/base/path-a=service-a:6330 --namespace workload-a --class nginx --annotation nginx.ingress.kubernetes.io/rewrite-target=/ $ kubectl create ingress ingress-b --rule=/base/path-b=service-b:6331 --namespace workload-b --class nginx --annotation nginx.ingress.kuberne

  En esta guía, vamos a desplegar aplicaciones en Kubernetes y a exponerlas a través de un controlador de Ingress NGINX, permitiendo así que las aplicaciones sean accesibles desde fuera del clúster de una forma controlada. Este es un paso esencial para cualquier administrador de Kubernetes, ya que permite gestionar el tráfico entrante de forma segura y organizada. 1. Crear Namespaces de Trabajo Los namespaces en Kubernetes permiten separar recursos en diferentes espacios lógicos, lo que facilita la organización y el control de acceso. Aquí crearemos dos namespaces, workload-a y workload-b , para alojar nuestras aplicaciones. $ kubectl create ns workload-a namespace/workload-a created $ kubectl create ns workload-b namespace/workload-b created 2. Crear e Implementar los Despliegues y Servicios A continuación, vamos a desplegar dos aplicaciones básicas (una con httpd y otra con nginx ) y a exponerlas mediante servicios de tipo ClusterIP . Desplegar las aplicaciones y exponerlas como