Planifier votre installation

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

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

Avant de commencer

  1. Lisez À 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 de projet Google Cloud, car vous en aurez besoin ultérieurement.

Présentation de la procédure

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

  1. Configurez 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 vos nœuds de 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 de cluster d'utilisateur et un nœud de calcul du cluster d'utilisateur.

  3. Planifiez votre réseautage. Planifiez les adresses IP de vos machines de nœud, adresses IP virtuelles (VIP) et plages CIDR de services et de 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 poste de travail administrateur

Le poste de travail administrateur héberge les outils et les fichiers de configuration permettant de créer et d'utiliser vos clusters.

Matériel requis

Le poste de travail administrateur nécessite une puissance de calcul, une mémoire et un espace de stockage importants pour exécuter les outils et stocker les ressources associées à la création et à la gestion du cluster.

Assurez-vous que votre poste de travail administrateur répond à la configuration matérielle suivante:

  • Au moins 2 cœurs de processeur
  • 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, 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, le poste de travail administrateur a les mêmes exigences en termes 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 vous assurer que chaque machine utilise la synchronisation temporelle:

  1. Désactivez le pare-feu simple (UFW) 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 exécutez maintenant la version 19.03 ou ultérieure de Docker:

    sudo docker version

    Les versions du client et du 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 synchronisée:

    timedatectl

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

    System clock synchronized: yes

Installer Google Cloud CLI

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

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

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

    gcloud auth login

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

    gcloud config set project PROJECT_ID

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

  3. Vérifiez que vos 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]

Installez kubectl.

Pour installer kubectl:

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

    gcloud components install kubectl

Installez bmctl.

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

Pour installer bmctl sur votre poste de travail administrateur:

  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.100-gke.251/linux-amd64/bmctl .
chmod +x ./bmctl

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

    bmctl version

    La réponse devrait 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 à partir de votre poste de travail administrateur, vous devez disposer de l'accès suivant 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 du cluster, en tant que root ou en tant qu'utilisateur disposant des droits 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 vos nœuds de cluster

Pour l'installation minimale d'un seul cluster d'administrateur non haute disponibilité et d'un seul cluster d'utilisateur non 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 d'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 disposer de la configuration matérielle suivante:

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

Configurer Ubuntu

Configurez Ubuntu sur chaque nœud à l'aide des mêmes instructions que celles utilisées pour le poste de travail administrateur.

Configurer l'accès SSH aux nœuds

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

Voici les grandes étapes de la configuration de 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 le poste 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 sur chaque machine de nœud.

Pour configurer SSH sur des machines exécutant Ubuntu:

  1. Si aucun serveur SSH n'est 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 annulant la mise en commentaire 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 le protocole 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 établir des connexions sécurisées et sans mot de passe entre le poste de travail administrateur et les nœuds, créez une clé SSH sur votre poste 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œuds:

    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 et définissez PasswordAuthentication sur no, puis 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 avec la machine de nœud à partir du poste de travail administrateur (en tant qu'utilisateur racine) sans mot de passe.

Pour vérifier que l'authentification par clé publique fonctionne entre votre poste de travail administrateur et vos nœuds de cluster:

  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éseautage

Lorsque vous installez des clusters, il est important de planifier vos adresses IP et de vous assurer que vous ne créez pas de conflits d'adressage. Votre administrateur réseau pourra peut-être vous aider à trouver les adresses appropriées, même pour cette installation simple. Sans compter les CIDR des pods et des 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 chaque pod et chaque service exécutés sur vos clusters.

Le reste de cette section contient des exemples de valeurs qui fonctionnent pour cette installation dans un réseau fictif. Vos valeurs seront différentes.

Pour cette petite installation, placez votre poste de travail administrateur, votre nœud de cluster d'administrateur et les 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 sont acheminées vers un domaine de couche 2 particulier. Supposons également que votre administrateur réseau indique que vous pouvez utiliser 172.16.20.10 - 172.16.20.12 pour les adresses des machines 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 comportant un poste de travail d'administrateur, un cluster d'administrateur et 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 donne un exemple d'utilisation des adresses IP pour les nœuds de cluster:

Machine Description Adresse IP
Nœud du plan de contrôle du cluster d'administrateur Machine physique servant de nœud de plan de contrôle au cluster d'administrateur 172.16.20.10
Nœud du plan de contrôle du cluster d'utilisateur Machine physique servant de nœud de plan de contrôle au cluster d'utilisateur 172.16.20.11
Nœud de calcul du cluster d'utilisateur Machine physique qui exécute les charges de travail des utilisateurs 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 du cluster d'utilisateur.

Cette plage inclut l'adresse IP virtuelle d'entrée. Ce chevauchement d'adresses IP est obligatoire 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

Outre les 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 plage CIDR à utiliser pour les adresses ClusterIP des services Kubernetes. Utilisez des adresses IP dans l'espace d'adressage privé, comme décrit dans le document 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 des adresses IP, décidez des plages CIDR que vous souhaitez utiliser pour les pods et les services. Sauf indication contraire, 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 les points suivants:

  • La plage CIDR des pods peut être identique pour plusieurs clusters dans le modèle de réseau par défaut en mode îlot.

  • La plage CIDR des services 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, la plage CIDR des pods est probablement plus grande que la plage CIDR des services. Par exemple, la plage de pods suggérée pour un cluster d'utilisateur comporte 2(32-16) = 216 adresses, mais la plage de pods suggérée pour un cluster d'utilisateur ne comporte que 2(32-20) = 212 adresses.

Éviter le chevauchement

Pour éviter tout chevauchement avec 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 la plage de vos pods soit 192.168.0.0/16. Le trafic envoyé depuis un pod vers une adresse de l'une de ces plages est traité comme au sein du 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 des serveurs 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 le 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 décrit dans 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 qui sont automatiquement activées:

  • 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. Aucune
anthos-baremetal-connect L'agent Connect utilise ce compte de service pour maintenir une connexion entre votre cluster et Google Cloud. Cela permet d'accéder au cluster et aux fonctionnalités de gestion de la charge de travail, y compris la console Google Cloud et la passerelle de connexion, 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

Étapes suivantes

Créer des clusters de base