Configurer des domaines de topologie

Cette page présente les domaines de topologie et fournit des consignes pour les configurer.

La configuration d'un domaine de topologie nécessite l'activation du cluster avancé.

Cette page s'adresse aux administrateurs et aux architectes qui définissent les solutions informatiques et l'architecture du système conformément à la stratégie de l'entreprise, et qui créent et gèrent des règles liées aux autorisations des utilisateurs. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Présentation

Un domaine de topologie est un groupe de nœuds de cluster considérés comme faisant partie du même regroupement logique ou physique, tel qu'un campus ou un centre de données. Un domaine de topologie doit correspondre à un matériel ou un logiciel sous-jacent présentant un risque de défaillance corrélée. Exemple :

  • Défaillance logicielle, par exemple différents serveurs vCenter
  • Défaillance matérielle, par exemple différents racks, différentes sources d'alimentation et différents bâtiments

Dans Google Distributed Cloud (logiciel uniquement) pour VMware, lorsque vous configurez un domaine de topologie lors de la création d'un cluster, vous définissez un libellé de topologie. Après la création du cluster, l'étiquette de topologie est renseignée dans les étiquettes des nœuds du domaine de topologie.

Pour utiliser un domaine de topologie, vous disposez des options suivantes :

  • Version 1.32 et ultérieures : configurez les contraintes de répartition de la topologie par défaut au niveau du cluster. Pour en savoir plus, consultez schedulerConfiguration.

  • Utilisez la contrainte par défaut au niveau du cluster Kubernetes, "topology.kubernetes.io/zone", comme clé dans l'étiquette de topologie. Pour en savoir plus, consultez Contraintes par défaut intégrées.

  • Configurez le PodTemplate dans votre déploiement, StatefulSet ou ReplicaSet, selon le cas, avec la clé d'étiquette de topologie. Dans la spécification du pod, vous utilisez la clé de l'étiquette de topologie comme valeur du champ topologySpreadConstraints.topologyKey. Cette clé permet au programmeur Kubernetes de répartir les pods sur le domaine de topologie afin d'assurer une haute disponibilité et d'éviter une concentration excessive dans une seule zone en cas de défaillance. Pour en savoir plus sur la configuration de topologySpreadConstraints dans la spécification de votre pod, consultez Contraintes de répartition de la topologie des pods dans la documentation Kubernetes.

Exemples d'étiquettes de domaine de topologie

Supposons que vous créiez les trois domaines de topologie suivants lors de la création d'un cluster d'utilisateur :

...
topologyDomains:
- name: "topology-domain-1"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-1"
...

...
topologyDomains:
- name: "topology-domain-2"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-2"
...

...
topologyDomains:
- name: "topology-domain-3"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-3"
...

Une fois le cluster créé, vous mettez à jour la spécification du pod, par exemple :

...
topologySpreadConstraints:
  topologyKey: "topology.examplepetstore.com/zone"
...

En gros, le programmeur Kubernetes utilise topology.examplepetstore.com/zone pour séparer les nœuds du cluster en différents groupes : zone-1, zone-2 et zone-3. Le programmeur répartit ensuite les pods sur ces trois groupes de nœuds.

Consignes pour configurer des domaines de topologie

Pour garantir une utilisation efficace de toutes les ressources des clusters par le programmeur Kubernetes, nous vous recommandons de suivre les consignes suivantes :

  • Les domaines de topologie doivent être équilibrés. Vous devez fournir des capacités de processeur et de RAM presque égales dans chaque domaine de topologie.
  • Fournissez au moins deux et de préférence trois domaines de topologie.
  • Ne répartissez pas les pods sur plus d'une clé de topologie.
  • Les nœuds doivent avoir une taille similaire dans chaque domaine de topologie.
  • Si vous utilisez des rejets et tolérances pour séparer les charges de travail au sein d'un cluster, chaque groupe de nœuds doit répondre aux exigences précédentes.

Si ces consignes ne sont pas respectées, le programmeur essaiera toujours d'utiliser la capacité totale du cluster, mais la programmation des pods pourra prendre plus de temps, et tous les pods ne bénéficieront pas du comportement de répartition attendu.

Limites

Vous ne pouvez pas utiliser gkectl get-config pour générer des fichiers de configuration à partir de clusters qui utilisent des domaines de topologie. Cette limite s'applique au cluster d'administrateur et à tous les clusters d'utilisateur qu'il gère. Conservez les fichiers de configuration que vous utilisez pour créer et mettre à jour ces clusters, y compris le fichier de configuration de l'infrastructure vSphere et les fichiers de blocs d'adresses IP. Utilisez ces fichiers comme source de vérité pour la configuration de votre cluster.

Étapes suivantes