Como economizar recursos e tempo ao lançar dezenas de clusters OpenShift

Qualquer pessoa que já implantou Kubernetes ou OpenShift em produção conhece essa dor. Você quer criar um pequeno cluster isolado para staging ou para um time separado, mas implantar pelo menos três nodes para nodes master com etcd e controllers é um exagero. Se você precisa de dez, trinta ou cem clusters, as contas da nuvem rapidamente se tornam astronômicas, e o tempo para criar outro ambiente se estende para dezenas de minutos.

Engenheiros da Red Hat encontraram o mesmo problema e lançaram uma solução como open source. O projeto se chama HyperShift (ou Hosted Control Planes). Essencialmente, é uma camada que move o control plane do cluster de nodes separados para pods regulares dentro de um cluster de gerenciamento central.

Vamos explorar como isso funciona e quem se beneficia disso.

O foco central da arquitetura

Em uma configuração clássica de OpenShift ou Kubernetes, cada cluster tem suas próprias máquinas virtuais ou físicas dedicadas para o API server, etcd, controllers e scheduler. Você paga por esses nodes mesmo se o cluster estiver mostly idle.

HyperShift separa o control plane dos worker nodes.

Você tem um grande cluster de gerenciamento. Quando você precisa criar um novo cluster OpenShift para usuários ou times de desenvolvimento, o HyperShift implanta os componentes de gerenciamento do novo cluster — etcd, kube-apiserver, openshift-apiserver — como pods padrão (Deployment e StatefulSet) diretamente no cluster de gerenciamento.

Enquanto isso, os worker nodes são criados separadamente onde você precisar: na AWS, Azure ou em bare metal. Eles se conectam ao API server que roda como um pod na infraestrutura de gerenciamento.

Por que mudar a abordagem familiar

Se você gerencia múltiplos clusters, os benefícios ficam imediatamente aparentes em três áreas.

Primeiro — eficiência de custos. Em vez de comprar pelo menos três VMs para nodes master para cada cluster individual, você aproveita os recursos de um cluster de gerenciamento existente. Como resultado, dezenas de control planes rodam em um único pool de recursos, alcançando um empacotamento muito mais denso.

Segundo — velocidade de provisionamento da infraestrutura. Fazer bootstrap de um node completo com sistema operacional, configuração do etcd e inicialização de componentes leva de 15 a 45 minutos. Os pods do control plane no HyperShift iniciam em minutos ou até segundos. Isso muda completamente a abordagem para ambientes de dev/test: um cluster se torna um recurso temporário fácil de criar para uma tarefa e rápido de excluir.

Terceiro — separação de responsabilidades e segurança. Desenvolvedores e aplicações têm acesso apenas aos seus worker nodes e ao API server. Eles não têm acesso físico ou de rede às máquinas que executam o control plane ou o etcd. A equipe de operações atualiza e monitora centralmente todos os API servers em um só lugar.

Como fica na prática

HyperShift mantém 100% de compatibilidade com a API padrão do Kubernetes e as ferramentas do OpenShift Container Platform (OCP). De uma perspectiva de desenvolvedor ou pipeline de CI/CD, o cluster criado é indistinguível de um regular: você obtém um kubeconfig padrão e trabalha através do kubectl ou oc.

O gerenciamento acontece através do utilitário CLI hypershift ou via Custom Resources (CRD), o que se encaixa perfeitamente em abordagens GitOps como ArgoCD.

Aqui está um exemplo de como é criar um cluster na AWS via CLI:

hypershift create cluster aws \
  --name dev-cluster \
  --node-pool-replicas 2 \
  --base-domain example.com \
  --pull-secret /path/to/pull-secret.json \
  --aws-creds /path/to/aws-credentials

Nos bastidores, o comando criará o CRD HostedCluster e NodePool. O HyperShift subirá os pods do control plane no cluster de gerenciamento, provisionará um par de instâncias EC2 na AWS para worker nodes e os vinculará.

Por baixo dos panos e nuances

O projeto é escrito em Go e está em desenvolvimento ativo pela equipe do OpenShift. O repositório já tem mais de 500 forks, embora as estrelas ainda sejam relativamente poucas — pouco mais de quinhentas. Isso ocorre porque o HyperShift foi por muito tempo uma tecnologia interna da Red Hat para o serviço ROSA (Red Hat OpenShift Service on AWS), e agora está gradualmente se tornando o padrão para instalações on-premises e multi-cloud.

Recursos importantes incluem:

• Isolamento completo entre o cluster de gerenciamento e as cargas de trabalho dos clientes.
• Suporte para implantação de worker nodes em diferentes provedores: AWS, Azure, KubeVirt, Bare Metal.
• Vetor de atualização unificado. Atualizar a versão do OpenShift para o control plane pode ser feito independentemente mudando a versão no CRD sem reiniciar imediatamente todos os worker nodes.

Existem desvantagens? Claro. O cluster de gerenciamento se torna um ponto único de falha para os control planes de todos os seus clusters clientes. Se o cluster de gerenciamento cair, os serviços rodando nos worker nodes continuarão funcionando, mas a gerenciabilidade será perdida até que a infraestrutura seja restaurada. Portanto, os requisitos de confiabilidade e backups de etcd do cluster de gerenciamento são elevados.

Quem deveria dar uma olhada

HyperShift não é necessário se você tem um único cluster monolítico para toda a empresa. Mas se torna um salva-vidas se:

• Você está construindo uma plataforma para times internos e quer fornecer clusters isolados sob demanda.
• Você está vendendo uma solução SaaS baseada em Kubernetes com separação física de clientes.
• Você está cansado de pagar por nodes master ociosos em nuvens públicas.

Você pode experimentar o projeto usando a documentação oficial em hypershift.pages.dev. Você precisará de um cluster OpenShift 4.x existente como cluster de gerenciamento e acesso à AWS ou VMs locais para criar workers.