Equipo de contenedores de plataforma en la nube 360 computación en la nube
Declaración de heroína
Al utilizar la actualización continua de kubernetes, a menudo puede encontrarse con la situación de "demasiado rápido e inestable" o "demasiado lento y deficiente". Este artículo presentará las características de la tasa de control de actualización continua de Kubernetes.
PD: tecnología de primera línea rica, una amplia gama de formas, todo en " 3 60 cloud computing " punto de preocupación ¡Oh!
1
sentido
Durante la actualización continua del servicio, el propósito del controlador de implementación es reducir el número de copias de la versión anterior (old_rs) a 0 y aumentar el número de copias de la nueva versión (new_rs) al valor esperado (réplicas) . Cuando lo usas, generalmente es fácil pasar por alto las características del control de la tasa. Los siguientes son los dos parámetros proporcionados por kubernetes:
1. maxUnavailable: en comparación con el número de copias que se espera estén listas, la proporción máxima (o el máximo) del número de copias no disponibles. Cuanto menor sea el valor, más estable
será el servicio y más fluida será la actualización; 2. maxSurge: el número de copias que se espera estén listas, superando la proporción máxima (o valor máximo) del número esperado de copias, cuanto mayor sea el valor, más rápida será la velocidad de actualización de la copia.
2
Rangos
Valor numérico
1. maxUnavailable: [0, número de copias] maxSurge: [0, número de copias]
2. maxSurge: [0, número de copias]
Nota: Ambos no pueden ser 0 al mismo tiempo.
proporción
1. maxUnavailable: [0%, 100%] Redondeo hacia abajo, por ejemplo, 10 copias, 5% == 0.5, pero el cálculo se basa en 0;
2. maxSurge: [0%, 100%] redondeado hacia arriba, como 10 copias, si 5% == 0.5, pero el cálculo se basa en 1;
Nota: Ambos no pueden ser 0 al mismo tiempo.
Configuración recomendada
1. maxUnavailable == 0
2. maxSurge == 1
Esta es la configuración predeterminada proporcionada a los usuarios en nuestro entorno de producción. Es decir, el principio más suave de "uno hacia arriba y hacia abajo, primero hacia arriba y hacia abajo": después de que una nueva versión del pod esté lista (combinada con la preparación), se destruirá la versión anterior del pod. El escenario aplicable de esta configuración es una actualización fluida y un servicio estable, pero también tiene la desventaja de que es "demasiado lento".
3
Estrategia personalizada
Cuando el controlador de implementación ajusta el número de conjuntos de réplicas, controla estrictamente el ritmo de liberación mediante la siguiente fórmula. Por lo tanto, si necesita publicar rápidamente, puede ajustar estos dos valores de acuerdo con la situación real:
(Número de copias de destino-maxUnavailable) <= número de copias listas reales en línea <= (número de copias de destino + maxSurge)
Ejemplo: si se espera que el número de copias sea 10, se espera que al menos el 80% de las copias puedan funcionar de manera estable, entonces: maxUnavailable = 2, maxSurge = 2 (personalizable, se recomienda ser consistente con maxUnavailable)
8 <= Número real de copias listas en línea <= 12
De esta manera, durante el proceso de actualización, la cantidad de pods que normalmente pueden brindar servicios en línea siempre permanecerá dentro de este rango.
4
para resumir
Este artículo explica las características de "control de la tasa de actualización en la estrategia de actualización continua" más ignoradas de kubernetes: maxUnavailable y maxSurge. Espero que le sea útil cuando lance la versión.
Los artículos posteriores explicarán el principio del controlador de implementación que controla las actualizaciones continuas en varias versiones (conjunto de réplicas) y analizarán la lógica de implementación del código fuente correspondiente.