Modifier

Générer des projets de la CNCF à l’aide d’Azure Kubernetes Service

Azure Kubernetes Service (AKS)

Cet article montre comment conceptualiser, architecturer, générer et déployer une application qui utilise des projets de la Cloud Native Computing Foundation (CNCF) après le déploiement d’Azure Kubernetes Service (AKS). L’architecture décrit la CNCF Projects App sur GitHub. Les instructions d’installation dans le dépôt GitHub couvrent les étapes de déploiement de l’architecture.

Architecture

Architecture diagram that shows the reference architecture for building a CNCF project.

Téléchargez un fichier Visio de cette architecture.

La charge de travail est une application web simple que les employés peuvent utiliser pour soumettre et afficher des notes de frais. Quand un employé soumet une note de frais, son responsable reçoit un e-mail.

Workflow

Flux d’application

1. L’employé accède à une application web via NGINX Ingress pour soumettre des frais.

2. L’application web appelle une application API pour trouver le responsable de l’employé.

3. L’application web envoie (push) un message qui est généré pour la création du rapport de dépenses dans un broker (répartiteur) Knative.

4. La note de frais est enregistrée dans MySQL.

5. Knative déclenche la fonction de dispatch d’emails avec le message de dépenses comme charge utile.

6. Le répartiteur d’e-mails crée un message SendGrid.

7. SendGrid envoie un e-mail au responsable trouvé pour révision.

Flux de DevOps

a. Les développeurs écrivent ou mettent à jour le code dans Visual Studio Code.

b. Les développeurs envoient (push) le code à GitHub à partir de leur espace de travail local dans Visual Studio Code.

c. Le Webhook GitHub déclenche les pipelines Tekton qui clonent le code GitHub.

d. Les pipelines construisent et poussent les images de conteneurs vers un registre Harbor.

e. Tekton déploie l’application web, l’application API et les applications du répartiteur d’e-mails.

f. Prometheus capture les métriques de l’application.

g. Les ingénieurs surveillent les métriques sur un tableau de bord Grafana.

h. les ingénieurs de DevOps surveillent le tableau de bord Grafana.

Infrastructure

i. Cluster AKS basé sur l’infrastructure présentée dans la ligne de base AKS.

ii. Rook Ceph utilisé pour le stockage du cluster.

iii. Maillage du service Linkerd.

iv. Jaeger pour le suivi d’application global sur le cluster Kubernetes.

Opérations de cluster

Il peut être bénéfique de gérer les clusters et l’amorçage de cluster à l’aide de la gestion GitOps. Flux est un opérateur GitOps populaire. Il est souvent associé à GitHub Actions pour activer la validation sur les manifestes mis à jour et les graphiques Helm.

Components

Azure

Logiciel open source (OSS)

  • Kubernetes. CNCF. Automatise le déploiement, la mise à l’échelle et la gestion des applications conteneurisées.
  • Flux. CNCF. Fournisseur GitOps pour la livraison d’infrastructure.
  • Rook. CNCF. Fournit la gestion du stockage pour les clusters.
  • Harbor. CNCF. Registre de conteneurs pour les images.
  • Linkerd. CNCF. Maillage de service qui s’intègre à OpenFaaS, NGINX, Prometheus et Jaeger.
  • Prometheus. CNCF. Capture les métriques de l’application.
  • Jaeger. CNCF. Assure le suivi d’application global sur le cluster Kubernetes.
  • Knative. CNCF. Utilisé pour construire des applications sans serveur et orientées événement. Il déploie la fonction de dispatch d’emails.
  • MySQL. Base de données qui stocke les notes de frais.
  • NGINX. Contrôleur d’entrée Kubernetes que les employés utilisent pour accéder à l’application web afin d’envoyer des notes de frais.
  • Tekton. Projet Continuous Delivery Foundation utilisé pour l’intégration continue et livraison continue (CI/CD). Déploie l’application web, l’application API et les applications du répartiteur d’e-mails.
  • Grafana. Tableau de bord pour les métriques d’application.
  • SendGrid. Service de courrier externe qui envoie un e-mail au responsable pour la révision de la note de frais.
  • GitHub. Dépôt de code. Les pipelines Tekton utilisent du code GitHub.
  • .NET Core. Utilisé pour le serveur frontal web et l’API web.
  • Flux. Assure la gestion de GitOps.

Autres solutions

Ce projet utilise des projets gradués et incubés par la CNCF. Il pourrait y avoir plusieurs alternatives pour les services utilisés. Pour découvrir des alternatives, consultez le site web de la CNCF. Voici des ressources qui décrivent certaines d’entre elles :

Vous pouvez envisager divers services Azure en guise d’alternatives. Par exemple, pour le routage d’applications web, Azure Container Registry, Azure Container Storage, Azure Monitor, le service géré Azure Monitor pour Prometheus, Azure Managed Grafana.

Microsoft soutient également les projets OSS comme Addons gérés/Projets dérivés dans AKS, incluant Nginx, Istio, Prometheus, Grafana, et OpenEBS.

Détails du scénario

Vous pouvez déployer cette architecture sur n’importe quel cluster Kubernetes, pas seulement sur AKS. Elle fournit un exemple de la flexibilité de la plateforme AKS. AKS simplifie le déploiement d’un cluster Kubernetes managé dans Azure.

Après avoir consulté cet article, vous aurez une bonne compréhension de la manière de déployer une application typique constituée principalement de projets de la CNCF.

Cas d’usage potentiels

Ces autres cas d’usage ont des modèles de conception similaires :

  • Création d’un pipeline CI/CD pour les charges de travail basées sur des conteneurs
  • Utilisation de GitOps pour AKS

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

  • Pour le cluster Kubernetes, vous avez besoin d’au moins un pool de nœuds utilisateur à 3 nœuds avec une référence (SKU) de machine virtuelle (VM) DS2_v2 ou de taille supérieure.
  • Des volumes utilisant des disques managés Azure ne peuvent pas être attachés entre zones. Ils doivent se trouver dans la même zone.
  • L’installation de Rook peut prendre de 20 à 25 minutes. Assurez-vous que le cluster Ceph est entièrement approvisionné avant de passer à l’étape suivante.
  • L’installation de Jaeger prend environ 5 minutes.
  • Il faut environ 12 minutes pour que Linkerd apparaisse dans le tableau de bord.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Vous pouvez utiliser la calculatrice de prix Azure pour estimer les coûts. Voici quelques considérations relatives à la tarification pour l’exécution de ce projet dans Azure. Un coût de bande passante négligeable s’applique.

Virtual Machine Scale Sets

Les machines virtuelles utilisées dans Azure Virtual Machine Scale Sets pour le cluster AKS ont un coût. Pour plus d’informations, consultez Tarification des groupes de machines virtuelles identiques.

Stockage

Des coûts de stockage s’appliquent à chaque disque de données requis par l’installation de Rook. Pour ce cluster AKS à 3 nœuds, la configuration de Rook utilise deux disques de données par nœud : un disque de 1 Go et un disque de 200 Go. Pour plus d’informations, consultez Tarification du coût de stockage.

Équilibrage de charge

L’équilibreur de charge associé à ce cluster AKS a un coût. Pour plus d’informations, consultez Facturation de Load balancer.

Réseau virtuel

Le réseau virtuel utilisé par le cluster AKS a un coût. Pour plus d’informations, consultez Tarification de Réseau virtuel Microsoft Azure.

Déployer ce scénario

Déployez ce scénario à partir du dépôt GitHub Azure/cloud-native-app. Suivez les instructions d’installation figurant dans la séquence fournie pour déployer la CNCF Pojects App dans votre environnement.

Ce dépôt est un projet de communauté. Il accepte et approuve les requêtes de tirage (PR) pour les améliorations et modifications apportées par la communauté.

Étapes suivantes