Clusters na edge

As aplicações exigem uma alta capacidade de computação para processamento de dados e armazenamento que os dispositivos de IOT não podem atender, visto que geralmente têm recursos limitados. Portanto, as empresas podem usar clusters na borda como ambientes dinâmicos e robustos onde as equipes de operações podem atender ao armazenamento, computação, baixa latência, alto desempenho e alta largura de banda necessários. Além disso, alguns serviços compartilhados no local altamente disponíveis podem exigir a escalabilidade que os clusters do Kubernetes foram projetados para fornecer, como implementações de nuvem de edge.

Um cluster de edge muitas vezes pode ser um limite de recursos lógicos para uma empresa. Os dispositivos de ponta de alta qualidade também são caros para as empresas investirem. Vários dispositivos legados de função fixa ou dedicados já podem ter sido implementados e orçados. A tecnologia de cluster de edge oferece às empresas uma maneira de modernizar e preparar as aplicações para o futuro usando uma abordagem nativa de edge. Isso é feito conectando esses dispositivos a um edge cluster de edge de pequenas dimensões executando uma solução de plataforma de IoT ou gerenciamento de dispositivos. O cluster de edge seria, então, gerenciado e operado como um dispositivo de edge.

Clusters na edge oferecem os seguintes benefícios principais:

• Escalável: ofereça a facilidade e a capacidade de os clientes adicionarem capacidade adicional ao cluster com base na demanda. Ele pode ser configurado para dimensionar automaticamente, reduzindo assim o tempo e o esforço da equipe de operações.
• Distribuído: insights e ações mais rápidos à medida que mais dados são processados e analisados pelo cluster de edge, evitando, assim, as despesas e o tempo de envio de dados para a nuvem.
• Em conformidade: o processamento de dados no cluster de edge também ajuda nas necessidades de conformidade regulatória, residência de dados e isolamento de dados.
• Seguro: comunicação segura entre todos os servidores de aplicativos hospedados no cluster.
• Altamente disponível: a maior confiabilidade é proporcionada pelas opções de failback no cluster e pela capacidade de criar novos nós conforme a necessidade para a operação contínua e tranquila da aplicação.

Vamos analisar um exemplo no setor de varejo. Um varejista quer retirar um produto específico da loja ou torná-lo indisponível para compra devido a um recall de segurança. Eles precisariam atualizar seu sistema central de inventário e enviar essa atualização para que entrasse em vigor em várias lojas.

Um cluster de edge na loja, juntamente com dispositivos de IOT, câmeras e sensores, é adequado para compatibilidade com esse cenário. Enquanto o sistema de inventário da loja sinaliza a SKU (Unidade de Manutenção de Estoque) específica como retirada, o gerente da loja é notificado para retirar o(s) produto(s) físico(s) das prateleiras. Simultaneamente, o sistema de Ponto de Venda (POS) é atualizado para invalidar o código de barras do produto específico. Uma solução de cluster de edge bem arquitetada permitiria essa ação rápida, em escala, sem atrasos dispendiosos ou erros humanos.

A Figura 1 mostra o cluster de edge implementado em uma loja típica de layout de grade com câmeras de segurança e inventário, sistemas de ponto de venda (POS), um sensor de entrada e sensores de temperatura em freezers:

Vejamos outro exemplo, este no setor de transporte. Um navio de carga com conectividade limitada à rede transporta centenas de contêineres refrigerados. Os contêineres refrigerados são, simplesmente, grandes refrigeradores transportados por navios de contêiner para transportar mercadorias sensíveis à temperatura, como carne, legumes e produtos farmacêuticos, sem deterioração. O conteúdo determina a temperatura a ser mantida dentro desses contêineres.

Os contêineres não só precisam manter uma temperatura estável dentro, mas também controlar a umidade e promover um fluxo de ar adequado. A melhor forma de monitorar e gerenciar termostatos, ventiladores e outros componentes vitais do contêiner é um cluster de edge, mesmo no cenário de conectividade limitada a bordo do navio. Essa configuração também permitirá o monitoramento e alertas a bordo das embarcações sem a necessidade de infraestrutura baseada em nuvem. Quando o navio chegasse a um porto, o cluster de edge se reconectaria ao hub de edge no cais de expedição ou na nuvem. Gerenciar esses contêineres e outros dispositivos em escala, com pouca ou nenhuma intervenção humana, é possível por meio de uma solução de cluster de edge bem arquitetada.

Um cluster de edge pode ser pequeno o suficiente para caber em uma prateleira disponível em um espaço confinado, como um QSR (restaurante de serviço rápido), um trem, uma ambulância, um quiosque, armazéns, lojas e andares de produção. Podemos implementar cargas de trabalho relevantes para esse ambiente. Podem ser aplicações de detecção de vídeo, aplicações de detecção de temperatura, aplicações de emissão de tíquetes, serviços de voz de missão crítica ou até mesmo aplicações de AR/VR.

Como exemplo representativo de uma instalação modesta de clusters do Kubernetes para os cenários acima, estão alguns detalhes sobre como implementar usando K3s. Lembre-se de que você também pode usar distribuições do Kubernetes semelhantes, como minikube ou microk8s. A lista abaixo mostra uma configuração de K3s básica, com um nó mestre e dois nós de trabalhadores (https://k3s.io/) de clusters. Mostramos o conjunto mínimo de comandos que são necessários para serem executados em cada componente. A topologia de três nós é mostrada na tabela abaixo:

K3S_URL é o endereço IP do nó mestre juntamente com a porta, em que 6443 é a porta de escuta de HTTPS. Observe que, por padrão, o K3s usa contêineres containerd e não Docker.

Mestre

$export K3S_URL="https://192.168.0.248:6443" $curl -sfL https://get.k3s.io | sh - $sudo cat /var/lib/rancher/k3s/server/node-token K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd

Trabalhador 1

$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd"

Trabalhador 2

$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d585

Do ponto de vista do IBM Edge Application Manager (IEAM), um cluster de edge é semelhante a um dispositivo de edge porque ambos têm um agente de edge instalado. A Figura 2 mostra os componentes de alto nível de um cluster de edge:

Os clusters de edge são basicamente nós de edge que são clusters baseados no Kubernetes. Então, qual é a justificativa para configurar um pequeno cluster como um nó de edge? Cada nó de edge (neste caso, o cluster de edge) é registrado na exchange sob a organização do proprietário do cluster de edge. O registro consiste em um ID e um token de segurança que se aplica somente a esse cluster de edge. Um processo de agente autônomo é executado nesse cluster de edge e aplica as políticas definidas pelo proprietário do cluster de edge. Simultaneamente, os bots de contrato autônomos (ou agbots) recebem políticas de implementação para implementar serviços nesses clusters de edge.

Acima estão descritas as etapas do produto IBM Edge Application Manager, que permite a implementação de serviços de edge em um cluster de edge, por meio de um operador do Kubernetes, permitindo, assim, os mesmos mecanismos de implementação autônoma usados com dispositivos de edge. Isso significa que todo o poder do Kubernetes como plataforma de gerenciamento de contêineres está disponível para serviços de edge.

Esse link no centro de conhecimento do produto detalha as etapas para instalar um agente de edge em um cluster de edge. Depois disso, as aplicações pertinentes podem ser instaladas nesse cluster de edge. Como você deve ter adivinhado, o IEAM é compatível com Kubernetes, K3s, MiniKube, Microk8s e Red Hat OpenShift.

Este blog descreve o valor comercial exclusivo fornecido pela implementação de clusters na edge — não necessariamente na edge distante, mas em nós de edge em locais remotos no local. Para reiterar, os recursos de clustering de nós de borda ajudam a gerenciar e implementar cargas de trabalho de um cluster de hub de gerenciamento para instâncias remotas de OCP ou outros clusters baseados no Kubernetes.

Um cluster de edge possibilita casos de uso na edge que exigem a colocalização da computação com operações comerciais ou que exigem mais escalabilidade, disponibilidade e recursos de computação do que o que é compatível com um dispositivo de edge. Além disso, não é incomum que clusters de edge forneçam serviços de aplicações necessários para compatibilidade com serviços executados em dispositivos de edge devido à sua proximidade com esses dispositivos.

Há uma ferramenta de gerenciamento de contêineres mais recente, de código aberto, para desenvolver, gerenciar e executar contêineres da Open Container Initiative (OCI). Chamada de Podman (abreviação de Pod Manager), é uma opção adequada para clusters de edge. O Podman é fornecido como parte da biblioteca libpod e pode ser usado para criar e manter contêineres. Embora possa executar contêineres Docker, atualmente, ele só funciona em sistemas operacionais baseados em Linux. Saiba mais sobre o Podman aqui.

O centro de arquitetura do IBM Cloud oferece muitas arquiteturas de referência híbrida e multinuvem. 

Você também pode ver a arquitetura de referência automotiva relacionada à edge recém-publicada.

Agradecimentos especiais a Joe Pearson e David Booz por avaliações do artigo.

Não deixe de conferir outras partes desta série de posts de blogs sobre edge computing:

• Parte 3: “Arquitetura na edge”
• Parte 4: “DevOps na edge”
• Parte 7: “Segurança na edge”
• Parte 8: “Análise de dados na edge”
• Parte 9: “5G na edge”
• Parte 10: “Clusters na edge”
• Part 11: “Automação na edge”
• Parte 12: “Fatiamento de rede na edge”
• Parte 13: “Dados na edge”
• Parte 14: “Decisões arquitetônicas na edge”
• Parte 15: “GitOps na edge”
• Parte 17: “Serviços de armazenamento na edge”
• Parte 18: “Serviços de nuvem na edge”
• Parte 20: “Soberania de dados na edge”
• Parte 22: “Produtos conectados na edge”
• Parte 23: “Modelos de base na edge”

• IBM Garage
  
• IBM Edge Application Manager
  

• Instalação do K3s
• Documentação do K3s
• Instalação do IEAM Agent no cluster
• O que é um contêiner refrigerado?
• Transição do Docker para o Podman
• Open Container Initiative da Linux Foundation