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

Este blog específico descreve como a Volterra ajuda os usuários a operar seus aplicativos e 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 de vários clusters, como Google Anthos, Azure Arc, Rancher, etc.

A esta altura, você deve estar se perguntando se estamos apenas fazendo uma jogada de marketing e chamando nossa gestão de multiclusters de operações de frota! As abordagens de gerenciamento de multicluster e operações de frota abordam diferentes casos de uso e são fundamentalmente diferentes em suas arquiteturas. Uma abordagem multicluster é projetada para abordar cenários em que há relativamente poucos clusters e o usuário deseja gerenciar esses clusters de infraestrutura usando um modelo operacional consistente. Enquanto isso, a abordagem de frota é projetada para abordar cenários em que há uma grande escala de clusters (por exemplo, clusters K8s em robôs, automotivos, gateways industriais, dezenas de regiões de nuvem pública, etc.) e o usuário deseja implantar o mesmo aplicativo e rede/segurança nesses clusters de grande escala. As próximas duas seções descrevem e comparam a abordagem de operações multicluster e de frota com mais detalhes.

Abordagem Multi-Cluster

Uma abordagem de gerenciamento de vários clusters é projetada para abordar casos de uso quando há relativamente poucos clusters sob as operações de uma única equipe. Exemplos desses cenários incluem dezenas de clusters em algumas zonas de disponibilidade para reduzir o raio de explosão. Da mesma forma, os usuários podem optar por ter vários clusters em algumas regiões para atender às necessidades regulatórias.

Os dois exemplos a seguir destacam como as soluções multicluster funcionam (em alto nível):

Configuração

Vamos dar um exemplo de implantação de aplicativo usando uma abordagem multicluster do Rancher, conforme mostrado na Figura 1. Em uma abordagem multicluster, o cliente seleciona os sites de destino para implantação do aplicativo um por um. Essa abordagem de selecionar sites de destino um por um funciona quando você tem alguns clusters. No entanto, essa abordagem não foi projetada para, digamos, mil clusters.

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 ver o status dos pods implantados e a utilização dos recursos de CPU e memória. Essa abordagem de observar os locais-alvo um por um é adequada para um pequeno número de clusters, mas não para gerenciar um grande número de clusters.

Grupo 1:

Grupo 2:

Uma abordagem óbvia para resolver o problema descrito no primeiro exemplo seria escrever alguma forma de automação que repetisse tarefas para cada um dos clusters. Por exemplo, sempre que um novo cluster é adicionado, o script pode executar a seguinte operação para implantar um novo aplicativo (checkoutservice, por exemplo)

exportar KUBECONFIG=~/Documentos/kubeconfig/ce01-ashburn-aws-staging

kubectl aplicar -f checkoutservice.yaml

No entanto, a automação terá que ser criada para cada operação — implantação, atualização, política, reserva de recursos, etc. Essa automação não só precisará executar a operação individual em muitos clusters, mas também precisará cuidar do tratamento de condições de falha. Além disso, quando há cenários complexos — por exemplo, testes beta em um subconjunto de clusters, atualizações contínuas em todos os clusters — a automação se tornará cada vez mais complexa. Percebemos isso no início do processo e construímos um plano de controle distribuído que fornece toda essa funcionalidade — usando uma abordagem de operações de frota descrita a seguir.

Abordagem de operações de frota da Volterra

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

Quando a intenção entra em vigor, o sistema permite que os usuários visualizem o status e a integridade da frota. O que isso significa é que os usuários obtêm uma visão agregada da integridade da infraestrutura e dos aplicativos em todos os sites da frota em um único painel de vidro, reduzindo a complexidade operacional para a equipe de operações do cliente. Os usuários não precisam clicar em cada site ou cluster um por um para determinar a integridade e escrever ferramentas de automação para agregar as informações.

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

Segmentação de frota

Os usuários geralmente têm uma mistura de sites na frota, como sites de desenvolvimento, teste e computação de produção. Diferentes cargas de trabalho precisam ser implantadas em um segmento específico de sites devido a políticas da organização, como cargas de trabalho de desenvolvimento que só são implantadas em sites de desenvolvimento. Permitimos que os usuários marquem sites de forma flexível com um rótulo composto de duas partes: chave e valor. Exemplos incluem: 

• Rótulo-Chave=região. Valor do rótulo = US-West, JP-North, JP-sul
   
• ano-modelo=(2015, 2016, 2017, 2018)
   
• função=(spray, solda)

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

Aqui está um trecho de configuração no Volterra onde 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=ves.io/country e o valor do rótulo de ves-io-jpn

Os usuários estão acostumados a um modelo operacional de definição de segmentos de sua frota a priori e, em seguida, marcação de seus sites no momento do provisionamento para serem incluídos na frota; sites virtuais combinam perfeitamente com o modelo operacional existente dos usuários. Quando um novo site é provisionado com a tag apropriada, ele é automaticamente incluído no site virtual definido anteriormente, sem exigir etapas manuais adicionais. Além disso, o Volterra descobre informações pré-provisionadas, como fabricante de hardware ou tipo de nuvem pública, para preencher previamente as tags do sistema. Os usuários podem, opcionalmente, escolher usar essas tags descobertas automaticamente para definir seus sites virtuais.

Configuração da frota

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

• Configuração de uma política de rede/segurança — Vamos dar um exemplo de um cliente implementando um novo serviço que exige que cada cluster se comunique com uma URL específica, por exemplo, github.com . Normalmente, os usuários empregam listas brancas, o que significa que os clusters têm permissão para atingir apenas destinos específicos. Portanto, a implementação deste novo serviço exigiria que os usuários fossem até cada cluster e modificassem a política de rede para adicionar github.com à lista de permissões. Além disso, o cliente gostaria de testar isso em alguns sites de teste antes de implementá-lo em todos os sites. Para atingir essa intenção no Volterra, o cliente começa definindo um site virtual de “teste” no console SaaS do Volterra que seleciona um segmento da frota. O usuário então define uma política de rede, como a lista de URLs permitida ( 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 para o plano de controle local em cada site selecionado pelo site virtual (conforme definido acima). O plano de controle local em cada site aplica a política de rede e coleta estatísticas de regras atingidas por site. Depois que o cliente estiver satisfeito que o serviço está funcionando conforme o esperado, ele pode aplicar a política de rede ao site virtual “prod”, que seleciona os sites restantes na frota. Aqui está um trecho de configuração usando Json e a interface do usuário no sistema da Volterra.

• Atualização do software de infraestrutura — A capacidade de configuração da frota permite que um usuário atualize o software de infraestrutura, por exemplo, a versão do sistema operacional em toda a frota (ou segmento da frota). Primeiro, o usuário define a intenção de atualizar o sistema operacional da versão 1 para a versão 2. Em seguida, o usuário define uma estratégia de implantação em toda a frota, como uma atualização contínua, azul/verde, entre outras. Uma atualização contínua significa que o sistema operacional de cada site da frota (ou segmento da frota) é atualizado sequencialmente. Uma estratégia de implantação azul/verde significa que o usuário deseja testar a atualização em um conjunto de sites “azuis” (por exemplo, sites de desenvolvimento) e comparar a integridade com sites “verdes” (por exemplo, sites de produção) que não foram atualizados. Em ambos os casos, o plano de controle distribuído da Volterra envia o software da versão 2 para o plano de controle local em cada site selecionado pelo site virtual e conforme definido na estratégia de implantação. O plano de controle local em cada site atualiza o sistema operacional de forma A/B, o que significa que ele cria uma nova partição, implanta a versão 2 na nova partição e permite que o cliente meça a integridade. Se a instalação da versão 2 não for bem-sucedida, o sistema retornará automaticamente para a versão 1 na partição original. Aqui estão algumas capturas de tela de como o usuário pode realizar uma atualização do software de infraestrutura usando o portal Volterra SaaS. O usuário pode ver a versão atual do software de infraestrutura e a versão mais recente do software disponível para todos os sites, conforme mostrado na próxima figura. O usuário pode facilmente atualizar os sites específicos ou todos os sites, conforme determinado pelo modelo operacional.

• Implantação de aplicativos em toda a frota — A Volterra fornece um objeto chamado Virtual Kubernetes (vK8s) que permite aos usuários gerenciar aplicativos em toda a frota usando APIs do Kubernetes. O usuário implanta seus aplicativos usando métodos padrão do Kubernetes (ou seja, arquivo Kubeconfig e APIs do Kubernetes) com arquivo de manifesto de implantação e indica o segmento de sites (ou frota inteira) onde o aplicativo precisa ser implantado. O Virtual Kubernetes (vK8s) da Volterra assume então a responsabilidade de implantar o aplicativo em cada site (ou segmento) da frota. Se houver falhas durante a implantação do aplicativo, como falhas de conectividade ou infraestrutura, o Volterra Virtual Kubernetes continuará tentando a implantação seguindo o paradigma do Kubernetes de um modelo eventualmente consistente. A próxima captura de tela mostra um exemplo do usuário implantando um aplicativo chamado “kuard” (veja Kubernetes-up-and-running-demo-app ) em um site virtual chamado “jpn-all-sites” que está selecionando 140 sites da frota. Para adicionar uma nova implantação, o usuário precisa simplesmente adicionar uma nova implantação, clicando em “Adicionar implantação” e especificando o local da implantação em termos do site virtual.

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

Observabilidade da frota

Sites virtuais e Kubernetes virtuais (vK8s) não são usados apenas para configuração, mas também para agregar a integridade entre sites distribuídos na frota. Esta é uma ferramenta realmente poderosa em comparação com outras soluções em que os usuários teriam que escrever ferramentas para obter o status de cada site, um por um, e agregar as informações. O sistema agrega automaticamente o status de saúde em todos os sites, em um único painel de vidro, reduzindo a complexidade operacional para a equipe de operações do cliente. O status de integridade coletado inclui muitos aspectos — como status de implantação do aplicativo, integridade do site e integridade do aplicativo, etc.

Os usuários podem obter uma visão geral rápida 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 saúde é maior que 75 (verde), entre 40–75 (laranja) e vermelho se for menor que 40. A pontuação de saúde é uma pontuação agregada composta de conectividade, confiabilidade, segurança e desempenho (ou seja, consumo de recursos).

Os usuários também podem ver uma visão agregada da conectividade em todos os seus sites, juntamente com a integridade do site. A integridade da conectividade de cada link que conecta os sites ao backbone Volterra também é mostrada conforme visualizado na Figura 10. O usuário pode clicar em links com baixo desempenho com base no status de integridade para revelar estatísticas detalhadas sobre solicitações e erros e solucionar quaisquer problemas de conectividade, conforme mostrado na Figura 11.

Em seguida, o usuário pode visualizar informações agregadas em todos os sites por meio da distribuição de carga de CPU e memória entre os sites. Essas informações são úteis para administradores de TI ou de sites identificarem quais sites estão sendo muito utilizados e correm risco de ficar sem recursos. Os administradores do site podem configurar alertas para serem notificados quando o consumo de recursos exceder os limites. 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 sites individuais nem escrever ferramentas adicionais para obter essas informações.

Os recursos de verificação contínua no objeto da frota fornecem o status das implantações de POD — 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.

Além disso, os usuários podem ter uma visão agregada da eficácia da política de segurança e obter acessos em todos os seus sites, como visto na próxima captura de tela.

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 do Kubernetes e leia este blog de Jakub Pavlik

No próximo blog, intitulado “Time to Effect”, explicarei como o plano de controle distribuído e o backbone do Volterra ajudam a propagar e garantir a consistência da configuração em sites distribuídos globalmente em um período de tempo muito curto. Fique atento!