Planifier votre installation

Cette page est la première partie d'un guide qui vous explique comment utiliser le logiciel Google Distributed Cloud (anciennement appelé Google Distributed Cloud) pour créer une petite installation de démonstration de faisabilité de clusters GKE sur votre logiciel bare metal. Ce document explique comment configurer un environnement matériel minimal et planifier vos adresses IP. La section Créer des clusters de base vous explique comment créer un cluster d'administrateur et un cluster d'utilisateur.

L'infrastructure que vous configurez à l'aide de ce guide peut ne pas convenir à vos besoins de production et à vos cas d'utilisation réels. Pour en savoir plus sur les installations de production, consultez Choisir un modèle de déploiement.

Avant de commencer

  1. Consultez À propos de Google Distributed Cloud.
  2. Familiarisez-vous avec certains concepts de base de Google Cloud, y compris les projets, les autorisations IAM et les comptes de service.
  3. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  5. Make sure that billing is enabled for your Google Cloud project.

  6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  7. Make sure that billing is enabled for your Google Cloud project.

  8. Notez l'ID du projet Google Cloud, car vous en aurez besoin ultérieurement.

Présentation de la procédure

La configuration d'une infrastructure minimale comprend les étapes principales suivantes :

  1. Configurer votre poste de travail administrateur Configurez un poste de travail administrateur Linux pour les tâches de gestion sur site. Il peut s'agir d'une machine existante ou dédiée, capable de gérer plusieurs clusters.

  2. Configurez les machines de nœud de votre cluster. Configurez au moins trois machines pour les nœuds : un nœud de cluster d'administrateur, un nœud de plan de contrôle du cluster d'utilisateur et un nœud de calcul du cluster d'utilisateur.

  3. Planifiez votre réseau. Planifiez les adresses IP de vos machines de nœud, vos adresses IP virtuelles, et les plages CIDR des services et des pods.

  4. Examinez les ressources Google Cloud requises. Pour créer des clusters, votre projet Google Cloud nécessite des API Google et des comptes de service spécifiques.

1. Configurer votre station de travail administrateur

La station de travail administrateur héberge des outils et des fichiers de configuration permettant de créer et d'utiliser vos clusters.

Matériel requis

La station de travail administrateur nécessite une puissance de calcul, une mémoire et un stockage importants pour exécuter des outils et stocker les ressources associées à la création et à la gestion des clusters.

Assurez-vous que votre poste de travail administrateur répond aux exigences matérielles suivantes:

  • Un processeur doté d'au moins 2 cœurs
  • Au moins 4 Gio de RAM
  • Au moins 128 Gio d'espace de stockage

Configurer le système d'exploitation et le logiciel

Sur le poste de travail administrateur, vous installez et configurez les éléments suivants:

  • Configurer Ubuntu

  • Installer gcloud CLI

  • Installer kubectl

  • Installer bmctl

Configurer le système d'exploitation

Pour exécuter bmctl et créer un cluster, la station de travail administrateur présente les mêmes exigences de système d'exploitation (OS) que les nœuds. Chaque machine doit exécuter une version compatible d'Ubuntu, telle qu'Ubuntu 20.04.

Exécutez les commandes suivantes pour mettre à jour les paramètres du pare-feu, installer et configurer Docker, et pour vous assurer que chaque machine utilise la synchronisation horaire:

  1. Désactivez le pare-feu UFW (Uncomplicated Firewall) et vérifiez son état:

    sudo ufw disable
sudo ufw status

  2. Supprimez toute version précédente de Docker, mettez à jour votre gestionnaire de packages et installez la dernière version de Docker :

    sudo apt-get remove docker docker-engine docker.io containerd runc
sudo apt-get update
sudo apt-get install \
  apt-transport-https \
  ca-certificates \
  curl \
  gnupg-agent \
  software-properties-common \
  docker.io

  3. Vérifiez que vous utilisez la version 19.03 ou une version ultérieure de Docker :

    sudo docker version

    Les versions client et serveur doivent être 19.03 ou ultérieures, comme indiqué dans l'exemple de réponse suivant :

    Client:
 Version:           20.10.21
 API version:       1.41
 Go version:        go1.18.1
 ...

Server:
 Engine:
  Version:          20.10.21
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.1
  ...

  4. Créez le groupe docker.

    sudo groupadd docker

  5. Ajoutez-vous au groupe Docker:

    sudo usermod -aG docker $USER

  6. Exécutez la commande suivante pour activer les modifications apportées à votre groupe:

    newgrp docker

  7. Exécutez la commande suivante pour vérifier que l'horloge système est bien synchronisée:

    timedatectl

    La sortie de timedatectl doit contenir l'état suivant :

    System clock synchronized: yes

Installer Google Cloud CLI

Pour installer Google Cloud CLI sur Ubuntu, suivez les instructions de ce guide d'installation.

Pour configurer gcloud CLI sur votre poste de travail administrateur, procédez comme suit :

  1. Connectez-vous pour définir la propriété account de gcloud CLI:

    gcloud auth login

  2. Définissez la propriété project de gcloud CLI :

    gcloud config set project PROJECT_ID

    Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.

  3. Vérifiez que les propriétés account et project sont correctement définies :

    gcloud config list

    Le résultat affiche les valeurs de vos propriétés account et project. Exemple :

    [core]
account = my-name@google.com
disable_usage_reporting = False
project = my-project-1234
Your active configuration is: [default]

Installer kubectl

Pour installer kubectl, procédez comme suit :

  1. Exécutez la commande suivante sur votre poste de travail administrateur :

    gcloud components install kubectl

Installer bmctl

bmctl est l'outil de ligne de commande propriétaire pour Google Distributed Cloud que vous pouvez utiliser pour créer et gérer des clusters.

Pour installer bmctl sur votre poste de travail administrateur, procédez comme suit:

  1. Créez un répertoire baremetal et ajoutez-le à votre chemin d'accès. Si vous êtes dans votre répertoire d'accueil, les commandes sont les suivantes:

    mkdir baremetal
export PATH="$HOME/baremetal:$PATH"

  2. Exécutez la commande suivante pour télécharger la dernière version du fichier binaire bmctl et le rendre exécutable :

    gsutil cp gs://anthos-baremetal-release/bmctl/1.29.200-gke.243/linux-amd64/bmctl .
chmod +x ./bmctl

  3. Vérifiez que bmctl est installé et exécutable:

    bmctl version

    La réponse doit en principe ressembler à ceci :

    [2023-05-12 17:36:16+0000] bmctl version: 1.14.2-gke.11, git commit: 4ff1347446a93925a079000b50437d4ecebcdf3a, build date: Mon Feb 27 14:07:30 PST 2023

Connectivité

La station de travail administrateur doit avoir accès à Google Cloud et à tous vos nœuds de cluster.

Accès à Google Cloud

La station de travail administrateur accède à Google Cloud pour télécharger et installer des outils et des images, traiter les demandes d'autorisation, créer des comptes de service, gérer la journalisation et la surveillance, etc. Vous ne pouvez pas créer de clusters sans accès à Google Cloud.

Accès depuis le poste de travail administrateur

Pour créer et gérer des clusters depuis votre station de travail administrateur, vous devez disposer des accès suivants aux machines de nœud :

  • Connectivité de couche 3 à toutes les machines de nœud de cluster.
  • Accès à l'adresse IP virtuelle du plan de contrôle.
  • Accès SSH sans mot de passe à toutes les machines de nœud de cluster, en tant qu'utilisateur root ou en tant qu'utilisateur disposant de privilèges sudo sans mot de passe.

La section suivante contient des instructions pour configurer SSH sur le poste de travail administrateur et les machines de nœud.

2. Configurer les machines de votre nœud de cluster

Pour l'installation minimale d'un seul cluster d'administrateur standard et d'un seul cluster d'utilisateur à haute disponibilité, vous avez besoin de trois machines:

  • Une machine pour un cluster d'administrateur avec un nœud de plan de contrôle.

  • Deux machines pour un cluster utilisateur avec un nœud de plan de contrôle et un nœud de calcul

Matériel requis

Chaque machine de nœud doit répondre aux exigences matérielles suivantes:

  • Un processeur doté d'au moins 2 cœurs
  • Au moins 4 Gio de RAM
  • Au moins 128 Gio d'espace de stockage

Configurer Ubuntu

Configurez Ubuntu sur chaque nœud en suivant les instructions utilisées pour le poste de travail administrateur.

Configurer l'accès SSH aux nœuds

La station de travail administrateur nécessite un accès SSH sans mot de passe à toutes les machines du nœud de cluster. Vous pouvez configurer SSH en tant que root ou avec un utilisateur disposant des droits sudo sans mot de passe.

Voici les principales étapes à suivre pour configurer SSH pour Google Distributed Cloud:

  1. Installer et configurer SSH sur toutes les machines

  2. Créer des clés SSH et copier la clé publique sur chaque machine de nœud

  3. Désactiver l'authentification par mot de passe sur les machines de nœud

  4. Vérifier l'accès SSH entre la station de travail administrateur et les machines de nœud

Installer et configurer SSH sur toutes les machines

Google Distributed Cloud nécessite une communication SSH sans mot de passe entre le poste de travail administrateur et les nœuds du cluster. Les étapes suivantes doivent être effectuées sur le poste de travail administrateur et chaque machine de nœud.

Pour configurer SSH sur des machines exécutant Ubuntu, procédez comme suit:

  1. Si vous n'avez pas encore de serveur SSH en cours d'exécution, installez-en un maintenant:

    sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh

  2. Activez l'authentification par mot de passe SSH root en supprimant les commentaires ou en ajoutant les lignes PermitRootLogin et PasswordAuthentication dans le fichier /etc/ssh/sshd_config, puis en définissant les valeurs sur yes :

    # Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
...
PasswordAuthentication yes

  3. Définissez un mot de passe racine:

    sudo passwd root

  4. Pour appliquer vos modifications de configuration SSH, redémarrez le service SSH :

    sudo systemctl restart ssh.service

  5. Redémarrez l'ordinateur.

  6. Vérifiez que SSH fonctionne en établissant une connexion SSH à partir d'une autre machine.

Créer des clés SSH et copier la clé publique sur chaque machine de nœud

Pour les connexions sécurisées et sans mot de passe entre la station de travail administrateur et les nœuds, créez une clé SSH sur votre station de travail administrateur et partagez la clé publique avec les nœuds.

  1. Sur votre poste de travail administrateur, générez une paire de clés privée et publique. Ne définissez pas de phrase secrète pour les clés.

    ssh-keygen -t rsa

  2. Sur votre poste de travail administrateur, copiez la clé publique générée sur chacune de vos machines de nœud :

    ssh-copy-id -i PUBLIC_KEY root@CLUSTER_NODE_IP

    Remplacez les éléments suivants :

    • PUBLIC_KEY : chemin d'accès au fichier contenant la clé publique SSH. Par défaut, le chemin d'accès est /home/USERNAME/.ssh/id_rsa.pub.
    • CLUSTER_NODE_IP: adresse IP de la machine de nœud
Désactiver l'authentification par mot de passe sur les machines de nœud

À ce stade, vous n'avez plus besoin d'activer l'authentification par mot de passe.

Pour chaque machine de nœud :

  1. Ouvrez /etc/ssh/sshd_config, définissez PasswordAuthentication sur no et enregistrez le fichier.

  2. Redémarrez le service SSH.

    sudo systemctl restart ssh.service
Vérifier l'accès SSH entre le poste de travail administrateur et les machines de nœud

Lorsque SSH est correctement configuré, vous pouvez établir une connexion SSH à la machine de nœud depuis la station de travail administrateur (en tant que racine) sans mot de passe.

Pour vérifier le fonctionnement de l'authentification par clé publique entre votre poste de travail administrateur et vos nœuds de cluster, procédez comme suit:

  1. Sur le poste de travail administrateur, exécutez la commande suivante pour chaque machine de nœud :

    ssh -o IdentitiesOnly=yes -i PRIVATE_KEY root@CLUSTER_NODE_IP

    Remplacez les éléments suivants :

    • PRIVATE_KEY : chemin d'accès au fichier contenant la clé privée SSH Par défaut, le chemin d'accès est /home/USERNAME/.ssh/id_rsa.
    • CLUSTER_NODE_IP: adresse IP de la machine de nœud

3. Planifier votre réseau

Lors de l'installation de clusters, il est important de planifier vos adresses IP et de vous assurer de ne pas créer de conflits d'adressage. Vous aurez peut-être besoin de votre administrateur réseau pour vous aider à trouver les adresses appropriées, même pour cette simple installation. Sans compter les CIDR de pods et de services, vous avez besoin d'au moins 15 adresses IP uniques pour une installation minimale de cluster d'administrateur et de cluster d'utilisateur.

Planifiez et spécifiez les adresses IP pour les composants de cluster suivants:

  • Nœuds de cluster: vous avez besoin d'une adresse IP pour chaque machine de nœud
  • Adresses IP virtuelles (VIP): vous avez besoin d'adresses IP virtuelles pour accéder aux serveurs d'API Kubernetes, au proxy d'entrée et aux services de type LoadBalancer.
  • Pods et services : vous avez besoin de plages d'adresses CIDR pour accueillir tous les pods et services exécutés sur vos clusters.

Le reste de cette section contient des exemples de valeurs compatibles avec cette installation dans un réseau hypothétique. Vos valeurs seront différentes.

Pour cette petite installation, placez votre poste de travail administrateur, votre nœud de cluster d'administrateur et vos nœuds de cluster d'utilisateur dans le même domaine de couche 2. Par exemple, supposons que toutes les adresses IP de la plage 172.16.20.0/24 soient acheminées vers un domaine de couche 2 particulier. Supposons également que votre administrateur réseau vous indique que vous pouvez utiliser 172.16.20.10-172.16.20.12 pour les adresses de machine de nœud et 172.16.0.13-172.16.20.24 pour les adresses IP virtuelles.

Le schéma suivant illustre un domaine de couche 2 doté d'un poste de travail d'administrateur, d'un cluster d'administrateur et d'un cluster d'utilisateur:

Adresses IP pour un cluster d'administrateur et un cluster d'utilisateur. 
Adresses IP pour un cluster d'administrateur et un cluster d'utilisateur (cliquez pour agrandir)

Exemples d'adresses IP de nœuds de cluster

Le tableau suivant montre comment les adresses IP peuvent être utilisées pour les nœuds de cluster :

Machine Description Adresse IP
Nœud du plan de contrôle du cluster d'administrateur Machine physique qui sert de nœud de plan de contrôle pour le cluster d'administrateur 172.16.20.10
Nœud du plan de contrôle du cluster d'utilisateur Machine physique qui sert de nœud du plan de contrôle pour le cluster d'utilisateurs 172.16.20.11
Nœud de calcul du cluster d'utilisateur Machine physique qui exécute les charges de travail d'utilisateur 172.16.20.12

Exemples d'adresses IP virtuelles

Le tableau suivant montre comment spécifier des adresses IP virtuelles pour vos clusters:

VIP Description Adresse IP
Adresse IP virtuelle du plan de contrôle du cluster d'administrateur Adresse IP virtuelle du plan de contrôle du cluster d'administrateur (serveur d'API Kubernetes du cluster d'administrateur) 172.16.20.13
Adresse IP virtuelle du plan de contrôle du cluster d'utilisateur Adresse IP virtuelle du plan de contrôle du cluster d'utilisateur (serveur d'API Kubernetes du cluster d'utilisateur) 172.16.20.14
Adresse IP virtuelle d'entrée Adresse IP virtuelle d'entrée (incluse dans la plage du pool d'adresses MetalLB) 172.16.20.15
Adresses IP virtuelles de service Dix adresses à utiliser comme adresses IP externes pour les services de type LoadBalancer. Les adresses sont allouées en fonction des besoins sur les nœuds de cluster d'utilisateur.

Cette plage inclut l'adresse IP virtuelle d'entrée. Ce chevauchement d'adresses IP est une exigence pour MetalLB, l'équilibreur de charge groupé par défaut.

 172.16.20.15 - 172.16.20.24

Adresses IP pour les pods et les services

En plus des adresses IP que vous avez spécifiées pour les nœuds de cluster et les adresses IP virtuelles, vous devez spécifier des adresses pour les pods et les services. Vous spécifiez une plage CIDR à utiliser pour les adresses IP des pods et une autre à utiliser pour les adresses ClusterIP des services Kubernetes. Utilisez des adresses IP dans l'espace d'adressage privé, comme décrit dans la RFC 1918. Ces adresses sont spécifiées dans le cadre de la configuration du cluster, comme illustré dans la partie suivante de ce guide.

Dans le cadre de la planification de vos adresses IP, choisissez les plages CIDR que vous souhaitez utiliser pour les pods et les services. Sauf indication contraire de votre part, utilisez les plages suggérées suivantes:

Objectif Plage CIDR pré-remplie
Pods du cluster d'administrateur 192.168.0.0/16
Services du cluster d'administrateur 10.96.0.0/20
Pods du cluster d'utilisateur 192.168.0.0/16
Services du cluster d'utilisateur 10.96.0.0/20

Les plages suggérées illustrent ces points:

  • La plage CIDR du pod peut être identique pour plusieurs clusters dans le modèle réseau par défaut, en mode île.

  • La plage CIDR du service peut être identique pour plusieurs clusters.

  • Généralement, vous avez besoin de plus de pods que de services dans un cluster. Par conséquent, vous souhaiterez probablement une plage CIDR de pods plus grande que la plage CIDR de service. Par exemple, la plage de pods suggérée pour un cluster d'utilisateur comporte 2(32-16) = 216 adresses, mais la plage de services suggérée pour un cluster d'utilisateur ne comporte que 2(32-20) = 212 adresses.

Éviter le chevauchement

Pour éviter le chevauchement des adresses IP accessibles sur votre réseau, vous devrez peut-être utiliser des plages CIDR différentes des suggestions précédentes. Les plages de services et de pods ne doivent chevaucher aucune adresse en dehors du cluster que vous souhaitez atteindre depuis l'intérieur du cluster.

Par exemple, supposons que votre plage de services soit 10.96.232.0/24 et que votre plage de pods soit 192.168.0.0/16. Le trafic envoyé depuis un pod vers une adresse dans l'une de ces plages est traité comme étant dans un cluster et ne peut atteindre aucune destination en dehors du cluster.

En particulier, les plages de services et de pods ne doivent pas chevaucher les éléments suivants :

  • Adresses IP des nœuds d'un cluster

  • Adresses IP utilisées par les machines des équilibreurs de charge

  • Adresses IP virtuelles utilisées par les nœuds de plan de contrôle et les équilibreurs de charge

  • Adresse IP des serveurs DNS ou NTP

4. Examiner les ressources Google Cloud requises

Avant de pouvoir créer des clusters, Google Distributed Cloud nécessite l'activation d'un ensemble spécifique d'API Google dans votre projet Google Cloud associé. Pour utiliser les API Google, Google Distributed Cloud nécessite des comptes de service configurés avec des rôles IAM spécifiques dans votre projet Google Cloud associé.

Le processus de création de clusters de la partie suivante de ce guide, Créer des clusters de base, active les API et crée automatiquement des comptes de service.

Voici les API Google activées automatiquement:

  • anthos.googleapis.com
  • anthosaudit.googleapis.com
  • anthosgke.googleapis.com
  • cloudresourcemanager.googleapis.com
  • connectgateway.googleapis.com
  • container.googleapis.com
  • gkeconnect.googleapis.com
  • gkehub.googleapis.com
  • gkeonprem.googleapis.com
  • iam.googleapis.com
  • logging.googleapis.com
  • monitoring.googleapis.com
  • opsconfigmonitoring.googleapis.com
  • serviceusage.googleapis.com
  • stackdriver.googleapis.com
  • storage.googleapis.com

Le tableau suivant décrit les comptes de service créés automatiquement:

Compte de service Objectif Rôles
anthos-baremetal-gcr Google Distributed Cloud utilise ce compte de service pour télécharger des images de conteneurs à partir de Container Registry. Aucun
anthos-baremetal-connect L'agent Connect utilise ce compte de service pour maintenir une connexion entre votre cluster et Google Cloud. Vous pouvez ainsi accéder au cluster et aux fonctionnalités de gestion de la charge de travail, y compris à la console Google Cloud et à la passerelle Connect pour interagir avec votre cluster. roles/gkehub.connect
anthos-baremetal-register L'agent Connect utilise ce compte de service pour enregistrer vos clusters auprès d'un parc. roles/gkehub.admin
anthos-baremetal-cloud-ops L'agent Stackdriver utilise ce compte de service pour exporter les journaux et les métriques des clusters vers Cloud Logging et Cloud Monitoring. roles/logging.logWriter
roles/monitoring.metricWriter
roles/stackdriver.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

Étape suivante

Créer des clusters de base