Para dominar totalmente o Kubernetes, você precisa conhecer diferentes maneiras de dimensionar os recursos do cluster: , esta é uma das principais tarefas do Kubernetes. Fornecemos uma visão geral de alto nível do escalonamento automático horizontal e vertical e dos mecanismos de redimensionamento de cluster, bem como recomendações sobre como usá-los de maneira eficaz.
Artigo traduzido pela equipe que implementou o escalonamento automático em .
Por que é importante pensar em escalar
- uma ferramenta para gerenciamento e orquestração de recursos. Claro, é bom mexer nos recursos interessantes de implantação, monitoramento e gerenciamento de pods (um pod é um grupo de contêineres iniciados em resposta a uma solicitação).
No entanto, você também deve pensar nas seguintes questões:
- Como dimensionar módulos e aplicações?
- Como manter os containers operacionais e eficientes?
- Como responder às constantes mudanças no código e nas cargas de trabalho dos usuários?
Configurar clusters Kubernetes para equilibrar recursos e desempenho pode ser desafiador e requer conhecimento especializado do funcionamento interno do Kubernetes. A carga de trabalho do seu aplicativo ou serviços pode variar ao longo do dia ou até mesmo ao longo de uma hora, portanto, é melhor considerar o balanceamento como um processo contínuo.
Níveis de escalonamento automático do Kubernetes
O escalonamento automático eficaz requer coordenação entre dois níveis:
- Nível do pod, incluindo horizontal (Horizontal Pod Autoscaler, HPA) e autoescalador vertical (Vertical Pod Autoscaler, VPA). Isso está dimensionando os recursos disponíveis para seus contêineres.
- Nível de cluster, que é gerenciado pelo Cluster Autoscaler (CA), que aumenta ou diminui o número de nós dentro do cluster.
Módulo escalonador automático horizontal (HPA)
Como o nome sugere, o HPA dimensiona o número de réplicas de pod. A maioria dos devops usa carga de CPU e memória como gatilhos para alterar o número de réplicas. No entanto, é possível dimensionar o sistema com base em , eles ou .
Diagrama operacional HPA de alto nível:
- O HPA verifica continuamente os valores métricos especificados durante a instalação em um intervalo padrão de 30 segundos.
- O HPA tenta aumentar o número de módulos se o limite especificado for atingido.
- O HPA atualiza o número de réplicas no controlador de implantação/replicação.
- O controlador de implantação/replicação implanta então quaisquer módulos adicionais necessários.
O HPA inicia o processo de implantação do módulo quando um limite de métrica é atingido
Ao usar HPA, considere o seguinte:
- O intervalo de verificação padrão do HPA é de 30 segundos. É definido pela bandeira período horizontal-pod-autoscaler-sync no gerenciador do controlador.
- O erro relativo padrão é 10%.
- Após o último aumento no número de módulos, a HPA espera que as métricas se estabilizem em três minutos. Este intervalo é definido pela bandeira horizontal-pod-autoscaler-upscale-atraso.
- Após a última redução no número de módulos, o HPA aguarda cinco minutos para se estabilizar. Este intervalo é definido pela bandeira horizontal-pod-autoscaler-downscale-atraso.
- O HPA funciona melhor com objetos de implantação em vez de controladores de replicação. O escalonamento automático horizontal é incompatível com a atualização contínua, que manipula diretamente os controladores de replicação. Com a implantação, o número de réplicas depende diretamente dos objetos de implantação.
Escalonamento automático vertical de pods
O escalonamento automático vertical (VPA) aloca mais (ou menos) tempo de CPU ou memória para pods existentes. Adequado para pods com ou sem estado, mas destinado principalmente a serviços com estado. No entanto, você também pode usar o VPA para módulos sem estado se precisar ajustar automaticamente a quantidade de recursos inicialmente alocados.
O VPA também responde a eventos OOM (falta de memória). A alteração do tempo e da memória da CPU requer a reinicialização dos pods. Quando reiniciado, o VPA respeita o orçamento de alocação () para garantir o número mínimo exigido de módulos.
Você pode definir os recursos mínimos e máximos para cada módulo. Assim, você pode limitar a quantidade máxima de memória alocada a 8 GB. Isto é útil se os nós atuais definitivamente não puderem alocar mais de 8 GB de memória por contêiner. Especificações detalhadas e mecanismo operacional são descritos em .
Além disso, o VPA possui uma função de recomendação interessante (VPA Recommender). Ele monitora o uso de recursos e eventos OOM de todos os módulos para sugerir novos valores de memória e tempo de CPU com base em um algoritmo inteligente baseado em métricas históricas. Há também uma API que usa um identificador de pod e retorna valores de recursos sugeridos.
É importante notar que o Recomendador VPA não rastreia o "limite" de recursos. Isso pode fazer com que o módulo monopolize recursos dentro dos nós. É melhor definir o limite no nível do namespace para evitar grande consumo de memória ou CPU.
Esquema de operação VPA de alto nível:
- O VPA verifica continuamente os valores métricos especificados durante a instalação em um intervalo padrão de 10 segundos.
- Se o limite especificado for atingido, o VPA tentará alterar a quantidade alocada de recursos.
- O VPA atualiza o número de recursos no controlador de implantação/replicação.
- Quando os módulos são reiniciados, todos os novos recursos são aplicados às instâncias criadas.
VPA adiciona a quantidade necessária de recursos
Lembre-se dos seguintes pontos ao usar o VPA:
- O dimensionamento requer uma reinicialização obrigatória do pod. Isto é necessário para evitar uma operação instável após fazer alterações. Para maior confiabilidade, os módulos são reiniciados e distribuídos entre nós com base nos recursos recém-alocados.
- VPA e HPA ainda não são compatíveis entre si e não podem ser executados nos mesmos pods. Se você estiver usando os dois mecanismos de escalabilidade no mesmo cluster, certifique-se de que suas configurações evitem que eles sejam ativados nos mesmos objetos.
- O VPA ajusta solicitações de contêiner para recursos com base apenas no uso passado e atual. Não define limites de uso de recursos. Pode haver problemas com aplicativos que não funcionam corretamente e começam a ocupar cada vez mais recursos, o que fará com que o Kubernetes desligue este pod.
- O VPA ainda está em um estágio inicial de desenvolvimento. Esteja preparado, pois o sistema poderá sofrer algumas alterações em um futuro próximo. Você pode ler sobre и . Assim, existem planos para implementar a operação conjunta de VPA e HPA, bem como a implantação de módulos juntamente com uma política de escalonamento automático vertical para eles (por exemplo, um rótulo especial 'requer VPA').
Escalonamento automático de um cluster Kubernetes
O Cluster Autoscaler (CA) altera o número de nós com base no número de pods em espera. O sistema verifica periodicamente se há módulos pendentes – e aumenta o tamanho do cluster caso sejam necessários mais recursos e se o cluster não ultrapassar os limites estabelecidos. A CA se comunica com o provedor de serviços de nuvem, solicita nós adicionais ou libera nós ociosos. A primeira versão do CA com disponibilidade geral foi introduzida no Kubernetes 1.8.
Esquema de alto nível de operação SA:
- A CA verifica módulos pendentes em um intervalo padrão de 10 segundos.
- Se um ou mais pods estiverem em estado de espera porque o cluster não tem recursos disponíveis suficientes para alocá-los, ele tenta provisionar um ou mais nós adicionais.
- Quando o provedor de serviços de nuvem aloca o nó necessário, ele se junta ao cluster e está pronto para servir os pods.
- O agendador do Kubernetes distribui pods pendentes para o novo nó. Se depois disso alguns módulos ainda permanecerem em estado de espera, o processo é repetido e novos nós são adicionados ao cluster.
Provisionamento automático de nós de cluster na nuvem
Considere o seguinte ao usar CA:
- A CA garante que todos os pods no cluster tenham espaço para execução, independentemente da carga da CPU. Ele também tenta garantir que não haja nós desnecessários no cluster.
- A CA registra a necessidade de escalar após aproximadamente 30 segundos.
- Quando um nó não for mais necessário, o padrão da CA é aguardar 10 minutos antes de expandir o sistema.
- O sistema de escalonamento automático possui o conceito de expansores. Estas são estratégias diferentes para selecionar um grupo de nós aos quais novos nós serão adicionados.
- Use a opção com responsabilidade cluster-autoscaler.kubernetes.io/safe-to-evict (verdadeiro). Se você instalar muitos pods ou se muitos deles estiverem espalhados por todos os nós, você perderá em grande parte a capacidade de expandir o cluster.
- Usar para evitar que os pods sejam excluídos, o que pode causar a quebra completa de partes do seu aplicativo.
Como os escalonadores automáticos do Kubernetes interagem entre si
Para uma harmonia perfeita, o escalonamento automático deve ser aplicado tanto no nível do pod (HPA/VPA) quanto no nível do cluster. Eles interagem entre si de forma relativamente simples:
- HPAs ou VPAs atualizam réplicas de pod ou recursos alocados para pods existentes.
- Se não houver nós suficientes para o escalonamento planejado, a CA percebe a presença de pods em estado de espera.
- A CA aloca novos nós.
- Os módulos são distribuídos para novos nós.
Sistema colaborativo de escalabilidade horizontal do Kubernetes
Erros comuns no escalonamento automático do Kubernetes
Existem vários problemas comuns que os devops enfrentam ao tentar implementar o escalonamento automático.
HPA e VPA dependem de métricas e de alguns dados históricos. Se recursos insuficientes forem alocados, os módulos serão minimizados e não poderão gerar métricas. Nesse caso, o escalonamento automático nunca acontecerá.
A operação de escalonamento em si é sensível ao tempo. Queremos que os módulos e o cluster sejam escalonados rapidamente – antes que os usuários percebam quaisquer problemas ou falhas. Portanto, o tempo médio de escalonamento dos pods e do cluster deve ser levado em consideração.
Cenário ideal - 4 minutos:
- 30 segundos. Atualizar métricas de destino: 30 a 60 segundos.
- 30 segundos. O HPA verifica os valores métricos: 30 segundos.
- Menos de 2 segundos. Os pods são criados e entram em estado de espera: 1 segundo.
- Menos de 2 segundos. A CA vê módulos em espera e envia chamadas para nós de provisionamento: 1 segundo.
- 3 minutos. O provedor de nuvem aloca nós. Os K8s esperam até estarem prontos: até 10 minutos (dependendo de vários fatores).
Pior cenário (mais realista) - 12 minutos:
- 30 segundos. Atualize as métricas alvo.
- 30 segundos. O HPA verifica os valores métricos.
- Menos de 2 segundos. Os pods são criados e entram no estado de espera.
- Menos de 2 segundos. A CA vê os módulos em espera e faz chamadas para provisionar os nós.
- 10 minutos. O provedor de nuvem aloca nós. K8s espera até que estejam prontos. O tempo de espera depende de vários fatores, como atraso do fornecedor, atraso do sistema operacional e ferramentas de suporte.
Não confunda os mecanismos de escalonamento dos provedores de nuvem com a nossa CA. Este último é executado dentro de um cluster Kubernetes, enquanto o mecanismo do provedor de nuvem opera com base na distribuição de nós. Ele não sabe o que está acontecendo com seus pods ou aplicativos. Esses sistemas operam em paralelo.
Como gerenciar o escalonamento no Kubernetes
- Kubernetes é uma ferramenta de gerenciamento e orquestração de recursos. As operações para gerenciar pods e recursos de cluster são um marco importante no domínio do Kubernetes.
- Entenda a lógica da escalabilidade do pod levando em consideração HPA e VPA.
- A CA só deve ser usada se você tiver um bom entendimento das necessidades de seus pods e contêineres.
- Para configurar um cluster de maneira ideal, você precisa entender como diferentes sistemas de escalabilidade funcionam juntos.
- Ao estimar o tempo de escalonamento, tenha em mente os piores e melhores cenários.
Fonte: habr.com