スケジューリングを構成する

このページでは、スケジューラ オプションと、ベアメタル クラスタ用の Google Distributed Cloud ソフトウェアのみでデフォルトの Pod スケジューリング制約を構成する方法について説明します。

Google Distributed Cloud には、Pod のスケジューリングを制御するために使用できる標準の Kubernetes 機能が多数用意されています。

Kubernetes の Pod トポロジの分散制約については、Kubernetes ドキュメントの Kubernetes スケジューラをご覧ください。

始める前に

デフォルトの Pod 分散を構成する前に、クラスタ内の各ノードに正しいトポロジラベルがあることを確認してください。Nodepool.Spec.TaintsAndLabels API を使用してラベルを適用できます。kubectl label を使用してノードに手動でラベルを付けると、柔軟性が高まりますが、クラスタに新しいノードを追加するときに手動でラベルを付ける必要があります。

デフォルトのカスタム スケジューラを構成する {#:config-default}

ノードにラベルを付ける

  1. クラスタとノードプールの YAML ファイルにトポロジ ラベルを追加します。次の例では、2 つのワーカー ノードプールが異なるラックにあり、コントロール プレーン ノードが 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. 更新されたクラスタ構成を適用します。

    bmctl update cluster -c CLUSTER_NAME

    CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

  3. topology.k8s.io/rack ラベルがクラスタ内のすべてのノードに伝播されるまで待ちます。

デフォルトの Pod スプレッド制約を有効にする

  1. preview.baremetal.cluster.gke.io/custom-scheduler-configuration:enable アノテーションをクラスタ YAML ファイルに追加します。

  2. クラスタ YAML ファイルの cluster.spec.controlPlane に schedulerConfiguration セクションを追加します。

    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. 更新されたクラスタ構成を適用します。

    bmctl update cluster -c CLUSTER_NAME

    CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

  4. クラスタの調整が完了するまで待ちます。cluster.status.clusterState が Running になるまでモニタリングします。このプロセスでは、コントロール プレーン ノードごとに control-plane-update ジョブが実行されます。

Pod の分散構成を確認する

  1. 5 つのレプリカを含むテスト デプロイを作成します。

  2. Pod の分布を観察します。nodepool-rack1 と nodepool-rack2 の Pod の数の差は 1 にする必要があります。

  3. 各コントロール プレーンノードの kube-scheduler-profile.config ファイルを確認します。/etc/kubernetes/kube-scheduler-profile.config にあるファイルには、cluster.spec のトポロジ分散構成が含まれている必要があります。

トラブルシューティング

デフォルトの Pod スプレッドに関する問題を診断して解決するには、次のことを確認します。

  1. 機能のステータスについては、BareMetalMachine.Status.ControlPlaneComponents を確認してください。
  2. cluster-operator と cap-controller-manager のログで関連するイベントを確認します。
  3. kube-scheduler 静的 Pod がクラッシュした場合は、クラスタ YAML ファイルでスケジューラ構成が正しいことを確認します。

次のステップ