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

Prérequis pour les machines du nœud de cluster

Google Distributed Cloud est compatible avec de nombreux systèmes qui s'exécutent sur le matériel compatible avec les distributions du système d'exploitation cible. Une configuration Google Distributed Cloud peut s'exécuter sur un matériel minimal, ou sur plusieurs machines, offrant ainsi plus de flexibilité, de disponibilité et de performances.

Quelle que soit la configuration de Google Distributed Cloud, vos nœuds et clusters doivent disposer de suffisamment de ressources de processeur, de mémoire RAM et de stockage pour répondre aux besoins des clusters et des charges de travail que vous exécutez.

Cette page s'adresse aux administrateurs, aux architectes et aux opérateurs qui définissent les solutions informatiques et l'architecture du système conformément à la stratégie de l'entreprise. 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.

Configuration minimale requise et recommandée pour le processeur, la mémoire RAM et le stockage

Lorsque vous installez Google Distributed Cloud, vous pouvez créer différents types de clusters:

Un cluster d'utilisateur qui exécute des charges de travail.
Un cluster d'administrateur crée et contrôle des clusters d'utilisateur pour exécuter des charges de travail.
Un cluster autonome est un cluster unique qui peut gérer et exécuter des charges de travail, mais qui ne peut pas créer ni gérer de clusters d'utilisateur.
Un cluster hybride peut gérer et exécuter des charges de travail, et un cluster hybride peut également créer et gérer des clusters d'utilisateur supplémentaires.

En plus du type de cluster, vous pouvez choisir parmi les profils d'installation suivants en termes de besoins en ressources :

Par défaut : le profil par défaut nécessite des ressources système standards. Vous pouvez l'utiliser pour tous les types de clusters.
Périphérie : le profil de périphérie a considérablement réduit les besoins en ressources système. Il est recommandé pour les appareils de périphérie disposant de ressources limitées. Vous ne pouvez utiliser le profil de périphérie que pour les clusters autonomes.

Ressources nécessaires pour tous les types de clusters utilisant le profil par défaut

Le tableau suivant décrit la configuration matérielle minimale recommandée pour que Google Distributed Cloud fonctionne et gère des clusters d'administrateur, hybrides, utilisateur et autonomes qui utilisent le profil par défaut:

Ressource	Minimum	Recommandée
Processeurs/vCPUs^*	4 cœurs	8 cœurs
RAM	16 Gio	32 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.

Ressources nécessaires pour les clusters autonomes utilisant le profil de périphérie

Le tableau suivant décrit la configuration matérielle minimale recommandée pour que Google Distributed Cloud fonctionne et gère des clusters autonomes qui utilisent le profil de périphérie:

Ressource	Minimum	Recommandée
Processeurs/vCPUs^*	2 cœurs	4 cœurs
RAM	Ubuntu: 5 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.

Pour configurer des clusters autonomes à l'aide du profil de périphérie, suivez ces bonnes pratiques :

Exécutez bmctl sur un poste de travail distinct. Si vous devez exécuter bmctl sur le nœud de cluster cible, vous avez besoin de 2 Go de mémoire pour répondre aux exigences minimales. Par exemple, vous avez besoin de 6 Gio pour Ubuntu et de 8 Gio pour RHEL.
Définissez MaxPodsPerNode sur 110. Le cluster n'exécute pas plus de 30 pods utilisateur en moyenne par nœud. Vous aurez peut-être besoin de ressources supplémentaires pour une configuration MaxPodsPerNode plus élevée ou d'exécuter plus de 30 pods utilisateur par nœud.
Les composants de l'environnement d'exécution de VM sur GDC ne sont pas pris en compte dans cette configuration minimale de ressources. L'environnement d'exécution des VM sur GDC nécessite des ressources supplémentaires en fonction du nombre de VM déployées dans le cluster.

Exigences de stockage supplémentaires

Google Distributed Cloud ne fournit aucune ressource de stockage. Vous devez provisionner et configurer l'espace de stockage nécessaire sur votre système.

Pour connaître les exigences de stockage détaillées, consultez la section Présentation des conditions préalables à l'installation.

Pour en savoir plus sur la configuration de l'espace de stockage requis, consultez la page Configurer le stockage pour Google Distributed Cloud.

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

Les machines virtuelles du nœud doivent remplir les conditions suivantes :

Disposer de la configuration matérielle minimale requise.
Le système d'exploitation fait partie des distributions compatibles avec Linux. Pour en savoir plus, y compris sur les exigences du kernel, consultez la section Sélectionner votre système d'exploitation.
Disposer d'un accès à Internet.
Connectivité de couche 3 à toutes les autres machines de nœud.
Accès à l'adresse IP virtuelle du plan de contrôle.
Accès aux ports requis. Pour connaître les exigences de port spécifiques aux nœuds de plan de contrôle, aux nœuds de calcul et aux nœuds d'équilibrage de charge, consultez la section Utilisation des ports sur la page "Exigences réseau".
Disposer de serveurs de noms DNS correctement configurés.
Aucun nom d'hôte en double.
L'un des services NTP suivants est activé et fonctionnel :
- chrony
- ntp
- ntpdate
- systemd-timesyncd
Un gestionnaire de paquets opérationnel, tel que apt ou dnf.
Sur Ubuntu, vous devez désactiver le pare-feu UFW (Uncomplicated Firewall). Exécutez systemctl stop ufw pour désactiver le pare-feu UFW.
L'un des kernel modules de réseau suivants doit être chargé :
- iptables-nft (ce qui est différent du package Debian de premier plan iptables, qui n'est pas obligatoire). iptables-legacy n'est pas compatible.
- nf_tables.
Pour charger un module, exécutez la commande suivante:
```
modprobe MODULE_NAME
```

Espace disque disponible requis:

1.29.100 et versions ultérieures

Lorsque vous installez Google Distributed Cloud, des vérifications préliminaires s'exécutent. Ces vérifications confirment que les systèmes de fichiers de ces répertoires disposent d'une capacité suffisante:

Annuaire	Espace requis
`/` (répertoire racine)	4 Gio (4 294 967 296 octets)
`/var/log/fluent-bit-buffers`	12 Gio (12 884 901 888 octets)
`/var/opt/buffered-metrics`	10 016 Mio (10 502 537 216 octets)
`/var/lib/containerd`	30 Gio (32 212 254 720 octets) pour les nœuds du plan de contrôle 10 Gio (10 485 760 octets) pour les nœuds de calcul
`/var/lib/kubelet`	500 Mio (524 288 000 octets)
`/var/lib/etcd`	20 Gio (21 474 836 480 octets, applicable uniquement aux nœuds du plan de contrôle)
`/var/lib/etcd-events`	5 Gio (5 368 709 120 octets, applicable uniquement aux nœuds du plan de contrôle)

Pour vous permettre de mieux contrôler l'espace que vous allouez aux charges de travail des applications, les vérifications préalables de la création de clusters ne vérifient que l'espace libre requis pour les composants du système Google Distributed Cloud. Vous devrez peut-être disposer d'un espace de stockage supplémentaire en fonction des charges de travail que vous prévoyez de déployer.

Lorsque vous mettez à niveau un cluster vers la version 1.29.100 ou ultérieure, les vérifications préalables vérifient que vous disposez d'au moins 2 Gio d'espace libre dans / (répertoire racine).

1.29.0 et versions antérieures

Chaque fois que vous installez Google Distributed Cloud, des vérifications préliminaires sont exécutées pour vous assurer que les systèmes de fichiers qui sauvegardent les répertoires suivants disposent de la capacité requise:

Annuaire	Espace requis
`/` (répertoire racine)	17 Gio (18 253 611 008 octets)
`/var/lib/containerd`	30 Gio (32 212 254 720 octets) pour les nœuds du plan de contrôle 10 Gio (10 485 760 octets) pour les nœuds de calcul
`/var/lib/kubelet`	500 Mio (524 288 000 octets)
`/var/lib/etcd`	20 Gio (21 474 836 480 octets, applicable uniquement aux nœuds du plan de contrôle)
`/var/lib/etcd-events`	5 Gio (5 368 709 120 octets, applicable uniquement aux nœuds du plan de contrôle)

Pour toute version de cluster, les répertoires peuvent se trouver sur les mêmes partitions de disque ou sur des partitions différentes. Si les répertoires partagent une partition de disque, calculez l'espace total requis en additionnant l'espace requis pour chaque répertoire individuel sur cette partition partagée. La configuration du cluster crée ces répertoires s'ils n'existent pas déjà.

Les répertoires /var/lib/etcd et /etc/kubernetes sont soit inexistants, soit vides.
Pour les machines exécutant RHEL 9.2 ou Ubuntu 22.04, les limites inotify du noyau Linux pour les instances utilisateur et les montres utilisateur doivent être supérieures ou égales aux valeurs suivantes:
- fs.inotify.max_user_instances : 8192
- fs.inotify.max_user_watches : 524288
Pour en savoir plus, consultez la documentation de configuration de RHEL ou d'Ubuntu.

En plus des conditions préalables à l'installation et à l'exécution de Google Distributed Cloud, les clients doivent se conformer aux normes applicables à leur secteur ou à leur segment d'activité, telles que les exigences PCI DSS pour les entreprises qui traitent des cartes de crédit ou les guides de mise en œuvre technique de sécurité (STIG, Security Technical Implementation Guides) pour les entreprises du secteur de la défense.

Prérequis pour les machines d'équilibrage de charge

Lorsque votre déploiement ne comporte pas de pool de nœuds d'équilibreur de charge spécialisé, vous pouvez utiliser des nœuds de calcul ou des nœuds de plan de contrôle pour en créer un. Dans ce cas, les conditions préalables supplémentaires sont les suivantes :

Les machines se trouvent dans le même sous-réseau de couche 2.
Toutes les adresses IP virtuelles se trouvent dans le sous-réseau des nœuds d'équilibreur de charge et peuvent être acheminés par la passerelle du sous-réseau.
La passerelle du sous-réseau d'équilibreur de charge doit écouter les messages ARP gratuits pour transmettre les paquets vers l'équilibreur de charge principal.