{"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\/pt\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Como as prioridades dos pods no Kubernetes causaram uma interrup\u00e7\u00e3o na Grafana Labs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota do tradutor.<\/b>: Apresentamos a voc\u00eas os detalhes t\u00e9cnicos sobre as raz\u00f5es do recente tempo de inatividade do servi\u00e7o de nuvem, mantido pelos criadores do Grafana. Este \u00e9 um exemplo cl\u00e1ssico de como uma nova e, aparentemente, extremamente \u00fatil funcionalidade, destinada a melhorar a qualidade da infraestrutura... pode causar danos se n\u00e3o forem considerados os in\u00fameros aspectos de sua aplica\u00e7\u00e3o na realidade da produ\u00e7\u00e3o. \u00c9 maravilhoso quando surgem materiais como este, que permitem aprender n\u00e3o apenas com nossos erros. Mais detalhes est\u00e3o na tradu\u00e7\u00e3o deste texto do vice-presidente de produtos da Grafana Labs.<\/i><\/p>\n

\"Como
\n
\nNa sexta-feira, 19 de julho, o servi\u00e7o Hosted Prometheus no Grafana Cloud parou de funcionar por cerca de 30 minutos. Pe\u00e7o desculpas a todos os clientes afetados pela falha. Nossa tarefa \u00e9 fornecer as ferramentas necess\u00e1rias para monitoramento, e entendemos que a falta delas complica sua vida. Levamos este incidente muito a s\u00e9rio. Neste comunicado, explicamos o que aconteceu, como reagimos e o que estamos fazendo para que isso n\u00e3o se repita.<\/a><\/noindex><\/p>\n

Antecedentes<\/h2>\n

\nO servi\u00e7o Grafana Cloud Hosted Prometheus \u00e9 baseado em Cortex<\/a><\/noindex> \u2014 um projeto da CNCF para criar um servi\u00e7o Prometheus horizontalmente escal\u00e1vel, altamente dispon\u00edvel e multi-tenant. A arquitetura Cortex \u00e9 composta por um conjunto de microservi\u00e7os separados, cada um executando sua fun\u00e7\u00e3o: replica\u00e7\u00e3o, armazenamento, consultas, etc. O Cortex est\u00e1 em desenvolvimento ativo, com novas funcionalidades e melhorias de desempenho sendo constantemente lan\u00e7adas. Regularmente, fazemos deploys de novas vers\u00f5es do Cortex nos clusters, permitindo que os clientes aproveitem essas funcionalidades \u2014 felizmente, o Cortex consegue se atualizar sem interrup\u00e7\u00f5es.<\/p>\n

Para atualiza\u00e7\u00f5es sem interrup\u00e7\u00f5es, o servi\u00e7o Ingester do Cortex requer uma r\u00e9plica adicional do Ingester durante o processo de atualiza\u00e7\u00e3o. (Nota do tradutor.<\/b>: Ingester<\/a><\/noindex> \u2014 \u00e9 o componente b\u00e1sico do Cortex. Sua tarefa \u00e9 coletar um fluxo cont\u00ednuo de amostras, agrup\u00e1-las em chunks do Prometheus e armazen\u00e1-las em um banco de dados como DynamoDB, BigTable ou Cassandra.<\/i> Isso permite que os antigos Ingesters enviem dados atuais para os novos Ingesters. Vale ressaltar que os Ingesters exigem muitos recursos. Para oper\u00e1-los, \u00e9 necess\u00e1rio ter 4 n\u00facleos e 15 GB de mem\u00f3ria por pod, ou seja, 25% do poder de CPU e mem\u00f3ria da m\u00e1quina base em nossos clusters Kubernetes. No geral, geralmente temos muitos mais recursos n\u00e3o utilizados no cluster do que 4 n\u00facleos e 15 GB de mem\u00f3ria, portanto podemos facilmente iniciar esses Ingesters adicionais durante as atualiza\u00e7\u00f5es.<\/p>\n

No entanto, muitas vezes acontece que durante a opera\u00e7\u00e3o normal n\u00e3o h\u00e1 esses 25% de recursos n\u00e3o utilizados em nenhuma das m\u00e1quinas. E n\u00e3o buscamos isso: CPU e mem\u00f3ria sempre ser\u00e3o necess\u00e1rios para outros processos. Para resolver esse problema, decidimos usar Prioridades de Pod do Kubernetes<\/a><\/noindex>. A ideia \u00e9 atribuir aos Ingesters uma prioridade mais alta do que a de outros microsservi\u00e7os (sem estado). Quando precisamos iniciar um Ingester adicional (N+1), temporariamente despriorizamos outros pods menores. Esses pods s\u00e3o movidos para recursos livres em outras m\u00e1quinas, deixando uma 'lacuna' suficiente para iniciar o Ingester adicional.<\/p>\n

Na quinta-feira, 18 de julho, implementamos quatro novos n\u00edveis de prioridade em nossos clusters: cr\u00edtico<\/b>, alto<\/b>, m\u00e9dio<\/b> e baixo<\/b>. Eles foram testados em um cluster interno sem tr\u00e1fego de clientes por cerca de uma semana. Por padr\u00e3o, os pods sem prioridade definida recebiam m\u00e9dio<\/b> prioridade, para os Ingesters foi definida uma classe com alta<\/b> prioridade. Cr\u00edtico<\/b> foi reservado para monitoramento (Prometheus, Alertmanager, node-exporter, kube-state-metrics, etc.). Nossa configura\u00e7\u00e3o \u00e9 aberta, e voc\u00ea pode ver o PR aqui<\/a><\/noindex>.<\/p>\n

Acidente<\/h2>\n

\nNa sexta-feira, 19 de julho, um dos engenheiros lan\u00e7ou um novo cluster dedicado do Cortex para um grande cliente. A configura\u00e7\u00e3o para esse cluster n\u00e3o inclu\u00eda novas prioridades dos pods, portanto todos os novos pods recebiam prioridade padr\u00e3o \u2014 m\u00e9dio<\/b>.<\/p>\n

O cluster Kubernetes n\u00e3o tinha recursos suficientes para o novo cluster do Cortex, e o cluster de produ\u00e7\u00e3o existente do Cortex n\u00e3o foi atualizado (os Ingesters ficaram sem alta<\/b> prioridade). Como os Ingesters do novo cluster tinham por padr\u00e3o m\u00e9dio<\/b> prioridade e os pods existentes em produ\u00e7\u00e3o operavam sem nenhuma prioridade, os Ingesters do novo cluster desalojaram os Ingesters do cluster de produ\u00e7\u00e3o existente do Cortex.<\/p>\n

O ReplicaSet para o Ingester desalojado no cluster de produ\u00e7\u00e3o detectou o pod desalojado e criou um novo para manter o n\u00famero especificado de c\u00f3pias. Ao novo pod foi atribu\u00edda por padr\u00e3o m\u00e9dio<\/b> prioridade, e o pr\u00f3ximo Ingester \u201cantigo\u201d na produ\u00e7\u00e3o perdeu recursos. O resultado foi um processo em cascata<\/b>, o que resultou no desalojamento de todos os pods com Ingester nos clusters de produ\u00e7\u00e3o do Cortex.<\/p>\n

Os Ingester mant\u00eam estado (stateful) e armazenam dados dos 12 horas anteriores. Isso nos permite compact\u00e1-los de forma mais eficiente antes de grav\u00e1-los em armazenamento de longo prazo. Para isso, o Cortex realiza o particionamento de dados por s\u00e9ries, utilizando uma tabela hash distribu\u00edda (Distributed Hash Table, DHT) e replica cada s\u00e9rie em tr\u00eas Ingester com consist\u00eancia de qu\u00f3rum no estilo Dynamo. O Cortex n\u00e3o grava dados em Ingester que est\u00e3o offline. Assim, quando um grande n\u00famero de Ingester sai do DHT, o Cortex n\u00e3o consegue garantir a replica\u00e7\u00e3o suficiente das entradas, e elas \u201ccaem\u201d.<\/p>\n

Detec\u00e7\u00e3o e resolu\u00e7\u00e3o<\/h2>\n

\nNovos alertas do Prometheus baseados em \"or\u00e7amento de erros\" (error-budget-based<\/i> \u2014 detalhes aparecer\u00e3o em uma futura publica\u00e7\u00e3o) come\u00e7aram a soar o alarme ap\u00f3s 4 minutos desde o in\u00edcio do desligamento. Durante os pr\u00f3ximos cinco minutos, realizamos uma avalia\u00e7\u00e3o e aumentamos o cluster Kubernetes subjacente para acomodar tanto os novos quanto os existentes clusters de produ\u00e7\u00e3o.<\/p>\n

Mais cinco minutos depois, os Ingester antigos gravaram seus dados com sucesso, e os novos foram iniciados, e os clusters do Cortex voltaram a estar dispon\u00edveis.<\/p>\n

Mais 10 minutos foram gastos na an\u00e1lise e corre\u00e7\u00e3o de erros de out-of-memory (OOM) dos servidores proxy de autentica\u00e7\u00e3o que estavam \u00e0 frente do Cortex. Os erros OOM foram causados por um aumento de dez vezes no QPS (como acreditamos, devido a solicita\u00e7\u00f5es excessivamente agressivas dos servidores Prometheus do cliente).<\/p>\n

Consequ\u00eancias<\/h2>\n

\nA dura\u00e7\u00e3o total do tempo de inatividade foi de 26 minutos. Nenhum dado foi perdido. Os Ingester carregaram com sucesso todos os dados in-memory para o armazenamento de longo prazo. Durante a desconex\u00e3o, os servidores Prometheus dos clientes armazenaram em buffer os dados removidos. (remote)<\/i> com o aux\u00edlio de uma nova API remote_write<\/a><\/noindex> baseada em WAL (escrita por Callum Styan<\/a><\/noindex> da Grafana Labs) e repetiram os registros falhados ap\u00f3s a falha.<\/p>\n

\"Como
\nOpera\u00e7\u00f5es de grava\u00e7\u00e3o do cluster de produ\u00e7\u00e3o<\/i><\/p>\n

Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/h2>\n

\n\u00c9 importante aprender com este incidente e tomar as medidas necess\u00e1rias para evitar que ele se repita.<\/p>\n

Olhando para tr\u00e1s, devemos reconhecer que n\u00e3o dever\u00edamos ter definido como padr\u00e3o m\u00e9dio<\/b> prioridade, at\u00e9 que todos os Ingester em produ\u00e7\u00e3o tenham recebido. alto<\/b> prioridade. Al\u00e9m disso, dever\u00edamos ter garantido anteriormente suas altas<\/b> prioridades. Agora est\u00e1 tudo corrigido. Esperamos que nossa experi\u00eancia ajude outras organiza\u00e7\u00f5es que consideram o uso de prioridades de pods no Kubernetes.<\/p>\n

Vamos adicionar um n\u00edvel adicional de controle sobre a implanta\u00e7\u00e3o de quaisquer objetos adicionais, cujas configura\u00e7\u00f5es s\u00e3o globais para o cluster. Daqui em diante, tais mudan\u00e7as ser\u00e3o avaliadas pormaior<\/i>um n\u00famero maior de pessoas. Al\u00e9m disso, a modifica\u00e7\u00e3o que levou \u00e0 falha foi considerada muito insignificante para um documento de projeto separado \u2014 ela foi discutida apenas em uma quest\u00e3o do GitHub. A partir deste momento, todas as modifica\u00e7\u00f5es semelhantes de configura\u00e7\u00f5es ser\u00e3o acompanhadas pela documenta\u00e7\u00e3o de projeto adequada.<\/p>\n

Finalmente, vamos automatizar o redimensionamento do servidor proxy reverso de autentica\u00e7\u00e3o para evitar OOM durante sobrecargas, das quais fomos testemunhas, e analisaremos as configura\u00e7\u00f5es padr\u00e3o do Prometheus relacionadas a rollback e escalonamento, para prevenir problemas semelhantes no futuro.<\/p>\n

A falha sofrida tamb\u00e9m teve algumas consequ\u00eancias positivas: ao obter os recursos necess\u00e1rios, o Cortex se recuperou automaticamente sem interven\u00e7\u00e3o adicional. Tamb\u00e9m obtivemos valiosa experi\u00eancia trabalhando com Grafana Loki<\/a><\/noindex> \u2013 nosso novo sistema de agrega\u00e7\u00e3o de logs, \u2013 que ajudou a garantir que todos os Ingester se comportassem adequadamente durante e ap\u00f3s a falha.<\/p>\n

P.S. do tradutor<\/h2>\n

\nConfira tamb\u00e9m em nosso blog:<\/p>\n