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.
Recapitulação: desafios de dimensionamento correto do Kubernetes
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.
Elastic Machine Pools para clusters EKS: uma camada de otimização de custos baseada em tecnologia VM comprovada
Retrocesso da história – Resolvendo desafios de utilização em ambientes VM
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:
O comprometimento excessivo permitiu alocar mais memória para VMs em execução em um nó hipervisor do que o próprio nó possui; se algumas VMs não estivessem usando toda a memória alocada, outras poderiam usá-la.
A fusão de páginas de memória permitiu que VMs executando sistemas operacionais e aplicativos semelhantes compartilhassem uma única cópia de porções idênticas de memória, aumentando a densidade com que as VMs poderiam ser colocadas em nós.
A migração ao vivo permitiu que as VMs fossem movidas perfeitamente para nós recém-provisionados quando o cluster precisava ser expandido para lidar com a demanda ou para consolidar cargas de trabalho quando os nós eram subutilizados, para que alguns pudessem ser desligados até que fosse necessário.
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.
Como os pools de máquinas elásticas usam tecnologia de virtualização comprovada para resolver os desafios de FinOps do Kubernetes
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:
EVMs com quantidades significativas de recursos alocados, mas não utilizados por suas cargas de trabalho, são consolidados de forma mais densa no Bare Metal gerenciado por EMP para melhorar a utilização, sem alterar a configuração de cargas de trabalho individuais do Kubernetes.
Quando mais cargas de trabalho são implantadas ou as existentes começam a usar mais alocações de recursos devido à demanda adicional dos aplicativos, mais instâncias Bare Metal são provisionadas e EVMs são migrados em tempo real para elas para reequilibrar a carga, sem interromper os pods em execução nelas. (especialmente benéfico para aplicativos monolíticos sensíveis a interrupções, como muitos aplicativos de negócios escritos em Java). Da mesma forma, se a utilização geral do cluster diminuir novamente, os EVMs subutilizados serão migrados em tempo real para um número menor de instâncias Bare Metal e o excesso de computação será desprovisionado sem interrupções.
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.
Comece a otimizar com EMP!
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!
Leitura Adicional
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
A carreira de Joe Thompson em TI começou quando o kernel Linux ainda estava nas versões 1.x e as velocidades da Internet doméstica eram expressas em kilobits por segundo. Desde 2014, trabalha principalmente com sistemas nativos em nuvem, começando com OpenStack e nuvens públicas,…
Este site utiliza cookies para melhorar sua experiência de navegação. Ao continuar, você concorda com o uso de cookies. Para mais informações, consulte nossa Política de Privacidade.
Funcional
Sempre ativo
O armazenamento ou acesso técnico é estritamente necessário para a finalidade legítima de permitir a utilização de um serviço específico explicitamente solicitado pelo assinante ou utilizador, ou com a finalidade exclusiva de efetuar a transmissão de uma comunicação através de uma rede de comunicações eletrónicas.
Preferências
O armazenamento ou acesso técnico é necessário para o propósito legítimo de armazenar preferências que não são solicitadas pelo assinante ou usuário.
Estatísticas
O armazenamento ou acesso técnico que é usado exclusivamente para fins estatísticos.O armazenamento técnico ou acesso que é usado exclusivamente para fins estatísticos anônimos. Sem uma intimação, conformidade voluntária por parte de seu provedor de serviços de Internet ou registros adicionais de terceiros, as informações armazenadas ou recuperadas apenas para esse fim geralmente não podem ser usadas para identificá-lo.
Marketing
O armazenamento ou acesso técnico é necessário para criar perfis de usuário para enviar publicidade ou para rastrear o usuário em um site ou em vários sites para fins de marketing semelhantes.