Configurer la planification

Cette page décrit les options de l'ordonnanceur et explique comment configurer les contraintes d'ordonnancement de pods par défaut dans votre logiciel Google Distributed Cloud uniquement pour les clusters bare metal.

Google Distributed Cloud fournit un certain nombre de fonctionnalités Kubernetes standards que vous pouvez utiliser pour contrôler l'ordonnancement des pods, telles que :

Pour en savoir plus sur les contraintes de répartition de la topologie des pods dans Kubernetes, consultez Kubernetes Scheduler dans la documentation Kubernetes.

Avant de commencer

Avant de configurer la répartition des pods par défaut, assurez-vous que chaque nœud de votre cluster comporte les étiquettes de topologie appropriées. Vous pouvez utiliser l'API Nodepool.Spec.TaintsAndLabels pour appliquer des étiquettes. L'étiquetage manuel des nœuds avec kubectl label offre plus de flexibilité, mais nécessite un étiquetage manuel lorsque vous ajoutez un nœud au cluster.

Configurer l'ordonnanceur personnalisé par défaut {#:config-default}

Étiqueter les nœuds

  1. Ajoutez des étiquettes de topologie à vos fichiers YAML de cluster et de pool de nœuds. L'exemple suivant suppose que deux pools de nœuds de calcul se trouvent dans des racks différents et que les nœuds du plan de contrôle se trouvent dans rack1.

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: abm-cluster
  namespace: cluster-abm-cluster
spec:
  controlPlane:
    nodePoolSpec:
      labels:
        topology.k8s.io/rack: rack1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: nodepool-rack1
  namespace: cluster-abm-cluster
spec:
  labels:
    topology.k8s.io/rack: rack1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: nodepool-rack2
  namespace: cluster-abm-cluster
spec:
  labels:
    topology.k8s.io/rack: rack2

  2. Appliquez la configuration de cluster mise à jour.

    bmctl update cluster -c CLUSTER_NAME

    Remplacez CLUSTER_NAME par le nom de votre cluster.

  3. Attendez que l'étiquette topology.k8s.io/rack soit propagée à tous les nœuds du cluster.

Activer les contraintes de répartition des pods par défaut

  1. Ajoutez l'annotation preview.baremetal.cluster.gke.io/custom-scheduler-configuration:enable à votre fichier YAML de cluster.

  2. Ajoutez la section schedulerConfiguration sous cluster.spec.controlPlane dans votre fichier YAML de cluster.

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: abm-cluster
  namespace: cluster-abm-cluster
  annotations:
    preview.baremetal.cluster.gke.io/custom-scheduler-configuration: enable
spec:
  controlPlane:
    schedulerConfiguration:
      defaultTopologySpreadConstraint:
        defaultConstraints:
        - topologyKey: topology.k8s.io/rack
          whenUnsatisfiable: DoNotSchedule
          maxSkew: 1
        defaultingType: List

  3. Appliquez la configuration de cluster mise à jour.

    bmctl update cluster -c CLUSTER_NAME

    Remplacez CLUSTER_NAME par le nom de votre cluster.

  4. Attendez la fin de la réconciliation du cluster. Surveillez cluster.status.clusterState jusqu'à ce qu'il affiche Running. Une tâche control-plane-update s'exécute pour chaque nœud du plan de contrôle au cours de ce processus.

Vérifier la configuration de la répartition des pods

  1. Créez un déploiement de test avec cinq répliques.

  2. Observez la distribution des pods. La différence entre le nombre de pods sur nodepool-rack1 et nodepool-rack2 doit être exactement de un.

  3. Vérifiez le fichier kube-scheduler-profile.config sur chaque nœud du plan de contrôle. Le fichier, situé dans /etc/kubernetes/kube-scheduler-profile.config, doit contenir la configuration de répartition de la topologie de cluster.spec.

Résoudre les problèmes

Pour diagnostiquer et résoudre les problèmes liés à la répartition des pods par défaut, vérifiez les points suivants :

  1. Consultez BareMetalMachine.Status.ControlPlaneComponents pour connaître l'état de la fonctionnalité.
  2. Examinez les journaux de cluster-operator et cap-controller-manager pour trouver les événements pertinents.
  3. Si les pods statiques kube-scheduler plantent, vérifiez que la configuration de l'ordonnanceur est correcte dans le fichier YAML du cluster.

Étape suivante