Cuando desee utilizar Linux para proporcionar servicios a una empresa, esos servicios deberán ser seguros, resistentes y escalables. Bonitas palabras, pero ¿qué queremos decir con ellas?
"Seguro" significa que los usuarios pueden acceder a los datos que necesitan, ya sea acceso de solo lectura o acceso de escritura. Al mismo tiempo, no se exponen datos a ninguna parte que no esté autorizada a verlos. La seguridad es engañosa: puedes pensar que tienes todo protegido solo para descubrir más tarde que hay agujeros. Diseñar con seguridad desde el inicio de un proyecto es mucho más fácil que intentar adaptarlo más tarde.
"Resiliente" significa que sus servicios toleran fallas dentro de la infraestructura. Una falla puede deberse a un controlador de disco del servidor que ya no puede acceder a ningún disco, lo que hace que los datos sean inaccesibles. O la falla puede deberse a un conmutador de red que ya no permite que dos o más sistemas se comuniquen. En este contexto, un "punto único de falla" o SPOF es una falla que afecta adversamente la disponibilidad del servicio. Una infraestructura resistente es aquella que no tiene SPOF.
"Escalable" describe la capacidad de los sistemas para manejar picos de demanda con elegancia. También dicta la facilidad con la que se pueden realizar cambios en los sistemas. Por ejemplo, agregar un nuevo usuario, aumentar la capacidad de almacenamiento o mover una infraestructura de Amazon Web Services a Google Cloud, o incluso moverla internamente.
Tan pronto como su infraestructura se expanda más allá de un servidor, hay muchas opciones para aumentar la seguridad, la resistencia y la escalabilidad. Veremos cómo estos problemas se han resuelto tradicionalmente y qué nueva tecnología está disponible para cambiar la cara de la computación de grandes aplicaciones.
¡Obtenga más Linux!
¿Disfrutas de lo que estás leyendo? ¿Quieres más Linux y código abierto? ¡Podemos entregar, literalmente! Suscríbase hoy a Linux Format a un precio de ganga. Puede obtener ediciones impresas, ediciones digitales o ¿por qué no ambas? Entregamos a su puerta en todo el mundo por una simple tarifa anual. Así que haz tu vida mejor y más fácil, suscríbete ahora!
Para comprender lo que es posible hoy en día, es útil observar cómo se han implementado tradicionalmente los proyectos de tecnología. En los viejos tiempos, es decir, hace más de 10 años, las empresas compraban o alquilaban hardware para ejecutar todos los componentes de sus aplicaciones. Incluso las aplicaciones relativamente simples, como un sitio web de WordPress, tienen múltiples componentes. En el caso de WordPress, se necesita una base de datos MySQL junto con un servidor web, como Apache, y una forma de manejar el código PHP. Entonces, construirían un servidor, configurarían Apache, PHP y MySQL, instalarían WordPress y ya estaban listos.
En general, funcionó. Funcionó lo suficientemente bien que todavía hay una gran cantidad de servidores configurados exactamente de esa manera en la actualidad. Pero no fue perfecto, y dos de los problemas más grandes fueron la resiliencia y la escalabilidad.
La falta de resistencia significaba que cualquier problema importante en el servidor daría lugar a una pérdida de servicio. Claramente, una falla catastrófica significaría que no hay sitio web, pero tampoco hay espacio para llevar a cabo el mantenimiento programado sin afectar el sitio web. Incluso instalar y activar una actualización de seguridad de rutina para Apache requeriría una interrupción del sitio web de unos segundos.
El problema de la resiliencia se resolvió en gran medida mediante la creación de "clústeres de alta disponibilidad". El principio era tener dos servidores ejecutando el sitio web, configurados de manera que la falla de cualquiera de ellos no provocara que el sitio web se cayera. El servicio proporcionado era resistente incluso si los servidores individuales no lo eran.
Nubes abstractasParte del poder de Kubernetes es la abstracción que ofrece. Desde la perspectiva de un desarrollador, desarrollan la aplicación para que se ejecute en un contenedor Docker. A Docker no le importa si se ejecuta en Windows, Linux o algún otro sistema operativo. Ese mismo contenedor de Docker se puede tomar del MacBook del desarrollador y ejecutarlo en Kubernetes sin ninguna modificación.
La propia instalación de Kubernetes puede ser una sola máquina. Por supuesto, muchos de los beneficios de Kubernetes no estarán disponibles: no habrá escalado automático; hay un punto único obvio de falla, y así sucesivamente. Sin embargo, como prueba de concepto en un entorno de prueba, funciona.
Una vez que esté listo para la producción, puede ejecutarlo internamente o en un proveedor de nube como AWS o Google Cloud. Los proveedores de la nube tienen algunos servicios integrados que ayudan a ejecutar Kubernetes, pero ninguno de ellos es un requisito estricto. Si desea moverse entre Google, Amazon y su propia infraestructura, configure Kubernetes y muévase. Ninguna de sus aplicaciones tiene que cambiar de ninguna manera.
¿Y dónde está Linux? Kubernetes se ejecuta en Linux, pero el sistema operativo es invisible para las aplicaciones. Este es un paso significativo en la madurez y usabilidad de las infraestructuras de TI.
El efecto Slashdot
El problema de la escalabilidad es un poco más complicado. Supongamos que su sitio de WordPress recibe 1.000 visitantes al mes. Un día, su negocio se menciona en Radio 4 o en la televisión del desayuno. De repente, obtiene más de un mes de visitantes en 20 minutos. Todos hemos escuchado historias de sitios web que "fallan" y, por lo general, esa es la razón: falta de escalabilidad.
Los dos servidores que ayudaron con la resiliencia pudieron administrar una carga de trabajo mayor que la que podría hacer un servidor solo, pero eso sigue siendo limitado. Pagaría por dos servidores el 100% del tiempo y la mayor parte del tiempo ambos funcionaban perfectamente. Es probable que uno solo pueda administrar su sitio. Luego, John Humphrys menciona su negocio en Hoy y necesitaría 10 servidores para manejar la carga, pero solo por unas pocas horas.
La mejor solución tanto para el problema de la resiliencia como de la escalabilidad fue la computación en la nube. Configure una instancia de servidor o dos, los pequeños servidores que ejecutan sus aplicaciones, en Amazon Web Services (AWS) o Google Cloud, y si una de las instancias fallaba por algún motivo, se reiniciaría automáticamente. Configure el escalado automático correctamente y cuando el Sr. Humphrys haga que la carga de trabajo en las instancias de su servidor web aumente rápidamente, se iniciarán automáticamente instancias de servidor adicionales para compartir la carga de trabajo. Más tarde, a medida que el interés disminuye, esas instancias adicionales se detienen y solo paga por lo que usa. Perfecto … ¿o no?
Si bien la solución en la nube es mucho más flexible que el servidor independiente tradicional, todavía existen problemas. Actualizar todas las instancias en la nube en ejecución no es sencillo. Desarrollar para la nube también presenta desafíos: la computadora portátil que usan sus desarrolladores puede ser similar a la instancia en la nube, pero no es la misma. Si se compromete con AWS, migrar a Google Cloud es una tarea compleja. Y supongamos que, por cualquier motivo, simplemente no desea entregar su computación a Amazon, Google o Microsoft.
Los contenedores han surgido como un medio para empaquetar aplicaciones con todas sus dependencias en un solo paquete que se puede ejecutar en cualquier lugar. Los contenedores, como Docker, pueden ejecutarse en las computadoras portátiles de sus desarrolladores de la misma manera que se ejecutan en sus instancias en la nube, pero administrar una flota de contenedores se vuelve cada vez más desafiante a medida que aumenta la cantidad de contenedores.
La respuesta es la orquestación de contenedores. Este es un cambio significativo de enfoque. Antes, nos asegurábamos de tener suficientes servidores, ya fueran físicos o virtuales, para garantizar que pudiéramos atender la carga de trabajo. El uso del ajuste de escala automático de los proveedores de la nube ayudó, pero todavía estábamos lidiando con instancias. Tuvimos que configurar balanceadores de carga, firewalls, almacenamiento de datos y más manualmente. Con la orquestación de contenedores, todo eso (y mucho más) está resuelto. Especificamos los resultados que requerimos y nuestras herramientas de orquestación de contenedores cumplen con nuestros requisitos. Especificamos lo que queremos que se haga, en lugar de cómo queremos que se haga.
Conviértete en Kubernete
Kubernetes (ku-ber-net-eez) es la herramienta de orquestación de contenedores líder en la actualidad y proviene de Google. Si alguien sabe cómo ejecutar infraestructuras de TI a gran escala, Google lo sabe. El origen de Kubernetes es Borg, un proyecto interno de Google que todavía se utiliza para ejecutar la mayoría de las aplicaciones de Google, incluido su motor de búsqueda, Gmail, Google Maps y más. Borg era un secreto hasta que Google publicó un artículo al respecto en 2015, pero el artículo dejó muy claro que Borg fue la principal inspiración detrás de Kubernetes.
Borg es un sistema que administra recursos computacionales en los centros de datos de Google y mantiene las aplicaciones de Google, tanto de producción como de otro tipo, en ejecución a pesar de fallas de hardware, agotamiento de recursos u otros problemas que ocurren que de otro modo podrían haber causado una interrupción. Lo hace monitoreando cuidadosamente los miles de nodos que componen una “celda” Borg y los contenedores que se ejecutan en ellos, e iniciando o deteniendo contenedores según sea necesario en respuesta a problemas o fluctuaciones en la carga.
El propio Kubernetes nació de la iniciativa GIFEE ("Infraestructura de Google para todos los demás") de Google y se diseñó para ser una versión más amigable de Borg que podría ser útil fuera de Google. Fue donado a la Fundación Linux en 2015 a través de la formación de la Cloud Native Computing Foundation (CNCF).
Kubernetes proporciona un sistema mediante el cual usted "declara" sus aplicaciones y servicios en contenedores, y se asegura de que sus aplicaciones se ejecuten de acuerdo con esas declaraciones. Si sus programas requieren recursos externos, como almacenamiento o balanceadores de carga, Kubernetes puede aprovisionarlos automáticamente. Puede escalar sus aplicaciones hacia arriba o hacia abajo para mantenerse al día con los cambios en la carga, e incluso puede escalar todo su clúster cuando sea necesario. Los componentes de su programa ni siquiera necesitan saber dónde se están ejecutando: Kubernetes proporciona servicios de nombres internos a las aplicaciones para que puedan conectarse a "wp_mysql" y conectarse automáticamente al recurso correcto ".
El resultado final es una plataforma que se puede utilizar para ejecutar sus aplicaciones en cualquier infraestructura, desde una sola máquina a través de un bastidor de sistemas en las instalaciones hasta flotas de máquinas virtuales basadas en la nube que se ejecutan en cualquier proveedor de nube importante, todas usando los mismos contenedores. y configuración. Kubernetes es independiente del proveedor: ejecútelo donde quiera.
Kubernetes es una herramienta poderosa y necesariamente compleja. Antes de entrar en una descripción general, debemos introducir algunos términos que se utilizan en Kubernetes. Los contenedores ejecutan aplicaciones individuales, como se mencionó anteriormente, y se agrupan en grupos. Un pod es un grupo de contenedores estrechamente vinculados que se implementan juntos en el mismo host y comparten algunos recursos. Los contenedores dentro de un pod funcionan en equipo: realizarán funciones relacionadas, como un contenedor de aplicación y un contenedor de registro con configuraciones específicas para la aplicación.
Los cuatro componentes clave de Kubernetes son el servidor API, el programador, el administrador del controlador y una base de datos de configuración distribuida llamada etcd. El servidor API está en el corazón de Kubernetes y actúa como el punto final principal para todas las solicitudes de administración. Estos pueden ser generados por una variedad de fuentes, incluidos otros componentes de Kubernetes, como el programador, administradores a través de la línea de comandos o paneles de control basados en la web, y las propias aplicaciones en contenedores. Valida las solicitudes y actualiza los datos almacenados en etcd.
El Programador determina en qué nodos se ejecutarán los distintos pods, teniendo en cuenta las limitaciones, como los requisitos de recursos, las limitaciones de hardware o software, la carga de trabajo, los plazos y más.
El administrador del controlador monitorea el estado del clúster e intentará iniciar o detener los pods según sea necesario, a través del servidor API, para llevar el clúster al estado deseado. También gestiona algunas conexiones internas y funciones de seguridad.
Cada nodo ejecuta un proceso de Kubelet, que se comunica con el servidor de API y administra los contenedores, generalmente mediante Docker, y Kube-Proxy, que maneja el proxy de red y el equilibrio de carga dentro del clúster.
El sistema de base de datos distribuida etcd deriva su nombre del / etc carpeta en los sistemas Linux, que se utiliza para contener la información de configuración del sistema, más el sufijo "d", que a menudo se utiliza para denotar un proceso demonio. Los objetivos de etcd son almacenar datos de valor clave de forma distribuida, coherente y tolerante a fallos.
El servidor de API mantiene todos sus datos de estado en etcd y puede ejecutar muchas instancias al mismo tiempo. El programador y el administrador del controlador solo pueden tener una instancia activa, pero utilizan un sistema de arrendamiento para determinar qué instancia en ejecución es la maestra. Todo esto significa que Kubernetes puede ejecutarse como un sistema de alta disponibilidad sin puntos únicos de falla.
Poniendolo todo junto
Entonces, ¿cómo usamos esos componentes en la práctica? Lo que sigue es un ejemplo de cómo configurar un sitio web de WordPress usando Kubernetes. Si quisiera hacer esto de verdad, probablemente usaría una receta predefinida llamada tabla de timón. Están disponibles para una serie de aplicaciones comunes, pero aquí veremos algunos de los pasos necesarios para que un sitio de WordPress esté en funcionamiento en Kubernetes.
La primera tarea es definir una contraseña para MySQL:
kubectl crea un mysql-pass genérico secreto --from-literal = password = YOUR_PASSWORD
kubectl hablará con el servidor API, que validará el comando y luego almacenará la contraseña en etcd. Nuestros servicios están definidos en archivos YAML, y ahora necesitamos algo de almacenamiento persistente para la base de datos MySQL.
apiVersion: v1 tipo: PersistentVolumeClaim metadatos: nombre: mysql-pv-reclamo etiquetas: aplicación: wordpress spec: accessModes: - ReadWriteOnce recursos: solicitudes: almacenamiento: 20Gi
La especificación debe ser en su mayoría autoexplicativa. Los campos de nombre y etiquetas se utilizan para hacer referencia a este almacenamiento desde otras partes de Kubernetes, en este caso nuestro contenedor de WordPress.
Una vez que hemos definido el almacenamiento, podemos definir una instancia de MySQL, apuntándola al almacenamiento predefinido. A continuación, se define la base de datos en sí. Le damos a esa base de datos un nombre y una etiqueta para facilitar la referencia dentro de Kubernetes.
Ahora necesitamos otro contenedor para ejecutar WordPress. Parte de la especificación de implementación de contenedores es:
tipo: Metadatos de implementación: nombre: etiquetas de wordpress: aplicación: especificación de wordpress: estrategia: tipo: Recrear
El tipo de estrategia "Recrear" significa que si cambia alguno de los códigos que componen la aplicación, las instancias en ejecución se eliminarán y se volverán a crear. Otras opciones incluyen poder alternar nuevas instancias y eliminar instancias existentes, una por una, lo que permite que el servicio continúe ejecutándose durante la implementación de una actualización. Finalmente, declaramos un servicio para WordPress en sí, que comprende el código PHP y Apache. Parte del archivo YAML que declara esto es:
metadatos: nombre: etiquetas de wordpress: aplicación: especificación de wordpress: puertos: - puerto: 80 selector: aplicación: nivel de wordpress: tipo de interfaz: LoadBalancer
Tenga en cuenta la última línea, que define el tipo de servicio como LoadBalancer. Eso indica a Kubernetes que haga que el servicio esté disponible fuera de Kubernetes. Sin esa línea, este sería simplemente un servicio interno "solo para Kubernetes". Y eso es. Kubernetes ahora usará esos archivos YAML como una declaración de lo que se requiere y configurará pods, conexiones, almacenamiento, etc., según sea necesario para que el clúster esté en el estado "deseado".
Esto ha sido necesariamente solo una descripción general de alto nivel de Kubernetes, y se han omitido muchos detalles y características del sistema. Hemos pasado por alto el ajuste de escala automático (tanto los pods como los nodos que componen un clúster), trabajos cron (contenedores de inicio de acuerdo con un cronograma), Ingress (equilibrio de carga HTTP, reescritura y descarga de SSL), RBAC (controles de acceso basados en roles) , políticas de red (cortafuegos) y mucho más. Kubernetes es extremadamente flexible y extremadamente poderoso: para cualquier nueva infraestructura de TI, debe ser un competidor serio.
Recursos
Si no está familiarizado con Docker, comience aquí: https://docs.docker.com/get-started.
Hay un tutorial interactivo sobre cómo implementar y escalar una aplicación aquí: https://kubernetes.io/docs/tutorials/kubernetes-basics.
Y consulte https://kubernetes.io/docs/setup/scratch para saber cómo crear un clúster.
Puede jugar con un clúster de Kubernetes gratuito en https://tryk8s.com.
Finalmente, puede leer detenidamente un documento técnico extenso con una excelente descripción general del uso de Borg por parte de Google y cómo eso influyó en el diseño de Kubernetes aquí: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.
Obtenga más información sobre Tiger Computing.
- El mejor almacenamiento en la nube de 2022-2023 en línea: opciones gratuitas, de pago y comerciales
¿Disfrutas de lo que estás leyendo? ¿Quieres más Linux y código abierto? ¡Podemos entregar, literalmente! Suscríbase hoy a Linux Format a un precio de ganga. Puede obtener ediciones impresas, ediciones digitales o ¿por qué no ambas? Entregamos a su puerta en todo el mundo por una simple tarifa anual. Así que haz tu vida mejor y más fácil, suscríbete ahora!