Kubernetes não é uma questão de redução de custos.

A maioria das pessoas concorda que o custo de operar o Kubernetes é elevado devido à maneira como desenvolvemos nossas aplicações.

Kubernetes é amplamente utilizado para agendar e administrar serviços em empresas de médio e grande porte, sendo uma ferramenta valiosa para gerenciar uma variedade de sistemas, desde websites até pipelines de processamento de dados, quando combinado com o padrão de projeto de microserviços. No entanto, há um consenso no ecossistema de que o Kubernetes enfrenta desafios relacionados a custos. Infelizmente, a abordagem predominante para reduzir esses custos também apresenta suas próprias complicações.

O desafio não está no Kubernetes em si, mas sim na maneira como desenvolvemos aplicações.

Também presente no InfoWorld: Os principais softwares de código aberto de 2023.

Por que o custo do Kubernetes é elevado.

Eu tenho estado envolvido com o Kubernetes desde o início e um dos primeiros benefícios que percebemos foi a economia de custos. Pensávamos que estávamos criando um sistema que ajudaria a gerenciar custos, reduzindo o número de máquinas virtuais sendo utilizadas. Estávamos certos nessa suposição, mas talvez errados ao pensar que isso resultaria, a longo prazo, em economia de custos. Na realidade, a opinião predominante nos dias de hoje é que o Kubernetes é, na verdade, muito caro de operar.

Houve algum problema?

Em resumo, tudo correu bem. A abordagem do Kubernetes revolucionou a forma como implantamos e gerenciamos aplicativos, tornando-se mais sofisticada ao longo do tempo. Além disso, o modelo de microservices se tornou amplamente adotado, substituindo as aplicações monolíticas que eram comuns anteriormente.

Pode-se afirmar de forma justa que a economia de custos sempre foi uma consequência secundária do Kubernetes e não um objetivo planejado. Se essa ideia foi deixada de lado, não foi porque o Kubernetes abandonou um objetivo, mas sim porque se revelou não ser totalmente verdadeira à medida que o modelo por trás do Kubernetes se desenvolveu e amadureceu.

Podemos discutir as razões pelas quais o custo do Kubernetes aumentou significativamente.

Kubernetes foi visto como uma opção mais econômica do que a execução de um sistema em que cada microserviço rodava em sua própria máquina virtual. A economia de tempo pode ter sido um fator decisivo nesse sentido. No entanto, comparar esse tipo de configuração já não é tão relevante, uma vez que o Kubernetes oferece plataformas sistematizadas que alteram a economia da computação em nuvem.

O preço da garantia de que o recipiente é confiável.

No começo, Kubernetes apresentou o conceito do Controlador de Replicação, que posteriormente evoluiu para Deployments e ReplicaSets. Essas abstrações foram criadas para lidar com a limitação de contêineres e máquinas virtuais, que têm um tempo de inicialização lento. Isso os torna inativos em situações de falha (quando um nó falha) ou de aumento de escala (quando o tráfego aumenta a ponto das instâncias atuais não conseguirem lidar com a demanda).

Antes do surgimento do Kubernetes, costumávamos lidar com servidores pré-provisionados ou máquinas virtuais para gerenciar nossas aplicações, movendo-os entre ambientes de produção e teste. Com a replicação do Kubernetes, agora podemos simplesmente especificar o número de instâncias desejadas e o controle de planos do Kubernetes cuidará automaticamente de tudo isso – garantindo a saúde, lidando com falhas e gerenciando as implantações de forma eficiente.

Porém, aqui é onde o custo do Kubernetes começa a aumentar. Para lidar com a escalabilidade e as falhas, o Kubernetes executa múltiplas instâncias de um aplicativo (geralmente pelo menos três, mas muitas vezes cinco ou mais). É crucial que essas réplicas dos aplicativos sejam distribuídas entre diferentes nós do cluster. Isso ocorre porque:

• Se um nó falhar, reiniciar ou deixar de responder, os recipientes programados nesse nó ficarão inacessíveis, e o Kubernetes redirecionará o tráfego para contêineres em outros nós.
• À medida que o tráfego aumenta, a carga é distribuída de forma mais equitativa entre todas as instâncias em funcionamento, evitando que algumas fiquem sobrecarregadas enquanto outras permanecem ociosas.

Isso implica que a qualquer momento você está pagando para manter várias instâncias de seu aplicativo em execução, mesmo que a carga seja baixa e as falhas sejam raras. É importante estar pronto para um aumento súbito no tráfego ou uma falha inesperada, o que requer manter capacidade de reposição disponível o tempo todo. Esse conceito é conhecido como superdimensionamento.

Autoscalers, que foram introduzidos mais tarde no desenvolvimento do Kubernetes, representaram uma melhoria significativa. Esses sistemas monitoram indicadores como o aumento do tráfego de rede ou do uso de CPU, e automaticamente ajustam a capacidade de forma apropriada. Um dos autoscalers mais populares do Kubernetes é o Horizontal Pod Autoscaler, que simplesmente adiciona mais réplicas do aplicativo conforme a demanda aumenta.

Entretanto, devido à demora dos recipientes em iniciar e à imprevisibilidade da carga, os autoscalers precisam ser acionados cedo e desligar a capacidade extra tardiamente. Embora possam resultar em economia de custos, os autoscalers não são uma solução perfeita. Como mostrado no gráfico acima, mesmo quando os autoscalers prevêem o aumento do tráfego, ainda há desperdício tanto durante a inicialização quanto quando a carga diminui.

Sidecars consomem recursos.

No entanto, não é apenas o uso de réplicas que torna o Kubernetes caro. O modelo sidecar também influencia nos custos. Uma cápsula pode conter diversos contêineres em funcionamento. Geralmente, um é o aplicativo principal, enquanto os outros contêineres são sidecars auxiliares. Um microserviço pode ter sidecars dedicados para serviços de dados, monitoramento de métricas, escalabilidade, entre outros. Cada um desses sidecars requer recursos próprios, como memória, CPU, armazenamento, e assim por diante.

Mais uma vez, não é preciso encarar isso como algo negativo. Essa estrutura mostra a grande capacidade do Kubernetes. É possível envolver toda uma operação em torno de um aplicativo na forma de sidecars. No entanto, é importante observar que agora um microserviço pode ter vários sidecars, o que implica que ao executar cinco réplicas, você estará lidando com cerca de 25 a 30 contêineres.

Isso leva os engenheiros de plataforma a terem que não apenas aumentar o tamanho de seus conjuntos de servidores (adicionando mais nós), mas também ampliar a capacidade de memória e processamento dos servidores já em uso.

‘O controle de custos não deve ser apenas uma adição.’

Quando a nuvem surgiu pela primeira vez, a economia global estava se recuperando da recessão de 2007. Em 2015, com a introdução do Kubernetes, a tecnologia estava em ascensão. Somente no final de 2022 é que as pressões econômicas começaram a impactar os custos da nuvem. A nuvem se desenvolveu em um momento em que a redução de custos não era considerada uma prioridade principal.

Em 2022, os princípios de design em nuvem que utilizávamos estavam bem estabelecidos. Optamos por priorizar a robustez e a tolerância a falhas em detrimento do custo. No entanto, com a queda na economia, foi necessário revisar nossos padrões de despesas na nuvem.

Não é surpresa que tenha surgido uma indústria focada nesse desafio. Existem várias ferramentas disponíveis para otimizar os custos do Kubernetes. Elas sugerem que é possível controlar os custos através da adequação do tamanho do cluster e da aquisição de recursos computacionais mais econômicos sempre que for viável.

Uma comparação válida pode ser feita com um carro que funciona com gasolina. Para economizar dinheiro, podemos (a) abastecer o tanque somente até a metade, considerando que não precisamos de um tanque cheio no momento, e (b) adquirir combustível mais barato sempre que nos depararmos com postos de gasolina abaixando seus preços o suficiente.

Não estou indicando que essa seja uma estratégia inadequada para o “carro” que possuímos atualmente. Se a nuvem tivesse se expandido em um período de pressão econômica mais rigorosa, é provável que o Kubernetes tivesse integrado essas funcionalidades essenciais no núcleo do sistema de controle, da mesma forma que os carros a gasolina de hoje são mais eficientes em termos de combustível do que aqueles fabricados em épocas de preços baixos de gasolina.

Para ampliar a comparação, pode ser mais vantajoso trocar um veículo a gasolina por um veículo elétrico. No contexto do Kubernetes, isso significa migrar de um ambiente de execução baseado exclusivamente em contêineres para uma alternativa diferente.

Os recipientes têm um custo elevado para serem utilizados.

Construímos grande parte de nossa infraestrutura em recipientes, os quais são dispendiosos para serem utilizados devido a três fatores que os tornam assim.

1. Os recipientes demoram a iniciar.
2. Os recipientes utilizam recursos continuamente, mesmo quando não estão em uso.
3. Os recipientes têm um tamanho maior do que as aplicações que guardam.

Começar de forma gradual: Um recipiente demora alguns segundos, ou até mesmo um minuto, para ficar completamente operacional online. Alguns desses atrasos são devido à sobrecarga de contêineres de baixo nível. Outros são simplesmente o tempo necessário para iniciar e configurar um servidor de longa duração. No entanto, essa lentidão é suficiente para impedir que um sistema responda adequadamente às necessidades de escalabilidade. Deve ser proativo, ou seja, deve ser capaz de se expandir antecipadamente em preparação para a carga, e não em resposta a ela.

Recursos de consumo: A abordagem dos microsserviços no Kubernetes propõe que cada recipiente contenha um servidor de software persistente, conhecido como daemon, que opera constantemente e processa múltiplas solicitações ao mesmo tempo. Isso resulta em uma utilização contínua de recursos, mesmo quando o servidor não está sob carga.

Paráfrase: O tamanho considerável de um recipiente pode ser subjetivo, já que depende da perspectiva de cada um. Por exemplo, um recipiente pode parecer pequeno em relação a uma imagem de vários gigabytes. No entanto, ao embalar um microserviço de 2 MB em uma imagem de base de 25 MB, a imagem resultante terá uma sobrecarga maior ao ser movida, iniciada e durante sua execução.

Se conseguíssemos resolver ou eliminar esses três desafios, poderíamos diminuir o custo de operar o Kubernetes e alcançar níveis de eficiência que nenhum outro método de controle de gastos poderia alcançar.

Serverless e WebAssembly oferecem uma solução.

A computação sem servidor refere-se a um modelo em que não há um servidor de software em execução continuamente. Em vez disso, um aplicativo sem servidor é acionado apenas quando uma solicitação é recebida e é encerrado após o tratamento da solicitação. Esse método também é conhecido como processamento direcionado a eventos, em que um evento específico, como uma solicitação HTTP, inicia um processo dedicado a lidar com aquela solicitação.

Diferentes sistemas, como AWS Lambda, OpenWhisk, Azure Functions e Google Cloud Functions, operam de maneira semelhante. Cada um possui vantagens e desvantagens específicas, mas nenhum se compara em velocidade ao WebAssembly, e muitos não são compatíveis com Kubernetes. Vamos analisar as características necessárias para um sistema sem servidor operar com eficácia e custo-benefício.

Quando um agrupamento de servidores processa uma única requisição de um programa, o processo segue da seguinte maneira:

• Uma vez que o aplicativo é aberto, uma solicitação é recebida e processada.
• A instância é executada até que um resultado seja fornecido.
• A instância é desativada e os recursos são liberados.

Os aplicativos sem servidor têm uma vida útil limitada e não conseguem lidar com diversas solicitações por instância. Quando várias solicitações simultâneas chegam, uma instância do aplicativo é gerada para cada solicitação. É importante que nenhum processo seja executado por mais do que alguns minutos, preferencialmente menos de meio segundo.

Três atributos se tornam extremamente relevantes.

• A inicialização do aplicativo deve ser extremamente rápida, com o objetivo de se iniciar em milissegundos ou menos em velocidade supersônica.
• É importante reduzir o uso de recursos ao mínimo possível ao desenvolver um aplicativo, limitando o uso de memória, CPU e GPU e mantendo os recursos bloqueados apenas pelo tempo necessário.
• A forma binária deve ser o mais compacta possível, contendo somente o código do aplicativo e os arquivos essenciais para seu funcionamento.

Entretanto, os três requisitos necessários para uma plataforma sem servidor ideal são pontos fracos para os recipientes. Portanto, é necessário um modelo de recipiente diferente.

WebAssembly oferece esse tipo de capacidade. Um exemplo prático disso é o Spin, uma ferramenta de código aberto que permite criar e executar aplicativos WebAssembly no estilo serverless, com um tempo de inicialização inferior a um milissegundo, ao contrário dos vários segundos necessários para iniciar um contêiner. O Spin consome poucos recursos do sistema e gerencia de forma eficaz o acesso a esses recursos conforme necessário.

Por exemplo, o Spin utiliza recursos como CPU, GPU e memória somente durante o processamento de uma solicitação e os libera imediatamente para serem utilizados por outro aplicativo. Além disso, o formato binário do WebAssembly é eficiente e compacto, com uma aplicação de 2 MB ocupando aproximadamente 2 MB em WebAssembly, sem adicionar muita sobrecarga como ocorre com contêineres.

Dessa forma, é possível empregar a estratégia conhecida como underprovisioning, que consiste em alocar uma quantidade reduzida de recursos por nó do que seria necessário para executar todos os aplicativos simultaneamente em plena capacidade. Essa abordagem é eficaz pois reconhecemos que não será necessário que todos os aplicativos estejam em plena capacidade ao mesmo tempo.

É neste ponto que começamos a compreender como o design do serverless é naturalmente mais econômico.

Reconhecer e ajustar automaticamente a capacidade de resposta do sistema conforme a demanda é uma estratégia eficiente para otimizar recursos em ambientes de nuvem, como os clusters Kubernetes. Isso pode ser alcançado por meio da utilização de tecnologias sem servidor, como Spin e WebAssembly, que permitem a ativação e desativação instantânea de aplicativos conforme necessário, resultando em economia significativa de recursos.

Manter este estado requer esforço. Em vez de processos demorados de daemon, é necessário desenvolver funções sem servidor, cada uma responsável por um microserviço. Um aplicativo sem servidor, como o Spin, pode executar múltiplas funções, sendo cada uma um binário WebAssembly. Isso significa que é possível ter serviços ainda menores do que os tradicionais microsserviços, tornando-os mais econômicos e simples de manter.

Utilizar essa abordagem é a maneira mais eficaz de otimizar o desempenho do seu grupo de servidores, ao mesmo tempo em que reduz os gastos.

Utilizar Kubernetes para economizar.

Algumas cargas de trabalho em nuvem não são ideais para serem executadas em um ambiente serverless. Em geral, os bancos de dados funcionam de forma mais eficiente em contêineres, especialmente em processos de longa duração nos quais os dados podem ser armazenados em memória. Iniciar e interromper um banco de dados a cada solicitação pode resultar em penalidades significativas de desempenho. Da mesma forma, serviços como Redis (filas pub/sub e armazenamento de chave/valor) são mais adequados para serem gerenciados em processos de longo prazo.

Aplicativos web, pipelines de dados, serviços REST, chatbots, websites, sistemas de gerenciamento de conteúdo e até mesmo inteligência artificial em inferência são mais econômicos quando desenvolvidos e operados como aplicativos sem servidor. Assim, ao executá-los dentro do Kubernetes com Spin, você economizará consideravelmente a longo prazo.

O WebAssembly oferece uma opção aos contêineres, obtendo os mesmos níveis de segurança e estabilidade, porém com um custo significativamente menor. Ao adotar um modelo de aplicação sem servidor, podemos economizar recursos de cluster, aumentando ao máximo a eficiência de nossos nós Kubernetes.

Matt Butcher, Ph.D. em filosofia, é o cofundador e CEO da Fermyon, uma empresa de nuvem que se destaca por sua abordagem sem servidor baseada em WebAssembly. Além disso, ele é reconhecido por sua contribuição na criação de diversas ferramentas como Helm, Brigade, CNAB, OAM, Glide e Krustlet. Butcher também é autor e coautor de vários livros, incluindo “Learning Helm” e “Go in Practice”, e é co-criador da série “Illustrated Children’s Guide to Kubernetes”. Residindo no Colorado, ele concentra sua atuação em projetos relacionados ao WebAssembly, como Spin, Fermyon Cloud e Bartholomew, enquanto desfruta de uma boa xícara de café.

Lo siento, pero necesito un texto para poder parafrasearlo. ¿Puedes proporcionarme un fragmento o una idea principal para que pueda ayudarte con la paráfrasis?

O New Tech Forum fornece um espaço para líderes da área de tecnologia, incluindo fornecedores e outros colaboradores externos, explorarem e debaterem com detalhes e amplitude sem precedentes sobre tecnologia empresarial emergente. A seleção é feita de forma subjetiva, com base nas tecnologias que consideramos serem importantes e mais interessantes para os leitores do InfoWorld. A InfoWorld não garante a publicação de materiais de marketing e reserva o direito de editar todo o conteúdo contribuído. Qualquer dúvida pode ser enviada para doug_dineley@foundryco.com.

Mais informações sobre Kubernetes:

• O surgimento do Kubernetes em 3 de junho de 2024.
• Recomendações ideais para armazenamento de objetos no Kubernetes | 19 de outubro de 2021
• Forma de utilizar a interface de programação de aplicativos do Kubernetes em 13 de maio de 2020.
• A comunidade do Kubernetes se encontra para a primeira edição europeia da KubeCon em 24 de março de 2016.
• Apresentando Konvoy – Solução Kubernetes de Nível Empresarial | 25 de setembro de 2019