Administrar clústeres de Kubernetes mediante Kubernetes
Actualmente, Kubernetes admite clústeres muy grandes. Un solo clúster puede admitir 5000 nodos y 150 000 POD. Sin embargo, el mantenimiento y la programación de clústeres a gran escala son demasiado complejos. Por ejemplo, algunas aplicaciones empresariales requieren calificaciones y diferencias. niveles de aplicaciones, es necesario utilizar diferentes grupos de recursos. Algunas aplicaciones comerciales requieren soporte de clúster para GPU, algunas aplicaciones requieren soporte de contenedor de Windows e incluso algunas aplicaciones requieren soporte de contenedor de Windows.
Algunas aplicaciones requieren compatibilidad con contenedores de Windows, e incluso diferentes aplicaciones dependen de diferentes versiones de Kubernetes, por lo que se ha convertido en una práctica recomendada implementar programación de recursos y multiinquilino a través de múltiples clústeres en un entorno empresarial.
Las herramientas y conceptos de administración automatizada son esenciales cuando necesita administrar múltiples clústeres, cada uno con diferentes tamaños, versiones, planes de actualización y grupos de recursos de hardware.
Como todos sabemos, muchos principios y conceptos de Kubernetes han cambiado el modelo tradicional de gestión y entrega de recursos. La introducción de API declarativas y mecanismos de autorreparación ha mejorado la eficiencia de los usuarios para implementar y gestionar aplicaciones. . Permite a los usuarios describir el estado esperado de la implementación del objeto a través de un archivo yaml (por ejemplo, implementar 3 instancias de POD) y observar continuamente el estado actual. Si no coincide con las expectativas (solo quedan 2 instancias de POD), se promoverá. al estado esperado (agregue 1 instancia de POD, lo que lleva el total a 3 esperados).
Dado que este modelo tiene tanto éxito, ¿se puede aplicar a más escenarios? Por ejemplo, ¿es posible utilizar las ideas de Kubernetes para gestionar clústeres de Kubernetes?
De hecho, algunas personas en la comunidad ya lo han hecho, y Cluster API es un proyecto iniciado por Google, Vmware y otros **** en este contexto. /kubernetes-sigs/cluster-api
La API de clúster es un proyecto de Kubernetes que proporciona una API declarativa estilo Kubernetes para la creación, configuración y gestión de clústeres. Al aprovechar la naturaleza estructurada y extensible de la API de Kubernetes, el proyecto crea herramientas de nivel superior independientes de la nube que mejoran de forma declarativa y automática la experiencia del usuario.
Actualmente, la API de Cluster admite la mayoría de entornos de infraestructura como AWS, Azure, GCP, Openstack, VMware, bare metal y más. En la versión actual, la API incluye cinco definiciones de recursos personalizados (CRD):
Combina estas CRD con analogías de objetos familiares de Kubernetes.
Nota: Los siguientes archivos CRD yaml pueden generar plantillas automáticamente, pero no todas las plantillas son necesarias al crear un clúster.
Clúster Este CRD es la nueva abstracción del clúster de Kubernetes. Puede definir la configuración del clúster de Kubernetes, como el CIDR de la red POD y el CIDR de la red de servicios, así como en qué plataforma de nube se ejecuta el clúster.
Una máquina es similar a un POD y se encarga de describir un único nodo de Kubernetes (máquina virtual).
MachineDeloyment es similar a Deployment en que permite actualizar las configuraciones de los nodos, definir cómo actualizar los nodos trabajadores (transmitirlos, recrearlos) y permitir la reversión a una versión anterior de la configuración. Los usuarios pueden modificar el archivo yaml para ajustar dinámicamente la cantidad de nodos del clúster.
MachineSet es similar a ReplicaSet en que puede gestionar la expansión y contracción de conjuntos de máquinas. De manera similar a ReplicaSet, en la práctica debería intentar utilizar MachineDeloyment para administrar la implementación de un conjunto de recursos en lugar de operar ReplicaSet directamente.
MachineClass es similar a StorageClass y define las especificaciones de la máquina. Todos los nodos se clonarán desde la plantilla de la máquina virtual de acuerdo con las especificaciones especificadas.
El principio de funcionamiento de la API del clúster es muy simple. Los usuarios definen las especificaciones del clúster de Kubernetes requerido a través de los CRD anteriores. El yaml se pasará al clúster de administración a través del conocido comando kubectl apply, que impulsará diferentes plataformas en la nube según sea necesario para crear instalaciones de máquinas virtuales para implementar binarios de Kubernetes y entregar el clúster a los usuarios.
Entonces, ¿cuál es el papel del clúster de gestión? ¿Dependen de ello las operaciones posteriores? De hecho, el clúster de gestión inicial suele ser una versión independiente de Kubernetes, como minikube o Kind. Una vez configurado el primer clúster de carga de trabajo, la funcionalidad para administrar el clúster se puede transferir a cualquier clúster de carga de trabajo. Un aspecto interesante es que puede encontrar que el clúster de carga de trabajo también es un clúster de administración, que puede administrarse y monitorearse a sí mismo.
A continuación se muestra un ejemplo del uso de la API del clúster en un entorno vsphere.
Primero, utilice las herramientas proporcionadas por el proyecto Cluster API para generar un conjunto de plantillas yaml de implementación.
Ajuste el contenido del archivo yaml según sea necesario, como el nombre de la plantilla de la máquina virtual, el número de nodos del clúster, etc.
Luego cree estos objetos de recursos en secuencia.
En este momento, puede ver las máquinas virtuales del clúster de Kubernetes creadas una por una en vcenter.
En aproximadamente unos minutos, el clúster de cargas de trabajo estará listo para entregarse a los usuarios.
Podemos simular un escenario de falla apagando o eliminando una máquina virtual en un nodo del clúster de carga de trabajo. La API del clúster detecta automáticamente el estado de todos los nodos e impulsa a vsphere para que reaparezca una máquina virtual en su lugar, dejando el clúster de Kubernetes en el estado descrito anteriormente. ¿Se parece esto a la funcionalidad POD de administración de Kubernetes?
Los detalles específicos de los experimentos anteriores se pueden encontrar en el documento oficial: /kubernetes-sigs/cluster-api-provider-vsphere/blob/master/docs/getting_started.md
Resolver múltiples clústeres El problema de la gestión del ciclo de vida es solo una cuestión de cómo utilizar Kubernetes en el entorno empresarial ¿Qué pasos se deben considerar a continuación?