Introducción al clúster de Nexus Kubernetes
En este artículo se describen los conceptos básicos del clúster de Nexus Kubernetes, un servicio de Kubernetes administrado que puede usar para implementar y operar aplicaciones en contenedores en plataforma Nexus de operador de Azure
¿Qué es Kubernetes?
Kubernetes es una plataforma de rápida evolución que administra aplicaciones basadas en contenedores y sus componentes de red y almacenamiento asociados. Se centra en las cargas de trabajo de la aplicación, no en los componentes subyacentes de la infraestructura. Proporciona un enfoque declarativo de las implementaciones, respaldadas por un conjunto sólido de API para las operaciones de administración. Consulte ¿Qué es Kubernetes? para obtener información sobre Kubernetes.
Servicio de Nexus Kubernetes
El servicio del clúster de Nexus Kubernetes es una distribución de Kubernetes diseñada para la implementación local en instancias de Nexus. Está diseñado para simplificar la creación automatizada de contenedores y está optimizado para ejecutar cargas de trabajo asociadas a funciones de red que consumen muchos datos.
Al igual que cualquier clúster de Kubernetes, el clúster de Nexus Kubernetes tiene dos componentes:
Plano de control: proporciona servicios principales de Kubernetes y administra el ciclo de vida de las cargas de trabajo de aplicaciones.
Nodos: para ejecutar las aplicaciones y los servicios auxiliares, necesita un nodo de Kubernetes. Proporciona el entorno de runtime del contenedor. Cada clúster de NKS tiene al menos un nodo. El nodo se hospeda en la máquina virtual (VM) que ejecuta los componentes del nodo de Kubernetes. La máquina virtual se crea como parte de la implementación del clúster de NKS en la instancia de Nexus. Hay dos tipos de grupos de nodos en clústeres de Nexus Kubernetes
- Cuando crea un clúster de AKS, define el número de nodos y su tamaño (SKU) inicial, lo cual crea un grupo de nodos del sistema. Los grupos de nodos del sistema hospedan pods críticos del sistema.
- Por otro lado, para admitir aplicaciones que tienen diferentes demandas de proceso o almacenamiento, puede crear grupos de nodos de usuario, también conocidos como grupo de agentes Nexus. Cada máquina virtual de un grupo del agente Nexus se adhiere a una configuración uniforme, como CPU, memoria, disco, etc. Una vez establecido un grupo de agentes, el número de máquinas virtuales dentro de él permanece fijo. Para escalar la capacidad de un clúster de Nexus Kubernetes, se pueden crear y integrar más grupos de agentes en el clúster existente. En otras palabras, el grupo del agente Nexus admite el escalado horizontal al permitir la adición o eliminación de grupos de agentes dentro del clúster de Nexus Kubernetes.
Sin embargo, los pods de aplicación se pueden programar en grupos de nodos del sistema en caso de que el usuario solo quiera un grupo de nodos en su clúster. Cada clúster de Nexus Kubernetes debe contener al menos un grupo de nodos del sistema con al menos un nodo.
Complementos de clúster de Nexus Kubernetes
Los complementos de clúster de Nexus Kubernetes son una característica de la plataforma Nexus que permite a los clientes mejorar sus clústeres de Nexus Kubernetes con paquetes o características adicionales. Los complementos se clasifican en dos tipos: obligatorios y opcionales.
Complementos obligatorios: los complementos se implementan automáticamente en clústeres de Nexus Kubernetes aprovisionados. Los complementos principales, como Calico, MetalLB, Nexus Storage CSI, complementos IPAM, metrics-server, node-local-dns, Arc for Kubernetes y Arc for Servers se incluyen de forma predeterminada cuando se crean clústeres. La finalización correcta del proceso de aprovisionamiento del clúster depende de que estos complementos se instalen correctamente. Si se produce un error en una instalación de complemento necesaria y no se puede corregir, el estado del clúster se marca como erróneo.
Complementos opcionales: los complementos son servicios complementarios asociados a un recurso de clúster de Kubernetes. Los clientes pueden elegir activar o desactivar estos complementos a petición. Por ejemplo, los servicios complementarios podrían incluir la implementación del registro de almacenamiento en caché de imágenes locales de nivel de clúster dentro del clúster de NKS para admitir escenarios desconectados. NKS permite al cliente observar el estado, la salud y la versión de cada complemento obligatorio y opcional, que se puede supervisar en Azure Portal o el estado se puede capturar mediante las API de Azure Resource Manager.
Los complementos se instalan una vez y solo se pueden actualizar o actualizar cuando el cliente actualiza el clúster de Nexus Kubernetes. Permite a los clientes aplicar revisiones críticas de producción sin interferencias de las operaciones de infraestructura subyacentes, lo que podría sobrescribir sus modificaciones del clúster.
Zonas de disponibilidad de Nexus
Nexus ha introducido un concepto de zona de disponibilidad. Se delimita en un nivel de Rack y permite a los clientes distribuir sus cargas de trabajo a través de la instancia para lograr una mejor disponibilidad. Para una instancia de Nexus con ocho bastidores, los clientes obtienen ocho zonas de disponibilidad. Cada zona consta de un par de servidores de administración con redundancia y una colección de servidores de proceso que funcionan como un grupo de recursos. Durante las implementaciones de varios bastidores en Nexus y al realizar actualizaciones de agrupación en tiempo de ejecución, las zonas de disponibilidad proporcionan la ventaja adicional de actuar como un dominio de actualización. Esto garantiza que, como máximo, solo los servidores de un único bastidor se desconectan para estas actualizaciones.
Dominio de error
El operador de Nexus garantiza que los nodos del clúster de Nexus Kubernetes se distribuyan entre dominios de actualización. Esta distribución se realiza de forma que mejore la resistencia y la disponibilidad del clúster. El operador de Nexus usa reglas de afinidad de Kubernetes para programar nodos en zonas específicas. Garantiza que las máquinas virtuales subyacentes no se colocan en el mismo servidor físico o en el mismo dominio de actualización, lo que mejora la tolerancia a errores del clúster.