|
Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi. |
Référence de configuration du cluster GKE
Emplacement du cluster
| Valeur | Description |
|---|---|
Type d’emplacement |
Zonal ou Régional. Avec GKE, vous pouvez créer un cluster adapté aux exigences de disponibilité de votre charge de travail et à votre budget. Par défaut, les nœuds d’un cluster s’exécutent dans une seule zone de calcul. Lorsque plusieurs zones sont sélectionnées, les nœuds du cluster s’étendront sur plusieurs zones de calcul, tandis que le plan de contrôle est situé dans une seule zone. Les clusters régionaux augmentent également la disponibilité du plan de contrôle. Pour obtenir de l’aide sur le choix du type de disponibilité du cluster, consultez ces documents. |
Zone |
Chaque région dans Compute Engine contient un certain nombre de zones. Pour plus d’informations sur les régions et zones disponibles, consultez ces documents. |
Zones supplémentaires |
Pour les clusters zonaux, vous pouvez sélectionner des zones supplémentaires pour créer un cluster multi-zone. |
Région |
Pour les clusters régionaux,, vous pouvez sélectionner une région. Pour plus d’informations sur les régions et zones disponibles, consultez cette section. La première partie de chaque nom de zone est le nom de la région. |
Options de grappe
Kubernetes Version
Mutable: oui
Pour plus d’informations sur les versions GKE Kubernetes, consultez ces documents.
Plage d’adresses des conteneurs
Mutable: non
La plage d’adresses IP pour les pods dans le cluster. Doit être une plage CIDR valide, par exemple 10.42.0.0/16. Si non spécifié, une plage aléatoire est automatiquement choisie parmi 10.0.0.0/8 et exclura les plages déjà attribuées aux VM, autres clusters ou routes. Les plages choisies automatiquement peuvent entrer en conflit avec des adresses IP réservées, des routes dynamiques ou des routes au sein des VPC se connectant au cluster.
Réseau
Mutable: non
Le réseau Compute Engine auquel le cluster se connecte. Des routes et des passerelles de périmètre de sécurité seront créées en utilisant ce réseau. Si vous utilisez des VPC partagés, les réseaux VPC de votre projet apparaîtront ici et pourront être sélectionnés dans ce champ. Pour plus d’informations, consultez cette page.
Sous-réseau de nœud / Sous-réseau
Mutable: non
Le sous-réseau Compute Engine auquel le cluster se connecte. Ce sous-réseau doit appartenir au réseau spécifié dans le champ Réseau. Sélectionnez un sous-réseau existant, ou choisissez « Créer un sous-réseau automatiquement » pour en créer un. Si vous n’utilisez pas un réseau existant, Nom du sous-réseau est requis pour en générer un. Si vous utilisez des VPC partagés, les sous-réseaux VPC partagés avec votre projet apparaîtront ici. Si vous utilisez un réseau VPC partagé, vous ne pouvez pas sélectionner "Créer un sous-réseau automatiquement". Pour plus d’informations, consultez cette page.
Nom du sous-réseau
Mutable : non
Créer automatiquement un sous-réseau avec le nom fourni. Requis si "Création automatique de sous-réseau" est sélectionné pour Sous-réseau de nœud ou Sous-réseau. Pour plus d’informations sur les sous-réseaux, consultez cette page.
Alias IP
Mutable : non
Activez les alias IP. Cela active le routage du trafic natif VPC. Requis si vous utilisez des VPC partagés.
Stratégie réseau
Mutable : oui
Activez l’application de la politique réseau sur le cluster. Une politique réseau définit le niveau de communication qui peut se produire entre les pods et les services dans le cluster. Pour plus d’informations, reportez-vous à cette page.
Isolation du réseau de projet
Mutable : oui
Choisissez d’activer ou de désactiver la communication inter-projets.
Clusters importés
Pour les clusters importés, l’isolement de réseau de projet (PNI) nécessite que la politique réseau Kubernetes soit activée sur le cluster au préalable. Pour les clusters créés par Rancher, Rancher active automatiquement la politique réseau Kubernetes.
-
Dans GKE, activez la politique réseau au niveau du cluster. Reportez-vous au guide officiel de GKE pour les instructions.
-
Après avoir activé la politique réseau, importez le cluster dans Rancher et activez le PNI pour l’isolement au niveau du projet.
Bloc CIDR IPv4 du nœud
Mutable : non
La plage d’adresses IP des IP d’instance dans ce cluster. Peut être défini si "Création automatique de sous-réseau" est sélectionné pour Node Subnet ou Subnet. Doit être une plage CIDR valide, par exemple 10.96.0.0/14. Pour plus d’informations sur la façon de déterminer la plage d’adresses IP, consultez cette page.
Nom de la plage secondaire du cluster
Mutable : non
Le nom d’une plage secondaire existante pour les adresses IP des pods. Si sélectionné, la plage d’adresses IP des pods du cluster sera automatiquement remplie. Requis si vous utilisez un réseau VPC partagé.
Plage d’adresses IP des pods du cluster
Mutable : non
La plage d’adresses IP assignée aux pods dans le cluster. Doit être une plage CIDR valide, par exemple 10.96.0.0/11. Si non fourni, sera créé automatiquement. Doit être fourni si vous utilisez un réseau VPC partagé. Pour plus d’informations sur la façon de déterminer la plage d’adresses IP pour vos pods, consultez cette section.
Nom de la plage secondaire des services
Mutable : non
Le nom d’une plage secondaire existante pour les adresses IP des services. Si sélectionné, la plage d’adresses IP des services sera automatiquement remplie. Requis si vous utilisez un réseau VPC partagé.
Plage d’adresses IP des services
Mutable : non
La plage d’adresses assignée aux services dans le cluster. Doit être une plage CIDR valide, par exemple 10.94.0.0/18. Si non fourni, sera créé automatiquement. Doit être fourni si vous utilisez un réseau VPC partagé. Pour plus d’informations sur la façon de déterminer la plage d’adresses IP pour vos services, consultez cette section.
Cluster privé
Mutable : non
|
Les clusters privés nécessitent une planification et une configuration supplémentaires en dehors de Rancher. Consultez le guide des clusters privés. |
Attribuez uniquement des adresses IP internes aux nœuds. Les nœuds du cluster privé ne peuvent pas accéder à Internet public à moins que des étapes de mise en réseau supplémentaires ne soient prises dans GCP.
Activer le point de terminaison privé
|
Les clusters privés nécessitent une planification et une configuration supplémentaires en dehors de Rancher. Consultez le guide des clusters privés. |
Mutable : non
Restreint l’accès externe au point de terminaison du plan de contrôle. Disponible uniquement si Cluster privé est également sélectionné. Si sélectionné, et si Rancher n’a pas d’accès direct au réseau VPC privé dans lequel le cluster fonctionne, Rancher fournira une commande d’inscription à exécuter sur le cluster pour permettre à Rancher de s’y connecter.
Réseau autorisé du plan de contrôle
Mutable : oui
Activez les réseaux autorisés du plan de contrôle pour bloquer les adresses IP sources non fiables, non-GCP, d’accéder au plan de contrôle Kubernetes via HTTPS. Si sélectionné, des réseaux autorisés supplémentaires peuvent être ajoutés. Si le cluster est créé avec un point de terminaison public, cette option est utile pour restreindre l’accès au point de terminaison public à certains réseaux, comme le réseau où votre service Rancher fonctionne. Si le cluster n’a qu’un point de terminaison privé, ce paramètre est requis.
Options supplémentaires
Add-ons du cluster
Composants supplémentaires du cluster Kubernetes. Pour plus d’informations, reportez-vous à cette page.
Mise à l’échelle horizontale des pods
Mutable : oui
L’autoscaler horizontal des pods modifie la configuration de votre charge de travail Kubernetes en augmentant ou réduisant automatiquement le nombre de pods en fonction de la consommation d’UC ou de mémoire, ou en réponse à des métriques personnalisées rapportées depuis Kubernetes ou à des métriques externes provenant de sources en dehors de votre cluster. Pour plus d’informations, consultez cette page.
Équilibrage de la charge HTTP (L7)
Mutable: oui
L’équilibrage de la charge HTTP (L7) distribue le trafic HTTP et HTTPS vers les backends hébergés sur GKE. Pour plus d’informations, reportez-vous à cette page.
Fonctionnalités du cluster (Fonctionnalités Alpha)
Mutable: non
Active tous les groupes et fonctionnalités de l’API alpha de Kubernetes pour le cluster. Lorsqu’il est activé, le cluster ne peut pas être mis à niveau et sera automatiquement supprimé après 30 jours. Les clusters alpha ne sont pas recommandés pour une utilisation en production car ils ne sont pas couverts par le SLA de GKE. Pour plus d’informations, reportez-vous à cette page.
Service de consignation
Mutable: oui
Le service de consignation que le cluster utilise pour écrire des journaux. Utilisez soit Cloud Logging soit aucun service de consignation, auquel cas aucun journal n’est exporté depuis le cluster.
Service de surveillance
Mutable: oui
Le service de surveillance que le cluster utilise pour écrire des métriques. Utilisez soit Cloud Monitoring soit le service de surveillance, auquel cas aucune métrique n’est exportée depuis le cluster.
Fenêtre de maintenance
Mutable: oui
Définissez l’heure de début pour une fenêtre de maintenance de 4 heures. L’heure est spécifiée dans le fuseau horaire UTC en utilisant le format HH:MM. Pour plus d’informations, reportez-vous à cette page.
Pools de nœuds
Dans cette section, entrez les détails décrivant la configuration de chaque nœud dans le pool de nœuds.
Kubernetes Version
Mutable: oui
La version de Kubernetes pour chaque nœud dans le pool de nœuds. Pour plus d’informations sur les versions GKE Kubernetes, consultez ces documents.
Type d’image
Mutable: oui
L’image du système d’exploitation du nœud. Pour plus d’informations sur les options d’image de nœud que GKE propose pour chaque système d’exploitation, consultez cette page.
|
L’option par défaut est "Système d’exploitation optimisé pour les conteneurs avec Docker". Le système de fichiers en lecture seule sur le système d’exploitation optimisé pour les conteneurs de GCP n’est pas compatible avec l’implémentation de xref:[journalisation héritée] dans Rancher. Si vous devez utiliser la fonctionnalité de journalisation héritée, sélectionnez "Ubuntu avec Docker" ou "Ubuntu avec Containerd". La fonctionnalité de journalisation actuelle est compatible avec l’image du système d’exploitation optimisé pour les conteneurs. |
|
Si vous sélectionnez "Windows Long Term Service Channel" ou "Windows Semi-Annual Channel" pour le type d’image du pool de nœuds, vous devez également ajouter au moins un pool de nœuds optimisé pour les conteneurs ou Ubuntu. |
Type de machine
Mutable: non
Les ressources matérielles virtualisées disponibles pour les instances de nœuds. Pour plus d’informations sur les types de machines Google Cloud, consultez cette page.
Type de disque racine
Mutable: non
Les disques persistants standard sont basés sur des disques durs standard (HDD), tandis que les disques persistants SSD sont basés sur des disques statiques à semiconducteurs (SSD). Pour plus d’informations, consultez cette section.
Disques SSD locaux
Mutable: non
Configurez le stockage de disque SSD local de chaque nœud en Go. Les disques SSD locaux sont physiquement attachés au serveur qui héberge votre instance VM. Les disques SSD locaux ont un débit plus élevé et une latence plus faible que les disques persistants standard ou les disques persistants SSD. Les données que vous stockez sur un disque SSD local persistent uniquement jusqu’à ce que l’instance soit arrêtée ou supprimée. Pour plus d’informations, consultez cette section.
Nœuds préemptibles (bêta)
Mutable: non
Les nœuds préemptibles, également appelés VMs préemptibles, sont des instances VM de Compute Engine qui durent un maximum de 24 heures en général et ne fournissent aucune garantie de disponibilité. Pour plus d’informations, consultez cette page.
Taints
Mutable: non
Lorsque vous appliquez une « taint » à un nœud, seuls les pods qui tolèrent la « taint » sont autorisés à s’exécuter sur le nœud. Dans un cluster GKE, vous pouvez appliquer une « taint » à un pool de nœuds, ce qui applique la « taint » à tous les nœuds du pool.
Étiquettes de nœud
Mutable: non
Vous pouvez appliquer des étiquettes au pool de nœuds, ce qui applique les étiquettes à tous les nœuds du pool.
Des étiquettes invalides peuvent empêcher les mises à niveau ou peuvent empêcher Rancher de démarrer. Pour plus de détails sur les exigences de syntaxe des étiquettes, consultez la documentation Kubernetes.
Tags réseau
Mutable: non
Vous pouvez ajouter des tags réseau au pool de nœuds pour créer des règles de passerelle de périmètre de sécurité et des routes entre les sous-réseaux. Les tags s’appliqueront à tous les nœuds du pool.
Pour plus de détails sur la syntaxe des tags et les exigences, consultez la documentation Kubernetes.
Détails du groupe
Dans cette section, entrez des détails décrivant le pool de nœuds.
Nombre initial de nœuds
Mutable: oui
Entier pour le nombre de départ de nœuds dans le pool de nœuds.
Nombre maximal de pods par nœud
Mutable: non
GKE a une limite stricte de 110 pods par nœud. Pour plus d’informations sur les limites de Kubernetes, consultez cette section.
Mise à l’échelle automatique
Mutable: oui
La mise à l’échelle automatique du pool de nœuds crée ou supprime dynamiquement des nœuds en fonction des demandes de votre charge de travail. Pour plus d’informations, consultez cette page.
Réparation Automatique
Mutable: oui
La fonctionnalité de réparation automatique des nœuds de GKE vous aide à maintenir les nœuds de votre cluster dans un état sain et opérationnel. Lorsqu’elle est activée, GKE effectue des vérifications périodiques de l’état de santé de chaque nœud de votre cluster. Si un nœud échoue à des vérifications de santé consécutives pendant une période prolongée, GKE initie un processus de réparation pour ce nœud. Pour plus d’informations, consultez la section sur la réparation automatique des nœuds.
Mise à jour automatique
Mutable: oui
Lorsqu’elle est activée, la fonctionnalité de mise à jour automatique maintient les nœuds de votre cluster à jour avec la version du plan de contrôle du cluster (maître) lorsque votre plan de contrôle est mis à jour en votre nom. Pour plus d’informations sur la mise à jour automatique des nœuds, consultez cette page.
Scopes d’accès
Mutable: non
Les scopes d’accès sont la méthode héritée pour spécifier les autorisations de vos nœuds.
-
Autoriser l’accès par défaut : L’accès par défaut pour les nouveaux clusters est le compte de service par défaut de Compute Engine.
-
Autoriser un accès complet à toutes les API Cloud : En général, vous pouvez simplement définir le scope d’accès cloud-platform pour permettre un accès complet à toutes les API Cloud, puis accorder au compte de service uniquement les rôles IAM pertinents. La combinaison des scopes d’accès accordés à l’instance de machine virtuelle et des rôles IAM accordés au compte de service détermine le niveau d’accès dont dispose le compte de service pour cette instance.
-
Définir l’accès pour chaque API : Alternativement, vous pouvez choisir de définir des scopes spécifiques qui permettent l’accès aux méthodes API particulières que le service appellera.
Pour plus d’informations, consultez la section sur l’activation des comptes de service pour une VM.
Configuration de l’intervalle de rafraîchissement
L’intervalle de rafraîchissement peut être configuré via le paramètre "gke-refresh", qui est un entier représentant des secondes.
La valeur par défaut est de 300 secondes.
L’intervalle de synchronisation peut être modifié en exécutant kubectl edit setting gke-refresh.
Plus la fenêtre de rafraîchissement est courte, moins il est probable que des conditions de concurrence se produisent, mais cela augmente la probabilité de rencontrer des limites de demande qui peuvent être en place pour les API GCP.