Quase todas as organizações com uma presença significativa na nuvem têm problemas com gastos desperdiçados em enormes quantidades de recursos de nuvem não utilizados, e um catálogo inteiro de ferramentas surgiu para tentar ajudar. Mas o que você faz quando escolhe e implanta uma ferramenta de controle de custos FinOps, como um escalonador automático, em seu cluster Amazon Web Services EKS e… ela fica aquém das expectativas?
Você escolheu a ferramenta errada? Provavelmente não — na Platform9, nossas conversas com clientes têm mostrado consistentemente que uma ampla variedade de ferramentas existentes ajudam… mas não o suficiente. Você precisa de algo mais do que apenas uma ferramenta – você precisa de um solução integrada construído para atingir seus objetivos de FinOps.
Se você leu nossas últimas postagens no blog sobre Kubernetes FinOps, sabe que há uma grande variedade de ferramentas destinadas a ajudá-lo a otimizar o uso de recursos de carga de trabalho – desde o código principal integrado ao próprio Kubernetes até componentes criados para fazer interface com recursos externos Produtos SaaS, até complementos destinados a serem executados no próprio cluster. Mas você também sabe que eles trazem complexidade adicional, desde o manuseio de credenciais de infraestrutura até interações inesperadas entre si ao usar várias ferramentas.
Muitos deles fazem um bom trabalho ao aumentar ou diminuir o cluster para atender às demandas de recursos do aplicativo e garantir a disponibilidade, mas na verdade não se destinam a otimizar essas cargas de trabalho de aplicativos — e mesmo quando o são, são limitadas pelos recursos de gerenciamento de recursos do próprio Kubernetes.
O resultado líquido é que mesmo com uma ou mais dessas ferramentas em funcionamento, o consumo real de recursos do cluster ainda fica em torno de 30%. Isto é significativamente menos do que a maioria das empresas gostaria – mas o que mais se pode fazer?
Este não é um problema novo — na verdade, é bastante antigo: os principais impulsionadores da ineficiência dos contêineres são os mesmos que levaram à ineficiência inicial da virtualização — desafios de gerenciamento de recursos e carga e o desejo de evitar deixar os aplicativos sem recursos por causa de escalar atrasos durante períodos de pico de demanda.
A questão da subutilização intratável no Kubernetes é uma repetição quase direta da mesma luta em ambientes de virtualização de 15 a 20 anos atrás. As máquinas virtuais (VMs) prometiam a capacidade de executar serviços com isolamento semelhante ao de hardware enquanto compartilhavam recursos de forma mais eficiente: em vez de precisar executar vários recursos no mesmo sistema operacional ou desperdiçar recursos de hardware para isolá-los totalmente uns dos outros. Em teoria, você poderia provisionar várias VMs pequenas por nó físico, com serviços executados em sistemas operacionais separados do kernel para manter um limite de segurança entre eles.
Na prática, a virtualização em suas formas iniciais não cumpriu esta promessa: se seu aplicativo tivesse períodos de maior utilização, você teria que permitir que ele usasse recursos suficientes para lidar com esses picos. Às vezes, implantar instâncias do aplicativo em VMs adicionais por trás de um balanceador de carga era suficiente para lidar com a demanda extra, mas se você não conseguisse provisionar com rapidez suficiente para absorver a carga à medida que ela aumentasse, seu aplicativo ainda acabaria atingindo um obstáculo. portanto, as máquinas virtuais ainda tendiam a ser configuradas com muita sobrecarga de recursos. Também era difícil lidar com a movimentação de VMs entre hipervisores para reequilibrar o uso de recursos sem interromper as cargas de trabalho executadas neles.
Em pouco tempo, os hipervisores começaram a ganhar capacidades destinadas a um melhor gerenciamento de recursos:
Um dos benefícios elogiados da tendência de conteinerização na última década foi a maior eficiência em relação à virtualização tradicional, usando novos recursos do Linux, como namespaces e grupos de controle; em teoria, sem a necessidade de executar um kernel completo do sistema operacional e bibliotecas para isolar aplicativos, os processos de aplicativos poderiam compartilhar o mesmo hardware em maior densidade com segurança. Na prática… não funcionou tão bem. O Kubernetes possui alguns mecanismos para ajudar, mas dentro da própria plataforma nada resolve esses problemas de forma abrangente.
A solução para problemas de gerenciamento de recursos do Kubernetes é hoje a mesma que era para máquinas virtuais: use comprometimento excessivo, mesclagem de páginas e migração em tempo real para fazer com que a consolidação necessária funcione perfeitamente. Mas o próprio Kubernetes não tem como fazer isso e, em um ambiente de nuvem como o AWS, normalmente você não tem acesso ao hipervisor que executa suas instâncias. Elastic Machine Pools (EMPs) preenchem a lacuna aproveitando o AWS Bare Metal, que lhe dá a capacidade de configurar uma camada de virtualização sob o controle direto do EMP (na verdade, permitir que os clientes executem seus próprios ambientes de virtualização como esse foi exatamente o motivo pelo qual a AWS construiu o Capacidade Bare Metal em primeiro lugar).
Com a camada de virtualização estabelecida, a EMP configura suas próprias máquinas virtuais, chamadas Elastic VMs (EVMs), e as une ao cluster EKS como novos nós – permitindo que a EMP use os mesmos mecanismos de virtualização comprovados em produção discutidos acima para otimizar automaticamente a utilização do Kubernetes sem sacrificar a disponibilidade:
Toda essa otimização automatizada ocorre em um nível abaixo do EKS e dos escalonadores automáticos baseados em cluster – você não precisa alterar a forma como define e executa suas cargas de trabalho para se beneficiar e ainda está usando o plano de controle de cluster EKS padrão e a API Kubernetes . Além disso, se você já estiver usando escalonadores automáticos ou ferramentas de dimensionamento correto de carga de trabalho em seus clusters EKS, poderá continuar a fazer isso — o EMP pode ser executado junto com eles, não interferirá em suas ações e ainda fornecerá otimização adicional por meio de seus EVMs.
A capacidade de gerenciar a utilização do cluster como um todo dessa forma é algo que está faltando no Kubernetes, e essa lacuna é a principal razão pela qual os operadores de cluster têm tido tanta dificuldade em alcançar uma maior utilização do cluster – usando ferramentas construídas sobre o A API Kubernetes simplesmente não consegue alcançar esses tipos de resultados sem impacto negativo nas cargas de trabalho no cluster.
Com o EMP finalmente preenchendo esta lacuna, os operadores de cluster não precisam mais percorrer uma linha difícil entre economizar dinheiro e proteger a disponibilidade de aplicações. Como resultado, agora é possível obter utilizações de até 70% no Kubernetes sem arriscar a disponibilidade dos aplicativos — e a economia de custos por não pagar por recursos de computação desperdiçados com o preço do EC2 é significativa. E, em disponibilidade geral, planejamos ativar o Always-On Assurance da Platform9 — nosso monitoramento e gerenciamento proativos do seu ambiente para detectar e corrigir problemas, geralmente antes mesmo que você perceba o desenvolvimento de um problema.
O Platform9 Elastic Machine Pool agora está disponível como uma oferta de acesso antecipado para o Amazon EKS (consulte nossa listagem do AWS Marketplace para obter detalhes). Entre em contato conosco para obter mais informações e nós o colocaremos em operação rapidamente. Os clientes normalmente obtêm economias significativas em clusters EKS em relação ao uso apenas de escalonadores automáticos em poucas semanas!
Do blog da Platform9: Kubernetes FinOps: dimensionando corretamente as cargas de trabalho do Kubernetes
Mais sobre o pool de máquinas elásticas:
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
