Les clusters Anthos sur bare metal sont désormais appelés Google Distributed Cloud (logiciel uniquement) pour bare metal. Pour en savoir plus, consultez la présentation du produit.

Cette page a été traduite par l'API Cloud Translation.

Prérequis pour la station de travail administrateur

La station de travail administrateur héberge des outils d'interface de ligne de commande (CLI) et des fichiers de configuration permettant de provisionner les clusters pendant l'installation, ainsi que des outils d'interface de ligne de commande permettant l'interaction avec les clusters provisionnés après l'installation.

Vous devez télécharger et exécuter des outils, tels que bmctl et la Google Cloud CLI, sur le poste de travail administrateur pour interagir avec les clusters et les ressources Google Cloud. La station de travail administrateur héberge les fichiers de configuration pour le provisionnement des clusters lors de l'installation, des mises à niveau et des mises à jour. Après l'installation, la station de travail administrateur héberge les fichiers kubeconfig afin que vous puissiez utiliser kubectl pour interagir avec les clusters provisionnés. Vous pouvez également accéder aux journaux des opérations de clusters critiques sur la station de travail administrateur. Un poste de travail administrateur unique peut être utilisé pour créer et gérer de nombreux clusters.

Assurez-vous que le poste de travail administrateur remplit les conditions préalables décrites dans les sections suivantes.

Système d'exploitation et logiciel

Pour exécuter bmctl et fonctionner en tant que nœud de plan de contrôle, la station de travail administrateur présente les mêmes exigences de système d'exploitation (OS) que les nœuds. La station de travail d'administrateur nécessite Docker, mais celui-ci ne doit pas être utilisé comme environnement d'exécution de conteneur. Lorsque Google Distributed Cloud crée des clusters, il déploie un cluster Kubernetes dans Docker (genre) sur le poste de travail administrateur. Ce cluster d'amorçage héberge les contrôleurs Kubernetes nécessaires à la création des clusters. Sauf indication contraire, le cluster d'amorçage est supprimé lorsque la création du cluster aboutit. Le cluster d'amorçage a besoin de Docker pour extraire les images de conteneurs.

La station de travail administrateur doit répondre aux exigences suivantes pour pouvoir installer un cluster :

Le système d'exploitation fait partie d'une distribution Linux compatible.

Pour obtenir la liste des systèmes d'exploitation Linux compatibles, consultez la page Sélectionner votre système d'exploitation. Cette page contient des liens vers des instructions de configuration, y compris la configuration Docker, pour chaque système d'exploitation.
Docker version 19.03 ou ultérieure Toutefois, si votre système utilise cgroup v2, l'installation de Docker sur votre poste de travail administrateur doit être de version 20.10.0 ou ultérieure. La présence du fichier /sys/fs/cgroup/cgroup.controllers vous permet de savoir si votre système utilise cgroup v2. cgroup v2 n'est compatible qu'en tant que fonctionnalité de preview. Nous vous déconseillons d'utiliser les fonctionnalités en preview dans les environnements de production.

Avertissement :Docker installé par snap est en mode de confinement strict par défaut, ce qui signifie que Docker ne peut pas accéder aux fichiers situés en dehors du répertoire $HOME. Vérifiez que Docker est en mode de confinement strict en exécutant snap info --verbose docker | grep confinement sur votre poste de travail administrateur. Si vous êtes dans ce cas, assurez-vous que le dossier bmctl-workspace se trouve dans le répertoire $HOME.
L'utilisateur non racine est membre du groupe docker (pour obtenir des instructions, consultez Gérer Docker en tant qu'utilisateur non racine).
Google Cloud CLI est installé.

Vous utilisez les outils kubectl et bmctl pour créer et gérer des clusters. Pour installer ces outils, vous avez besoin des outils gcloud et gsutil. Les outils de ligne de commande gcloud, gsutil et kubectl sont des composants de gcloud CLI. Pour obtenir des instructions d'installation, y compris des instructions sur l'installation de composants, consultez la page Installer gcloud CLI.
kubectl est installé. Utilisez la gcloud CLI pour installer kubectl à l'aide de la commande suivante :
```
gcloud components install kubectl
```
bmctl est installé pour la version du cluster que vous créez ou exploitez.

L'installation consiste à utiliser gsutil pour télécharger le fichier binaire ou le package d'images bmctl. Pour obtenir des instructions, consultez la page Google Distributed Cloud pour les téléchargements Bare Metal.

Exigences en ressources matérielles

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.

Par défaut, les opérations de mise à niveau et de création de cluster utilisent un cluster d'amorçage. Lorsqu'un cluster d'amorçage est utilisé, l'utilisation du processeur et de la mémoire augmente considérablement. Si vous comptez utiliser le poste de travail administrateur en tant que nœud de plan de contrôle, utilisez au minimum la quantité de processeurs et de mémoire RAM recommandée pour empêcher les activités de la station de travail administrateur de perturber les opérations du plan de contrôle du cluster.

En fonction de la taille de la base de données etcd et du nombre de nœuds du plan de contrôle, les opérations de sauvegarde et de restauration du cluster consomment beaucoup de RAM. L'estimation approximative de la mémoire RAM requise pour les sauvegardes est de 3 à 5 Gio par nœud de plan de contrôle. Le processus de sauvegarde échoue, car la mémoire est insuffisante. Planifiez vos besoins en termes de RAM en conséquence.

Le tableau suivant indique les exigences matérielles minimales et recommandées pour la station de travail administrateur :

Ressource	Minimum	Recommandé
Processeurs / Processeurs virtuels^*	2 cœurs	4 cœurs
RAM	Ubuntu: 4 Gio RHEL: 6 Gio	Ubuntu: 8 Gio RHEL: 12 Gio
Stockage	128 Gio	256 Gio

^* Google Distributed Cloud n'est compatible qu'avec les processeurs x86-64 et les processeurs virtuels au niveau de la microarchitecture de processeur v3 (x86-64-v3) ou version ultérieure.

Exigences de mise en réseau

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.

L'accès à Google Cloud peut être direct ou via un serveur proxy. Pour en savoir plus sur les différentes méthodes de connexion à Google Cloud, consultez Se connecter à Google. Pour en savoir plus sur la configuration d'un serveur proxy, consultez la section Installer derrière un proxy.

Pour en savoir plus sur les conséquences d'une interruption de l'accès à Google Cloud, consultez la page Impact d'une déconnexion temporaire de Google Cloud.

Accès aux nœuds

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 SSH sans mot de passe à toutes les machines de nœud de cluster en tant que root ou en tant qu'utilisateur non racine disposant des droits sudo sans mot de passe.
Accès à l'adresse IP virtuelle du plan de contrôle.

Transfert IP

Le transfert IP doit être activé sur le poste de travail administrateur. Sans transfert IP, le cluster d'amorçage ne peut pas être créé, ce qui bloque la création du cluster. Si le transfert IP est désactivé, une erreur semblable à la suivante s'affiche lorsque vous tentez de créer un cluster:

Error message: E0202 14:53:25.979322 225917 console.go:110] Error creating cluster: create kind cluster failed: error creating bootstrap cluster: failed to init node with kubeadm: command "docker exec --privileged bmctl-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6" failed with error: exit status 1

Vous pouvez vérifier le paramètre de transfert IP à l'aide de la commande suivante:

cat /proc/sys/net/ipv4/ip_forward

La valeur 1 indique que le transfert IP est activé. Si le transfert IP est désactivé (0), utilisez la commande suivante pour l'activer:

echo '1' | sudo tee /proc/sys/net/ipv4/ip_forward

Configurer l'accès SSH aux nœuds pour `root`

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

Activez l'authentification par mot de passe SSH root sur chaque machine de nœud de cluster 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.
```
# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

...

# Authentication:

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

...

PasswordAuthentication yes
```
Au départ, vous devez activer l'authentification par mot de passe SSH sur les machines distantes du nœud de cluster pour partager les clés de la station de travail administrateur.
Pour appliquer vos modifications de configuration SSH, redémarrez le service SSH :
```
sudo systemctl restart ssh.service
```
Générez une paire de clés privée et publique sur le poste de travail administrateur. Ne définissez pas de phrase secrète pour les clés. Générez les clés à l'aide de la commande suivante :
```
ssh-keygen -t rsa
```
Vous pouvez également utiliser l'accès utilisateur sudo aux machines de nœud de cluster pour configurer SSH. Toutefois, pour les connexions utilisateur sans mot de passe et non racine, vous devez mettre à jour le fichier de configuration du cluster avec le champ spec.nodeAccess.loginUser. Par défaut, ce champ est commenté. Vous pouvez spécifier votre nom d'utilisateur non racine avec loginUser lors de la création du cluster ou à tout moment par la suite. Pour en savoir plus, consultez loginUser.
Ajoutez la clé publique générée aux machines du nœud de cluster :
```
ssh-copy-id -i PATH_TO_IDENTITY_FILE root@CLUSTER_NODE_IP
```
Remplacez les éléments suivants :
- PATH_TO_IDENTITY_FILE : chemin d'accès au fichier contenant la clé publique SSH. Par défaut, le chemin d'accès au fichier d'identité contenant la clé publique est /home/USERNAME/.ssh/id_rsa.pub.
- CLUSTER_NODE_IP : adresse IP de la machine de nœud à laquelle vous ajoutez la clé publique SSH.
Désactivez l'authentification par mot de passe SSH sur les machines de nœud de cluster en définissant PasswordAuthentication sur no dans le fichier sshd_config et en redémarrant le service SSH.
Exécutez la commande suivante sur la station de travail administrateur pour vérifier que l'authentification par clé publique fonctionne entre la station de travail et les machines de nœud.
```
ssh -o IdentitiesOnly=yes -i PATH_TO_IDENTITY_FILE root@CLUSTER_NODE_IP
```
Lorsque SSH est correctement configuré, vous pouvez vous connecter à la machine de nœud depuis la station de travail administrateur (sous root) sans avoir à saisir de mot de passe.

Étapes suivantes

Prérequis associés à la machine de nœud