Red Hat OpenShift na edge: provisionamento zero touch

A tecnologia da informação está passando por uma grande transformação, onde os cenários de implantação e manutenção mudam a cada dia. Processar e gerenciar dados e dispositivos na edge é cada vez mais necessário. É por isso que as tecnologias precisam se adaptar para viabilizar e promover a adoção dessas estratégias.

Com o Red Hat OpenShift, você atende a necessidades que vão desde o gerenciamento de uma plataforma de aplicações não dependente de infraestrutura até a implantação on-premises e na nuvem, seja ela privada, pública ou híbrida.

No entanto, a capacidade de se adaptar a qualquer cenário evoluiu muito ao longo do tempo. O uso de configurações mais leves, como o modo de implantação compacto de três nós ou a definição de um único nó, oferece a mesma flexibilidade e desempenho, mesmo que com uma área de ocupação menor. 

Graças a essa flexibilidade, é possível adaptar o OpenShift a implantações em cenários com capacidade de computação reduzida e restrições de uso de hardware. Isso inclui locais remotos, como filiais ou ambientes físicos de computação e processamento.

Imagine que você tenha uma enorme quantidade de locais de edge e precise acessar todos eles com uma tecnologia que ofereça capacidade de computação centralizada e permita o gerenciamento das cargas de trabalho. É possível replicar e propagar configurações que estejam em conformidade com as políticas predefinidas e os cenários relacionados ao local e que, principalmente, sejam disponibilizadas rapidamente, o que diminui a complexidade e aumenta a replicabilidade e confiabilidade.

O provisionamento zero touch (ZTP) é ideal para esse caso de uso. Isso é possível graças à flexibilidade do Assisted Installer do OpenShift e à versatilidade e simplicidade do gerenciamento centralizado de clusters e infraestruturas oferecido pelo Red Hat Advanced Cluster Management for Kubernetes.

O provisionamento zero touch é um tipo de provisionamento de clusters do OpenShift no bare metal. Com ele, você cria vários flavors de configuração de cluster com base nas necessidades de locais remotos, sem precisar interagir fisicamente com os dispositivos. Para isso, é necessário declarar as configurações pretendidas para os clusters em recursos específicos, deixando que os vários componentes do Red Hat Advanced Cluster Management as transformem em operações de provisionamento, tanto dos nós de infraestrutura, o que é viabilizado pela conexão com o Baseboard Management Controller (BMC), como dos clusters, devido ao uso das funções do Assisted Installer do OpenShift.

Como são independentes, todos os recursos definidos podem ser armazenados em um repositório git e aplicados por meio do operador do OpenShift GitOps (baseado no ArgoCD). Isso define os locais e os clusters como se fossem aplicações normais.

Confira abaixo o diagrama de alguns casos de uso. Perceba que esse tipo de provisionamento envolve apenas um cluster que funciona como um hub no data center central.

As funcionalidades que você vai conhecer a seguir estão na versão de apresentação prévia da tecnologia. No entanto, mostraremos como criar e implantar configurações otimizadas em escala.

Caso de uso: OpenShift de um nó na edge com o ZTP

Vamos analisar cada peça que compõe nosso quebra-cabeça e como podemos juntar todas elas para ter um panorama.

Os principais componentes do Red Hat Advanced Cluster Management envolvidos no processo são:

• Operador bare metal do OpenShift
• Assisted Installer
• mecanismo multicluster: operador do Hive

Como falaremos sobre questões relacionadas a dispositivos de edge, usaremos o bare metal como referência. Aqui os modos de configuração já estão disponíveis conforme a infraestrutura do usuário e as instalações feitas nela pelo instalador, que exploraremos nos vários estágios da implantação.

Cada dispositivo remoto é associado a um local, que corresponde à definição dos parâmetros fundamentais que devem ser considerados na fase de configuração. Isso forma uma definição de recurso personalizado (CRD) chamada de SiteConfig.

A CRD define o seguinte:

• Detalhes sobre o BMC que usaremos para gerenciar os nós
• Detalhes relacionados aos clusters (nome e domínio) 
• Configurações de rede (sub-rede de pods, serviços e máquinas)
• Configurações de nós (definições de rede, particionamento e proteções exigidas por políticas)

Essas informações são gerenciadas e transformadas em sub-recursos controlados por diferentes componentes. O objetivo é orquestrar os vários estágios da implantação.

Para simplificar, o fluxo lógico do ZTP é assim:

Vamos conferir detalhes sobre os diferentes recursos mencionados e as funções deles.

BareMetalHost

O BareMetalHost (BMH) lida com as informações do BMC. Depois, essas informações são interpretadas pelo operador bare metal do OpenShift para criar o nó bare metal no OpenShift, antecedendo a preparação e a configuração do nó remoto. Essa é a parte fundamental do provisionamento de nós, porque permite que o operador configure remotamente os dispositivos de inicialização conforme a configuração que implementaremos.

InfraEnv

O InfraEnv define os detalhes sobre a rede, os servidores NTP a serem usados nos nós que ele hospedará, a chave secure shell (SSH) que será utilizada para acessar os nós a serem conectados e as credenciais para acessar as imagens de container necessárias para a instalação. Ele é usado com o recurso ClusterDeployment para criar o ISO de descoberta do Assisted Installer.

AgentClusterInstall

Contém as informações que serão consumidas pelo Assisted Installer para gerar a imagem de inicialização usada pelos nós. Isso dá continuidade à instalação e configuração do cluster, incluindo as definições de versão, nome e rede.

ClusterDeployment

Combina as informações definidas no AgentClusterInstall e adiciona outras necessárias para a implantação correta do cluster. Elas são incorporadas ao ISO de inicialização do nó.

ManagedCluster e KlusterletAddonConfig

É provável que os usuários do Red Hat Advanced Cluster Management já conheçam esses recursos. Eles definem as informações sobre o cluster para permitir sua importação e gerenciamento no hub do Red Hat Advanced Cluster Management, configurando os serviços necessários para a comunicação.

Quando o processo de provisionamento e configuração do cluster por meio do instalador do OpenShift são concluídos, o hub exibe o novo nó do OpenShift como instalado e fixado. Ele estará pronto para uso na implantação das cargas de trabalho.

Resumo

Neste artigo, você aprendeu o conceito de ZTP do OpenShift em cenários de edge e descobriu como ele deixa o processo de provisionamento de plataformas mais simples, reproduzível e escalável usando uma abordagem de infraestrutura como código (IaC).

A tecnologia está em desenvolvimento contínuo, mas é madura o suficiente para você experimentar esse método inovador para ter uma plataforma de aplicações completa em qualquer cenário.