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.

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 d'administrateur 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 des clusters Anthos sur bare metal créent des clusters, ils déploient 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 de votre part, le cluster d'amorçage est supprimé une fois le cluster créé. Le cluster d'amorçage nécessite que Docker extraie des 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 et des versions 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

  • Un utilisateur non racine est un 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 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 package binaire ou d'images bmctl. Pour obtenir des instructions, consultez la page Téléchargements des clusters Anthos sur bare metal.

Ressources matérielles requises

Le poste de travail administrateur nécessite une puissance de calcul, de la mémoire et de l'espace de stockage considérables 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 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 RAM en conséquence.

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

Ressource Minimum Recommandations
Processeurs / Processeurs virtuels* 2 cœurs 4 cœurs
Mémoire RAM Ubuntu : 4 Gio
CentOS/RHEL : 6 Gio		 Ubuntu : 8 Gio
CentOS/RHEL : 12 Gio
Stockage 128 Gio 256 Gio

* Les clusters Anthos sur solution Bare Metal sont uniquement compatibles avec les processeurs et les processeurs virtuels de la famille de processeurs x86.

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éder à Google Cloud.

L'accès à Google Cloud peut être direct ou via un serveur proxy. Pour en savoir plus sur les différentes manières 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 section 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 sans mot de passe root à toutes les machines de nœud de cluster via SSH. L'accès SSH peut être direct ou via sudo.
  • Accès à l'adresse IP virtuelle du plan de contrôle.

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.

  1. 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.

  2. Pour appliquer vos modifications de configuration SSH, redémarrez le service SSH :

    sudo systemctl restart ssh.service

  3. 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 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. 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.

  4. 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 ~/.ssh/id_rsa.pub.
    • CLUSTER_NODE_IP : adresse IP de la machine de nœud à laquelle vous ajoutez la clé publique SSH.

  5. Désactivez l'authentification par mot de passe SSH sur les machines des nœuds du cluster en mettant en commentaire la ligne PasswordAuthentication dans le fichier sshd_config et en redémarrant le service SSH.

  6. 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