Planifier votre installation

Cette page est la première partie d'un guide qui présente en quelques étapes une démonstration de faisabilité de la GDCV pour 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 montre comment créer un cluster d'administrateur et un cluster d'utilisateur. L'infrastructure que vous configurez à l'aide de ce guide n'est peut-être pas adaptée à vos besoins de production et cas d'utilisation réels. Pour en savoir plus sur les installations de production, consultez la page Choisir un modèle de déploiement.

Avant de commencer

  1. Consultez l'article À propos de GKE sur une solution Bare Metal.
  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 minimale de l'infrastructure 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 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 du 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œuds, de vos adresses IP virtuelles (VIP), et de vos 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 le poste 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.

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 des clusters.

Assurez-vous que votre poste de travail administrateur dispose de la configuration matérielle requise 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, 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, 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 de l'heure:

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

    sudo ufw disable
sudo ufw status

  2. Supprimez toutes les versions précédentes 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 une version 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 au groupe:

    newgrp docker

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

    timedatectl

    Le résultat 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.

Procédez comme suit sur votre poste de travail administrateur pour configurer la gcloud CLI:

  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 de GKE sur une solution Bare Metal 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:

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

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

    bmctl version

    La réponse doit se présenter comme suit:

    [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 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 root sans mot de passe à toutes les machines des nœuds du cluster via SSH. L'accès SSH peut être direct ou via sudo.

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

2. Configurer les machines des nœuds du cluster

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

  • Machine d'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 requise 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 en suivant les 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 a besoin d'un accès root sans mot de passe à toutes les machines de nœud de cluster via SSH. L'accès root peut être direct ou via sudo.

Voici les grandes étapes de la configuration de SSH pour GKE sur une solution Bare Metal:

  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œuds

  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

GKE sur Bare Metal 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 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 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 du nœud
Désactiver l'authentification par mot de passe sur les machines de nœuds

À 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

Une fois la connexion SSH configurée correctement, vous pouvez établir une connexion SSH à la machine de nœuds à 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, 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 du nœud

3. Planifiez votre réseautage

Lors de l'installation 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 aurez peut-être besoin de votre administrateur réseau pour qu'il vous aide à 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 des 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 : 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 service s'exécutant 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, le nœud du cluster d'administrateur et les nœuds du 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 vous demande d'utiliser 172.16.20.10 - 172.16.20.12 pour les adresses 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 comportant un poste de travail 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 pour le cluster d'administrateur 172.16.20.10
Nœud du plan de contrôle du cluster d'utilisateur Ordinateur physique servant de nœud de plan de contrôle pour le cluster d'utilisateur 172.16.20.11
Nœud de calcul du cluster d'utilisateur Machine physique exécutant les charges de travail de l'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 du cluster d'utilisateur.

Cette plage inclut l'adresse IP virtuelle d'entrée. Ce chevauchement d'adresses IP est une exigence de 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. 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 d'adresses IP, déterminez les plages CIDR que vous souhaitez utiliser pour les pods et les services. Sauf raison 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 île.

  • La plage CIDR des services peut être identique pour plusieurs clusters.

  • En règle générale, dans un cluster, vous avez besoin de plus de pods que de services. Vous avez donc probablement besoin d'une plage CIDR des pods plus grande que celle 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 services 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 votre plage de 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 faisant partie 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

Pour que vous puissiez créer des clusters, GKE sur une solution Bare Metal nécessite l'activation d'un ensemble spécifique d'API Google dans votre projet Google Cloud associé. Pour utiliser les API Google, GKE sur une solution Bare Metal 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 prochaine partie 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 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 GDCV pour Bare Metal utilise ce compte de service pour télécharger des images de conteneurs à partir de Container Registry. Aucune
anthos-baremetal-connect Connect Agent 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 qu'ils puissent 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