Planifier une installation de base sur votre matériel

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

Cette page s'adresse aux administrateurs, aux architectes et aux opérateurs qui configurent, surveillent et gèrent le cycle de vie de l'infrastructure technologique sous-jacente. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenuGoogle Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

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 la section Choisir un modèle de déploiement.

Avant de commencer

  1. Consultez À propos de Google Distributed Cloud.
  2. Familiarisez-vous avec certains concepts Google Cloud de base, 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' Google Cloud ID de projet, car vous en aurez besoin ultérieurement.

    9. Présentation de la procédure

    La configuration d'une infrastructure minimale comprend les étapes principales 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 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. Consultez les Google Cloud ressources requises. Pour créer des clusters, votre projetGoogle Cloud nécessite des API et des comptes de service Google spécifiques.

    1. Configurer votre station de travail administrateur

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

    Configuration matérielle requise

    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

    Configuration système requise

    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.

    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

    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 de l'heure :

    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 paquets 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 illustré 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 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 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 projetGoogle 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 de Google Distributed Cloud que vous pouvez 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 vous trouvez 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:

      gcloud storage cp gs://anthos-baremetal-release/bmctl/1.32.100-gke.106/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'root ou en tant qu'utilisateur disposant de droits sudo sans mot de passe.

    La section suivante contient des instructions pour configurer le 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

    Configuration matérielle requise

    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

    Configuration système requise

    Chaque machine de nœud doit exécuter une version compatible d'Ubuntu.

    Configurer Ubuntu

    Configurez Ubuntu sur chaque nœud en suivant les mêmes instructions que celles utilisées pour la station de travail administrateur.

    Configurer l'accès SSH aux nœuds

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

    Voici les étapes principales à 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 la station 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 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 et 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 des 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 et partagez cette clé publique avec les nœuds.

    1. Sur votre poste de travail administrateur, générez une paire de clés privée/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 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 la station 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 root) 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, y compris de vous assurer de ne pas créer de conflits d'adressage. Vous devrez peut-être demander à votre administrateur réseau de vous aider à trouver des adresses appropriées, même pour cette installation simple. 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 de VIP 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 service exécuté sur vos clusters.

    Le reste de cette section présente des exemples illustrant les valeurs qui fonctionnent pour 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 de plan de contrôle au 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 (VIP)

    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 selon les 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 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 VIP, vous devez spécifier des adresses pour les pods et les services. Vous devez spécifier 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 la configuration du cluster, comme illustré dans la partie suivante de ce guide.

    Lors de la planification de votre adresse IP, déterminez 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 de 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. Consulter les ressources Google Cloud requises

    Avant de pouvoir créer des clusters, Google Distributed Cloud nécessite qu'un ensemble spécifique d'API Google soit activé 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 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 d'Artifact 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 charge de travail, y compris à la Google Cloud console 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