Choisir une option de calcul Kubernetes à la périphérie

Ce document traite des compromis liés aux différentes options disponibles pour étendre le calcul en périphérie. Pour chaque option Kubernetes, considérations abordées sont les suivantes :

  • Coût opérationnel. Travail attendu requis pour gérer et exploiter les clusters Kubernetes.

  • Facilité de configuration. Niveau de difficulté de la configuration et du déploiement d’un cluster Kubernetes.

  • Flexibilité. Mesure de l’adaptabilité de l’option Kubernetes pour intégrer une configuration personnalisée avec une infrastructure existante en périphérie.

  • Nœud mixte. Possibilité d’exécuter un cluster Kubernetes avec des nœuds Linux et Windows.

Hypothèses

  • Vous êtes un opérateur de cluster cherchant à comprendre les différentes options d’exécution de Kubernetes en périphérie et de gestion des clusters dans Azure.

  • Vous avez une bonne compréhension de l’infrastructure existante et des autres exigences applicables à celle-ci, dont les exigences de stockage et de mise en réseau.

Après avoir lu ce document, vous serez mieux à même d’identifier l’option la mieux adaptée à votre scénario et à l’environnement requis.

Choix de Kubernetes en un coup d’œil

Coût opérationnel Facilité de configuration Flexibilité Nœud mixte Résumé
Bare-metal Kubernetes Élevé** Difficile** Élevé** Oui Configuration de bout en bout sur toute infrastructure disponible dans un emplacement, avec la possibilité d’utiliser Azure Arc pour disposer de fonctionnalités Azure supplémentaires.
K8s sur Azure Stack Edge Pro Faible Facile Faible Linux uniquement Kubernetes déployé sur une appliance Azure Stack Edge déployée dans l’emplacement.
AKS hybride Faible Facile Moyenne Oui AKS déployé sur Azure Stack HCI ou Windows Server 2019.

* D’autres plateformes de périphérie gérées (OpenShift, Tanzu, etc.) ne sont pas abordées dans ce document.

** Ces valeurs sont basées sur l’utilisation de kubeadm, par souci de simplicité. La diversité des possibilités pour l’exécution de l’option bare-metal Kubernetes en périphérie altère le classement dans ces catégories.

Bare-metal Kubernetes

Configuration de bout en bout de Kubernetes à l’aide d’outils tels que kubeadm sur toute infrastructure sous-jacente.

Les plus grandes contraintes liées à l’option bare-metal Kubernetes ont trait aux besoins et exigences spécifiques de l’organisation. La possibilité d’utiliser n’importe quels distribution, interface réseau et un plug-in induit une complexité et un coût opérationnel plus élevés. Mais il s’agit de l’option la plus flexible pour personnaliser votre cluster.

Scénario

Souvent, les emplacements en périphérie imposent des exigences spécifiques pour l’exécution de clusters Kubernetes, que ne satisfont pas les autres solutions Azure décrites dans ce document. Cela signifie que cette option est généralement idéale pour des personnes qui ne peuvent pas utiliser des services managés parce que leur infrastructure existante n’est pas prise en charge, ou qui cherchent à avoir un contrôle maximal de leurs clusters.

  • Cette option peut s’avérer particulièrement difficile pour les personnes qui ne connaissent rien à Kubernetes. Il n’est pas rare que ce soit le cas d’organisations qui cherchent à exécuter des clusters en périphérie. Des options telles que MicroK8s ou K3S visent à aplatir cette courbe d’apprentissage.

  • Il est important de comprendre d’emblée l’infrastructure sous-jacente et l’intégration qui devra avoir lieu. Cela vous aidera à limiter les options viables et à identifier d’éventuelles lacunes avec les outils et/ou plug-ins open source.

  • L’activation de clusters avec Azure Arc offre un moyen simple de gérer votre cluster à partir d’Azure, ainsi que d’autres ressources. Cela apporte également d’autres capacités Azure à votre cluster, dont Azure Policy, Azure Monitor, Microsoft Defender pour le cloud et d’autres services.

  • Étant donné que la configuration du cluster n’est pas simple, il est particulièrement important de vous soucier de l’intégration continue et livraison continue (CI/CD). Le suivi et l’action sur les modifications en amont de différents plug-ins ainsi que la vérification que ces modifications n’affectent pas l’intégrité de votre cluster devient une responsabilité directe. Il est important de disposer d’une solution de CI/CD forte, de tests renforcés et d’une supervision effective.

Options des outils

Démarrage du cluster :

  • kubeadm : outil Kubernetes pour la création de clusters Kubernetes de bout en bout. Adapté aux ressources de calcul standard (Linux/Windows).

  • MicroK8s : administration et configuration simplifiées (« LowOps »), conformes à Kubernetes par Canonical.

  • K3S : distribution Kubernetes certifiée conçue pour l’Internet des objets (IOT) et le computing en périphérie.

Stockage :

  • Explorez les pilotes CSI disponibles : de nombreuses options sont disponibles pour répondre à vos besoins, du cloud aux partages de fichiers locaux.

Mise en réseau :

Considérations

Coût opérationnel :

  • Sans le support qui accompagne les services managés, il appartient à l’organisation de gérer et d’exploiter le cluster comme un tout (stockage, réseau, mises à niveau, observabilité, gestion des applications). Le coût opérationnel est jugé élevé.

Facilité de configuration :

  • L’évaluation des nombreuses options open source à chaque étape de la configuration, qu’il s’agisse d’options de mise en réseau, de stockage ou de surveillance, est inévitable et peut devenir complexe. Nécessite d’accorder plus d’attention à la CI/CD pour la configuration du cluster. En raison de ces préoccupations, la configuration est jugée difficile.

Flexibilité :

  • Offrant la possibilité d’utiliser n’importe quel outil ou plug-in open source sans aucune restriction de fournisseur, l’option bare-metal Kubernetes est très flexible.

Kubernetes sur Azure Stack Edge

Cluster Kubernetes (machine virtuelle maître et machine virtuelle de travail) configuré et déployé pour vous sur votre appareil Azure Stack Edge Pro.

Les appareils Azure Stack Edge Pro fournissent des fonctionnalités Azure, telles que le calcul, le stockage, la mise en réseau et l’apprentissage automatique avec accélération matérielle, où vous voulez en périphérie. Des clusters Kubernetes peuvent être créés une fois le rôle de calcul activé sur l’un des appareils Pro-GPU, Pro-R et Mini-R. La gestion des mises à niveau du cluster Kubernetes peut être effectuée à l’aide des mises à jour standard disponibles pour l’appareil.

Scénario

Idéal pour ceux qui ont des charges de travail IoT (Linux) existantes ou qui mettent à niveau leur calcul pour le ML en périphérie. Il s’agit d’une bonne option quand il n’est pas nécessaire d’avoir un contrôle plus fin sur les clusters.

  • Les autorisations d’administrateur ne sont pas accordées par défaut. Bien que vous puissiez collaborer avec le groupe de produits pour faire certaines exceptions, cela rend difficile un contrôle plus fin de votre cluster.

  • À défaut de disposer déjà d’un appareil Azure Stack Edge, il y a un coût supplémentaire. Explorez les appareils Azure Stack Edge pour voir s’ils répondent à vos besoins en matière de calcul.

  • Calico, MetalLBet CoreDNS sont installés pour la mise en réseau de Kubernetes sur l’appareil.

  • Seules des charges de travail Linux sont prises en charge actuellement.

  • En plus de Kubernetes, Azure Stack Edge comprend le runtime IoT, ce qui signifie que des charges de travail peuvent également être déployées sur vos clusters Azure Stack Edge via IoT Edge.

  • La prise en charge de deux clusters à nœuds n’est pas disponible actuellement. Cela signifie effectivement que cette option n’est pas une solution à haute disponibilité.

Considérations

Coût opérationnel :

  • Avec le support associé à l’appareil, le coût opérationnel est minime et limité à la gestion des charges de travail.

Facilité de configuration :

  • Le déploiement d’un cluster Kubernetes préconfiguré et bien documenté simplifie la configuration requise par rapport à l’option bare-metal Kubernetes.

Flexibilité :

  • La configuration est prédéfinie et les autorisations d’administrateur ne sont pas accordées par défaut. Une implication du groupe de produits peut être nécessaire au-delà de la configuration de base, et l’infrastructure sous-jacente doit être un appareil Azure Stack Edge Pro, ce qui en fait une option moins flexible.

AKS hybride

AKS hybride est un ensemble de paramètres et de configurations prédéfinis qui sont utilisés pour déployer un ou plusieurs clusters Kubernetes (avec Windows Admin Center ou des modules PowerShell) sur un cluster à plusieurs nœuds exécutant Windows Server ou Azure Stack HCI 20H2, ou versions ultérieures.

Scénario

Idéal pour ceux qui souhaitent une méthode simplifiée et rationalisée pour obtenir un cluster pris en charge par Microsoft sur des appareils compatibles (Azure Stack HCI ou Windows Server). La complexité de l’exploitation et de la configuration est réduite au détriment de la flexibilité par rapport à l’option bare-metal Kubernetes.

Considérations

Coût opérationnel :

  • Le cluster pris en charge par Microsoft minimise les coûts opérationnels.

Facilité de configuration :

  • Le déploiement d’un cluster Kubernetes préconfiguré et bien documenté simplifie la configuration requise par rapport à l’option bare-metal Kubernetes.

Flexibilité :

  • La configuration du cluster est prédéfinie, mais les autorisations d’administrateur sont accordées. L’infrastructure sous-jacente doit être un appareil Azure Stack HCI ou Windows Server. 2019. Cette option est plus flexible que l’option Kubernetes sur Azure Stack Edge et moins flexible que l’option bare-metal Kubernetes.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Pour plus d’informations, consultez les articles suivants :