Lorsque nous avons commencé à travailler sur le projet NGINX Modern Apps Reference Architecture (MARA), nous avons choisi AWS comme fournisseur IaaS car nous connaissions déjà la plateforme et nous pouvions utiliser notre budget départemental pour le financer. Bien entendu, tout le monde n’a pas la même expérience ni le même budget, et beaucoup d’entre vous nous ont demandé de fournir des options pour exécuter MARA localement (dans un environnement de laboratoire ou même sur un poste de travail) avec des distributions Kubernetes telles que K3s , Canonical MicroK8s et minikube .
Nous vous avons entendu et aujourd’hui nous sommes heureux d’annoncer que nous avons testé MARA sur MicroK8s et que nous fournissons des instructions pour que vous puissiez le déployer vous-même !
Pourquoi avons-nous choisi MicroK8s pour nos tests ? Parce qu'il fournit les capacités DNS, de stockage et de sortie dont MARA a besoin, dans un modèle facile à déployer avec une faible empreinte mémoire. Avec MicroK8s, nous pouvons facilement et à plusieurs reprises parcourir des scénarios de test pour déterminer les exigences minimales pour les déploiements qui offrent des niveaux de performances raisonnables.
Nous espérons que ce travail facilitera nos tests sur d'autres distributions Kubernetes ; pour plus d'informations sur l'état actuel des différentes distributions, consultez notre dépôt GitHub . Si vous avez une distribution préférée que vous souhaitez voir sur la liste, nous vous invitons à forker, tester et créer des pull requests !
Les plus grandes contraintes à l’exécution de MARA localement sont la mémoire et le processeur. Lors des tests préliminaires, nous avons constaté que la plupart des problèmes d’épuisement de la mémoire concernaient Elasticsearch. Kibana est quasiment inutilisable dans des configurations avec une quantité de mémoire extrêmement faible (moins de 16 Go ). Pour résoudre ce problème, nous avons fourni des paramètres dans le fichier de configuration MARA qui éliminent les protections de redondance dont dispose normalement un déploiement Elasticsearch complet. Bien que cela augmente le nombre de modes de défaillance, il s’agit d’un compromis nécessaire dans les environnements aux ressources limitées.
Les contraintes sur le processeur sont directement liées à la quantité de charge imposée à notre exemple d'application Bank of Sirius . Le déploiement MARA inclut Locust pour générer une charge sur Bank of Sirius, avec des paramètres contrôlés par l'utilisateur pour le nombre d'utilisateurs et le taux d'apparition de nouveaux utilisateurs.
Notez que l’augmentation de la charge sur Bank of Sirius affecte également le reste du système. Si le nombre d'utilisateurs ou le taux d'apparition est trop élevé, les performances de MARA se dégradent au point où les composants risquent de planter ou de se bloquer. Les valeurs qui provoquent ce comportement dépendent du processeur disponible, mais vous pouvez vous attendre à un déploiement avec au moins la capacité spécifiée dans Exigences pour gérer la charge créée par jusqu'à 64 utilisateurs et une fréquence d'exécution de 16 utilisateurs à la fois.
Maintenant que vous avez tout compris, vous êtes prêt à défendre MARA sur MicroK8s !
accès root
sur un système (serveur Linux bare-metal, virtualisé ou cloud) exécutant Ubuntu 20.04 (Focal) ou une version ultérieure, avec au minimum :
Un environnement virtuel Python 3 sur le système local avec toutes les bibliothèques et binaires requis par MARA. Si Python 3 n’est pas déjà installé, exécutez ces commandes :
$ sudo apt update $ sudo apt install -y python3-venv
Au moins une adresse IPv4 libre pour l'équilibreur de charge MetalLB intégré de MicroK8s à attribuer à la sortie du contrôleur d'entrée NGINX. Si vous accédez à l'application Bank of Sirius via localhost, toute adresse privée disponible (conforme RFC 1918 ) est acceptable. Par exemple, si votre réseau est 192.168.100.0/24, vous pouvez utiliser une adresse telle que 10.10.10.10.
Un compte Pulumi et un jeton d'accès. Si vous ne les possédez pas déjà, vous les créerez à l'étape 1 du déploiement de MARA .
Notez que même si Pulumi vous permet de stocker le fichier d’état dans un magasin d’objets compatible S3 ou sur le système de fichiers local, MARA ne prend pas en charge cette fonction au moment de la rédaction. Cette limitation sera supprimée dans une future version de MARA ou Pulumi.
Installer MicroK8s :
$ sudo snap install microk8s --classic microk8s (1.23/stable) v1.23.3 de Canonical✓ installé
Définissez les autorisations nécessaires pour exécuter les commandes microk8s
. Pour <nom d'utilisateur>
, remplacez votre compte qui a racine
privilège sur le système :
$ sudo usermod -a -G microk8s <nom d'utilisateur>$ sudo chown -f -R <nom d'utilisateur> ~/.kube
$ nouveau groupe microk8s
Déconnectez-vous de votre compte root et reconnectez-vous pour que les nouvelles autorisations prennent effet.
Activez les modules complémentaires MicroK8s pour DNS , stockage et MetalLB .
À l'invite, spécifiez une plage d'adresses IP au format X . X . X . X ‑ X . X . X . Y
pour représenter :
192.168.100.100-192.168.100.110
, la valeur utilisée ci-dessous)192.168.100.100-192.168.100.100
)$ microk8s enable dns storage metallb Activation du DNS Application du manifeste ...
Redémarrage du kubelet DNS activé Activation de la classe de stockage par défaut ...
Le stockage sera bientôt disponible Activation de MetalLB Entrez chaque plage d'adresses IP délimitée par une virgule (par exemple '10.64.140.43-10.64.140.49,192.168.0.105-192.168.0.111') : 192.168.100.100-192.168.100.110
Application du manifeste Metallb ...
MetalLB est activé
Confirmez que MicroK8s est en cours d'exécution :
$ microk8s status microk8s est en cours d'exécution en haute disponibilité : aucun nœud maître de banque de données : 127.0.0.1:19001 datastore standby nodes: none addons: enabled: dns # CoreDNS ha-cluster # Configurer la haute disponibilité sur le nœud actuel metallb # Équilibreur de charge pour votre cluster Kubernetes storage # Classe de stockage ; alloue du stockage à partir du répertoire hôte ...
Chargez la configuration MicroK8s dans le fichier où la plupart des utilitaires s'attendent à la trouver ( ~/.kube/config ) et définissez les autorisations recommandées sur le répertoire et le fichier :
$ microk8s config > ~/.kube/config $ sudo chmod 0644 ~/.kube/config
Clonez le référentiel MARA et initialisez le sous-module Bank of Sirius :
$ git clone https://github.com/nginxinc/kic-reference-architectures.git $ cd kic-reference-architectures/ $ git submodule update --init --recursive --remote
En travaillant dans le répertoire racine du référentiel MARA cloné (vous avez changé de répertoire à l'étape précédente), configurez l'environnement virtuel Python pour le cluster MicroK8s :
$ ./bin/setup_venv.sh
Cette commande génère une longue trace. S'il y a des erreurs, veuillez consulter la section Problèmes connus/Avertissements du référentiel GitHub MARA pour obtenir des suggestions.
Activer l'environnement virtuel Python. La commande définit votre PATH
et d’autres variables d’environnement pour utiliser l’environnement virtuel :
$ source ./pulumi/python/venv/bin/activate
Confirmez que le cluster MicroK8s est correctement configuré pour le déploiement MARA :
$ ./bin/testcap.sh Ce script effectuera des tests sur l'installation actuelle de Kubernetes en utilisant la configuration et le contexte de Kubernetes actuellement actifs.
Tout échec doit être examiné, car il indique que l'installation ne répond pas à l'ensemble minimal de fonctionnalités requises pour exécuter MARA. ... ================================================================ | Tous les tests ont réussi ! Ce système répond aux exigences de base | | pour déployer MARA. | ===================================================================
Le script start.sh
, utilisé dans cette section pour déployer MARA, prend en charge les options qui nécessitent des actions supplémentaires pour que le déploiement réussisse. Par souci de simplicité, nous supposons ici un déploiement de base qui :
AVIS !
à l’étape 3 ci-dessous pour plus d’informations.AVIS !
à l’étape 3.Déployer MARA dans le cluster MicroK8s :
Si vous n'avez pas encore configuré votre poste de travail pour utiliser Pulumi, vous êtes invité à vous connecter à Pulumi (en créant un compte si nécessaire), puis à saisir le jeton API associé à votre compte Pulumi.
$ ./bin/start.sh Ajout de [/home/ubuntu/kic-reference-architectures/bin/venv/bin] à PATH Gérez vos piles Pulumi en vous connectant.
Exécutez « pulumi login --help » pour des options de connexion alternatives.
Saisissez votre jeton d'accès depuis https://app.pulumi.com/account/tokens
ou appuyez sur <ENTRÉE> pour vous connecter à l'aide de votre navigateur : <jeton>
Veuillez lire la documentation pour plus de détails.
Sélectionnez le type de déploiement en tapant k
à l’invite pour créer le déploiement avec les fichiers kubeconfig. Ignorez les avertissements concernant make
et Docker qui ne sont pas installés : le déploiement utilise à la place une image NGINX Ingress Controller à partir d’un registre.
Tapez a pour AWS, k pour kubeconfig ? k Appel du script de démarrage de kubeconfig make n'est pas installé - il doit être installé si vous avez l'intention de créer NGINX Kubernetes Ingress Controller à partir de la source. docker n'est pas installé - il doit être installé si vous avez l'intention de créer NGINX Kubernetes Ingress Controller à partir de la source.
À l'invite, spécifiez le nom de la pile Pulumi à créer (ici, mara
). Il doit être unique dans votre compte Pulumi.
Entrez le nom de la pile Pulumi à utiliser dans tous les projets : mara Source du sous-module trouvée Configuration de tous les projets Pulumi pour utiliser la pile : mara Pile créée « mara » REMARQUE ! Actuellement, le déploiement via kubeconfig ne prend en charge que l’extraction d’images à partir du registre ! Un JWT est requis pour accéder au référentiel NGINX Plus. Cela doit être placé dans un fichier dans le répertoire extras à la racine, dans un fichier nommé jwt.token. Voir https://docs.nginx.com/nginx-ingress-controller/installation/using-the-jwt-token-docker-secret/ pour plus de détails et d'exemples.
Aucun JWT trouvé ; écriture d'un manifeste d'espace réservé REMARQUE ! Lorsque vous utilisez un fichier kubeconfig, vous devez vous assurer que votre environnement est configuré pour se connecter correctement à Kubernetes. Si vous avez plusieurs contextes Kubernetes (ou contextes personnalisés), vous devrez peut-être les supprimer et les remplacer par un simple fichier ~/.kube/config. Ce problème sera résolu dans une prochaine version.
Aux invites, spécifiez le chemin d’accès complet à votre fichier kubeconfig et le nom du cluster. Les voici /maison/<nom d'utilisateur>/.kube/config
et cluster microk8s
.
Fournissez un chemin absolu vers la valeur de votre fichier kubeconfig : /maison/<nom d'utilisateur>/.kube/config
Fournissez la valeur de votre nom de cluster
: cluster microk8s
Tentative de connexion au cluster Kubernetes
Spécifiez le nom de domaine complet (FQDN) du cluster à l’invite suivante. Le script utilise le FQDN à deux fins : pour configurer NGINX Ingress Controller et pour créer le certificat auto-signé (la deuxième utilisation signifie que la valeur ne peut pas être une adresse IP). Si vous remplacez mara.example.com
par un autre FQDN, n'oubliez pas de l'utiliser également dans les étapes suivantes.
Créez un nom de domaine complet pour votre valeur de déploiement : mara.example.com
Spécifiez le mot de passe administrateur Grafana :
Créez un mot de passe pour l'utilisateur administrateur de Grafana ; ce mot de passe sera utilisé pour accéder au tableau de bord Grafana. Il doit s'agir d'une chaîne alphanumérique sans aucun caractère spécial shell ; il est présenté en texte brut en raison des limitations actuelles des secrets Pulumi. Vous aurez besoin de ce mot de passe pour accéder au tableau de bord Grafana.
valeur : <mot de passe>
Une trace du processus d'installation apparaît, affichant les informations suivantes pour chaque étape :
Logstore
signale le début du déploiement d'Elasticsearch)Lorsque l'étape finale (pour Bank of Sirius) est terminée, la trace indique l'adresse IP attribuée au contrôleur d'entrée NGINX par MetalLB (ici192.168.100.100
) et le FQDN que vous avez choisi pour le déploiement (ici mara.example.com
) ainsi que d'autres informations sur le déploiement.
Le processus de démarrage s'est terminé avec succès
Prochaines étapes :
1. Mappez l'adresse IP (192.168.100.100) de votre contrôleur d'entrée avec votre FQDN (mara.example.com).
2. Utilisez le programme ./bin/test-forward.sh pour établir des tunnels que vous pouvez utiliser pour vous connecter aux outils de gestion.
3. Utilisez kubectl, k9s ou le tableau de bord Kubernetes pour explorer votre déploiement.
Pour revoir vos options de configuration, y compris les mots de passe définis, vous pouvez accéder aux secrets pulumi via les commandes suivantes :
Configuration principale : pulumi config -C /jenkins/workspace/jaytest/bin/../pulumi/python/config
Configuration de Bank of Sirius (exemple d'application) : pulumi config -C /jenkins/workspace/jaytest/bin/../pulumi/python/kubernetes/applications/sirius
IP de l'équilibreur de charge K8 : kubectl get services --namespace nginx-ingress
Veuillez consulter la documentation du dépôt github pour plus d'informations
Créez un mappage entre le FQDN et l’adresse IP signalés à l’étape précédente, dans l’outil que vous utilisez pour résoudre les FQDN (tel que le fichier /etc/hosts local ou le serveur DNS).
Vérifiez qu’une demande de déploiement MARA réussit. Incluez l’option -k
pour que curl
accepte un certificat auto-signé. Pour afficher plus d'informations sur le certificat, ajoutez l'option -v
.
$ curl -k -I https://mara.example.com HTTP/1.1 200 OK Serveur : nginx/1.21.5 Date : Jour , JJ Lun AAAA hh:mm:ss TZ Type de contenu : texte/html ; charset=utf-8 Longueur du contenu : 7016 Connexion : keep-alive
Accédez à https://mara.example.com dans un navigateur pour afficher le site Web de la Bank of Sirius. Au moment de la rédaction de cet article, avec de nombreux navigateurs (y compris Firefox et Safari), vous pouvez cliquer en toute sécurité sur l’avertissement qui s’affiche concernant le site utilisant un certificat auto-signé. Nous vous recommandons de ne pas utiliser Chrome : en raison de récents changements de sécurité, il est probable que vous ne puissiez pas accéder au site.
Exécutez le script test-forward.sh
pour configurer la redirection de port Kubernetes afin de pouvoir accéder aux outils de la suite de gestion MARA : Elasticsearch , Grafana , Kibana , Locust et Prometheus . Le script détermine les noms de service appropriés et exécute les commandes kubectl
pour les transmettre aux ports locaux.
Note: Pour que la redirection de port fonctionne correctement, votre navigateur doit être exécuté sur le même système que l'interpréteur de commandes sur lequel vous exécutez cette commande. Dans le cas contraire (parce que vous utilisez un environnement de virtualisation, par exemple), la commande semble réussir, mais la redirection de port ne fonctionne pas réellement. Pour plus d'informations, consultez Accès aux outils de gestion dans MARA dans notre référentiel GitHub.
$ ./bin/test-forward.sh Détails des connexions ==================================== Kibana : http://localhost:5601 Grafana : http://localhost:3000 Locust : http://localhost:8089 Prometheus : http://localhost:9090 Elasticsearch : http://localhost:9200 ==================================== Appuyez sur Ctrl-C pour quitter
C'est ça! Avec ces instructions, un déploiement MARA fonctionnel est opérationnel dans votre environnement en 20 minutes environ. À ce stade, vous pouvez interagir avec l’application Bank of Sirius comme n’importe quelle autre application Kubernetes. Un bon point de départ consiste à utiliser les outils d’observabilité intégrés pour tester le comportement de l’environnement lorsque vous générez différentes quantités de charge avec Locust.
Notre objectif est de rendre MARA aussi utile que possible pour autant d'utilisateurs Kubernetes que possible. Vous n'aimez pas les choix que nous avons faits pour certains composants ? Nous vous encourageons à remplacer vos composants et à ouvrir une demande d'extraction si vous souhaitez partager. N'hésitez pas également à partager vos réflexions et à poser des questions, notamment sur les hypothèses douteuses que nous avons formulées, sur les pages Problèmes et discussions de notre référentiel.
Cet article fait partie d'une série. Au fur et à mesure que nous ajoutons des fonctionnalités à MARA, nous publions les détails sur le blog :
« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."