Les clusters Anthos sur bare metal s'appellent désormais 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 répond aux 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 le poste de travail d'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 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 est une distribution Linux compatible.

Pour obtenir la liste des systèmes d'exploitation Linux compatibles et des versions compatibles, consultez la section Sélectionner votre système d'exploitation. Cette page contient des liens vers les 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. (Vous pouvez savoir si votre système utilise cgroup v2 par la présence du fichier /sys/fs/cgroup/cgroup.controllers.). cgroup v2 n'est compatible qu'en tant que fonctionnalité d'aperçu. Nous vous déconseillons d'utiliser les fonctionnalités en version preview dans des 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 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 la section Gérer Docker en tant qu'utilisateur non racine.
Google Cloud CLI est installé.

Vous allez utiliser les outils kubectl et bmctl pour créer et gérer des clusters. Pour les installer, 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 binaire bmctl ou le package d'images. Pour obtenir des instructions, consultez la page Téléchargements Google Distributed Cloud pour les solutions Bare Metal.

Ressources matérielles requises

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.

Par défaut, les opérations de mise à niveau et de création du cluster utilisent un cluster d'amorçage. L'utilisation d'un cluster d'amorçage entraîne une augmentation significative de l'utilisation du processeur et de la mémoire. 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.

Selon la taille de la base de données etcd et le nombre de nœuds de plan de contrôle, les opérations de sauvegarde et de restauration du cluster consomment une mémoire RAM importante. 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 mémoire 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'accepte que les processeurs et les processeurs virtuels x86-64 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 soit direct, soit 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 de l'interruption de l'accès à Google Cloud, consultez la page 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 du cluster, en tant que 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 IP doit être activé sur le poste de travail administrateur. Sans transfert IP, il est impossible de créer le cluster d'amorçage, 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 `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 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 de sudo aux machines de nœud du cluster pour configurer SSH. Toutefois, pour les connexions utilisateur non racines 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 du 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