Gestão de clusters Kubernetes multi-cloud

Ferramentas e dashboards fragmentados por nuvem

Um cluster GKE no GCP para uma unidade de negócio, EKS para outra, um cluster RKE2 local para uma carga de trabalho regulamentada e, agora, um cluster OVHcloud para computação soberana na UE. Cada um destes fornecedores disponibiliza a sua própria consola, a sua própria CLI, a sua própria forma de fazer as coisas. Não existe uma visão global da saúde, capacidade ou política de segurança dos clusters em todos os ambientes, apenas N fornecedores e N conjuntos de ferramentas, cada um exigindo conhecimentos específicos. 

A visibilidade é a primeira vítima, e todas as outras tarefas operacionais tornam-se mais difíceis sem ela. Cada nuvem adicional multiplica a área de superfície que a sua equipa tem de cobrir, e nada disto torna a carga de trabalho da aplicação em execução mais fiável.

Proliferação de RBAC e desvio de configuração entre clusters

O serviço Kubernetes gerido de cada fornecedor tem o seu próprio modelo de identidade e permissões, pelo que múltiplas nuvens significam múltiplos modelos. Definir uma política de segurança consistente para um engenheiro, para programadores ou para um auditor significa repetir a mesma configuração em três ou quatro consolas e sintaxes. O desvio não é um risco aqui, é uma certeza, e é o desafio que pior escala. Uma permissão concedida num cluster e esquecida noutro é uma falha de conformidade que surge durante uma auditoria, e não antes.

O desvio estende-se muito para além das permissões. As regras de rede, as quotas de recursos, o isolamento de cargas de trabalho e as regras de admissão que eram consistentes na configuração inicial divergem silenciosamente à medida que cada cluster é corrigido, atualizado ou ajustado manualmente por quem estiver de serviço. O desvio na governação de segurança é a versão mais dispendiosa: uma regra de endurecimento aplicada num cluster e nunca propagada é invisível até que um incidente ou uma auditoria a exponha.

GitOps que falha na fronteira entre nuvens

O GitOps deveria fornecer uma única fonte de verdade sobre o que é executado onde, e um pipeline de entrega contínua para cada ambiente. Na prática, a maioria das equipas executa instâncias separadas de Fleet ou ArgoCD por nuvem, ou mantém pipelines por nuvem, cada um com as suas próprias credenciais, lógica de sincronização e gestão de falhas. Cada pipeline adicionado é mais um ponto de falha. 

No momento em que uma aplicação tem de ser implementada de forma consistente em vários ambientes, no GKE no GCP, no EKS e localmente ao mesmo tempo, a promessa de um único repositório Git divide-se em três pipelines de entrega paralelos que se afastam. A gestão de tráfego segue o mesmo caminho: balanceadores de carga, encaminhamento de tráfego global e política de tráfego entre clusters geridos nuvem a nuvem em vez de como uma regra de rede única. As ferramentas ancoradas em hiperescaladores também não resolvem isto de forma limpa, porque encaminham os dados de telemetria e de permissões através de infraestruturas dos EUA, mesmo quando os seus nós de trabalho estão numa região da UE, independentemente da localização física do hardware.

O custo oculto de alojar o Rancher por si próprio

O alojamento próprio é uma solução para o desafio agnóstico da nuvem, uma vez que uma única ferramenta centrada em Kubernetes gere então qualquer cluster em conformidade com a CNCF. Cria uma nova: agora a sua equipa mantém essa ferramenta. A configuração de alta disponibilidade, um arquivo de dados de suporte, a rotação de certificados e as atualizações trimestrais recaem todas sobre o seu backlog, além dos clusters subjacentes. Uma camada de gestão autogerida é um produto por si só, com uma pegada de infraestrutura que deve ser dimensionada e corrigida adequadamente, com a mesma atenção de SRE que o património que governa. Uma solução alojada remove essa camada.

Arquitetura: o Gestor na OVHcloud, agentes em cada cluster

Uma distinção de arquitetura é importante em primeiro lugar: A OVHcloud não gere diretamente os seus clusters no GKE, EKS ou AKS. O Gestor é o que está alojado na OVHcloud, na região da UE à sua escolha, uma localização única sob uma jurisdição única. Um agente leve, apenas de saída, é executado em cada um dos seus clusters Kubernetes, onde quer que residam, e reporta de volta. Os seus clusters GKE, EKS, AKS ou on-prem existentes permanecem onde estão, sob as suas próprias contas e responsabilidade.

Cada tipo de cluster, seja gerido pela nuvem, autogerido ou nativo da OVHcloud, aparece na mesma interface, por trás da mesma API, e pode ser provisionado através dos mesmos recursos Terraform. As equipas que padronizam no Ansible ou Pulumi mantêm também esses fluxos de trabalho. Se os seus clusters partilham um armazenamento de imagens de contentor, o OVHcloud Managed Private Registry fornece um registo baseado em Harbor a partir do qual qualquer cluster pode extrair, independentemente da nuvem ou região em que é executado.

Padrão A: importar clusters GKE, EKS, AKS ou on-prem existentes

Se já executa clusters Kubernetes no GCP, AWS, Azure ou nos seus próprios centros de dados, não migra nada. Instale o agente em cada cluster existente; este abre uma ligação apenas de saída para o Manager e o cluster aparece em poucos minutos. Não há re-platforming, nem interrupção de implementação, nem qualquer alteração na forma como implementa aplicações nesse cluster atualmente. As cargas de trabalho existentes continuam a ser executadas exatamente como antes.

Padrão B: aprovisionar novos clusters RKE2 ou k3s em qualquer infraestrutura

Para novos clusters em vez dos importados, utilize o Manager para aprovisionar o RKE2, uma distribuição Kubernetes de nível de produção e reforçada com CIS-benchmark, ou o k3s, uma distribuição leve adequada para implementações edge. Ambos são executados em qualquer infraestrutura com computação disponível: bare metal on-prem, máquinas virtuais ou instâncias IaaS em qualquer fornecedor de cloud, em qualquer região. O fluxo de trabalho de aprovisionamento, o RBAC e a monitorização centralizada são idênticos em todas as regiões, onde quer que os nós resultantes estejam fisicamente localizados.

Padrão C: adicionar o MKS da OVHcloud como o cluster soberano da UE

O terceiro padrão de arquitetura é a solução soberana: um cluster nativo da OVHcloud para qualquer carga de trabalho que exija especificamente soberania da UE. Os clusters do OVHcloud Managed Kubernetes Service registam-se no mesmo Manager que os seus clusters importados e aprovisionados, e aparecem como cidadãos de primeira classe ao lado deles, com a mesma interface de utilizador, o mesmo RBAC e os mesmos pipelines GitOps. Ao contrário dos clusters em clouds de terceiros, a OVHcloud gere totalmente o plano de controlo MKS, pelo que este é o único tipo de cluster no seu parque com zero carga operacional de plano de controlo da sua parte.

Controlo de acesso unificado em todos os clusters, definir uma vez, propagar em todo o lado

Defina uma função uma vez e propague-a para cada cluster Kubernetes, em vez de a repetir em três ou quatro consolas separadas. Os utilizadores iniciam sessão através do mesmo fornecedor de identidade em todo o lado. Cada concessão, revogação e alteração de permissão por utilizador termina num registo de auditoria consistente, o que faz a diferença entre uma revisão de acesso que demora uma tarde e uma que demora uma semana.

Integrar um novo engenheiro torna-se um passo de aprovisionamento, não uma lista de verificação por cloud, e os pedidos de suporte sobre quem pode aceder a quê deixam de ser projetos de investigação. Para uma organização que executa clusters em mais do que uma cloud, esse ponto de controlo único é o que torna uma auditoria de conformidade tratável e o que lhe permite demonstrar os compromissos de privacidade de dados que assumiu perante os seus próprios utilizadores.

GitOps multi-cluster com Rancher Fleet

O Fleet permite-lhe definir aplicações uma vez num repositório GitHub e sincronizá-las por seletor de etiquetas, por exemplo, todos os clusters de produção da UE ou todos os ambientes de teste, em vez de manter um pipeline separado por fornecedor. O desvio entre o que é declarado no Git e o que está em execução é detetado e reconciliado automaticamente em cada cluster no seletor, o que é o controlo de versão aplicado à infraestrutura e não apenas ao código.

Esta é uma gestão centralizada tanto para o isolamento de cargas de trabalho como para a política de namespaces: as mesmas regras aplicam-se em todo o lado, o que é a única forma de garantir a consistência em clusters que ninguém verifica frequentemente. É a solução direta para a fragmentação do pipeline de entrega, com uma única fonte de verdade e um único motor de sincronização, quer a carga de trabalho de destino seja executada no GKE, localmente ou no OVHcloud MKS. O nosso guia de gestão multi-cluster é o local para saber mais sobre a operação diária assim que um conjunto é configurado, e como as equipas simplificam as versões entre regiões.

Ciclo de vida do cluster: atualizações, aprovisionamento, desaprovisionamento via IU, API ou Terraform

As atualizações da versão do Kubernetes são orquestradas em todos os clusters com definições de aumento configuráveis, em vez de janelas de manutenção separadas por cluster por nuvem. Pode automatizar o aprovisionamento, a atualização e o desaprovisionamento através da mesma IU, da mesma API, dos mesmos recursos Terraform ou dos seus fluxos de trabalho Ansible existentes, e obtém visibilidade do estado atual sem mudar de consola, não dependendo de nada além do próprio cluster.

Os comandos que os seus engenheiros já conhecem continuam a funcionar de forma idêntica. Alterne o contexto e, em seguida, execute as mesmas operações:

kubectl create namespace payments-staging
kubectl get events --all-namespaces

Essa consistência transforma a gestão do ciclo de vida de um exercício propenso a erros num exercício repetível e automatizado. Remove a complexidade que, de outra forma, aumentaria com cada implementação multirregional complexa, permitindo que uma pequena equipa gira eficazmente um grande conjunto à escala, desde o desenvolvimento até à produção.

Monitorização e registo centralizados com Prometheus e Grafana

O Prometheus e o Grafana integram-se à escala do conjunto, proporcionando-lhe uma pilha de observabilidade unificada e multi-cluster em todos os clusters, em vez de uma ferramenta e configuração diferentes por nuvem. O armazenamento de métricas e a agregação de registos são ativados da mesma forma em todos os nós de todas as regiões, e os mesmos dashboards, regras de alerta e guias de runbook aplicam-se quer um alerta seja disparado num cluster GKE, num cluster RKE2 local ou num nó OVHcloud MKS. As questões de fiabilidade obtêm uma resposta em vez de uma por fornecedor, e as tendências de utilização e tráfego tornam-se visíveis numa única vista global.

Porquê adicionar um cluster soberano da UE (CLOUD Act, dependência de um único hiperescalador)

Se todos os clusters que executa residem num hiperescalador dos EUA, todos esses dados do plano de controlo estão sujeitos à CLOUD Act dos EUA, independentemente da localização física dos nós de trabalho. A solução é adicionar o OVHcloud Managed Kubernetes Service: um cluster cujo plano de controlo é executado numa região europeia sem empresa-mãe nos EUA e sem exposição estrutural à CLOUD Act.

Isto é importante para qualquer organização, independentemente da ferramenta que utilize para gerir o resto dos seus clusters. Esta abordagem reduz a dependência de um único hiperescalador para qualquer carga de trabalho crítica e oferece às equipas reguladas nos setores da saúde, serviços financeiros e setor público uma opção sob jurisdição da UE sem abandonar os clusters que já executam noutros locais.

MKS Free: adicione um cluster OVHcloud a custo zero

O MKS está disponível como um nível gratuito em todas as 14 regiões, sem necessidade de cartão de crédito, pelo que validar um cluster soberano da UE não custa nada. É executado dentro do seu projeto Public Cloud existente, ao lado de quaisquer outros recursos e nós que a sua equipa já utiliza. Para uma carga de trabalho de produção, o MKS Standard é executado em 3-AZ na região de Paris ao abrigo de um acordo de nível de serviço de 99,99%. Qualquer um dos níveis regista-se exatamente como qualquer outro cluster, com o mesmo RBAC, o mesmo GitOps e a mesma monitorização, na região que escolher.

100% open source, zero bloqueio: o seu caminho de saída é o autoalojamento, não a migração

O Rancher é lançado sob a licença Apache 2.0, e as distribuições RKE2 e k3s que disponibiliza são projetos da CNCF. A OVHcloud não executa uma bifurcação proprietária nem adiciona uma camada de funcionalidades fechada por cima: é o projeto upstream idêntico, agnóstico em relação à cloud e alojado para si como uma solução gerida. Se decidir mais tarde trazer a gestão de volta para a sua infraestrutura, o seu caminho de saída é o autoalojamento desse mesmo projeto, não uma migração nem uma reescrita da forma como os seus clusters estão configurados. Os clusters não são afetados em qualquer dos casos, porque nunca estiveram bloqueados a nada além do Kubernetes padrão e dos agentes padrão.