Déployer des clusters en périphérie à grande échelle avec Anthos sur solution Bare Metal
Cet article présente une solution avancée et prête à l'emploi pour les opérateurs et développeurs de plates-formes qui exploitent Anthos sur solution Bare Metal et Anthos Config Management pour déployer des clusters Kubernetes en périphérie à grande échelle. Pour les besoins de ce guide, nous partons du principe que vous connaissez les éléments suivants :
- Playbooks Ansible
- Déploiements en périphérie et défis associés
- Utilisation d'un projet Google Cloud
- Interfaces de ligne de commande
gcloudetkubectl
Vous trouverez les scripts qui configurent l'infrastructure Bare Metal dans le dépôt anthos-samples. Les scripts vous permettent de répliquer ce déploiement et de le personnaliser en fonction de vos besoins. Le code source de l'application qui constitue la charge de travail de périphérie est hébergé dans le dépôt point-of-sale.
À propos des déploiements en périphérie
L'une des caractéristiques clés de l'exploitation à grande échelle est de disposer d'un plan de gestion centralisé pour toutes les parties de la plate-forme. Les entreprises qui se développent au-delà des centres de données traditionnels dans des emplacements périphériques ont toutefois des exigences uniques. Les déploiements en périphérie doivent exécuter leurs charges de travail de manière isolée, recevoir des mises à jour au plus vite, signaler des métriques critiques et être conçus pour permettre l'expansion à d'autres emplacements périphériques à l'avenir. Anthos sur solution Bare Metal est la réponse de Google pour ces exigences de déploiement en périphérie à grande échelle.
À partir de la version 1.8, les clusters Anthos sur solution Bare Metal sont dotés d'un profil de périphérie. Celui-ci minimise les besoins en ressources système et est recommandé pour les appareils de périphérie présentant de contraintes importantes. Le profil de périphérie n'est disponible que pour les clusters autonomes. Les clusters autonomes sont des clusters autogérés qui exécutent des charges de travail. Ils ne gèrent pas d'autres clusters, ce qui élimine le besoin d'exécuter un cluster d'administrateur distinct dans les scénarios à ressources limitées. Le profil de périphérie fournit des exigences minimales pour les processeurs virtuels et la mémoire RAM, à l'exception des charges de travail de l'utilisateur. Le profil de périphérie Anthos sur solution Bare Metal offre les avantages suivants :
- Réduction de 75 % des besoins en processeur à 1 nœud x 2 processeurs virtuels au lieu de 2 nœuds x 4 processeurs virtuels.
- Réduction de 90 % des besoins en mémoire à 1 nœud x 4 Gio au lieu de 2 nœuds x 32 Gio pour Ubuntu.
Pour en savoir plus sur la configuration d'un cluster avec le profil de périphérie, consultez la page Créer des clusters autonomes. Le tableau suivant montre comment la configuration système minimale requise pour Anthos sur solution Bare Metal a été réduite pour offrir un encombrement minimal compatible avec les appareils de périphérie.
| Anthos 1.7 | Anthos 1.8 et versions ultérieures | Anthos 1.8 et versions ultérieures avec le profil de périphérie | |
|---|---|---|---|
| Processeur | 2 nœuds x (4 processeurs virtuels) | 1 nœud x (4 processeurs virtuels) | 1 nœud x (2 processeurs virtuels) |
| RAM | 2 nœuds x (32 Gio de RAM) | 1 nœud x (16 Gio de RAM) | 1 nœud x (4 Gio de RAM Ubuntu) 1 nœud x (6 Gio de RAM RHEL/CentOS) |
| Stockage | 2 nœuds x (128 Gio) | 1 nœud x (128 Gio) | 1 nœud x (128 Gio) |
Dans les sections suivantes, vous allez utiliser des VM Compute Engine et un exemple d'application de point de vente en tant que charge de travail de périphérie pour émuler des nœuds déployés en périphérie. Les clusters Anthos sur solution Bare Metal et Anthos Config Management fournissent une gestion et un contrôle centralisés pour votre cluster de périphérie. Anthos Config Management extrait de manière dynamique de nouvelles configurations de GitHub, et applique ces règles et configurations à vos clusters.
Schéma de l'architecture d'un déploiement en périphérie
Le schéma suivant présente l'architecture d'un déploiement en périphérie, en montrant comment l'application est exécutée sur Anthos sur solution Bare Metal et gérée par Anthos Config Management. Dans le schéma, ABM fait référence à Anthos sur solution Bare Metal et ACM fait référence à Anthos Config Management.
Schéma de l'architecture d'une charge de travail en périphérie
Le schéma suivant illustre l'architecture de la charge de travail d'une application de point de vente simple que nous utilisons dans ce guide. Il décrit également comment l'application est déployée dans des clusters Anthos sur solution Bare Metal dans un emplacement périphérique émulé. Les VM Compute Engine sont semblables aux nœuds qui s'exécutent en périphérie.
Workflow de la solution
Dans cette solution, nous allons effectuer les opérations suivantes :
- Émuler une infrastructure Bare Metal exécutée dans un emplacement périphérique à l'aide de VM Compute Engine
- Déployer un cluster Anthos sur solution Bare Metal sur l'infrastructure périphérique émulée
- Connecter et enregistrer le cluster Anthos sur solution Bare Metal avec Google Cloud
- Déployer un exemple de charge de travail d'application de point de vente sur le cluster Anthos sur solution Bare Metal
- Vérifier et surveiller l'application exécutée en périphérie via Cloud Console
- Utiliser Anthos Config Management pour mettre à jour l'application exécutée sur le cluster Anthos sur solution Bare Metal
Ce guide peut prendre 55 à 60 minutes si vous avez déjà configuré tous les prérequis (répertoriés dans la section Avant de commencer ci-après).
Avant de commencer
Pour effectuer le déploiement en périphérie décrit dans ce guide, vous devez disposer des éléments suivants :
Une station de travail avec un accès à Internet et les outils suivants installés. Vous exécutez toutes les commandes du guide sur cette station de travail :
- Google Cloud CLI
- Python (version 2.7 ou ultérieure)
- Outil d'interface de ligne de commande Ansible
- Outil d'interface de ligne de commande envsubst (généralement préinstallé sous Linux et d'autres systèmes d'exploitation de type Unix)
- Modules Python (installés avec
pip2 install) :- ansible
- dnspython
- requêtes
- google-auth
Un projet Google Cloud.
Configurer l'environnement de la station de travail
Dupliquez le dépôt anthos-samples pour créer votre propre copie du code source pour cette solution de déploiement en périphérie. Pour obtenir plus d'informations sur la duplication, y compris des instructions permettant de dupliquer un dépôt, consultez la page Dupliquer un dépôt.
Créez un jeton d'accès personnel pour votre dépôt dupliqué, comme décrit dans la documentation GitHub Créer un jeton d'accès personnel.
- Sélectionnez uniquement le niveau d'accès
public_repo. - Enregistrez le jeton d'accès que vous avez créé dans un endroit sûr, car vous en aurez besoin ultérieurement.
- Sélectionnez uniquement le niveau d'accès
Clonez votre dépôt dupliqué sur votre station de travail.
git clone https://github.com/GITHUB_USERNAME/anthos-samples cd anthos-samples/anthos-bm-edge-deployment- Remplacez
GITHUB_USERNAMEpar votre nom d'utilisateur GitHub.
- Remplacez
Initialisez les variables d'environnement dans une nouvelle instance d'interface système.
export PROJECT_ID="PROJECT_ID" export REGION="us-central1" export ZONE="us-central1-a" # path to which the Google Service Account key file is downloaded to export LOCAL_GSA_FILE="$(pwd)/remote-gsa-key.json" # port on the admin Compute Engine instance we use to set up an nginx proxy to allow traffic into the Anthos on bare metal cluster export PROXY_PORT="8082" # should be a multiple of 3 since N/3 clusters are created with each having 3 nodes export MACHINE_COUNT="3" # url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples" # this is the username used to authenticate to your fork of this repository export SCM_TOKEN_USER="GITHUB_USERNAME" # access token created in the earlier step export SCM_TOKEN_TOKEN="ACCESS_TOKEN"PROJECT_ID: ID de votre projet Google Cloud.GITHUB_USERNAME: votre nom d'utilisateur GitHub.ACCESS_TOKEN: jeton d'accès personnel que vous avez créé pour votre dépôt GitHub.
Initialisez Google Cloud CLI.
gcloud config set project "${PROJECT_ID}" gcloud services enable compute.googleapis.com gcloud config set compute/region "${REGION}" gcloud config set compute/zone "${ZONE}"Créez le compte de service Google Cloud utilisé par les instances Compute Engine.
# when prompted "Create a new key for GSA? [y/n]" type "y" and press the return key # the service account key file is downloaded to the path referred to by $LOCAL_GSA_FILE ./scripts/create-primary-gsa.sh
Provisionner les instances Compute Engine
Créez des clés SSH et des instances Compute Engine sur lesquelles Anthos sur solution Bare Metal est installé.
# press the return key when asked for a passphrase for the SSH key (i.e. empty string) ./scripts/cloud/easy-install.shTestez la connectivité SSH aux instances Compute Engine.
# If the checks fail the first time with errors like # "sh: connect to host cnuc-1 port 22: Connection refused", # then wait a few seconds and retry for i in `seq $MACHINE_COUNT`; do HOSTNAME="cnuc-$i" ssh abm-admin@${HOSTNAME} 'ping -c 3 google.com' doneLorsque les scripts s'exécutent correctement, ils génèrent un résultat semblable au suivant :
PING google.com (74.125.124.113) 56(84) bytes of data. 64 bytes from jp-in-f113.1e100.net (74.125.124.113): icmp_seq=1 ttl=115 time=1.10 ms 64 bytes from jp-in-f113.1e100.net (74.125.124.113): icmp_seq=2 ttl=115 time=1.10 ms 64 bytes from jp-in-f113.1e100.net (74.125.124.113): icmp_seq=3 ttl=115 time=0.886 ms --- google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.886/1.028/1.102/0.100 ms PING google.com (108.177.112.139) 56(84) bytes of data. ... ...
Installer Anthos sur solution Bare Metal avec Ansible
Le script utilisé dans ce guide crée des clusters Anthos sur solution Bare Metal dans des groupes de trois instances Compute Engine. Par exemple, vous définissez la variable d'environnement MACHINE_COUNT sur 6 pour créer deux clusters Anthos sur solution Bare Metal comportant chacun trois instances. Le nom des instances doit commencer par le préfixe cnuc-, suivi d'un numéro. La première instance de chaque cluster agit en tant qu'instance d'administration à partir de laquelle l'installation d'Anthos sur solution Bare Metal est déclenchée. Les clusters d'utilisateur Anthos sur solution Bare Metal tiennent également leur nom de ces instances d'administration (par exemple, cnuc-1, cnuc-4, cnuc-7).
Le playbook Ansible effectue les opérations suivantes :
- Il configure les instances Compute Engine avec les outils nécessaires, tels que
docker,bmctl,gcloudetnomos. - Il installe Anthos sur solution Bare Metal sur les instances Compute Engine configurées.
- Il crée un cluster d'utilisateur Anthos sur solution Bare Metal appelé
cnuc-1. - Il enregistre le cluster
cnuc-1à l'aide de Google Cloud. - Il installe Anthos Config Management dans le cluster
cnuc-1. - Il configure Anthos Config Management pour se synchroniser avec les configurations de cluster situées dans
anthos-bm-edge-deployment/acm-config-sinkdans votre dépôt dupliqué.
Suivez ces étapes pour configurer et lancer le processus d'installation.
Générez le fichier d'inventaire Ansible à partir du modèle.
# replace environment variables in the template envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yamlVérifiez la configuration de la station de travail et l'accès aux hôtes Compute Engine.
# verify workstation environment setup ./scripts/verify-pre-installation.sh # verify access to hosts ./scripts/health-check.shLorsque les scripts s'exécutent correctement, ils génèrent un résultat semblable au suivant :
Proceed!! cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"} cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"} cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"} SUCCESS!!Exécutez le playbook Ansible pour installer Anthos sur solution Bare Metal sur des instances Compute Engine.
ansible-playbook -i inventory cloud-full-install.yamlLorsque les scripts s'exécutent correctement, ils génèrent un résultat semblable au suivant :
... ... PLAY RECAP ******************************************************************************************************** cnuc-1 : ok=136 changed=106 unreachable=0 failed=0 skipped=33 rescued=0 ignored=8 cnuc-2 : ok=86 changed=67 unreachable=0 failed=0 skipped=71 rescued=0 ignored=2 cnuc-3 : ok=86 changed=67 unreachable=0 failed=0 skipped=71 rescued=0 ignored=2
Se connecter au cluster Anthos sur solution Bare Metal dans Cloud Console
Pour copier le script utilitaire dans l'instance d'administration Compute Engine et générer un jeton de compte de service Kubernetes, exécutez les scripts et les commandes suivants.
# Copy the utility script into the admin node of the cluster scp -i ~/.ssh/cnucs-cloud scripts/cloud/cnuc-k8s-login-setup.sh abm-admin@cnuc-1: # Use SSH to connect to the admin node of the cluster ssh -i ~/.ssh/cnucs-cloud abm-admin@cnuc-1 # execute the script and copy token that is printed out ./cnuc-k8s-login-setup.shLorsque les scripts s'exécutent correctement, ils génèrent un résultat semblable au suivant :
... ... 💡 Retrieving Kubernetes Service Account Token 🚀 ------------------------------TOKEN-------------------------------- 🚀 eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eyJpc3MiOiJrdW mljZS1hY2NvdW50LnVpZCI6IjQwYWQxNDk2LWM2MzEtNDhiNi05YmUxLWY5YzgwODJjYzgzOSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYW iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3Nl cnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZWRnYS1zYSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2Vyd 4CwanGlof6s-fbu8IUy1_bTgCminylNKb3VudC5uYW1lIjoiZWRnYS1zYSIsImt1YmVybmV0ZXuaP-hDEKURb5O6IxulTXWH6dxYxg66x Njb3VudDpkZWZhdWx0OmVkZ2Etc2EifQ.IXqXwX5pg9RIyNHJZTM6cBKTEWOMfQ4IQQa398f0qwuYlSe12CA1l6P8TInf0S1aood7NJWx xe-5ojRvcG8pdOuINq2yHyQ5hM7K7R4h2qRwUznRwuzOp_eXC0z0Yg7VVXCkaqnUR1_NzK7qSu4LJcuLzkCYkFdSnvKIQABHSvfvZMrJP Jlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3V MgyLOd9FJyhZgjbf-a-3cbDci5YABEzioJlHVnV8GOX_q-MnIagA9-t1KpHA 🚀 ------------------------------------------------------------------- 🚀Copiez le jeton à partir de la sortie.
Dans Cloud Console, accédez à la page Clusters Kubernetes et utilisez le jeton copié pour vous connecter au cluster
cnuc-1.Accéder à la page des clusters Kubernetes
- Dans la liste des clusters, cliquez sur Actions à côté du cluster
cnuc-1, puis sur Se connecter. - Sélectionnez Jeton et collez le jeton copié.
- Cliquez sur Login (Connexion).
- Dans la liste des clusters, cliquez sur Actions à côté du cluster
Dans Cloud Console, accédez à la page Config Management pour vérifier l'état des spécifications de configuration. Vérifiez que l'état est Synchronisé. Un état Synchronisé indique qu'Anthos Config Management a synchronisé vos configurations GitHub avec votre cluster
cnuc-1déployé.Accéder à la page Config Management
Configurer un proxy pour le trafic externe
Le produit Anthos sur solution Bare Metal installé lors des étapes précédentes utilise un équilibreur de charge groupé appelé MetalLB. Ce service d'équilibrage de charge n'est accessible qu'à l'aide d'une adresse IP de cloud privé virtuel (VPC). Nous avons donc configuré un service de proxy inverse dans l'hôte administrateur (cnuc-1) pour acheminer le trafic entrant vers l'équilibreur de charge groupé via son adresse IP externe. Cela nous permet d'accéder au serveur d'API de l'application de point de vente via l'adresse IP externe de l'hôte administrateur (cnuc-1).
Les scripts d'installation des étapes précédentes auraient déjà installé nginx sur les hôtes administrateur, avec un exemple de fichier de configuration. Nous mettons à jour ce fichier pour utiliser l'adresse IP du service d'équilibrage de charge et redémarrer nginx.
Configurez le proxy inverse nginx pour qu'il achemine le trafic vers le service d'équilibrage de charge du serveur d'API.
# get the IP address of the Load balancer type Kubernetes service ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1) # update the template configuration file with the fetched IP address sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf" # restart nginx to ensure the new configuration is picked up sudo systemctl restart nginx # check and verify the status of the nginx server to be "active (running)" sudo systemctl status nginxLorsque les scripts s'exécutent correctement, ils génèrent un résultat semblable au suivant :
● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago Docs: man:nginx(8) Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 92573 (nginx) Tasks: 17 (limit: 72331) Memory: 13.2M CGroup: /system.slice/nginx.service ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; ├─92574 nginx: worker process ├─92575 nginx: worker process ├─92577 nginx: .... ... ...Quittez la session SSH dans l'instance d'administration.
exit
Accéder à l'application de point de vente
Vous exécutez les commandes suivantes sur votre station de travail locale.
Obtenez l'adresse IP externe de l'instance d'administration Compute Engine et accédez à l'UI de l'application de point de vente.
EXTERNAL_IP=$(gcloud compute instances list --project ${PROJECT_ID} --filter="name:cnuc-1" --format="get(networkInterfaces[0].accessConfigs[0].natIP)") echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"Lorsque les scripts s'exécutent correctement, ils génèrent un résultat semblable au suivant :
Point the browser to: 34.134.194.84:8082
Mettre à jour la version du serveur d'API et observer l'évolution
Mettez à jour le champ
imagepour remplacer la version du serveur d'APIv1parv2. La configuration YAML du déploiement se trouve dans le fichier à l'adresseanthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml.Transférez les modifications vers votre dépôt dupliqué.
git add acm-config-sink/namespaces/pos/api-server.yaml git commit -m "chore: updated api-server version to v2" git pushDans Cloud Console, accédez à la page Config Management pour vérifier l'état des spécifications de configuration. Vérifiez que l'état est Synchronisé.
Dans Cloud Console, accédez à la page Charges de travail Kubernetes Engine pour vérifier que le déploiement est mis à jour.
Lorsque l'état du déploiement est OK, faites pointer votre navigateur vers l'adresse IP de la section précédente pour afficher l'application de point de vente. Notez que la version du titre affiche "V2", ce qui indique que la modification de votre application a été déployée.
Effectuer un nettoyage
Pour éviter d'encourir des frais inutiles liés à Google Cloud, supprimez les ressources utilisées dans ce guide lorsque vous n'en avez plus besoin. Vous pouvez supprimer ces ressources manuellement ou supprimer votre projet Google Cloud, ce qui supprime également toutes les ressources associées. En outre, vous pouvez supprimer les modifications apportées sur votre station de travail locale :
Station de travail locale
Vous devez mettre à jour les fichiers suivants pour supprimer les modifications apportées par les scripts d'installation.
- Supprimez les adresses IP des VM Compute Engine ajoutées au fichier
/etc/hosts. - Supprimez la configuration SSH de
cnuc-*dans le fichier~/.ssh/config. - Supprimez les empreintes des VM Compute Engine du fichier
~/.ssh/known_hosts.
Suppression du projet
Si vous avez créé un projet dédié pour cette procédure, supprimez le projet Google Cloud de Cloud Console.
Manuel
Si vous avez utilisé un projet existant pour cette procédure, procédez comme suit :
- Annulez l'enregistrement de tous les clusters Kubernetes dont le nom commence par le préfixe
cnuc-. - Supprimez toutes les VM Compute Engine dont le nom commence par le préfixe
cnuc-. - Supprimez le bucket Cloud Storage dont le nom commence par le préfixe
abm-edge-boot. - Supprimez les règles de pare-feu
allow-pod-ingressetallow-pod-egress. - Supprimez le secret Secret Manager
install-pub-key.
Étape suivante
Vous pouvez développer ce guide en ajoutant un autre emplacement périphérique. La définition de la variable d'environnement MACHINE_COUNT sur 6 et la réexécution des mêmes étapes que dans les sections précédentes créent trois instances Compute Engine (cnuc-4, cnuc-5, cnuc-6) et un cluster d'utilisateur Anthos sur solution Bare Metal appelé cnuc-4.
Vous pouvez également essayer de mettre à jour les configurations de cluster dans votre dépôt dupliqué pour appliquer de manière sélective différentes versions de l'application de point de vente aux deux clusters, cnuc-1 et cnuc-4, à l'aide de ClusterSelectors.
Pour en savoir plus sur les étapes individuelles du présent guide ainsi que sur les scripts impliqués, consultez le dépôt anthos-samples.