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

Prérequis pour le poste 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.

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 contenu Google Cloud, consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

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 seul poste de travail administrateur peut être utilisé pour créer et gérer de nombreux clusters.

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

Système d'exploitation et logiciels

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 la station de travail administrateur. Ce cluster d'amorçage héberge les contrôleurs Kubernetes nécessaires à la création de clusters. Sauf indication contraire, le cluster d'amorçage est supprimé une fois la création du cluster terminée. Le cluster d'amorçage nécessite que Docker récupère les images de conteneur.

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

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

Pour obtenir la liste des versions et des systèmes d'exploitation Linux compatibles, consultez Sélectionner votre système d'exploitation. Cette page contient des liens vers des instructions de configuration, y compris la configuration Docker, pour chaque OS.
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 la version 20.10.0 ou ultérieure. (Vous pouvez savoir si votre système utilise cgroup v2 grâce à la présence du fichier /sys/fs/cgroup/cgroup.controllers).

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 en dehors du répertoire $HOME. Vérifiez que Docker est en mode confinement strict en exécutant snap info --verbose docker | grep confinement sur votre poste de travail administrateur. Si tel est le 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 la section 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 de l'outil gcloud. Les outils de ligne de commande gcloud, kubectl et 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 gcloud pour télécharger le binaire bmctl ou le package d'images. Pour obtenir des instructions, consultez Téléchargements de Google Distributed Cloud pour solution Bare Metal.

Ressources matérielles requises

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.

Par défaut, les opérations de mise à niveau et de création de clusters utilisent un cluster d'amorçage. Lorsque vous utilisez un cluster d'amorçage, 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 une quantité importante 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 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ée
Processeurs/vCPUs^*	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'accepte que les processeurs virtuels x86-64 au niveau de la microarchitecture de processeur v3 (x86-64-v3) et 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 façons de se connecter à 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 section Impact de la 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 qu'root ou en tant qu'utilisateur non racine disposant de droits sudo sans mot de passe.
Accès à l'adresse IP virtuelle du plan de contrôle.

Transfert IP

Le transfert d'adresses IP doit être activé sur le poste de travail administrateur. Sans transfert d'adresses IP, le cluster d'amorçage ne peut pas être créé, ce qui bloque la création du cluster. Si le transfert d'adresses IP est désactivé, un message d'erreur semblable à celui-ci 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 d'adresses IP à l'aide de la commande suivante:

cat /proc/sys/net/ipv4/ip_forward

Une valeur de 1 indique que le transfert d'IP est activé. Si le transfert d'adresses 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 `root` aux nœuds

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/publique sur le poste de travail d'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 du nœud de cluster pour configurer SSH. Toutefois, pour les connexions utilisateur non racine sans mot de passe, vous devez mettre à jour le fichier de configuration du cluster avec le champ spec.nodeAccess.loginUser. Ce champ est commenté par défaut. 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