Les clusters à la périphérie

Les applications gourmandes en calcul nécessitent une capacité de calcul élevée afin de traiter et de stocker les données, chose dont les appareils IdO ne sont pas capables, dans la mesure où ils sont souvent limités en ressources. Les entreprises peuvent donc utiliser les clusters en périphérie de réseau (edge) comme des environnements dynamiques et robustes permettant aux équipes opérationnelles de répondre aux exigences de stockage, de calcul, de faible latence ainsi que de performance et de bande passante élevées. De plus, certains services partagés sur site à haute disponibilité peuvent nécessiter l’évolutivité que les clusters Kubernetes sont conçus pour fournir, par exemple les déploiements de cloud en périphérie de réseau.

Un cluster edge peut souvent constituer une limite logique en matière de ressources pour une entreprise. Les appareils edge haut de gamme représentent également un investissement coûteux pour les entreprises. De nombreux appareils hérités à fonction fixe ou dédiés ont peut-être déjà été déployés et budgétés. La technologie des clusters edge offre aux entreprises un moyen de moderniser et de pérenniser leurs applications à l’aide d’une approche edge native. Pour ce faire, ces appareils sont connectés à un cluster edge compact exécutant une solution de gestion des appareils ou une plateforme IdO. Le cluster edge est alors géré et exploité comme un appareil edge.

Les clusters en périphérie de réseau offrent les avantages clés suivants :

• Évolutif : permettez aux clients d'ajouter facilement de la capacité supplémentaire au cluster en fonction de la demande. Il peut être configuré pour une mise à l’échelle automatique, réduisant ainsi le temps et les efforts de l’équipe d’opérations.
• Distribution : ils permettent d’obtenir des informations et d’agir plus rapidement, car une plus grande partie des données est traitée et analysée par ceux-ci, ce qui évite les frais et les délais liés à l’envoi des données vers le cloud.
• Conformité : le traitement des données au niveau des clusters edge apporte également des garanties en matière de conformité réglementaire, de résidence des données et d’isolation des données.
• Sécurité : la communication est sécurisée entre tous les serveurs d’applications hébergés sur les clusters.
• Haute disponibilité : les options de restauration automatique sur les clusters et la possibilité de créer de nouveaux nœuds en cas de besoin pour assurer le bon fonctionnement continu de l’application offrent une fiabilité accrue.

Prenons un exemple dans le secteur de la vente au détail. Un détaillant souhaite retirer un produit donné des rayons de son magasin ou le rendre indisponible à la vente en raison d’un rappel de sécurité. Il doit mettre à jour son système central de gestion des stocks et diffuser cette modification afin qu’elle soit prise en compte dans plusieurs magasins.

Un cluster edge dans le magasin, associé à des appareils IdO, des caméras et des capteurs, est parfaitement adapté à ce scénario. Lorsque le système de gestion des stocks du magasin signale que l’UGS concernée est retirée, le gérant est également informé afin de retirer le ou les produits physiques des rayons. Simultanément, le système de point de vente est mis à jour pour invalider le code-barres de ce produit particulier. Ainsi, une solution de cluster edge bien conçue permettrait une action rapide, à grande échelle, sans retards coûteux ni erreurs humaines.

La figure 1 montre le cluster edge déployé dans un magasin à agencement linéaire classique, équipé de caméras de sécurité et de contrôle des stocks, de systèmes de point de vente, d’un capteur d’entrée et de capteurs de température dans les congélateurs :

Prenons un autre exemple, cette fois dans le secteur des transports. Un navire de transport de marchandises disposant d'une connectivité limitée au réseau transporte des centaines de conteneurs réfrigérés. Les conteneurs réfrigérés sont, en termes simples, de grands réfrigérateurs transportés par des navires porte-conteneurs afin de transporter des marchandises sensibles à la température, telles que la viande, les légumes et les produits pharmaceutiques, sans qu'elles ne s'abîment. Le contenu détermine la température à maintenir à l'intérieur de ces conteneurs.

Les conteneurs réfrigérés doivent non seulement maintenir une température stable à l'intérieur, mais également contrôler l'humidité et favoriser une circulation d'air adéquate. La surveillance et la gestion des thermostats, des ventilateurs et des autres composants essentiels du conteneur réfrigéré sont mieux assurées par un cluster périphérique, même dans le contexte de connectivité limitée à bord d'un navire. Cette configuration permettra également une surveillance et une alerte à bord des navires sans nécessiter d’infrastructure basée sur le cloud. Lorsque le navire atteint un port, le cluster à la périphérie se reconnecte au hub edge sur le quai d’expédition ou sur le cloud. La gestion de ces référentiels et d'autres appareils à l'échelle, avec peu ou pas d'intervention humaine, n'est possible que via une solution de cluster edge bien conçue.

Un cluster périphérique peut être suffisamment compact pour être installé sur une étagère disponible dans un espace restreint tel qu'un restaurant à service rapide, un train, une ambulance, un kiosque, un magasin, un entrepôt ou un atelier de production. Nous pouvons déployer des workloads pertinents pour cet environnement. Il peut s’agir d’applications de détection vidéo, de détection de température, de gestion de tickets, de services vocaux essentiels ou même d’applications de réalité augmentée/réalité virtuelle.

En guise d’exemple d‘une installation modeste de cluster Kubernetes pour les scénarios ci-dessus, voici quelques détails sur la manière de procéder à la mise en œuvre à l’aide de K3s. Veuillez noter que vous pouvez également utiliser des distributions Kubernetes similaires telles que minikube ou microk8s. La liste ci-dessous présente une configuration simple de cluster K3s (https://k3s.io/) à 1 nœud maître et 2 nœuds esclaves. Nous vous présentons le minimum de commandes à exécuter sur chaque composant. La topologie à 3 nœuds est illustrée dans le tableau ci-dessous :

K3S_URL correspond à l’adresse IP du nœud maître ainsi qu’au port, où 6443 est le port d’écoute HTTPS. Veuillez noter que, par défaut, K3s utilise des conteneurs containerd et non Docker.

Master

$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

Esclave 1

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

Worker 2

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

Dans le cadre d’IBM Edge Application Manager (IEAM), un cluster edge est similaire à un appareil edge, car les deux ont un agent edge installé. La figure 2 présente les composants de haut niveau d’un cluster edge :

Les clusters edge sont essentiellement des nœuds edge qui sont des clusters basés sur Kubernetes. Donc, quelle est la logique de la configuration d'un petit cluster en tant que nœud edge ? Chaque nœud edge (ou périphérique) dans ce cas, le cluster edge, est enregistré auprès de la plateforme d'échange sous l'organisation du propriétaire du cluster périphérique. L'enregistrement se compose d'un identifiant et d'un token de sécurité qui s'appliquent uniquement à ce cluster edge. Un processus d'agent autonome s'exécute sur ce cluster edge et applique les politiques définies par le propriétaire du cluster périphérique. De manière simultanée, les bots autonomes (ou agbots) sont assignés des politiques de déploiement pour déployer des services sur ces clusters périphériques.

La description ci-dessus présente les étapes du produit IBM Edge Application Manager, qui permet de déployer des services edge sur un cluster edge via un opérateur Kubernetes, et donc de bénéficier des mêmes mécanismes de déploiement autonomes que ceux utilisés avec les appareils edge. Cela signifie que toute la puissance de Kubernetes en tant que plateforme de gestion de conteneurs est disponible pour les services edge.

Ce lien vers le centre de connaissances sur les produits détaille les étapes à suivre pour installer un agent edge sur un cluster edge. Une fois cette opération effectuée, il est possible d’installer les applications pertinentes sur ce cluster edge. Comme vous l’avez peut-être deviné, IEAM prend en charge Kubernetes, K3s, MiniKube, Microk8s et Red Hat OpenShift.

Cet article de blog décrit la valeur métier unique offerte par le déploiement de clusters périphériques, pas nécessairement à distance, mais des nœuds en des emplacements sur site, néanmoins. Pour récapituler, les capacités de clustering des nœuds périphériques vous permettent de gérer et de déployer des workloads depuis un cluster de hub de gestion vers des instances distantes d'OCP ou d'autres clusters basés sur Kubernetes.

Un cluster edge permet des cas d’utilisation en périphérie de réseau qui nécessitent la colocalisation du calcul avec les opérations métier ou qui exigent plus d’évolutivité, de disponibilité et de capacité de calcul que ce que peut prendre en charge un appareil edge. De plus, il n’est pas rare que les clusters edge fournissent les services d’application nécessaires pour prendre en charge les services exécutés sur les appareils edge en raison de leur proximité avec ces derniers.

Il existe un nouvel outil de gestion de conteneurs open source qui permet de développer, de gérer et d'exécuter des conteneurs Open Container Initiative (OCI). Appelée Podman (abréviation de Pod Manager), il s’agit d’une option bien adaptée aux clusters edge. Podman est fourni dans le cadre de la bibliothèque libpod et peut être utilisé pour créer et gérer des conteneurs. Bien qu'il puisse exécuter des conteneurs Docker, il ne fonctionne actuellement que sur des systèmes d'exploitation basés sur Linux. Pour en savoir plus sur Podman, cliquez ici.

Le centre d’architecture d’IBM Cloud propose de nombreuses architectures de référence hybrides et multicloud. 

Vous pouvez également consulter la toute nouvelle architecture de référence relative à l’edge computing.

Un merci tout particulier à Joe Pearson et à David Booz pour la révision de cet article.

Nous vous invitons à consulter les autres articles de cette série d’articles de blog sur l’edge computing :

• Partie 3 : « L'architecture à la périphérie »
• Partie 4 : « Le DevOps à la périphérie »
• Partie 7 : « La sécurité à la périphérie »
• Partie 8 : « L’analytique à la périphérie »
• Partie 9 : « La 5G à la périphérie »
• Partie 10 : « Les clusters à la périphérie »
• Partie 11 : « L'automatisation à la périphérie »
• Partie 12 : « Découpage du réseau à la périphérie »
• Partie 13 : «Les données à la périphérie »
• Partie 14 : « Les décisions architecturales à la périphérie »
• Partie 15 : « Le GitOps à la périphérie »
• Partie 17 : « Services de stockage à la périphérie »
• Partie 18 : « Les services cloud en périphérie »
• Partie 20 : « Souveraineté des données à la périphérie »
• Partie 22 : « Les produits connectés à la périphérie »
• Partie 23 : « Les modèles de fondation à la périphérie »

• IBM Garage
  
• IBM Edge Application Manager
  

• Installation K3s
• Documentation K3s
• Installation de l'agent IEAM sur le cluster
• Qu’est-ce qu’un conteneur frigorifique ?
• Transition de Docker à Podman
• Open Container Initiative de la Linux Foundation