O que é um bom plano de controle para operar um grande número de clusters Kubernetes?

Pranav DharwadkarVice-presidente de Produtos de IA | F5

Este blog específico descreve como a Volterra ajuda os usuários a operar seus aplicativos e sua infraestrutura como uma frota. Explicaremos como nossa abordagem baseada em plano de controle facilita as operações de uma grande frota de clusters de aplicativos e a compararemos com outras abordagens de plano de gerenciamento multicluster, como Google Anthos, Azure Arc, Rancher etc.

A esta altura, você talvez esteja se perguntando se estamos apenas usando uma estratégia de marketing ao chamar nosso gerenciamento de vários clusters de operações de frota! As abordagens de gerenciamento de vários clusters e de operações de frota atendem a casos de uso distintos e apresentam arquiteturas fundamentalmente diferentes. Uma abordagem de vários clusters foi projetada para cenários em que há relativamente poucos clusters e o usuário deseja gerenciar esses clusters de infraestrutura usando um modelo operacional consistente. Já a abordagem de frota foi projetada para cenários em que há clusters em grande escala (por exemplo, clusters K8s em robôs, veículos, gateways industriais, dezenas de regiões de nuvem pública etc.) e o usuário deseja implantar a mesma aplicação e as mesmas configurações de rede e segurança nesses clusters em grande escala. As próximas duas seções descrevem e comparam com mais detalhes as abordagens de gerenciamento de vários clusters e de operações de frota.

Abordagem multicluster

Uma abordagem de gerenciamento de múltiplos clusters foi projetada para atender a casos de uso em que há relativamente poucos clusters sob a responsabilidade de uma única equipe. Exemplos desses cenários incluem dezenas de clusters distribuídos por algumas zonas de disponibilidade para reduzir o raio de impacto. Da mesma forma, os usuários podem optar por ter vários clusters em algumas regiões para atender a requisitos regulatórios.

Os dois exemplos a seguir destacam como as soluções multicluster funcionam (em linhas gerais):

Configuração

Vejamos um exemplo de implantação de uma aplicação usando a abordagem multicluster do Rancher, conforme mostrado na Figura 1. Em uma abordagem multicluster, o cliente seleciona, um a um, os sites de destino para a implantação da aplicação. Essa abordagem de selecionar os sites de destino individualmente funciona quando há poucos clusters. No entanto, ela não foi projetada para cenários com, digamos, mil clusters.

Figura 1

Observabilidade

A Figura 2 mostra como a observabilidade funciona em uma abordagem multicluster, usando o Rancher como exemplo. Em uma abordagem multicluster, o cliente precisa clicar duas vezes em cada cluster, um por um, para verificar o status dos pods implantados e a utilização dos recursos de CPU e memória. Essa abordagem de observar os sites de destino individualmente é adequada para um pequeno número de clusters, mas não para gerenciar grandes quantidades de clusters.

Cluster 1:

Cluster 2:

Figura 2

Uma abordagem óbvia para resolver o problema descrito no primeiro exemplo seria criar algum tipo de automação que repetisse as tarefas para cada um dos clusters. Por exemplo, sempre que um novo cluster fosse adicionado, o script poderia executar a seguinte operação para implantar uma nova aplicação (checkoutservice, por exemplo)

export KUBECONFIG=~/Documents/kubeconfig/ce01-ashburn-aws-staging

kubectl apply -f checkoutservice.yaml

No entanto, será necessário criar uma automação para cada operação — implantação, atualização, política, reserva de recursos etc. Essa automação não só terá que executar cada operação em vários clusters, como também precisará lidar com condições de falha. Além disso, em cenários complexos — por exemplo, testes beta em um subconjunto de clusters ou atualizações graduais em todos os clusters —, a automação se tornará cada vez mais complexa. Percebemos isso logo no início do processo e criamos um plano de controle distribuído que oferece todas essas funcionalidades, usando uma abordagem de operações de frota descrita a seguir.

Abordagem da Volterra para operações de frota

Operações de Frota significa que o cliente define declarativamente sua intenção uma única vez para toda a frota, e o sistema assume a responsabilidade de garantir que os sites afetados estejam alinhados à intenção definida. Exemplos de intenção incluem a versão do software da aplicação, a versão do software de infraestrutura (por exemplo, a versão do sistema operacional), a política de rede, a política de segurança e a reserva de recursos.

Depois que a intenção entra em vigor, o sistema permite que os usuários visualizem o status e a integridade da frota. Isso significa que os usuários obtêm uma visão agregada da integridade da infraestrutura e das aplicações em todos os sites da frota em um único painel, reduzindo a complexidade operacional para a equipe de operações do cliente. Os usuários não precisam acessar cada site ou cluster individualmente para verificar sua integridade nem desenvolver ferramentas de automação para agregar as informações.

A abordagem da Volterra para operações de frota consiste em três componentes principais — Segmentação, Configuração e Observabilidade — que serão abordados nas seções a seguir.

Segmentação da frota

Os usuários geralmente têm uma combinação de sites na frota, como sites de computação de desenvolvimento, teste e produção. Diferentes cargas de trabalho precisam ser implantadas em um segmento específico de sites devido a políticas organizacionais, como a exigência de que cargas de trabalho de desenvolvimento sejam executadas apenas em sites de desenvolvimento. Permitimos que os usuários identifiquem os sites de forma flexível com um rótulo composto por duas partes: chave e valor. Alguns exemplos são:

• Chave do rótulo=região. Valor do rótulo = Oeste dos EUA, Norte do Japão, Sul do Japão
  
• ano-do-modelo=(2015, 2016, 2017, 2018)
  
• função=(pintura, soldagem)

Depois que os sites forem marcados, os usuários poderão definir um “site virtual” usando condições de chave-valor de rótulos. Em um cenário multinuvem, por exemplo, os usuários podem marcar seus sites como dev, pre-prod e prod. A Figura 3 a seguir mostra um exemplo de caso de uso de robótica utilizando os valores de chave de rótulo descritos anteriormente.

Figura 3

Veja um trecho de configuração no Volterra em que o usuário pode usar a sintaxe blend/go-sdk para criar um site virtual. Neste exemplo específico, os sites individuais foram marcados com a chave de rótulo key=ves.io/country e o valor de rótulo ves-io-jpn.

Figura 4

Os usuários estão acostumados a um modelo operacional no qual definem previamente os segmentos de sua frota e, durante o provisionamento, atribuem tags aos sites para incluí-los na frota. Os sites virtuais se integram perfeitamente ao modelo operacional já utilizado pelos usuários. Quando um novo site é provisionado com a tag apropriada, ele é incluído automaticamente no site virtual definido anteriormente, sem exigir etapas manuais adicionais. Além disso, a Volterra identifica informações pré-provisionadas, como o fabricante do hardware ou o tipo de nuvem pública, para preencher previamente as tags do sistema. Opcionalmente, os usuários podem utilizar essas tags identificadas automaticamente para definir seus sites virtuais.

Configuração da frota

Os recursos de configuração de frota podem ser melhor descritos por meio dos três exemplos a seguir:

• Configuração de uma política de rede/segurança — Vejamos o exemplo de um cliente que está implantando um novo serviço que exige que cada cluster possa se comunicar com uma URL específica, por exemplo, github.com. Normalmente, os usuários adotam listas de permissões, o que significa que os clusters só podem acessar destinos específicos. Portanto, para implantar esse novo serviço, os usuários precisariam acessar cada cluster e modificar a política de rede para adicionar github.com à lista de permissões. Além disso, o cliente gostaria de testar o serviço em alguns sites de teste antes de implantá-lo em todos os sites. Para fazer isso na Volterra, o cliente começa definindo um site virtual de “teste” no console SaaS da Volterra, que seleciona um segmento da frota. Em seguida, o usuário define uma política de rede, como uma lista de URLs permitidas (github.com neste exemplo), e a aplica ao site virtual de “teste”. O plano de controle distribuído da Volterra envia a política de rede ao plano de controle local de cada site selecionado pelo site virtual (conforme definido acima). O plano de controle local de cada site aplica a política de rede e coleta estatísticas sobre as regras acionadas em cada site. Quando o cliente estiver satisfeito com o funcionamento do serviço, poderá aplicar a política de rede ao site virtual de “produção”, que seleciona os demais sites da frota. Veja a seguir um trecho da configuração em JSON e na interface do sistema da Volterra.

Figura 5

Figura 6

• Atualização do software de infraestrutura -- O recurso de configuração de frota permite que o usuário atualize o software de infraestrutura, como a versão do sistema operacional, em toda a frota (ou em um segmento dela). Primeiro, o usuário define a intenção de atualizar o sistema operacional da versão 1 para a versão 2. Em seguida, define uma estratégia de implantação em toda a frota, como atualização gradual, blue/green, entre outras. Uma atualização gradual significa que o sistema operacional de cada site da frota (ou de um segmento dela) é atualizado sequencialmente. Uma estratégia de implantação blue/green significa que o usuário deseja testar a atualização em um conjunto de sites “blue” (por exemplo, sites de desenvolvimento) e comparar a integridade deles com a dos sites “green” (por exemplo, sites de produção), que não são atualizados. Em ambos os casos, o plano de controle distribuído da Volterra envia o software da versão 2 ao plano de controle local de cada site selecionado pelo site virtual, conforme definido na estratégia de implantação. O plano de controle local de cada site atualiza o sistema operacional no modelo A/B, ou seja, cria uma nova partição, implanta a versão 2 nela e permite que o cliente avalie a integridade. Se a instalação da versão 2 não for bem-sucedida, o sistema reverte automaticamente para a versão 1 na partição original. Veja a seguir algumas capturas de tela que mostram como o usuário pode atualizar o software de infraestrutura usando o portal SaaS da Volterra. O usuário pode consultar a versão atual do software de infraestrutura e a versão mais recente disponível para todos os sites, conforme mostrado na próxima figura. O usuário pode atualizar facilmente sites específicos ou todos os sites, de acordo com o modelo operacional.

Figura 7

• Implantação de aplicações em toda a frota -- A Volterra fornece um objeto chamado Virtual Kubernetes (vK8s), que permite aos usuários gerenciar aplicações em toda a frota usando APIs do Kubernetes. O usuário implanta suas aplicações usando métodos padrão do Kubernetes (ou seja, arquivo Kubeconfig e APIs do Kubernetes), com um arquivo de manifesto de implantação, e indica o segmento de sites (ou toda a frota) no qual a aplicação deve ser implantada. O Virtual Kubernetes (vK8s) da Volterra assume então a responsabilidade de implantar a aplicação em todos os sites da frota (ou de um segmento dela). Se ocorrer alguma falha durante a implantação da aplicação, como falhas de conectividade ou de infraestrutura, o Virtual Kubernetes da Volterra continuará tentando realizar a implantação, seguindo o paradigma do Kubernetes de um modelo de consistência eventual. A próxima captura de tela mostra um exemplo de um usuário implantando uma aplicação chamada “kuard” (consulte Kubernetes-up-and-running-demo-app) em um site virtual chamado “jpn-all-sites”, que seleciona 140 sites da frota. Para adicionar uma nova implantação, basta clicar em “Adicionar implantação” e especificar o local da implantação por meio do site virtual.

Figura 8

Se um novo site for adicionado à frota com o rótulo apropriado, ele será automaticamente incluído no site virtual (jpn-all-sites, neste exemplo), e a configuração da frota (ou seja, a implantação do Kuard, neste exemplo) será aplicada automaticamente ao site recém-adicionado, reduzindo a carga das equipes de operações e eliminando erros humanos.

Observabilidade da frota

Os sites virtuais e o Kubernetes Virtual (vK8s) não são usados apenas para configuração, mas também para agregar o status de integridade dos sites distribuídos na frota. Essa é uma ferramenta realmente poderosa em comparação com outras soluções, nas quais os usuários precisariam desenvolver ferramentas para obter o status de cada site individualmente e agregar as informações. O sistema agrega automaticamente o status de integridade de todos os sites em um único painel, reduzindo a complexidade operacional para a equipe de operações do cliente. O status de integridade coletado abrange diversos aspectos, como o status da implantação de aplicações, a integridade dos sites e a integridade das aplicações, entre outros.

Os usuários podem obter rapidamente uma visão geral da integridade de todos os seus sites em um mapa, conforme mostrado na próxima captura de tela. A cor indica se a pontuação de integridade é superior a 75 (verde), está entre 40 e 75 (laranja) ou é inferior a 40 (vermelho). A pontuação de integridade é uma pontuação agregada composta por conectividade, confiabilidade, segurança e desempenho (ou seja, consumo de recursos).

Figura 9

Os usuários também podem visualizar uma visão consolidada da conectividade de todos os seus sites, juntamente com a integridade de cada um deles. A integridade da conectividade de cada link que conecta os sites ao backbone da Volterra também é exibida, conforme ilustrado na Figura 10. Com base no status de integridade, o usuário pode clicar nos links com baixo desempenho para consultar estatísticas detalhadas sobre solicitações e erros e solucionar eventuais problemas de conectividade, conforme mostrado na Figura 11.

Figura 10

Figura 11

Em seguida, o usuário pode visualizar informações agregadas de todos os sites por meio da distribuição da carga de CPU e memória entre eles. Essas informações são úteis para que os administradores de TI ou dos sites identifiquem quais sites estão sendo muito utilizados e correm o risco de ficar sem recursos. Os administradores dos sites podem configurar alertas para serem notificados quando o consumo de recursos ultrapassar os limites definidos. Nesta captura de tela, os usuários podem ver que metade dos sites está consumindo mais de 75% da memória disponível. Eles não precisam clicar em cada site nem desenvolver ferramentas adicionais para obter essas informações.

Figura 12

Os recursos de verificação contínua no objeto de frota fornecem o status das implantações de PODs — quantos PODs foram implantados, estão em andamento ou falharam. Após a implantação, os usuários também podem visualizar o status de integridade dos Pods — se estão em execução, aguardando uma imagem, sem memória etc.

Figura 13

Além disso, os usuários podem visualizar uma visão consolidada da eficácia da política de segurança e consultar as ocorrências em todos os seus sites, como mostra a captura de tela a seguir.

Figura 14

Resumo

Para saber mais sobre como a abordagem de operações de frota da Volterra foi usada para gerenciar uma frota de 3.000 clusters, assista à apresentação da Volterra em uma conferência sobre Kubernetes e leia este artigo de Jakub Pavlik

No próximo post, intitulado “Time to Effect”, explicarei como o plano de controle distribuído e o backbone da Volterra ajudam a propagar as configurações e garantir sua consistência em sites distribuídos globalmente em pouquíssimo tempo. Fique ligado!

Sobre o autor

Pranav DharwadkarVice-presidente de Produtos de IA | F5

Mais publicações de Pranav Dharwadkar