Kubernetes, también abreviado como K8s, es una plataforma de código abierto para automatizar y orquestar la implementación, el escalamiento y la gestión de aplicações y cargas de trabajo en contenedores. Proporciona infraestructura computacional con flexibilidad, escalabilidad, confiabilidad, alta disponibilidad y portabilidad integradas para aplicaciones que se ejecutan como contenedores en cualquier entorno: local, en la nube y en el borde.
Kubernetes automatiza las tareas más comunes asociadas con la gestión de cargas de trabajo en contenedores a escala, incluidos la implementación, el equilibrio de carga, el escalamiento horizontal, las implementaciones y reversiones, y la autorreparación.
Muchas organizaciones ya están utilizando Kubernetes en producción, ya sea para algunas o para la mayoría de sus aplicaciones, y otras lo están evaluando. Su popularidad ha convertido a Kubernetes en el estándar de facto para la orquestación y gestión de contenedores.
La adopción de Kubernetes está creciendo rápidamente porque puede ayudar a:
La refactorización de aplicações monolíticas tradicionales en partes más pequeñas y débilmente acopladas, llamadas microservicios , ayuda a mejorar la agilidad empresarial porque las nuevas características y actualizaciones de las aplicaciones se pueden lanzar más rápido y escalar más fácilmente. La adopción de una arquitectura de microservicios nativa de la nube impulsa la necesidad de evolucionar la infraestructura informática subyacente, por lo que observamos la transición de sistemas físicos y máquinas virtuales a contenedores como una de las formas más eficientes de ejecutar microservicios.
A medida que crece la cantidad de microservicios y contenedores, también aumenta la necesidad de automatizar la gestión de contenedores. Aquí es donde entra en juego Kubernetes.
Kubernetes orquesta y ejecuta aplicaciones en contenedores a escala; sin embargo, no proporciona los medios para empaquetar el código de la aplicação en un formato en contenedores para su distribución y ejecución (una imagen de contenedor incluye el código de la aplicación y los entornos de ejecución, bibliotecas y otras dependencias de software necesarios). Para que los pods se ejecuten, Kubernetes también requiere que se instale un entorno de ejecución de contenedor en cada nodo. Kubernetes utilizó originalmente Docker Engine como entorno de ejecución del contenedor. Sin embargo, a partir de Kubernetes 1.24, el entorno de ejecución del contenedor debe cumplir con la Interfaz de tiempo de ejecución del contenedor (CRI), algo que Docker Engine no hace. Dos entornos de ejecución de contenedores compatibles con CRI populares son CRI-O y containerd (originalmente un proyecto Docker).
Para empaquetar aplicaciones en contenedores, necesitas una herramienta como Docker , una de las herramientas más populares para crear, compartir y ejecutar aplicaciones en contenedores. Optimiza y automatiza el empaquetado de aplicaciones en imágenes de contenedores portátiles que están listas para ejecutarse e implementarse localmente, en la nube, incluso en entornos de Kubernetes. Los contenedores empaquetados en Docker se pueden ejecutar de forma nativa en los entornos de ejecución containerd y CRI-O.
Una plataforma Kubernetes está formada por nodos que se unen entre sí en un clúster donde comparten recursos informáticos agrupados. Cada clúster administra pods, que son las unidades implementables más pequeñas en la arquitectura de Kubernetes. Un pod contiene uno o más contenedores de aplicaciones. Los pods se agrupan para formar un servicio. Se puede acceder a las aplicaciones dentro de un clúster de Kubernetes desde el exterior mediante varios métodos , siendo el controlador Ingress uno de los más populares y eficientes.
Echemos un vistazo más de cerca a los componentes en un entorno de Kubernetes:
Un pod de Kubernetes es la unidad ejecutable más pequeña que se puede implementar en Kubernetes. El pod es un “host virtual” para la imagen o imágenes del contenedor de la aplicación (como un servidor físico o una máquina virtual para aplicaciones tradicionales) y encapsula uno o más contenedores que comparten los mismos recursos de computación, almacenamiento y red (y, por lo tanto, pueden considerarse acoplados de forma relativamente estrecha). Los pods se implementan y ejecutan en los nodos de Kubernetes.
Un nodo de Kubernetes es la unidad más pequeña de una infraestructura informática. El nodo puede ser una máquina virtual o un servidor físico que asigna recursos de procesador, memoria, almacenamiento y red para implementar, ejecutar, escalar y administrar pods. Los nodos se unen entre sí para formar un clúster.
Un clúster de Kubernetes es un grupo de nodos donde los recursos computacionales agrupados se comparten entre pods. Hay dos tipos de nodos en un clúster:
Normalmente, hay más de un nodo de cada tipo en un clúster de Kubernetes, para lograr alta disponibilidad y tolerancia a fallas.
Una implementación de Kubernetes describe cómo ejecutar una aplicación como un conjunto de réplicas (o instancias) del pod en un clúster. Una implementación define:
Kubernetes admite una pila dual IPv4/IPv6 para proporcionar conectividad de red para aplicaciones en contenedores que se ejecutan en un clúster. Tanto la comunicación hacia y desde las aplicaciones en el clúster de Kubernetes como la comunicación entre servicios dentro del clúster se administran en la Capa 4 (dirección IP, puerto) y la Capa 7 (nombre de host, identificador universal de recursos [URI]) e incluyen capacidades de enrutamiento, equilibrio de carga, seguridad, monitoreo y visibilidad.
En el modelo de red de Kubernetes , cada pod tiene una dirección IP única que se asigna dinámicamente desde el grupo de direcciones privadas del clúster. Todos los pods que se ejecutan en todos los nodos del mismo clúster pertenecen a la misma red IP y pueden comunicarse entre sí a través de esa red. Varios contenedores dentro de un pod se comunican entre sí a través de la interfaz de bucle invertido.
Un servicio de Kubernetes hace que la aplicación o el microservicio que se ejecuta como uno o más pods en el clúster sean accesibles (“los expone”) en la red. Un servicio de Kubernetes representa la aplicación como un grupo lógico de pods designados que realizan la misma función, por ejemplo, servicio web. El mismo selector (o etiqueta) se aplica a todos los pods de un servicio para marcar su membresía en el servicio. Kubernetes usa la etiqueta para rastrear el conjunto de pods de un servicio a medida que se implementan nuevos pods o se finalizan los pods en ejecución.
Los servicios de Kubernetes pueden comunicarse entre sí dentro del clúster de acuerdo con las políticas de conectividad definidas y pueden hacerse accesibles desde fuera del clúster, por ejemplo, mediante un controlador de Ingress.
El objeto Ingress, una parte de la API Ingress de Kubernetes, se puede utilizar para exponer externamente aplicações que se ejecutan en Kubernetes a través de protocolos de capa 7 (capa de aplicação ) como HTTP. Las puertas de enlace de Ingress y los controladores de Ingress son herramientas diseñadas para controlar el objeto de Ingress y administrar las comunicaciones entre usuarios y aplicações (conectividad de usuario a servicio o norte-sur).
Por diseño, el objeto Ingress tiene un soporte limitado para políticas de manejo de solicitudes personalizadas; por ejemplo, no se pueden definir ni adjuntar políticas de seguridad a él. Como resultado, muchos proveedores utilizan definiciones de recursos personalizadas (CRD) para ampliar las capacidades de sus controladores Ingress, como una forma de satisfacer los requisitos cambiantes de los clientes.
A modo de ejemplo, NGINX Ingress Controller define recursos personalizados (VirtualServer, VirtualServerRoute, TransportServer y Policy) para mejorar el rendimiento, la resiliencia, el tiempo de actividad, la seguridad y la capacidad de observación para la puerta de enlace de API, el balanceador de carga y la funcionalidad de Ingress en el borde de un clúster de Kubernetes.
NGINX proporciona servicios de equilibrio de carga, autenticación, autorización, control de acceso, cifrado, observabilidad y división de tráfico (disyuntor, pruebas A/B e implementaciones azul-verde y canario) para garantizar que la comunicación sea rápida, confiable y segura. Para respaldar los lanzamientos frecuentes de aplicaciones, los recursos personalizados de NGINX también permiten la gobernanza de autoservicio en equipos de desarrollo de múltiples inquilinos y DevOps.
Gateway API es un proyecto de código abierto destinado a mejorar y estandarizar la red de servicios en Kubernetes. Administrada por la comunidad de Kubernetes, la especificación de la API de Gateway evolucionó a partir de la API de Ingress de Kubernetes para resolver las limitaciones del recurso de Ingress en entornos de producción, incluida la capacidad de definir políticas detalladas para el procesamiento de solicitudes y delegar el control sobre la configuración en múltiples equipos y roles.
Obtenga más información sobre la implementación de la API Gateway de NGINX en 5 cosas que debe saber sobre NGINX Gateway Fabric en nuestro blog.
Una malla de servicios es una capa de infraestructura que controla las comunicaciones entre servicios en un clúster de Kubernetes (conectividad de servicio a servicio o de este a oeste). Los casos de uso de malla de servicio más comunes incluyen autenticación/encriptación mTLS y capacidad de observación de las comunicaciones que ocurren entre servicios en un clúster K8s.
Obtenga más información sobre la entrega unificada de aplicaciones con NGINX Gateway Fabric , que está diseñada para combinar de manera efectiva los casos de uso del controlador de Ingress y la malla de servicio en una sola herramienta en Anuncio de NGINX Gateway Fabric versión 1.0 en nuestro blog.
La seguridad de Kubernetes es un enfoque en capas para proteger la infraestructura (recursos informáticos locales y en la nube, comunicaciones de red y plano de administración) y las aplicações que se ejecutan dentro de un clúster de Kubernetes.
Para proteger la infraestructura, siga las recomendaciones de seguridad generales, los tutoriales y las mejores prácticas para proteger las implementaciones locales y en la nube.
Para aplicações seguras, implemente controles de seguridad sólidos en el borde y dentro de un clúster de Kubernetes para proporcionar autenticación, autorización, control de acceso, cifrado, monitoreo y visibilidad, con firewall de aplicação web opcional y protección contra denegación de servicio, para todas las comunicaciones hacia/desde y dentro de un clúster.
Lea más sobre cómo proteger Kubernetes en nuestro blog Seis formas de proteger Kubernetes mediante herramientas de gestión de tráfico .
En los primeros días de la adopción de Kubernetes, el enfoque "hágalo usted mismo" (DIY) era dominante; sin embargo, es complejo y difícil de construir y operar para muchas organizaciones. Debido a esto, para las implementaciones de producción, las organizaciones están adoptando plataformas Kubernetes administradas en la nube y distribuciones Kubernetes preempaquetadas que integran varios componentes tecnológicos, simplificando el ciclo de vida del mantenimiento y pueden implementarse en entornos híbridos y de múltiples nubes.
A continuación se muestran algunos ejemplos de plataformas Kubernetes administradas y preempaquetadas:
Kubernetes administrado en la nube:
Distribuciones de Kubernetes preempaquetadas:
La pila de seguridad y conectividad nativa de Kubernetes de NGINX ayuda a mejorar las experiencias de los clientes con menor complejidad, mayor tiempo de actividad y visibilidad detallada en tiempo real a escala para aplicações de Kubernetes que se ejecutan en las instalaciones, en la nube y en el borde.
Pila de conectividad para Kubernetes : optimice, escale y proteja las aplicaciones de Kubernetes en entornos híbridos y de múltiples nubes.
Comience solicitando su prueba gratuita de 30 días de NGINX Ingress Controller con NGINX App Protect WAF y DoS.