O dimensionamento automático, que ajuda a otimizar a utilização e minimizar os custos, é um dos aspectos mais importantes da computação em nuvem. O dimensionamento automático aloca recursos dinamicamente para seu aplicativo de nuvem com base na carga. Ele lida com rajadas de carga e tráfego durante os horários de pico, garantindo que a experiência do usuário final não seja prejudicada. O escalonamento automático também garante que você não tenha servidores ociosos e lhe custem dinheiro fora dos horários de pico.
Escalonamento automático no Kubernetes
No mundo do Kubernetes, existem 3 autoescaladores diferentes que ajudam a gerenciar custos e otimizar recursos:
- Cluster Autoscaler dimensiona o número de nós de trabalho no cluster Kubernetes. A maioria dos provedores Kubernetes de nuvem, como EKS, GKE e AKS, oferece suporte a alguma forma de autoescalador de cluster, mas cada um deles tem suas próprias ” pegadinhas “.
- O Vertical Pod Autoscaler (VPA) gerencia picos de tráfego alterando as solicitações de recursos e os limites nos pods, fornecendo aos pods mais recursos quando necessário. Isso libera o usuário de ter que configurar as solicitações ideais de CPU e memória. No entanto, o VPA exige que os pods sejam reiniciados para aplicar as novas recomendações recomendadas de CPU e memória. A reinicialização dos pods pode levar à interrupção do serviço para os usuários finais do serviço.
- O horizontal Pod Autoscaler (HPA) gerencia o número de pods com base na carga. Quando a carga aumenta, o HPA cria réplicas idênticas do aplicativo e distribui a carga entre diferentes pods. A principal vantagem que o HPA oferece sobre o VPA é o aumento da confiabilidade. O HPA dimensiona um número maior de pods menores que são compactados com mais eficiência nos nós. Isso garante interrupção mínima do serviço caso um único nó falhe. O HPA é o único recurso de escalonamento automático com suporte na API Kubernetes padrão.
O HPA apresenta desafios únicos quando usado em conjunto com estratégias avançadas de implantação como Blue/Green. Por exemplo, um de nossos clientes queria usar uma estratégia Blue/Green para mover todos os usuários da versão antiga para a nova versão sem interrupção. No entanto, o que nosso cliente descobriu foi que o HPA reduziu a próxima versão porque não estava recebendo nenhum tráfego. Isso significava que os usuários finais viam um serviço lento/degradado por um tempo quando o tráfego mudava para a próxima versão. Quando a Armory decidiu adicionar suporte para HPA nas implantações contínuas como serviço, queríamos fornecer confiabilidade ao usar estratégias de implantação sem aumentar os custos para nossos clientes. Aqui está o que nós inventamos.
Como a implantação contínua como serviço da Armory otimiza o HPA durante a implantação
Etapa 1 : antes de iniciar uma implantação em um ambiente, o CD-as-a-Service observa a escala em que seu aplicativo está sendo executado no momento e mantém essa escala até que a implantação no ambiente seja concluída.
Os detalhes: como o CD-as-a-Service conhece a escala logo antes do início da implantação, ele pode alterar as estratégias de implantação de uma forma que não cause degradação do serviço. Por exemplo, ao usar uma estratégia Blue/Green, a próxima versão do aplicativo é ampliada para atender à carga de tráfego atual antes que o tráfego seja transferido para a nova versão. Depois que o tráfego for transferido para a nova versão, seus usuários não sofrerão interrupções ou serviço degradado. Além disso, essa abordagem garante confiabilidade e velocidade ao reverter – suas reversões não precisam ser dimensionadas para dar suporte ao tráfego necessário.
Etapa 2 : o CD-as-a-Service desativa o HPA para seu aplicativo e executa sua estratégia de implantação.
Os detalhes: ao desabilitar o HPA durante a estratégia de implantação, o CD-as-a-Service garante que o HPA não interfira nessa estratégia. Por exemplo, ao usar resultados de análises automatizadas, se a nova versão tiver um vazamento de memória, o HPA poderá aumentar e impedir as consultas baseadas em limite. Ou durante as implantações de Canary de proporção de pod, o HPA pode reduzir os pods e forçar mais usuários a usar a versão Canary do aplicativo.
Etapa 3 : Após a implantação bem-sucedida da nova versão do aplicativo, o CD-as-a-Service ativa o HPA para a nova versão do aplicativo.
Os detalhes : o CD-as-a-Service implanta todas as alterações feitas, até mesmo as alterações no HPA. Isso significa que conforme você refina sua configuração de HPA de acordo com as necessidades do aplicativo, você pode executar testes de desempenho automatizados em ambientes de preparação antes mesmo de implantar novas configurações de HPA na produção.
Para concluir:
Com o CD-as-a-Service, você pode aproveitar todos os benefícios do HPA juntamente com estratégias avançadas de implantação para implantar de forma confiável sem causar interrupções de serviço. Você pode começar a usar o HPA com seus aplicativos adicionando-o à lista de manifestos sem adicionar nenhuma configuração extra. Fale com um de nossos especialistas e teste seus próprios cenários de implantação HPA experimentando o CD-as-a-Service gratuitamente!
Fonte: Armory
