{"id":36706,"date":"2019-10-31T22:13:15","date_gmt":"2019-10-31T19:13:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs\/"},"modified":"2019-10-31T22:13:15","modified_gmt":"2019-10-31T19:13:15","slug":"kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"C\u00f3mo las prioridades de los pod\u2019s en Kubernetes causaron tiempo de inactividad en Grafana Labs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota de traducci\u00f3n.<\/b>: Le presentamos los detalles t\u00e9cnicos sobre las causas de la reciente inactividad en el servicio de nube administrado por los creadores de Grafana. Este es un ejemplo cl\u00e1sico de c\u00f3mo una nueva y aparentemente \u00fatil funcionalidad, dise\u00f1ada para mejorar la calidad de la infraestructura... puede causar problemas si no se consideran los numerosos matices de su aplicaci\u00f3n en entornos de producci\u00f3n. Es fant\u00e1stico cuando surgen materiales como este que permiten aprender no solo de nuestros propios errores. Los detalles est\u00e1n en la traducci\u00f3n de este texto del vicepresidente de producto de Grafana Labs.<\/i><\/p>\n

\"C\u00f3mo
\n
\nEl viernes 19 de julio, el servicio Hosted Prometheus en Grafana Cloud dej\u00f3 de funcionar durante aproximadamente 30 minutos. Pido disculpas a todos los clientes afectados por la interrupci\u00f3n. Nuestra misi\u00f3n es proporcionar las herramientas necesarias para la monitorizaci\u00f3n, y entendemos que su falta dificulta su trabajo. Tomamos este incidente muy en serio. En esta nota se explica lo que ocurri\u00f3, c\u00f3mo respondimos y qu\u00e9 estamos haciendo para asegurarnos de que no vuelva a ocurrir.<\/a><\/noindex><\/p>\n

Antecedentes<\/h2>\n

\nEl servicio Grafana Cloud Hosted Prometheus se basa en Cortex<\/a><\/noindex> \u2014 el proyecto CNCF para crear un servicio Prometheus escalable horizontalmente, altamente disponible y multitenant. La arquitectura de Cortex consiste en un conjunto de microservicios individuales, cada uno de los cuales cumple su funci\u00f3n: replicaci\u00f3n, almacenamiento, consultas, etc. Cortex se est\u00e1 desarrollando activamente, constantemente se a\u00f1aden nuevas capacidades y se aumenta su rendimiento. Desplegamos regularmente nuevas versiones de Cortex en los cl\u00fasteres para que los clientes puedan aprovechar estas funciones, ya que Cortex puede actualizarse sin tiempos de inactividad.<\/p>\n

Para actualizaciones sin interrupciones, el servicio Ingester de Cortex requiere una r\u00e9plica adicional de Ingester durante el proceso de actualizaci\u00f3n. (Nota de traducci\u00f3n.<\/b>: Ingester<\/a><\/noindex> \u2014 es un componente b\u00e1sico de Cortex. Su funci\u00f3n es recoger un flujo constante de muestras, agruparlas en chunks para Prometheus y almacenarlas en una base de datos como DynamoDB, BigTable o Cassandra.<\/i> Esto permite que los Ingester antiguos transfieran datos actuales a los nuevos Ingester. Cabe destacar que los Ingester son exigentes en cuanto a recursos. Se necesitan 4 n\u00facleos y 15 GB de memoria por pod, es decir, el 25 % de la capacidad de procesamiento y memoria de la m\u00e1quina base en nuestros cl\u00fasteres de Kubernetes. En general, nosotros usualmente contamos con muchos m\u00e1s recursos no utilizados en el cl\u00faster que esos 4 n\u00facleos y 15 GB de memoria, por lo que podemos ejecutar f\u00e1cilmente estos Ingester adicionales durante las actualizaciones.<\/p>\n

Sin embargo, a menudo ocurre que durante el funcionamiento normal no hay esos 25% de recursos no utilizados en ninguna de las m\u00e1quinas. Adem\u00e1s, no estamos buscando eso: la CPU y la memoria siempre son \u00fatiles para otros procesos. Para solucionar este problema, decidimos utilizar Prioridades de Pod en Kubernetes<\/a><\/noindex>. La idea es asignar a los Ingester una prioridad m\u00e1s alta que a otros microservicios (sin estado). Cuando necesitamos iniciar un Ingester adicional (N+1), temporalmente despriorizamos otros pods m\u00e1s peque\u00f1os. Estos pods se trasladan a recursos libres en otras m\u00e1quinas, dejando un \"hueco\" suficientemente grande para iniciar un Ingester adicional.<\/p>\n

El jueves 18 de julio, desplegamos cuatro nuevos niveles de prioridad en nuestros cl\u00fasteres: cr\u00edtico<\/b>, un alto<\/b>, medio<\/b> y bajo<\/b>. Se probaron en un cl\u00faster interno sin tr\u00e1fico de clientes durante una semana aproximadamente. Por defecto, los pods sin prioridad asignada recib\u00edan medio<\/b> prioridad, mientras que para los Ingester se estableci\u00f3 una clase con alta<\/b> prioridad. El Cr\u00edtico<\/b> fue reservado para la monitorizaci\u00f3n (Prometheus, Alertmanager, node-exporter, kube-state-metrics, etc.). Nuestra configuraci\u00f3n es p\u00fablica, y se puede ver el PR aqu\u00ed<\/a><\/noindex>.<\/p>\n

Fallo<\/h2>\n

\nEl viernes 19 de julio, uno de los ingenieros lanz\u00f3 un nuevo cl\u00faster dedicado de Cortex para un gran cliente. La configuraci\u00f3n para este cl\u00faster no inclu\u00eda nuevas prioridades para los pods, por lo que a todos los nuevos pods se les asignaba prioridad por defecto \u2014 medio<\/b>.<\/p>\n

No hubo suficientes recursos en el cl\u00faster de Kubernetes para el nuevo cl\u00faster de Cortex, y el cl\u00faster de producci\u00f3n existente de Cortex no se actualiz\u00f3 (los Ingester quedaron sin alta<\/b> prioridad). Dado que los Ingester del nuevo cl\u00faster ten\u00edan por defecto medio<\/b> prioridad, mientras que los pods existentes en producci\u00f3n funcionaban sin prioridad, los Ingester del nuevo cl\u00faster desplazaron a los Ingester del cl\u00faster de producci\u00f3n existente de Cortex.<\/p>\n

El ReplicaSet para el Ingester desplazado en el cl\u00faster de producci\u00f3n detect\u00f3 el pod desplazado y cre\u00f3 uno nuevo para mantener el n\u00famero especificado de r\u00e9plicas. Al nuevo pod se le asign\u00f3 por defecto medio<\/b> prioridad, y el siguiente \"antiguo\" Ingester en producci\u00f3n perdi\u00f3 recursos. El resultado fue un proceso avalancha<\/b>, lo que result\u00f3 en el desalojo de todos los pods con Ingester para los cl\u00fasteres de producci\u00f3n de Cortex.<\/p>\n

Los Ingester mantienen el estado (stateful) y almacenan datos de las \u00faltimas 12 horas. Esto nos permite comprimirlos m\u00e1s eficientemente antes de grabarlos en el almacenamiento a largo plazo. Para ello, Cortex realiza el sharding de datos por series, utilizando una tabla hash distribuida (DHT), y replica cada serie en tres Ingester mediante un consenso de qu\u00f3rum al estilo de Dynamo. Cortex no escribe datos en los Ingester que est\u00e1n desconectados. As\u00ed, cuando un gran n\u00famero de Ingester abandona la DHT, Cortex no puede garantizar una replicaci\u00f3n adecuada de los registros, lo que provoca que estos \"caigan\".<\/p>\n

Detecci\u00f3n y resoluci\u00f3n<\/h2>\n

\nLas nuevas alertas de Prometheus basadas en el \"presupuesto de errores\" (error-budget-based<\/i> \u2014 los detalles aparecer\u00e1n en un futuro art\u00edculo) empezaron a sonar la alarma 4 minutos despu\u00e9s del inicio de la desconexi\u00f3n. Durante los siguientes cinco minutos aproximadamente, realizamos un diagn\u00f3stico y aumentamos el cl\u00faster de Kubernetes subyacente para alojar tanto los nuevos como los existentes cl\u00fasteres de producci\u00f3n.<\/p>\n

Cinco minutos m\u00e1s tarde, los antiguos Ingester hab\u00edan grabado sus datos con \u00e9xito, y los nuevos se hab\u00edan iniciado, lo que hizo que los cl\u00fasteres de Cortex volvieran a estar disponibles.<\/p>\n

Otros 10 minutos se dedicaron al diagn\u00f3stico y la correcci\u00f3n de errores de falta de memoria (OOM) de los servidores proxy reversos de autenticaci\u00f3n, situados delante de Cortex. Los errores OOM fueron causados por un aumento de diez veces en el QPS (lo que creemos que se debi\u00f3 a solicitudes excesivamente agresivas de los servidores clientes de Prometheus).<\/p>\n

Consecuencias<\/h2>\n

\nLa duraci\u00f3n total del tiempo de inactividad fue de 26 minutos. No se perdi\u00f3 ning\u00fan dato. Los Ingester cargaron con \u00e9xito todos los datos en memoria en el almacenamiento a largo plazo. Durante la desconexi\u00f3n, los servidores Prometheus de los clientes continuaron almacenando en b\u00fafer los datos eliminados. (remotas)<\/i> con apoyo del nuevo API remote_write<\/a><\/noindex> basado en WAL (desarrollado por Callum Styan<\/a><\/noindex> de Grafana Labs) y repitieron las entradas fallidas despu\u00e9s de la ca\u00edda.<\/p>\n

\"C\u00f3mo
\nLas operaciones de escritura del cl\u00faster de producci\u00f3n<\/i><\/p>\n

Conclusiones<\/h2>\n

\nEs importante aprender lecciones de este incidente y tomar las medidas necesarias para evitar que se repita.<\/p>\n

Al mirar hacia atr\u00e1s, debemos reconocer que no debimos establecer por defecto medio<\/b> prioridad, hasta que todos los Ingester en producci\u00f3n hayan recibido un alto<\/b> prioridad. Adem\u00e1s, debimos preocuparnos de antemano por su alto<\/b> prioridad. Ahora todo est\u00e1 corregido. Esperamos que nuestra experiencia ayude a otras organizaciones que est\u00e1n considerando el uso de prioridades de pods en Kubernetes.<\/p>\n

A\u00f1adiremos un nivel adicional de control sobre el despliegue de cualquier objeto adicional, cuya configuraci\u00f3n sea global para el cl\u00faster. En adelante, tales cambios ser\u00e1n evaluados pormayor audiencia.<\/i>m\u00e1s personas. Adem\u00e1s, la modificaci\u00f3n que caus\u00f3 la falla se consider\u00f3 demasiado insignificante para un documento de proyecto separado \u2014 solo se discuti\u00f3 en un issue de GitHub. De ahora en adelante, todos los cambios de configuraci\u00f3n similares ir\u00e1n acompa\u00f1ados de la documentaci\u00f3n del proyecto correspondiente.<\/p>\n

Por \u00faltimo, automatizaremos la mejora del tama\u00f1o del proxy inverso de autenticaci\u00f3n para prevenir OOM en caso de sobrecarga, lo que hemos presenciado, y analizaremos los par\u00e1metros predeterminados de Prometheus relacionados con la reversi\u00f3n y escalado, para prevenir problemas similares en el futuro.<\/p>\n

La falla experimentada tuvo algunas consecuencias positivas: al obtener los recursos necesarios, Cortex se recuper\u00f3 autom\u00e1ticamente sin intervenci\u00f3n adicional. Tambi\u00e9n obtuvimos valiosa experiencia al trabajar con Grafana Loki<\/a><\/noindex> \u2014 nuestro nuevo sistema de agregaci\u00f3n de registros, \u2014 que ayud\u00f3 a asegurar que todos los Ingester se comportaran adecuadamente durante y despu\u00e9s de la falla.<\/p>\n

P.D. del traductor<\/h2>\n

\nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n