Kubernetes – Introducción a los contenedores

Aquí en el departamento de Capacitación y Educación de Percona, siempre estamos trabajando para tratar de mantener nuestros materiales actualizados y relevantes para las tecnologías actuales. Además, vigilemos qué temas están «candentes» y generan mucho revuelo. A menos que haya estado viviendo bajo una roca durante el último año, Kubernetes es la palabra/tecnología actual. Esta es la primera publicación de esta serie de blogs en la que profundizaremos en Kubernetes y descubriremos el uso con Percona XtraDB Cluster.

Descargo de responsabilidad del editor: Esta publicación no pretende convencerlo de que se cambie a un entorno en contenedores. Esta publicación solo tiene la intención de educarlo sobre una tendencia creciente en la industria.

Vamos a empezar desde el principio. Primero, había servidores basados ​​en hardware; todavía tenemos estos hoy. A pesar del predominio de la “nube”, muchas grandes empresas aún utilizan centros de datos privados y ejecutan sus bases de datos y aplicaciones “de la manera tradicional”. Pasando por el hardware, nos adentramos en el territorio de la máquina virtual. Las soluciones populares aquí son VMWare (producto comercial), QEMU, KVM y Virtual Box (los tres últimos son OSS).

Las máquinas virtuales (VM) abstraen el hardware en el que se ejecutan con el software de emulación; esto generalmente se llama un hipervisor. Tal metodología permite que un sistema operativo (SO) completamente separado se ejecute «sobre» el SO que se ejecuta de forma nativa contra el hardware. Por ejemplo, puede tener CentOS 7 ejecutándose en una VM, que a su vez se ejecuta en su computadora portátil Mac, o puede tener Windows 10 ejecutándose en una VM, que se ejecuta en su PC de escritorio Ubuntu 18.

Hay varias cosas buenas sobre el uso de VM en su infraestructura. Uno de ellos es la capacidad de transferir una máquina virtual de un servidor a otro. De manera similar, implementar 10 VM más como la primera generalmente requiere solo un par de clics o algunos comandos. Otro es un mejor uso de los recursos de hardware. Si sus servidores tienen 8 núcleos de CPU y 128 GB de memoria, es posible que la ejecución de una aplicación en ese servidor no utilice todo ese hardware. En su lugar, puede ejecutar varias máquinas virtuales en ese servidor, aprovechando todos los recursos. Además, el uso de una VM le permite agrupar su aplicación y todas las bibliotecas y configuraciones asociadas en una «unidad» que se puede implementar y copiar muy fácilmente (volveremos a eso en un minuto).

Una de las principales desventajas de la solución VM es el hecho de que tiene un sistema operativo completo e independiente en ejecución. Es una gran pérdida de recursos ejecutar una VM CentOS 7 en un servidor de hardware CentOS 7. Si tiene 5 VM CentOS 7 ejecutándose, tiene cinco kernels de Linux separados (además del kernel host), cinco copias separadas de /usr, y cinco copias separadas de las mismas bibliotecas y código de aplicación que ocupan memoria valiosa. Algunos podrían decir que, en esta configuración, el 90-99% de cada VM duplica los esfuerzos que ya realiza el sistema operativo base. Además, cada VM maneja su propia administración de conversión de contexto de CPU. Además, ¿qué sucede cuando una VM necesita un poco más de CPU que la otra? Existe el concepto de CPU «robada» donde una VM puede tomar la CPU de otra VM. ¡Imagínese si fuera su base de datos crítica la que hubiera robado la CPU!

¿Qué pasaría si pudiera eliminar toda esa duplicación, pero aún así darle a su aplicación la capacidad de agruparse e implementarse en docenas o cientos de servidores con unos pocos comandos? Entre: contenedores.

En pocas palabras, un contenedor es un tipo de máquina virtual «ligera» sin toda la sobrecarga de ejecutar un sistema operativo independiente en un hipervisor. Un continuo puede ser tan pequeño como un guión de una sola línea o tan grande .

Con los contenedores, tiene esencialmente todas las «ventajas» que rodean a las máquinas virtuales con muchas menos «contras», principalmente en el área de rendimiento. Un contenedor no es una emulación, como VM. En Linux, el kernel proporciona grupos de control (cgroups) funcionalidad, que puede limitar y aislar la CPU, la memoria, el disco y la red. Esta acción de aislamiento se vuelve continua; todo lo que se necesita es «contenido» en un lugar/grupo. En configuraciones más avanzadas, estos cgrupos también puede limitar/acelerar la cantidad de recursos asignados a cada contenedor. Con contenedores, no hay necesidad de una instalación de sistema operativo adicional; sin emulación, sin supervisor. Debido a esto, puede obtener un «rendimiento casi completo» al usar contenedores.

Los contenedores, y cualquier aplicación que se ejecute en contenedores, operan en su propio espacio de nombres, aislados y, por lo tanto, un contenedor solo puede ver su propio proceso, contenido del disco, dispositivos asignados y acceso a permanecer.

Al igual que las máquinas virtuales, los contenedores se pueden iniciar, detener y copiar de una máquina a otra, lo que facilita la implementación de aplicaciones en cientos de servidores.

Un inconveniente potencial de los contenedores es que son intrínsecamente apátridas. Esto significa que si tiene un contenedor en ejecución y realiza un cambio en su configuración o actualiza una biblioteca, etc., ese estado no se guarda si se reinicia el contenedor. El estado inicial del contenedor lanzado se restaurará al reiniciar. Dicho esto, la mayoría de las implementaciones de contenedores proporcionan un método para proporcionar almacenamiento externo que puede contener información con estado para sobrevivir a un reinicio o redistribución.

Atraca una Nave, Capitán

El concepto de “contenedores” es genérico. Hay muchas implementaciones diferentes de contenedores, como diferentes distribuciones de Linux. La implementación más popular de contenedores en el espacio Linux es Estibador. Docker es un software gratuito de código abierto, pero también se puede vender con una licencia comercial para funciones más avanzadas. Docker se basa en una de las primeras implementaciones de contenedores de Linux, LXC.

Docker utiliza el concepto de «imágenes» para distribuir contenedores. Por ejemplo, puedes descargarlo e instalarlo. Imagen Percona MySQL 8.0 a su servidor, y desde esa imagen, cree tantos contenedores separados e independientes de «Percona MySQL 8» como su hardware pueda manejar. Sin entrar en demasiados detalles sobre las especificaciones, las imágenes de Docker son el resultado final de muchas capas comprimidas que se usaron durante el proceso de construcción de esta imagen. Aquí hay otro profesional para Docker. Si muchas imágenes comparten capas comunes, solo debe haber una copia de esa capa en cada sistema, por lo que el potencial de ahorro de espacio puede ser enorme.

Otra buena característica de los contenedores Docker es su capacidad de versión integrada. Si está familiarizado con el software de control de versiones Git, entonces necesita conocer el concepto de «etiquetas», que es muy similar a las etiquetas de Docker. Estas etiquetas le permiten rastrear y especificar imágenes de Docker al crear y compartir imágenes. Por ejemplo, usando la misma imagen (
percona/perconaservidor ), puede implementar
percona/perconaservidor:5.7 o
percona/perconaservidor:8.0 En este ejemplo, «5.7» y «8.0» son las etiquetas utilizadas.

Docker también tiene un enorme ecosistema comunitario para compartir imágenes. Visita https://hub.docker.com/ y mire casi todos los proyectos populares de OSS y probablemente encontrará que alguien ya ha creado una imagen para que la use.

Demasiados barcos en el puerto

Los contenedores Docker son extremadamente simples de mantener, implementar y usar en su infraestructura. Pero, ¿qué sucede cuando tiene cientos de servidores e intenta administrar miles de contenedores docker? Por supuesto, si un servidor falla, todo lo que tiene que hacer, técnicamente hablando, es volver a lanzar esos contenedores bloqueados en otro servidor. ¿Tienes otro servidor en tu mar de servidores con suficiente capacidad libre para manejar esta carga extra? ¿Qué pasa si usa almacenamiento persistente y necesita que el volumen se mueva con el contenedor? Administrar y administrar grandes instalaciones de contenedores puede volverse confuso rápidamente.

Ahora hablemos del tema de la orquestación del contenedor.

Pronunciado, koo-ber-net-ies, y a menudo abreviado K8S (hay 8 letras entre la «K» y la última «S»), es el proyecto principal actual para administrar contenedores Docker a gran escala. Kubernetes en griego significa «gobernador», «timonel» o «capitán». En lugar de repetirlo aquí, puedes leer más al respecto. la historia de k8s por su cuenta

Terminología

K8S tiene muchas partes móviles en sí mismo, como puedes imaginar. Mira esta imagen.

Kubernetes

Fuente: Wikipedia (modificado)

Nodos

En la parte inferior de la imagen hay dos «nodos de Kubernetes». Estos suelen ser sus servidores de hardware físico, pero también pueden ser máquinas virtuales para su proveedor de nube. Estos nodos tienen instalado un sistema operativo mínimo, junto con otros paquetes necesarios, como K8S y Docker.

Kubelet es un binario de administración utilizado por K8S para proteger los contenedores existentes, realizar controles de estado y lanzar nuevos contenedores.

Proxy de cubo es un servicio de proxy de mapeo de puertos simple. Supongamos que tiene un servidor web simple ejecutándose como contenedor en 172.14.11.109:34223. Sus usuarios finales tienen acceso a una dirección IP externa/pública superior a 443 como de costumbre, y kube-proxy mapeando / dirigiendo ese acceso externo al contenedor interno correcto.

vainas

El siguiente concepto a entender es un vaina. Este suele ser el término base que se usa cuando se habla de lo que se ejecuta en un nodo. Un pod puede ser un solo contenedor o puede ser una configuración completa, correspondiente a varios contenedores, con almacenamiento externo mapeado, que debe agruparse como una sola unidad.

Redes

La creación de redes en K8S es un tema complejo, y una discusión en profundidad no es apropiada para esta publicación. En un nivel de entrada, lo que necesita saber es que K8S crea una red «superpuesta», que permite que un contenedor en un pod en el nodo 1 se comunique con un contenedor en un pod en el nodo 322 que está en otro centro de datos. Si la política de su empresa lo requiere, puede crear varias redes superpuestas en su K8S y utilizarlas como una forma de aislar el tráfico entre los módulos (es decir, piense en las VLAN como módulos de la vieja escuela).

Nodo maestro

En la parte superior del esquema, puede ver al desarrollador/operador interactuando con el nodo principal de K8S. Este nodo realiza varios procesos que son críticos para el funcionamiento de K8S:

kube-apiserver: Un servidor simple para manejar/direccionar/procesar solicitudes de API de otras herramientas de K8S, así como sus herramientas personalizadas

eccd: un almacén de clave-valor de alta disponibilidad. Aquí es donde K8S guarda todos sus datos con estado.

programador de cubos: Administre el inventario y decida dónde lanzar nuevos pods en función de los recursos de nodo disponibles.

Es posible que haya notado que solo hay 1 nodo maestro en el diagrama anterior. Esta es la instalación predeterminada. Esto no está muy disponible y si el nodo principal falla, toda la infraestructura de K8S también lo hará. En un entorno de producción real, se recomienda encarecidamente que ejecute el nodo maestro en un manera altamente disponible.

En esta publicación, analizamos cómo las configuraciones tradicionales basadas en hardware han ido migrando lentamente, primero a configuraciones de máquinas virtuales y ahora a implementaciones en contenedores. Trajimos los problemas relacionados con la gestión de entornos de contenedores grandes e introdujimos el capítulo la orquestación del contenedor plataforma, Kubernetes. Finalmente, nos sumergimos en los diversos componentes y la arquitectura de K8S.

Una vez que haya configurado su clúster K8S con un nodo maestro y varios nodos de trabajo, finalmente puede iniciar algunos pods y tener servicios accesibles. Esto es lo que haremos en la parte 2 de esta serie de blogs.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario