docker Archives - Software Evolutivo

Kubernetes: Arquitectura y Recursos Principales

Jorge Aguilar — Thu, 18 Jul 2024 18:29:50 +0000

En un mundo donde se hace necesario disponer de aplicaciones escalables y que puedan responder a las exigencias de disponibilidad más demandantes, es donde surgen plataformas de orquestamiento de contenedores como Kubernetes. En esta entrada veremos la plataforma Kubernetes, su arquitectura y los recursos principales que la conforman.

¿Qué es Kubernetes?

Kubernetes se puede definir como un sistema de código abierto para la automatización del despliegue, el escalado y la gestión de aplicaciones contenerizadas.
Fue desarrollado por Google y es ampliamente utilizado en la industria para implementar y administrar aplicaciones en la nube privada, pública o híbrida entre estos dos tipos.
Kubernetes se ha convertido en la alternativa de facto cuando se requiere coordinar una gran cantidad de contenedores.

Kubernetes (K8s) se presenta como la respuesta natural al escalamiento de soluciones como Docker, containerd o contenedores en general.

(Si te interesa, en un artículo anterior compartimos los Primeros pasos en Docker).

Su adopción ha sido masiva en todas las industrias, con una tendencia a soluciones provistas en la nube.

Kubernetes no llega para reemplazar a los contenedores, sino más bien a complementarlos, lo que es muy beneficioso para responder a las demandas crecientes que tienen las aplicaciones nativas de la nube.

5 Beneficios Principales de Kubernetes

Kubernetes ofrece muchos beneficios para el despliegue de aplicaciones en entornos empresariales, más allá del escalamiento de la contenerización, así presentamos los siguientes 5 beneficios principales de esta tecnología:

– Escalabilidad Automática: Kubernetes permite escalar automáticamente las aplicaciones según la demanda, aumentando o disminuyendo el número de contenedores en función del tráfico o la carga de trabajo.
– Alta Disponibilidad: Gracias a su arquitectura distribuida y sus mecanismos de autorecuperación, Kubernetes asegura que las aplicaciones estén siempre disponibles, incluso en caso de fallos en los nodos o contenedores.
– Portabilidad y Flexibilidad: Las aplicaciones desplegadas en Kubernetes pueden ejecutarse en cualquier entorno que soporte Kubernetes, ya sea en la nube pública, privada o en entornos híbridos, sin necesidad de cambios significativos.
– Eficiencia en el Uso de Recursos: Kubernetes optimiza la utilización de los recursos del clúster, asignando contenedores a los nodos de manera eficiente y permitiendo un mejor aprovechamiento del hardware.
– Despliegues y Rollbacks Simplificados: Con Kubernetes, es posible realizar actualizaciones y rollbacks de aplicaciones de manera controlada y sin tiempo de inactividad (por ejemplo despliegue blue/green), lo que facilita la implementación de estrategias de integración y entrega continuas (CI/CD).

Arquitectura de Kubernetes

La arquitectura de Kubernetes se divide en dos partes:

Control Plane

El Control Plane es el corazón del sistema y se encarga de la gestión del cluster, así es, estamos hablando de un conjunto de servidores, conocidos como servidores master, trabajando de manera colaborativa. Los componentes principales del Control Plane son:

– API server: Servicios Web del tipo REST que dan acceso a consultas y peticiones sobre el sistema. La interfaz por línea de comandos o la consola Web lo utilizan para realizar las diferentes tareas administrativas y de monitoreo.
– etcd: Es una base de datos distribuida donde se aloja la configuración y el estado del sistema. Se accede a ella mediante el API server.
– scheduler: Es el componente encargado de asignar la nueva carga de trabajo a los nodos del cluster. Éste necesita información actualizada sobre la disponibilidad de los nodos y de los recursos que puedan ofrecer.
controller: Es el que monitorea el estado de los recursos del cluster y toma acciones para asegurarse que se regrese al estado esperado.

Cluster

El Cluster como tal, formado por nodos esclavos (servidores de máquinas virtuales o físicas) y que ejecutan las aplicaciones contenerizadas.

Nodo

Cada nodo ejecuta un agente llamado kubelet, el cuál se comunica con el Control Plane para reportar el estado y conocer sobre nuevos requerimientos. También se encarga de solicitar el inicio o detención de los contenedores en cada uno de los nodos.

Los nodos también ejecutan el kube-proxy de Kubernetes, que se encarga de la comunicación por la red.

Finalmente, tienen al Container runtime, que corresponde al espacio de ejecución de los contenedores, brindando acceso a los recursos de Hardware que puedan requerir, como son: memoria, CPU, red, etc.

Componentes Complementarios

Por otro lado, también podríamos considerar otros servicios que no son, de por sí, parte de Kubernetes pero que lo complementan para brindar soluciones integrales. Estas podrían ser:

– Image Registry: Repositorio de las imágenes de contenedor utilizados para crear los contenedores de las aplicaciones y servicios como por ejemplo una base de datos.
– Load Balancer: Servicio que redirige las peticiones de los clientes para que la carga pueda ser distribuida y también para aislar a los nodos que puedan tener problemas, soportando alta disponibilidad.

Recursos Principales

A continuación detallaremos los recursos que se consideran la base de Kubernetes y que a través de ellos se obtienen los beneficios más importantes de este tipo de soluciones.

Pod

La unidad más pequeña del despliegue en Kubernetes es el Pod y puede contener uno o más contenedores. Entre los contenedores que forman parte de un Pod comparten el mismo espacio de nombres y recursos como la dirección IP o volúmenes de disco, lo que significa que pueden comunicarse entre sí de forma fácil y rápida.

Service

Otro recurso importante de Kubernetes incluye al Service, que es una abstracción de uno o más Pods (están al frente de los Pods y proveen un balanceo de carga), proporcionan una dirección IP más estable que un Pod y además se publica un nombre DNS para facilitar la ubicación del mismo dentro de la red. Los Service se utilizan para que los Pods se comuniquen entre sí, siendo un intermediario, de forma segura y estable.

Deployment

Finalmente tenemos al Deployment, que es el elemento encargado de gestionar y actualizar un conjunto de pods similares. Un Deployment define la plantilla para los Pods y se encarga de crear y mantener la cantidad de los mismos que sean necesarios para cumplir con la especificación deseada. Los deployments también facilitan el despliegue gradual y el rollback de las aplicaciones.

Conclusiones

– Kubernetes como Solución Integral para la Gestión de Contenedores: Kubernetes se ha establecido como una plataforma esencial para la automatización y orquestación de aplicaciones contenerizadas. Su capacidad para escalar aplicaciones de manera automática, gestionar eficientemente los recursos y garantizar alta disponibilidad lo convierte en una solución robusta y adaptable para entornos de nube pública, privada e híbrida.
– Arquitectura de Kubernetes:
Control Plane y Clúster Distribuido: La arquitectura de Kubernetes está diseñada para proporcionar un control centralizado mediante el Control Plane, que gestiona el estado del clúster, y una ejecución distribuida en nodos, que asegura la operación continua de las aplicaciones. Esta separación de funciones permite una gestión eficiente y una recuperación automática ante fallos, mejorando la resiliencia de las aplicaciones.
– Beneficios tangibles de Kubernetes para DevOps: Kubernetes ofrece ventajas significativas en términos de escalabilidad automática, alta disponibilidad, portabilidad y eficiencia en el uso de recursos, lo que lo convierte en una herramienta fundamental para equipos de desarrollo y operaciones que buscan optimizar sus procesos de CI/CD.

Hasta aquí llegamos con esta entrega, para una próxima oportunidad estaremos abordando contenido práctico, donde crearemos recursos como los que hemos analizado previamente.

Esperamos que nos sigas acompañando en esta serie de artículos sobre Kubernetes y te invitamos a dejar tus comentarios o preguntas en la sección inferior. Nos encantaría conocer sobre qué otros temas te gustaría que compartamos. ¡Nos leemos pronto!

Referencias:

– https://kubernetes.io/

Conoce Nuestros Servicios

Escalabilidad sin Límites: Consultoría de Kubernetes para su Empresa

Nuestro enfoque en Kubernetes está diseñado para impulsar la escalabilidad de su infraestructura de TI, a través de la implementación estratégica de contenedores y la orquestación eficiente de aplicaciones y servicios, su infraestructura estará lista para escalar sin límites.

Solicitar DEMO

The post Kubernetes: Arquitectura y Recursos Principales appeared first on Software Evolutivo.

Docker: Primeros pasos

Ariel Altamirano — Thu, 30 Jun 2022 22:55:58 +0000

Docker fue presentado en marzo de 2013 por Solomon Hykes en PyCon como una herramienta para desarrolladores, la cuál permite empaquetar e implementar fácilmente aplicaciones dentro de un contenedor, pero, ¿Qué es un contenedor?

Hykes describió a los contenedores como: unidades autónomas de software que se pueden entregar y desplegar en cualquier servidor ya que están aisladas a nivel de proceso y tienen su propio sistema de archivos, por ende, no son dependientes de librerías o dependencias externas para ejecutarse.

¿Cómo funciona Docker?

Los contenedores se han presentado como una alternativa a la virtualización que usan las máquinas virtuales (VM) debido a los múltiples beneficios que brindan los contenedores, entre ellos está que los contenedores son mucho más livianos que las VMs. Docker es la opción más común para implementar contenedores, sin embargo, existen más opciones como Podman, LXD, entre otros. En la figura 1, podemos ver que cada máquina virtual tiene su propio Sistema Operativo (SO) invitado por encima del Host, a diferencia de los contenedores que comparten el SO del anfitrión (Host) y es por eso que son más livianos.‎

Figura 1. Funcionamiento de Docker y VMs

El hecho de que los contenedores no usen un SO completo ayuda a que sean más livianos, es decir, reduce de gran manera la carga que soporta la máquina anfitriona, además, el espacio de almacenamiento es menor ya que solamente utiliza lo mínimo para funcionar, y el tiempo que necesita para lanzar una aplicación es considerablemente menor a las máquinas virtuales.

Diferencias entre Contenedores y VMs

Las máquinas virtuales nos permiten crear entornos con sistemas operativos totalmente aislados del sistema operativo host, obteniendo así un control total sobre el sistema operativo invitado, de esta manera se puede mezclar diferentes sistemas operativos entre el host y los invitados.

Por otro lado, los contenedores además de permitirnos desplegar aplicaciones de manera más rápida también ayudan a crear entornos de desarrollo replicables entre los diferentes miembros de un equipo de desarrollo y así asegurar que se ejecutará de la misma manera en todos los equipos, independientemente del sistema operativo cada integrante del equipo tendrá el ambiente funcional.

Docker cada vez es más indispensable entre los desarrolladores.

A continuación, en la tabla 1 se presentan las diferencias entre contenedores y VMs.

Contenedores	Máquinas Virtuales
Despliegue en segundos	Despliegue en minutos
Generalmente son ligeros (KB – MB)	Generalmente son pesadas (Mb – Gb)
Pueden compartir el sistema operativo	Tiene un sistema operativo independiente
Usa menos recursos	Usa más recursos
Se pueden destruir y recrear en cuestión de segundos	Se puede exportar e importar en un nuevo host en cuestión de minutos
Por lo general vienen con un ambiente listo para usarse	Se tiene que prepara el ambiente para ser usadas
Se pueden crear en segundos	Su creación lleva más tiempo que los contenedores
Parametrización de límites para el consumo de recursos de la máquina host	Pre aprovisionamiento de recursos de la máquina host

Tabla 1. Diferencias entre contenedores y máquinas virtuales

Arquitectura de Docker

Docker utiliza la arquitectura cliente servidor, en donde, el cliente de Docker tiene el trabajo de comunicarse con el demonio de Docker para que pueda crear, ejecutar o distribuir los contenedores.

Este demonio de Docker puede ser tanto local como puede ser remoto ya que el cliente y el demonio de Docker se comunican mediante una API REST.

Figura 2. Arquitectura de Docker

En la figura 2 se puede observar 3 grandes divisiones:

Client: se encarga de crear un puente de comunicación para que el usuario pueda interactuar con el demonio de Docker mediante diferentes comandos como: docker run.
Docker Host: dentro de esta división se encuentra los contenedores creados por el usuario (Apagados o encendidos), también las imágenes descargadas que se pueden utilizar para crear contenedores, y, finalmente el demonio Docker que escucha las peticiones de la API REST y el cuál administra tanto contendores, imágenes, redes y volúmenes. El demonio de Docker también se puede comunicar con más demonios para administrar los servicios de Docker.
Registry: Los registros de Docker almacenan imágenes de Docker, Docker Hub es un repositorio público y es el repositorio predeterminado de Docker para buscar imágenes y descargarlas mediante comandos como docker pull.

Por qué usar contenedores

Docker brinda un solo objeto para poder ejecutar con total confianza en cualquier equipo, además de que su sintaxis simple brinda el control absoluto de la implementación y por ende la fácil identificación de problemas ya que se maneja por fases.

Entre los muchos beneficios que ofrece Docker, para los desarrolladores se ha vuelto primordial ya que:

Entrega de software aislado con rapidez

Estandarización de operaciones para mayor control de implementación y despliegue

Manejo de código entre diferentes equipos ya sea locales o remotos

Cuando usarlos

Docker facilita la creación y distribución de microservicios por lo que es usado en aplicaciones con arquitectura de microservicios distribuidos, que mediante CI/CD se puede automatizar el despliegue de los mismos y estandarizando los procesos y entornos. Al ser los contenedores independientes y de fácil distribución, también son muy usados para preparar e instalar un entorno de algún servicio para usuarios sin conocimientos técnicos.

Conclusiones:

Facilitan preparar un nuevo ambiente de trabajo independientemente de la máquina anfitriona.
Permiten arrancar aplicaciones rápidamente aprovechando los recursos de hardware.
Se puede mantener un control de versiones para la infraestructura ya que docker se gestiona mediante archivos de texto plano

Referencias

The post Docker: Primeros pasos appeared first on Software Evolutivo.

[:es]Implementación de Liferay 6.2 sobre JBoss 6.4.0 – Como[:]

Fernando Paz — Mon, 12 Sep 2016 17:00:42 +0000

[:es]

Esquema Instalación Liferay sobre JBoss usando Docker. Copyleft www.softwareevolutivo.com.ec

Liferay es un producto para gestionar portales empresariales de información, construido sobre Java y con licenciamiento en Software libre LGPL define a esta tecnología como uno de los actores más importante y con mayores implementaciones en el mercado.

Animados por nuestros valores empresariales que considera al conocimiento como fin social, dejamos una experiencia acerca de este portal y su despliegue en infraestructuras de software modernas.

Antes de continuar con la implementación nos referimos a los productos que usamos como software base:

Docker es una tecnología que implementa contenedores livianos que complementan o sustituyen a las estrategias de virtualización tradicionales. Dado el aprovechamiento masivo del hardware y su rápido despliegue y replicación, es muy utilizado en la tendencia actual de la industria especialmente en áreas como: desarrollo de software, implementación de estrategias de entrega continua y provisión de ambientes de producción con alto crecimiento por demanda.
JBoss EAP, es la versión empresarial de Redhat de un servidor de aplicaciones JEE, con una alta ocupación del mercado y una comprobada comunidad que lo desarrolla y potencia.

Instalación:

El desarrollo de esta instalación de Liferay, está apoyada por documentación existente en proyectos complementarios a este objetivo. Los pasos de estos proyectos complementarios, que serán detallados a continuación, cubren las siguientes actividades:

Definición y creación de un contenedor Docker que contenga una implementación activa del servidor de aplicaciones JBoss 6.4.0.
Definición y creación de un contenedor Docker, a partir del contenedor anterior, que contenga una instalación activa del software Liferay 6.2.
Configuración inicial de software Liferay 6.2.

Docker JBoss 6.4.0:

El primer paso es crear el contenedor Docker que soporte al servidor de aplicaciones JBoss 6.4.0, para este fin se puede revisar otra referencia de cómo podemos realizar esta implementación en https://github.com/pazfernando/jboss-eap-6.4.0-docker.

Es muy importante, en este punto, revisar el README.md de este proyecto debido a que previamente requieren descargar por su cuenta la distribución de JBoss (por cuestiones de licencia) y adicionalmente el contenedor se crea con el nombre “jboss-eap:6.4.0” que es con el que partiremos esta instalación de Liferay 6.2.

Docker Liferay 6.2:

La propuesta de esta implementación de Liferay se basa en el contenedor anterior. La siguiente actividad será crear el contenedor Docker mismo de Liferay a partir del proyecto https://github.com/pazfernando/liferay-6.2-jboss-eap-6.4.0-docker. Este proyecto usa el nombre “jboss-eap:6.4.0” como base de su implementación, y apoyado en esta infraestructura instala el producto Liferay. Para la consecución de esta actividad se debe seguir las instrucciones del archivo README.md.

El nombre “jboss-eap:6.4.0” por su puesto puede cambiar pero requerirá que esté coordinado con el primer proyecto base.

Configuración Liferay 6.2:

Esperamos que en este punto tengan instalado Liferay en esta infraestructura correctamente; Liferay en adelante tiene un wizard el cual lo guiará con los pasos de configuración y datos iniciales. Hasta este momento y como pueden haberlo advertido, no se ha mencionado la base de datos, puesto que la definición de la misma es parte del wizard inicial de configuración de Liferay. Nuestra implementación ha sido pensada para ejecutar el producto sobre el motor Oracle 11g, para lo cual se ha adjuntado y configurado el driver en las actividades previas anteriores.

Recomendaciones finales:

Este proyecto por supuesto es una implementación de una solución para ambientes de desarrollo o testing y requerirá de varios cambios para pensar en una automatización en producción.

Si se requiere profundizar en las configuraciones del producto Liferay en la tecnología JBoss, se puede partir de la URL: https://dev.liferay.com/discover/deployment/-/knowledge_base/6-2/installing-liferay-on-jboss-7-1, estas configuraciones se han automatizado en el contenedor Docker utilizado en este tutorial. Básicamente son los mismos pasos, pero existen especificaciones concretas debido a que JBoss 7.2 fue la última versión antes de que Redhat lo renombrara como JBoss EAP Alpha 6.2; y de ahí en adelante al ser la versión comercial tiene ciertas diferencias a las versión Wildfly que es la comunitaria.

Adicionalmente y como siempre si tiene dudas, comentarios, erratas o algo que decir 🙂 los animamos a comentar en este blog para todos tener un mejor conocimiento y entendimiento.[:]

The post [:es]Implementación de Liferay 6.2 sobre JBoss 6.4.0 – Como[:] appeared first on Software Evolutivo.