Utilice el mecanismo de Admission Webhook para lograr el control de la cuota de recursos de varios clústeres

1 Problema por resolver

Cuando el clúster se asigna a varios usuarios, es necesario utilizar cuotas para limitar el uso de recursos del usuario, incluida la cantidad de núcleos de CPU, el tamaño de la memoria y la cantidad de tarjetas GPU, para evitar que algunos usuarios agoten los recursos, lo que resultará en una asignación de recursos injusta.

En la mayoría de los casos, un ResourceQuotamecanismo nativo de clúster puede resolver el problema. Pero con la expansión del tamaño del clúster y el aumento de los tipos de tareas, necesitamos ajustar las reglas de administración de cuotas:

ResourceQuotaPara el diseño de un solo clúster, pero de hecho, el desarrollo / producción se utiliza a menudo en un entorno de varios clústeres .
Para la mayoría de las tareas, tales como los clústeres deployment, mpijoby otras confirmaciones de objetos de recursos de alto nivel , esperamos que la fase de confirmación de objetos de recursos de alto nivel pueda juzgar la cuota. Sin embargo, ResourceQuotaal calcular la podgranularidad de la solicitud de recursos , que no puede satisfacer esta demanda.

En base a los problemas anteriores, debemos realizar la gestión de cuotas por nosotros mismos. Y Kubernetes proporciona un mecanismo de admisión dinámico que nos permite escribir complementos personalizados para lograr la admisión de solicitudes. Nuestro plan de gestión de cuotas comienza con esto.

2 Principios de la admisión dinámica de clústeres

Una vez que el servidor API recibe la solicitud para ingresar al clúster K8s, pasará por las siguientes etapas de ejecución secuencial:

Autenticación / Autenticación
Control de acceso (cambio)
Verificación de formato
Control de acceso (verificación)
Resistencia

La solicitud se procesará en consecuencia en las primeras cuatro etapas mencionadas anteriormente, y se juzgará si se permite aprobar. Una vez que hayan pasado todas las etapas, puede persistir, es decir, almacenarse en la base de datos etcd, que se convierte en una solicitud exitosa. Entre ellos, se llamará la fase de control de admisión (cambio)mutating admission webhook , se podrá modificar el contenido de la solicitud. En la fase de control de admisión (verificación) , validating admission webhookse llamará y se podrá comprobar si el contenido solicitado cumple ciertos requisitos, para determinar si permitir o denegar la solicitud. Estos webhookapoyan la expansión, se pueden desarrollar e implementar de forma independiente en el clúster.

Aunque la etapa de control de admisión (cambio) , webhooktambién puede examinar y rechazar la solicitud, pero no puede garantizar que se llame a la orden, no puede restringir la webhookmodificación de otras solicitudes de recursos. Por lo tanto, implementamos cuotas para verificación validating admission webhook, organizadas en llamadas de fase de control de admisión (validación) , verificamos el recurso solicitado, puede lograr propósitos de administración de cuotas de recursos.

3 plan

3.1 Cómo implementar el servicio de verificación en el clúster

Utilice la costumbre en el clúster de K8 validating admission webhookpara implementar:

ValidatingWebhookConfigurationConfiguración (necesidad de permitir cúmulo ValidatingAdmissionWebhook), que se utiliza para definir objetos a los recursos (lo que pod, deployment, mpijobetc.) para la verificación, y para proporcionar una dirección para el servicio de devolución de llamada de verificación de la transformación real. Recomendado en una Serviceforma de configuración de clúster para proporcionar la dirección del servicio de calibración.
El proceso real de los servicios de verificación a través de la ValidatingWebhookConfigurationconfiguración de direcciones accesibles puede ser.

Un entorno de clúster único, servirá para verificar deploymentla forma en que se implementa en un clúster. En un entorno de varios clústeres, puede elegir:

Utilice kubelet virtual, federación de clústeres y otras soluciones para fusionar varios clústeres en un solo clúster, que degenera en una implementación de un solo clúster.
El servicio de verificación en deloymentel desplegado uno o más clústeres, pero conduce a la red de servicios de comunicación para cada clúster.

Cabe señalar que si se trata de un entorno de un solo clúster o de varios clústeres, la verificación del procesamiento del servicio requiere la supervisión de recursos, que generalmente se implementa en un solo punto. Por tanto, es necesario elegir al maestro.

3.2 Cómo implementar el servicio de verificación

3.2.1 Diseño de la arquitectura del servicio de validación

3.2.1.1 Composición de los componentes básicos

Utilice el mecanismo de Admission Webhook para lograr el control de la cuota de recursos de varios clústeres

Servidor de la API : solicitud de clúster de entrada, llamadas validating admission webhooka la solicitud de verificación
API : interfaz de servicio de acceso, utilizando la estructura de datos AdmissionReview acordada por el clúster como solicitud y devolución
Servicio de uso de cuotas : solicitar interfaz de uso de recursos
Admisiones : la implementación del servicio de acceso, incluyendo deploymenty mpijobdiferentes tipos de acceso a los recursos
Validador de recursos : verificación de cuotas para solicitudes de recursos
Adaptador de cuota : conéctese al servicio de cuota externo para que el validador consulte
Administrador de uso de recursos : administrador de uso de recursos , mantener el uso de recursos, realizar juicios de cuotas
Informadores : K8 proporcionados por el mecanismo de vigilancia para monitorear los recursos del clúster, incluidos deploymenty mpijob, para mantener el uso actual de los recursos.
Almacenar : Almacene los datos de uso de recursos, que se pueden realizar al conectarse a la memoria local del servicio o al conectarse al servicio Redis

3.2.1.2 El proceso básico de determinación de cuotas de recursos

deploymentRecursos creados por el usuario , por ejemplo:

El usuario para crear deploymentrecursos debe incluir la definición de la información del grupo de aplicaciones que se especifica annotation, por ejemplo ti.cloud.tencent.com/group-id: 1, como se usa en este documento, representa un grupo de 1recursos de la aplicación (si no hay información de grupo con la aplicación, dependiendo de la escena, directamente rechazada o enviada al conjunto predeterminado de aplicaciones, Por ejemplo, un grupo de aplicaciones 0, etc.).
Solicitud por parte del servidor de API para recibir, debido a que el clúster está configurado correctamente ValidatingWebhookConfiguration, por lo que en la fase de validación del control de admisión, solicitará el despliegue de un clúster validating admission webhookde API , utilizando la estructura K8 especificada AdmissionReviewRequestcomo solicitud y esperará AdmissionReviewResponsela estructura como devolución.
El servicio de verificación de cuotas recibe la solicitud, ingresará a la lógica de admisión dedeployment recursos de los manejadores , según la acción de solicitud de cambio sea CREAR o ACTUALIZAR para calcular la solicitud de recurso o requerir una nueva aplicación para su liberación.
Desde deploymentel spec.template.spec.containers[*].resources.requestscampo de solicitar la extracción de recursos, como por ejemplo cpu: 2, y memory: 1Gipara aplicar expresa.
Validador de recursos para encontrar el adaptador de cuotas para obtener 1información de cuotas de conjuntos de aplicaciones , como cpu: 10y memory: 20Gi, para la representación de cuotas . Junto con la solicitud obtenida anteriormente, solicite recursos del administrador de uso de recursos .
El administrador de uso de recursos ha pasado por el informante que ha adquirido el control del deploymentuso de recursos y el mantenimiento de la tienda en. La tienda puede usar memoria local, por lo que no hay dependencia externa. O utilícelo Rediscomo medio de almacenamiento, expansión de servicio conveniente.
El administrador de uso de recursos recibió el validador de recursos cuando se lo solicitó, puede almacenar el recurso del grupo de aplicaciones encontrado 1que ha sido ocupado por la situación actual, por ejemplo cpu: 8, y memory: 16Gipara indicar el uso . La inspección encontró que aplicar + uso <= cuota se considera que no se supera la cuota , se pasa la solicitud y finalmente se devuelve al servidor API .

Lo anterior es el proceso básico para realizar la verificación de cuotas de recursos. Hay algunos detalles que vale la pena agregar:

La API del servicio de verificación debe usar https para exponer el servicio.
Para los tipos de recursos no utilizados, como deployment, mpijobetc., debe implementar la admisión y el informador correspondientes .
Cada tipo de recurso puede tener diferentes versiones, como las deploymenthay apps/v1, apps/v1beta1etc., deben ser compatibles según la situación real del clúster.
Cuando se recibe la solicitud de ACTUALIZACIÓN, según el tipo de recurso requerido podsi el campo cambia, si es necesario reconstruir la podinstancia actual existente , el número de recursos informáticos en la aplicación correcta.
Además, los tipos de recursos propios de K8, como cpuotros tipos de recursos necesarios si el control de cuotas personalizado, como el tipo de GPU, etc., necesita solicitar los recursos preasignados correspondientes es bueno annotations, comoti.cloud.tencent.com/gpu-type: V100
En el administrador de uso de recursos, el uso llevado a cabo, procesa aplicaciones y determina las cuotas, puede haber competencia por los recursos , pero la cuota real al verificar la creación de recursos falla y otros problemas. A continuación, explicaremos estos dos temas.

3.2.2 Acerca de la competencia de aplicaciones de recursos

Debido a la existencia de solicitudes de recursos concurrentes:

El uso debe poder actualizarse inmediatamente después de la solicitud de recursos
Las actualizaciones de uso requieren control de simultaneidad

En el paso por encima de 7, cuando el gestor del uso de recursos verifica la cuota, se necesita consultar la ocupación actual de los recursos del grupo de aplicaciones, es decir, el uso del valor del grupo de aplicaciones . Este valor de uso por parte de los informantes encargados de la actualización y mantenimiento, pero debido a que la solicitud de recurso se validating admission webhookpasa al informador se puede observar, existe una diferencia horaria. Durante este proceso, aún puede haber solicitudes de recursos, por lo que el valor de uso es inexacto. Por lo tanto, el uso debe poder actualizarse inmediatamente después de la solicitud de recursos.

Y la actualización del uso requiere control de concurrencia, por ejemplo:

2La cuota del grupo de aplicaciones era cpu: 10, el uso escpu: 8
En las dos solicitudes deployment1y deployment2aplicaciones que usan el grupo de aplicaciones 2, aplican lo mismocpu: 2
Debe determinarse deployment1, calculando Aplicar + Uso = cpu: 10, no excede el valor de la cuota , las deployment1solicitudes están permitidas.
el uso se actualiza acpu: 10
Para juzgar nuevamente deployment2, debido a que el uso se actualiza a cpu: 10, se calcula aplicar + uso = cpu: 12, que excede el valor de la cuota , por lo que la solicitud no puede pasar.

El proceso anterior, el uso fácil de encontrar son variables compartidas críticas , debe consultar y actualizar el pedido. Si deployment1y deployment2el uso incontrolado de uso es cpu: 8, que dará lugar deployment1, y deployment2se pasan las solicitudes, por lo que el límite de cuota real superó. De esta forma, el usuario puede hacerse cargo de la cuota de recursos especificada.

Soluciones posibles:

La aplicación de recursos entra en la cola y, a su vez, es consumida y procesada por un único punto de servicio.
Bloquee la sección crítica donde se encuentra el uso de la variable compartida y consulte y actualice el valor de uso en el bloqueo .

3.2.3 Acerca de la falla en la creación de recursos

Debido a la competencia de recursos, requerimos que el uso se pueda actualizar inmediatamente después de la solicitud de recursos, pero esto también trae nuevos problemas. En 4. Control de admisión (validación) , después de la fase, ingresará el objeto de recurso solicitado 5. La fase de persistencia , el proceso también puede ser anormal (como otros webhookrechazan la solicitud, o el clúster apagado, falla ETCD, etc.) Como resultado, la tarea no se envió correctamente a la base de datos del clúster. En este caso, verificamos la fase, ha aumentado el valor de uso , no ponemos ninguna ocupación real de cuotas contabilizada como asumir la tarea de cuotas. De esta forma, un usuario puede consumir recursos insuficientes según la cuota prescrita.

Para resolver este problema, el servicio en segundo plano actualizará periódicamente el valor de uso de cada grupo de aplicaciones a nivel mundial . Por lo tanto, si la aparición de la fase de validación aumentó el valor de uso , pero la tarea en realidad está comprometida con la base de datos falló, cuando la actualización global, el valor de uso final se actualizará nuevamente para valorar con precisión el momento en que el conjunto de aplicaciones de utilización de recursos en el clúster.

Sin embargo, en casos excepcionales, la actualización global ocurrirá esta vez: un éxito finalmente se acreditará a la solicitud de creación de objeto de recurso persistente etcd ha pasado la webhook validación pero no ha completado el momento de persistencia . La presencia de esos momentos, que conducirá a una actualización global, hará que los usuarios sigan ocupando más de la cuota de.
Por ejemplo, en el ejemplo anterior, después de deployment1actualizar el valor de uso , se produjo una actualización global. En este momento, deployment1la información simplemente no ha sido acreditada, etcd, se actualizará el uso global nuevamente actualizado el valor anterior, esto hará que dployment2también se pueda adoptar, superando así el límite de cuota.
Pero en general, desde la validación hasta la persistencia de muy poco tiempo. Baja frecuencia en las actualizaciones globales, tales casos rara vez ocurren . En el futuro, si hay más demanda, se pueden utilizar soluciones más complejas para sortear este problema.

3.2.3 `ResourceQuota`obras nativas

Quota Management K8 se agrupa de forma nativa en ResourceQuotarespuesta a que estas aplicaciones compiten por los recursos y los problemas de creación de recursos fallan , una solución similar:

Actualización en tiempo real para resolver problemas de competencia de aplicaciones

Después de verificar la cuota, el uso de recursos se actualiza inmediatamente. El bloqueo optimista que viene con el sistema K8s garantiza el control concurrente de recursos (ver la implementación de checkQuotas en el código fuente de K8s para más detalles ) y resuelve el problema de la competencia de recursos.

checkQuotas La interpretación del código fuente más relevante en:

// now go through and try to issue updates.  Things get a little weird here:
// 1. check to see if the quota changed.  If not, skip.
// 2. if the quota changed and the update passes, be happy
// 3. if the quota changed and the update fails, add the original to a retry list
var updatedFailedQuotas []corev1.ResourceQuota
var lastErr error
for i := range quotas {
    newQuota := quotas[i]
    // if this quota didn't have its status changed, skip it
    if quota.Equals(originalQuotas[i].Status.Used, newQuota.Status.Used) {
        continue
    }
    if err := e.quotaAccessor.UpdateQuotaStatus(&newQuota); err != nil {
        updatedFailedQuotas = append(updatedFailedQuotas, newQuota)
        lastErr = err
    }
}

Aquí quotasestá la cuota después de la información de calibración, donde newQuota.Status.Usedel campo registra el uso de recursos de la cuota. Si se pasa la solicitud de recursos para la cuota, cuando se ejecuta este código, Usedla cantidad de recursos recién aplicados se ha agregado al campo. Posteriormente, Equalsse llama a la función, es decir, si Usedel campo no ha cambiado, indicando que no hay nueva aplicación de recursos. De lo contrario, se ejecutará para e.quotaAccessor.UpdateQuotaStatusir inmediatamente a las cuotas de acuerdo con las newQuota.Status.Usedactualizaciones de información etcd .

Actualización global programada para resolver el problema del error de creación

Actualice regularmente el uso de recursos a nivel mundial (consulte la implementación de Ejecutar en el código fuente de K8s para obtener más detalles ) para resolver posibles fallas en la creación de recursos.

Run La interpretación del código fuente más relevante en:

// the timer for how often we do a full recalculation across all quotas
go wait.Until(func() { rq.enqueueAll() }, rq.resyncPeriod(), stopCh)

Aquí rqhay ResourceQuotauna referencia correspondiente del objeto controlador. El Runciclo de ejecución del controlador , control continuo de todos los ResourceQuotaobjetos. Ciclo, llamada regular ininterrumpida enqueueAll, es decir, toda la ResourceQuotacola de prensa, modifica su Usedvalor, para una actualización global.