Documentação do SUSE Edge 3.3.1 #

O SUSE Edge é composto de componentes existentes tanto do SUSE quanto do Rancher, junto com outros recursos e componentes desenvolvidos pela equipe do Edge, para enfrentarmos as restrições e as complexidades previstas na computação de borda. Veja abaixo uma explicação dos componentes usados nos clusters de gerenciamento e downstream, com um diagrama simplificado de alto nível (observe que não se trata de uma lista completa):

3.1.1 Cluster de gerenciamento #

 

• Gerenciamento: trata-se da parte centralizada do SUSE Edge usada para gerenciar o provisionamento e o ciclo de vida dos clusters downstream conectados. Normalmente, o cluster de gerenciamento inclui os seguintes componentes:

  • Gerenciamento multicluster com o Rancher Prime (Capítulo 5, Rancher), que oferece um dashboard comum para integração de clusters downstream e gerenciamento do ciclo de vida contínuo da infraestrutura e dos aplicativos, além do isolamento total de locatários e das integrações de IDP (provedor de identidade), um amplo mercado de integrações e extensões de terceiros e uma API independente de fornecedor.

  • Gerenciamento de sistemas Linux com o SUSE Multi-Linux Manager, que permite o gerenciamento automatizado de patches e configurações do sistema operacional Linux subjacente (*SUSE Linux Micro (Capítulo 9, SUSE Linux Micro)) executado nos clusters downstream. Quando esse componente está conteinerizado, observe que ele precisa ser executado em um sistema separado dos outros componentes de gerenciamento, devidamente identificado no diagrama acima como "Linux Management".

  • Um controlador dedicado de gerenciamento do ciclo de vida (Capítulo 23, Controller de upgrade) encarregado dos upgrades dos componentes do cluster de gerenciamento para uma determinada versão do SUSE Edge.

  • Integração remota do sistema ao Rancher Prime com Elemental (Capítulo 13, Elemental), que permite a vinculação posterior dos nós de borda conectados aos clusters Kubernetes e a implantação de aplicativos, por exemplo, pelo GitOps.

  • Suporte opcional completo ao ciclo de vida e gerenciamento bare metal com os provedores de infraestrutura Metal3 (Capítulo 10, Metal³), MetalLB (Capítulo 19, MetalLB) e CAPI (Cluster API), que permite o provisionamento total, de ponta a ponta, dos sistemas bare metal com recursos de gerenciamento remoto.

  • Um mecanismo opcional do GitOps chamado Fleet (Capítulo 8, Fleet) que gerencia o provisionamento e o ciclo de vida dos clusters downstream e dos aplicativos que residem neles.

  • O cluster de gerenciamento conta com o SUSE Linux Micro (Capítulo 9, SUSE Linux Micro) como o alicerce do sistema operacional de base e com o RKE2 (Capítulo 16, RKE2) como a distribuição Kubernetes que oferece suporte aos aplicativos do cluster de gerenciamento.

3.1.2 Clusters downstream #

 

• Downstream: trata-se da parte distribuída do SUSE Edge usada para executar as cargas de trabalho dos usuários no Edge, ou seja, o software que é executado no próprio local de borda, e que normalmente inclui os seguintes componentes:

  • Uma seleção de distribuições Kubernetes, com distribuições seguras e leves como K3s (Capítulo 15, K3s) e RKE2 (Capítulo 16, RKE2) (RKE2 é protegido, certificado e otimizado para uso em órgãos governamentais e setores regulamentados).

  • SUSE Security (Capítulo 18, SUSE Security) para habilitar recursos de segurança, como verificação de vulnerabilidade de imagens, inspeção detalhada de pacotes e proteção contra ameaças e vulnerabilidades em tempo real.

  • Armazenamento de software em blocos com o SUSE Storage (Capítulo 17, SUSE Storage), que possibilita o armazenamento em blocos leve, persistente, resiliente e escalável.

  • Um sistema operacional Linux leve, otimizado para contêiner e protegido com o SUSE Linux Micro (Capítulo 9, SUSE Linux Micro), que oferece um sistema operacional imutável e altamente resiliente para execução de contêineres e máquinas virtuais na borda. O SUSE Linux Micro está disponível para as arquiteturas AArch64 e AMD64/Intel 64 e também suporta o kernel Real-Time para aplicativos sensíveis à latência (por exemplo, os casos de uso de telecomunicações).

  • Para os clusters conectados (ou seja, os que têm conectividade com o cluster de gerenciamento), dois agentes são implantados: Agente do sistema Rancher, para gerenciar a conectividade com o Rancher Prime, e venv-salt-minion, para receber as instruções do SUSE Multi-Linux Manager e aplicar as atualizações de software Linux. Eles não são obrigatórios para o gerenciamento de clusters desconectados.

A imagem acima apresenta uma visão geral de alto nível da arquitetura dos clusters downstream conectados e sua relação com o cluster de gerenciamento. É possível implantar o cluster de gerenciamento em uma ampla variedade de plataformas de infraestrutura subjacentes, em instalações tanto no local quanto na nuvem, dependendo da disponibilidade de rede entre os clusters downstream e o cluster de gerenciamento de destino. O único requisito para que isso funcione é que a API e o URL de callback estejam acessíveis pela rede que conecta os nós do cluster downstream à infraestrutura de gerenciamento.

É importante reconhecer que existem mecanismos em que a conectividade é estabelecida e que são diferentes do mecanismo de implantação do cluster downstream. Há uma explicação mais detalhada sobre isso na próxima seção; mas, para um entendimento geral, há três mecanismos principais para estabelecer os clusters downstream conectados como um cluster "gerenciado":

Nota

É recomendada a implementação de vários clusters de gerenciamento para acomodar a grande escala de implantações, otimizar os ambientes geograficamente dispersos conforme as expectativas de largura de banda e de latência e minimizar as interrupções em caso de paradas ou upgrades do cluster de gerenciamento. Você encontra os limites de escalabilidade dos clusters de gerenciamento e os requisitos do sistema atuais aqui.

O provisionamento de rede direcionado é por onde você fica sabendo dos detalhes do hardware em que deseja implantar e tem acesso direto à interface de gerenciamento fora da banda para orquestrar e automatizar todo o processo de provisionamento. Nesse cenário, nossos clientes esperam uma solução capaz de provisionar sites de borda completamente automatizados de um local centralizado, indo muito além da criação de uma imagem de inicialização, minimizando as operações manuais no local de borda: basta montar, ligar e conectar as redes necessárias ao hardware físico, e o processo de automação liga a máquina por meio do gerenciamento fora da banda (por exemplo, pela API Redfish) e cuida do provisionamento, da integração e da implantação da infraestrutura sem intervenção do usuário. A chave para que esse processo funcione é que os administradores conheçam os sistemas e saibam qual hardware está em que local, e que a implantação seja realizada centralmente.

Esta solução é a mais robusta, já que você interage diretamente com a interface de gerenciamento do hardware, trabalha com um hardware conhecido e tem menos restrições de disponibilidade de rede. Quanto às funcionalidades, a solução usa amplamente a Cluster API e o Metal³ para o provisionamento automatizado, de bare metal a sistema operacional, Kubernetes e aplicativos em camadas, e oferece a opção de se vincular aos demais recursos de gerenciamento do ciclo de vida comuns de pós-implantação do SUSE Edge. O início rápido da solução está disponível em Capítulo 1, Implantações automatizadas de BMC com Metal³.

Pode acontecer de você trabalhar em um ambiente onde o cluster de gerenciamento central não pode gerenciar o hardware diretamente (por exemplo, a rede remota é protegida por firewall ou não há uma interface de gerenciamento fora da banda; o que é comum em hardware do tipo "PC" mais encontrado na borda). Nesse cenário, oferecemos ferramentas para provisão remota de clusters e suas cargas de trabalho sem a necessidade de saber para onde o hardware é enviado quando é iniciado. É isto que a maioria das pessoas pensa sobre computação de borda: são milhares, ou dezenas de milhares, de sistemas um tanto desconhecidos que são iniciados nos locais de borda e se comunicam de maneira segura com a central ("phone home"), validando suas identidades e recebendo as instruções do que devem fazer. Nesse caso, nossos requisitos são o provisionamento e o gerenciamento do ciclo de vida com muito pouca intervenção do usuário, além de pré-criar a imagem da máquina de fábrica ou simplesmente anexar uma imagem de inicialização, por exemplo, por USB, e ligar o sistema. O principal desafio nesse caso é abordar a escala, a consistência, a segurança e o ciclo de vida desses dispositivos no mundo real.

Esta solução oferece um ótimo nível de flexibilidade e consistência no modo como os sistemas são provisionados e integrados, seja qual for seu local, tipo ou especificação ou quando são ligados pela primeira vez. O SUSE Edge oferece total flexibilidade e personalização do sistema pelo Edge Image Builder, além de aproveitar a oferta de recursos de registro Elemental do Rancher para integração de nós e provisionamento do Kubernetes, junto com o SUSE Multi-Linux Manager para aplicação de patches no sistema operacional. O início rápido da solução está disponível no Capítulo 2, Integração remota de host com o Elemental.

Para os clientes que precisam trabalhar em ambientes independentes, air-gapped ou com limitações de rede, o SUSE Edge oferece uma solução que permite gerar mídias de instalação totalmente personalizadas com todos os artefatos de implantação necessários para habilitar clusters Kubernetes de alta disponibilidade na borda, tanto de um quanto de vários nós, incluindo qualquer carga de trabalho ou componentes adicionais em camadas que sejam necessários. Tudo isso sem precisar de conectividade de rede com ambientes externos e sem a intervenção de uma plataforma de gerenciamento centralizada. A experiência do usuário é muito parecida com a solução "phone home", no que se refere à mídia de instalação fornecida aos sistemas de destino, mas a solução é "iniciada no local". Nesse cenário, é possível conectar os clusters resultantes ao Rancher para gerenciamento contínuo (ou seja, passar do modo de operação "desconectado" para "conectado" sem precisar de reconfiguração ou reimplantação significativa) ou continuar a operação de forma isolada. Observe que, em ambos os casos, é possível usar o mesmo mecanismo consistente para automatizar as operações de ciclo de vida.

Além disso, é possível usar a solução para criar rapidamente clusters de gerenciamento que podem hospedar a infraestrutura centralizada que sustenta os modelos de provisionamento de rede tanto "direcionado" quanto "phone home", já que pode ser a forma mais rápida e simples de provisionar todos os tipos de infraestrutura de borda. Essa solução faz uso intensivo dos recursos do SUSE Edge Image Builder para criar mídias de instalação totalmente personalizadas e autônomas. O início rápido está disponível no Capítulo 3, Clusters independentes com o Edge Image Builder.