Prérequis pour le poste de travail administrateur

Le poste de travail administrateur héberge les outils d'interface de ligne de commande (CLI) et les fichiers de configuration permettant de provisionner les clusters pendant l'installation, et les outils CLI pour interagir avec les clusters provisionnés après l'installation.

Vous pouvez télécharger et exécuter des outils tels que bmctl et Google Cloud CLI sur le poste de travail administrateur pour interagir avec les clusters et les ressources Google Cloud. Le poste de travail administrateur héberge les fichiers de configuration pour provisionner les clusters lors de l'installation, des mises à niveau et des mises à jour. Après l'installation, le poste de travail administrateur héberge des fichiers kubeconfig. Vous pouvez ainsi utiliser kubectl pour interagir avec les clusters provisionnés. Vous accédez également aux journaux des opérations critiques de cluster sur le poste de travail administrateur.

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

Système d'exploitation et logiciels

Pour pouvoir exécuter bmctl et travailler en tant que nœud de plan de contrôle, le poste de travail administrateur doit répondre aux mêmes exigences de système d'exploitation que les nœuds. Le poste de travail administrateur nécessite Docker, mais ne peut pas être utilisé comme environnement d'exécution de conteneur. Lorsque des clusters Anthos sur solution Bare Metal créent des clusters, il déploie un cluster Kubernetes in Docker (kind) sur le poste de travail administrateur. Ce cluster bootstrap 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 conteneurs.

Le poste de travail administrateur doit répondre aux exigences suivantes pour que vous puissiez 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 un 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 est installé.

  • 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 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 les instructions d'installation des composants, consultez Installer la CLI gcloud.

  • kubectl est installé. Utilisez 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 à télécharger gsutil à l'aide d'un package binaire ou d'images bmctl. Pour obtenir des instructions, consultez la page sur les clusters Anthos sur solution Bare Metal.

Ressources matérielles requises

Le poste 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 de 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 avez l'intention d'utiliser le poste de travail administrateur comme nœud du plan de contrôle, n'utilisez pas au moins la quantité recommandée de processeurs et de mémoire RAM pour empêcher les activités du poste de travail administrateur de perturber les fonctions du plan de contrôle du cluster.

Selon la taille de la base de données etcd et le 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 de la RAM nécessaire 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 la configuration matérielle minimale et recommandée pour le poste de travail administrateur:

Ressource Minimum Recommandé
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

Exigences de mise en réseau

Le poste de travail administrateur doit avoir accès à Google Cloud et à tous les nœuds de votre cluster.

Accès à Google Cloud

Le poste de travail administrateur accède à Google Cloud pour télécharger et installer des images et des outils, traiter des requêtes 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 la page Se connecter à Google. Pour en savoir plus sur la configuration d'un serveur proxy, consultez la page 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 d'une déconnexion temporaire de Google Cloud.

Accès aux nœuds

Pour créer et gérer des clusters à partir de votre poste de travail administrateur, vous devez disposer de l'accès suivant aux machines de nœuds:

  • Connectivité de couche 3 à toutes les machines de nœud de cluster.
  • Accès root sans mot clé à toutes les machines de nœuds 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 des connexions sans mot de passe sécurisées entre le poste de travail administrateur et les machines de nœud de cluster, créez une clé SSH sur votre poste de travail administrateur et partagez la clé publique avec les nœuds du cluster.

  1. Activez l'authentification par mot de passe SSH root sur chaque machine de nœud de cluster en annulant la mise en commentaire des lignes PermitRootLogin et PasswordAuthentication dans le fichier /etc/ssh/sshd_config, puis définissez 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

    Dans un premier temps, vous devez activer l'authentification par mot de passe SSH sur les machines de nœud du cluster distant pour partager des clés depuis le poste 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 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 à l'aide de 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 de 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 de nœud de cluster en commentant la ligne PasswordAuthentication dans le fichier sshd_config et en redémarrant le service SSH.

  6. Utilisez la commande suivante sur le poste de travail administrateur pour vérifier que l'authentification par clé publique fonctionne entre le poste de travail et les machines de nœud.

    ssh -o IdentitiesOnly=yes -i PATH_TO_IDENTITY_FILE root@CLUSTER_NODE_IP

    WheN SSH est correctement configuré. Vous pouvez vous connecter à la machine de nœud à partir du poste de travail administrateur (en tant que root) sans avoir à saisir de mot de passe.

Étapes suivantes