Andy Suderman
Andy Suderman é um especialista líder em Kubernetes e tecnologias nativas de nuvem, atuando como Diretor de Tecnologia na Fairwinds, que oferece Kubernetes Gerenciado como Serviço.
Com uma rica experiência em arquitetura de sistemas e computação em nuvem, Suderman tem estado na vanguarda da inovação do Kubernetes. Nesta entrevista aprofundada, ele compartilha suas experiências, insights e as últimas tendências em autoscaling do Kubernetes.
O autoescala no Kubernetes é uma ciência e uma arte. Ele envolve configurações precisas e uma compreensão do comportamento do aplicativo para garantir desempenho e utilização de recursos ideais. Nesta entrevista, Suderman discute a evolução, o estado atual e o futuro do autoescala do Kubernetes, fornecendo perspectivas valiosas para engenheiros de plataforma.
Você pode se apresentar e contar um breve histórico do seu primeiro contato com o Kubernetes e o escalonamento automático em particular?
Comecei com o Kubernetes na época da versão 1.4, enquanto trabalhava na ReadyTalk. Nossa plataforma na época estava rodando em VMs Xen em servidores em um data center físico que eu mantinha, e estávamos apenas descobrindo a conteinerização e os K8s.
Na época, o Horizontal Pod Autoscaler (HPA) já existia há algum tempo. Parecia mágica: de repente, nossos serviços podiam escalar instantaneamente com base no uso da CPU, o que na época das VMs e do hardware era muito mais difícil de implementar.
Avançando alguns anos, estou trabalhando na ReactiveOps (mais tarde chamada Fairwinds) executando o Kubernetes para vários clientes diferentes, e o HPA combinado com o dimensionamento automático de cluster era comum para nós. Ajudamos todos os nossos clientes a implementá-los para seus aplicativos em execução no cluster que mantivemos.
Você pode nos contar um breve histórico da evolução do dimensionamento automático do Kubernetes?
Tudo começou com o HPA, que foi introduzido no início. Isso permitiu o dimensionamento automático de réplicas de pod dentro de uma implantação. Bem, não uma implantação na época, mas o que se tornaria uma implantação. O HPA aceita basicamente qualquer provedor de métricas que possa ser consultado por meio das métricas apiServicee permite que você defina uma meta para essa métrica por pod.
O HPA ainda existe em uma forma muito similar hoje, mas com melhorias, como segmentação de múltiplas métricas e ajuste fino do comportamento de escala. Outra coisa interessante a ser notada aqui é que o HPA ainda é o único autoescalador in-tree (incluído na base de código do núcleo do Kubernetes).
Uma vez que os pods estavam dimensionando automaticamente seus replicaCounthavia uma necessidade óbvia de dimensionar dinamicamente o número de nós em um cluster para acomodar o número crescente de pods. O Cluster Autoscaler se tornou o de fato maneira de fazer isso.
Este projeto foi GA em 2017 — então, bem cedo. Começou bem direto: assim que via um pod que estava em status “pendente” porque não havia espaço para o planejador agendá-lo, o Cluster Autoscaler adicionava um novo nó ao cluster. Semelhante ao HPA, isso ainda é muito comumente usado hoje, embora com muito mais ajustes finos, opções, suporte do provedor de nuvem, etc.
Nos últimos dois anos, conforme as limitações dos mecanismos principais do HPA e do Cluster Autoscaler começaram a se tornar muito mais aparentes para os usuários, começamos a ver o lançamento de projetos adicionais que se baseiam nesses conceitos. KEDA para dimensionamento automático de pod horizontal e Karpenter para dimensionamento automático de cluster vêm à mente.
Em alguns casos, essas ferramentas mudam completamente os mecanismos subjacentes do dimensionamento, mas o objetivo final continua o mesmo: precisamos dimensionar os pods horizontalmente, e os clusters precisam ser dimensionados automaticamente junto com isso.
Além disso, começando por volta de 2018, algumas pessoas perceberam que haveria uma necessidade de escalar pods verticalmente automaticamente — ou seja, aumentar/diminuir dinamicamente sua CPU/memória solicitada. O Vertical Pod Autoscaler (VPA) existe há quase tanto tempo quanto o Cluster Autoscaler e vive no mesmo repositório.
Analisando mais a fundo, o HPA ou VPA foi inspirado por outras tecnologias de sistemas distribuídos ou foi revolucionário?
A ideia de escalar infraestrutura horizontal ou verticalmente não é realmente nova — havia maneiras de fazer isso em data centers com VMs no passado. Elas pareciam muito semelhantes ao que vemos agora, exceto que agora podemos escalar contêineres em vez de VMs inteiras, e as APIs do Kubernetes nos fornecem uma maneira de fazer isso mais facilmente.
Cluster Autoscaler, Horizontal Pod Autoscaler, Vertical Pod Autoscaler, Karpenter, KEDA e a lista continua. Você pode colocar isso em perspectiva para nós?
A primeira parte a entender são os diferentes tipos de autoescala, e então podemos categorizar os diferentes projetos com base nisso. Temos:
Então, dentro dessas categorias, temos os vários projetos que mencionei anteriormente, mas que vale a pena resumir rapidamente:
apiServices.ScaledObject e então gerenciar os objetos HPA subjacentes.Você pode mencionar alguns dos projetos ou tecnologias de dimensionamento automático do Kubernetes menos conhecidos aos quais os engenheiros de plataforma devem prestar atenção?
Não estou ciente de nenhum outro projeto de software de código aberto que tenha soluções mais inovadoras para esses problemas, mas posso dizer que há muitos projetos comerciais sendo construídos em cima (ou em vez) das soluções existentes. Geralmente, eles são voltados para empresas maiores e podem ser caros. Alguns que me vêm à mente são Fairwinds Insights, StormForge e Platform9 EMP.
Quais são as métricas primárias e secundárias às quais os engenheiros de plataforma devem prestar atenção para o autoscaling? Existe mais arte do que ciência no autoscaling do Kubernetes?
Penso nisso de forma semelhante a como penso sobre monitoramento. Qual métrica vai realmente afetar a experiência do usuário final? Isso me leva a pensar sobre os quatro sinais dourados: latência, tráfego, taxa de erro e saturação.
A latência pode não ser o melhor gatilho para escalonamento, e a taxa de erro pode ser apropriada apenas para um aplicativo que é construído de tal forma que só começa a produzir erros quando está sobrecarregado. Acho que o tráfego geralmente é uma métrica realmente ótima, mas funciona melhor se você entender a taxa de tráfego que um único pod pode manipular, o que requer dados ou testes de carga.
Para resumir, acho que há muito “Depende”, então pense no comportamento do seu aplicativo e na experiência dos seus usuários finais ou consumidores. Também direi que a utilização da CPU e da memória raramente é a métrica certa para escalar. Nós adotamos isso como padrão em muitos lugares porque era a maneira mais fácil de começar, mas provavelmente é hora de começar a seguir em frente.
Quanto a se há mais arte do que ciência, isso é algo interessante para se ponderar. Minha reação imediata é que é mais arte do que ciência quando você não tem os dados para fazer ciência. Se você tem testes de carga ou dados do mundo real, então você pode experimentar diferentes métricas e alvos, e medir os resultados desses experimentos. É aí que se torna ciência.
Qual foi a motivação para criar o projeto Goldilocks? Você pode entrar em detalhes técnicos do projeto? HPA, VPA, etc., o complementam?
Por volta do final de 2018, tivemos muitos clientes que estavam enfrentando problemas com seus aplicativos não escalando ou tendo um bom desempenho, e nós recomendamos fortemente que eles definissem suas solicitações de recursos e limites em suas cargas de trabalho. Eles frequentemente voltavam para nós e diziam: “Isso é ótimo, mas o que eu deveria definir para eles?”
Essa foi uma pergunta muito razoável que nos levou a vasculhar muitas métricas do Datadog e reunir recomendações. Na época, eu estava procurando aprender a escrever Go, especificamente dentro do ecossistema Kubernetes, e também queria uma maneira mais automatizada de fornecer essas recomendações aos clientes.
Enquanto eu pesquisava a melhor forma de fornecer essas recomendações, tropecei no projeto VPA. Percebi que o VPA já tinha um mecanismo de recomendação integrado, então, em vez de reinventar a roda, decidi escrever um wrapper bacana em torno desse projeto.
Goldilocks se tornou um controlador que criaria automaticamente objetos VPA para todas as suas implantações no seu cluster e, em seguida, agregaria as recomendações em um único painel. Isso permitiu que você obtivesse uma linha de base para solicitações de recursos para seus pods de forma relativamente rápida, sem precisar peneirar métricas históricas.
Há muitos detalhes complexos sobre como o HPA funciona junto com o VPA que não cabem nesta discussão, mas a resposta geral é: se você estiver dimensionando horizontalmente em métricas diferentes de CPU/memória, os dois funcionam muito bem um com o outro.
Qual é o roteiro de autoescala do Kubernetes? Para onde a comunidade do Kubernetes está indo em termos de autoescala? Há mais alguma coisa que você gostaria de acrescentar?
Outra coisa que vale a pena ficar de olho é o autoescalador de pod multidimensional (MPA) que o Google construiu. Ele está disponível no Google Kubernetes Engine há algum tempo, mas eles recentemente o contribuíram de volta para o repositório de autoescala do Kubernetes. Este autoescalador tem como objetivo escalar pods vertical e horizontalmente com base na CPU ou na memória.
Como mencionei anteriormente, ainda acredito que, na maioria dos casos, CPU e memória não são a melhor métrica de escala horizontal, mas para aquelas pessoas que não têm outra métrica, ou que é a métrica certa, então o MPA pode ser uma solução que vale a pena considerar.
Outro item interessante do roteiro adjacente que está chegando no Kubernetes é a capacidade de alterar dinamicamente as solicitações e limites de recursos de pod. Isso não afetará como esses pods são agendados nos nós, mas abre algumas oportunidades interessantes para o VPA e outros projetos redimensionarem dinamicamente os pods.
YOUTUBE.COM/THENEWSTACK
A tecnologia se move rápido, não perca um episódio. Inscreva-se em nosso canal do YouTube para transmitir todos os nossos podcasts, entrevistas, demos e muito mais.
SE INSCREVER
