Agora que o Kubernetes se tornou uma solução madura, as organizações buscam expandir suas plataformas para dar suporte a um número maior de aplicativos e mais linhas de negócios. Para fazer isso em escala, elas precisam oferecer suporte a esses aplicativos e linhas de negócios em ambientes com vários locatários. Mesmo os aplicativos modernos de microsserviços precisam compartilhar recursos.

Citamos o exemplo de uma empresa do setor de saúde. Eles mergulharam no Kubernetes (especificamente o Red Hat OpenShift) há dois anos e agora são primeira plataforma (platform-first), significando que todos os seus novos aplicativos são arquitetados para se beneficiar da velocidade, agilidade e elasticidade nativas da nuvem e os aplicativos existentes estão sendo gradualmente reprogramados para o ambiente de cloud. São aplicativos críticos para os negócios que, por exemplo, aproveitam grandes quantidades de dados e aprendizado de máquina para ajudar os médicos a diagnosticar e tratar com mais precisão e eficácia seus pacientes.

Como organização de primeira plataforma, essa organização precisa gerenciar vários aplicativos no Kubernetes e está alavancando a multilocação de software (multitenancy).

O Kubernetes permite que os administradores gerenciem recursos compartilhados por meio de solicitações e limites, alocando CPU e memória. Os limites podem ficar supercomprometidos, mas as solicitações têm seus recursos garantidos. Em outras palavras, o Kubernetes agendará apenas um pod de contêiner quando a soma das solicitações de todos os contêineres nos pods puder caber em um nó.

As empresas que incorporam aplicativos ao Kubernetes geralmente adotam certas práticas recomendadas em termos de gerenciamento de solicitações e limites de recursos de contêiner. Para a maioria das organizações, as linhas de negócios (LOBs) acessam a plataforma começando por atribuir um “namespace” (ou “project” no OpenShift) e definem uma cota de recursos. Essa cota protege a quantidade de recursos permitidos para os pods implantados nesse namespace, enquanto as solicitações garantem que diferentes linhas de negócio não excedam os recursos no nível do cluster. Ao usar cotas, um usuário que envia um aplicativo ao Kubernetes deve fornecer uma solicitação de recursos pelos seguintes motivos:

• Manter um certo nível de qualidade de serviço (QoS). Isso é especialmente crítico para aplicativos com uso intenso de CPU, onde a CPU solicitada pode ser forçada a responder pelo runtime do cgroup, quando o nó ficar congestionado.
• Garantir uma quantidade mínima de recursos. A memória não pode ficar supercomprometida ou ser trocada no Kubernetes, portanto, muitos serviços Java usam solicitações para garantir que uma quantidade mínima esteja disponível para a JVM, para reduzir os riscos de OOM (out-of-memory ou memória insuficiente).
• Facilitar o gerenciamento e o planejamento de recursos em um ambiente multilocatário. Isso é obtido juntamente com as cotas de recursos definidas nos namespaces, fornecendo a cada aplicativo ou LOB seus próprios recursos.

O desafio: as práticas atuais recomendadas para a multilocação ainda são complexas para gerenciar e limitar a elasticidade

As melhores práticas para gerenciar solicitações de recursos requerem certa capacidade de gerenciamento, mas em escala, as empresas continuam enfrentando desafios. Como as solicitações de recursos especificadas para um serviço são estimadas, é muito fácil para um cluster enfrentar as seguintes situações:

• Superestimativa de recursos. É muito comum ver uma estimativa de uso de recursos significativamente maior do que o uso real. É compreensível que os desenvolvedores tendem a ser excessivamente conservadores sobre suas necessidades de uso de recursos. Eles geralmente solicitam recursos com grandes buffers para que seu serviço não sofra.
• Subestimativa de recursos. É uma situação em que o uso real dos recursos é superior ao uso solicitado, o que pode resultar em problemas adjacentes complicados ou, ainda pior, em nós com supercomprometimento, em que os pods podem ser desalojados devido à pressão do recurso (para recursos sem compressão, como memória). Essa contenção de recursos resulta em baixo desempenho do aplicativo e experiências ruins para os usuários.

O cerne da questão é que os desenvolvedores apenas veem e têm responsabilidade por seus serviços. Um cluster multitenant hospedará muitos serviços, cada um com suas próprias especificações, que não consideram o efeito global da execução em paralelo.

Se 100 serviços tiverem apenas 10% de superalocação, a soma da demanda em um cluster ou projeto aparecerá como “cheia”, mesmo quando não estiver. A consequência é que você não poderá executar mais serviços, não poderá redimensionar os limites para aqueles que precisam e acabará desperdiçando dinheiro executando mais nós do que o necessário.

É um desafio muito difícil. As equipes de DevOps e SRE (Site Reliability Engineering) devem se preocupar com isso. É difícil ver o impacto da alocação geral e onde otimizar, ao pesquisar em centenas ou mesmo em apenas 50 serviços diferentes em execução em projetos diferentes. DevOps e SREs AMBOS precisam verificar se:

• Os serviços estão superalocados;
• O project / namespace está subalocado;
• O cluster está subdimensionado.

As solicitações de recursos são aquelas “matadoras” silenciosas da elasticidade e da eficiência.

Como o Turbonomic ajuda você a gerenciar efetivamente a multilocação do Kubernetes

No Turbonomic 6.4, foi introduzida a funcionalidade de descoberta das solicitações de recursos nos clusters Kubernetes. Isso permite aos clientes:

• Visualizar a quantidade de solicitações de recursos em todos os níveis da pilha, do pod ao nó e do namespace ao cluster.
• Visualizar a tendência histórica das solicitações de recursos em todos os níveis.

Abaixo, nas capturas de tela da interface do usuário, a Turbonomic mostra as principais máquinas virtuais (nós), nesse caso, classificadas por solicitações de CPU (Figura 1). Você também pode visualizar o uso real da CPU em comparação com as solicitações de CPU durante um período de tempo, neste caso, nas últimas 2 horas (Figura 2).

Figura 1. Principais máquinas virtuais classificadas por solicitações de CPU.

Figura 2. Uso real da CPU x solicitação da CPU em um nó durante um período de 2 horas.

Mas, uma visualização no nível do cluster não é suficiente. Como os recursos são alocados pelo namespace, você também precisa ter uma visão da utilização provisionada e da real em cada namespace. Isso permite um melhor “autoatendimento”, para que cada LOB possa ver com que eficácia eles estão usando o que está reservado. Para a equipe da plataforma, ela permite identificar quais projetos estão ficando sem recursos e quais não estão (veja a Figura 3, com o exemplo de um único namespace).

Para os projetos que estão sendo preenchidos, é possível avaliar se estão cheios com base no uso real ou se foi solicitado mais do que o necessário, o que pode ser uma oportunidade para otimizar a carga de trabalho. As equipes da LOB ou do App podem examinar a utilização do namespace e fazer uma busca detalhada para ver os pods específicos em seu namespace.

Figura 3. Uso real da CPU / Mem x. solicitação da CPU / Mem para um namespace. O usuário pode ver as ações de redimensionamento para os pods implantados ali.

Mais importante ainda, o Turbonomic identifica se há oportunidades para redimensionar solicitações e consolidar recursos (pods “móveis”) nos nós, para acomodar mais pods.

Observe os botões “Ações” à direita na Figura 1. No nível do cluster, o Turbonomic também determinará quanta capacidade está disponível para a entrada de novos serviços ou projetos. Com a visualização (Figuras 1 e 2) de Solicitações x Uso Real, os profissionais podem ver rapidamente as discrepâncias entre o que está sendo alocado e o que está sendo usado. Mas, quando você está operando em escala, o monitoramento e os painéis não são suficientes.

O Turbonomic identifica automaticamente oportunidades para otimizar seus clusters para desempenho e eficiência, com automação

Garantir automaticamente um desempenho contínuo, enquanto maximiza a eficiência é o objetivo do Turbonomic. É o que fazemos desde o início do conceito de virtualização, quando os aplicativos começaram a ser executados em ambientes compartilhados.

Quando se trata do Kubernetes, o Turbonomic analisa continuamente a pilha completa, para garantir que as necessidades de recursos em tempo real dos aplicativos sejam atendidas exatamente pelo suprimento definido de recursos. Ele gera ações específicas que podem e devem ser automatizadas ou integradas aos fluxos de trabalho existentes da sua organização, a saber:

• Alterar ações para mover pods de um nó com plena utilização da solicitação para um nó com solicitação menos utilizada.

Figura 4: O Turbonomic determina se dois pods de Contêiner que estão atualmente com congestionamento no nó devem ser movidos para um nó com capacidade para eles. Observe que o Turbonomic identifica qual pod mover, onde e quando, antes que os pods falhem, uma lacuna do orquestrador k8s.

• Otimizar as decisões de posicionamento contínuo, para que a utilização da solicitação não exceda a capacidade de alocação (zona de despejo).
• Gerar o redimensionamento da solicitação de recurso, quando ela for superestimada em comparação com o uso real.
• Gerar a ação do nó de provisionamento, quando todos os nós existentes estiverem congestionados com a solicitação de recurso.

Figura 5: O Turbonomic determina se o cluster requer outro nó para suportar os aplicativos em execução.

Com o Turbonomic, multilocação não significa que você deve limitar a elasticidade

Os limites e as solicitações visam facilitar o gerenciamento da multilocação e fazem isso até certo ponto. Mas, como vimos, surgem desafios porque, no final das contas as pessoas estão tomando decisões de alocação. Elas precisam estimar e adicionar buffers, porque não conseguem analisar a demanda dinâmica 24 horas por dia, 7 dias por semana. Isso coloca em risco o desempenho do aplicativo, pode aumentar desnecessariamente os custos e limitar a elasticidade, e é por isso que você fez esse investimento em Kubernetes.

Com o software Turbonomic tomando decisões de recursos para você, de forma contínua e automática, você pode obter os benefícios da multilocação, sem limitar a elasticidade e a eficiência das aplicações.

Fundada em 2009, a Turbonomic Inc. é uma das empresas privadas de tecnologia que mais rapidamente cresceu, com base na confiança de milhares de organizações empresariais nas suas soluções voltadas para maximizar o valor de seus investimentos em TI.

A Leadcomm é uma empresa parceira da Turbonomic que atua desde 1998 no Brasil, Estados Unidos e Europa, construindo um sólido portfólio de softwares e serviços. Somos especializados em Segurança de Dados e Performance de Aplicações, com foco na distribuição e integração de soluções inovadoras.

Conte com nosso conhecimento e experiência, adquiridos em projetos realizados em organizações de diversos portes e setores da economia. Fale conosco.

Este texto foi adaptado do artigo “Managing Multitenancy in Kubernetes Environments” (Turbonomic, 2019)