# 複数のスケジューラーを設定する LLMS index: [llms.txt](/llms.txt) --- Kubernetesには[こちら](/docs/reference/command-line-tools-reference/kube-scheduler/)で説明されているデフォルトのスケジューラーが付属します。 もしデフォルトのスケジューラーがあなたの要求を満たさない場合、独自にスケジューラーを実装できます。 さらに、デフォルトのスケジューラーと一緒に複数のスケジューラーを同時に実行し、どのPodにどのスケジューラーを使うかKubernetesに指示できます。 具体例を見ながらKubernetesで複数のスケジューラーを実行する方法を学びましょう。 スケジューラーの実装方法の詳細は本ドキュメントの範囲外です。 標準的な例としてKubernetesのソースディレクトリの[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler)にあるkube-schedulerの実装が参照できます。 ## 始める前に

Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:

バージョンを確認するには次のコマンドを実行してください: kubectl version.

## スケジューラーをパッケージ化する スケジューラーのバイナリをコンテナイメージとしてパッケージ化します。 例として、デフォルトのスケジューラー(kube-scheduler)を2つ目のスケジューラーとして使用します。 [GitHubからKubernetesのソースコード](https://github.com/kubernetes/kubernetes)をクローンし、ビルドします。 ```shell git clone https://github.com/kubernetes/kubernetes.git cd kubernetes make ``` kube-schedulerバイナリを含むコンテナイメージを作成します。 そのための`Dockerfile`は次のとおりです: ```docker FROM busybox ADD ./_output/local/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler ``` これを`Dockerfile`として保存し、イメージをビルドしてレジストリにプッシュします。 次の例では[Google Container Registry (GCR)](https://cloud.google.com/container-registry/)を使用します。 詳細はGCRの[ドキュメント](https://cloud.google.com/container-registry/docs/)から確認できます。 代わりに[Docker Hub](https://hub.docker.com/search?q=)を使用することもできます。 Docker Hubの詳細は[ドキュメント](https://docs.docker.com/docker-hub/repos/create/#create-a-repository)から確認できます。 ```shell docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 . # The image name and the repository gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0 # used in here is just an example ``` ## スケジューラー用のKubernetes Deploymentを定義する スケジューラーをコンテナイメージとして用意できたら、それ用のPodの設定を作成してクラスター上で動かします。 この例では、直接Podをクラスターに作成する代わりに、[Deployment](/docs/concepts/workloads/controllers/deployment/)を使用します。 [Deployment](/docs/concepts/workloads/controllers/deployment/)は[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)を管理し、そのReplicaSetがPodを管理することで、スケジューラーを障害に対して堅牢にします。 `my-scheduler.yaml`として保存するDeploymentの設定を示します:
admin/sched/my-scheduler.yaml 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-scheduler
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-scheduler-as-kube-scheduler
subjects:
- kind: ServiceAccount
  name: my-scheduler
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: system:kube-scheduler
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-scheduler-as-volume-scheduler
subjects:
- kind: ServiceAccount
  name: my-scheduler
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: system:volume-scheduler
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-scheduler-extension-apiserver-authentication-reader
  namespace: kube-system
roleRef:
  kind: Role
  name: extension-apiserver-authentication-reader
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: my-scheduler
  namespace: kube-system
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-scheduler-config
  namespace: kube-system
data:
  my-scheduler-config.yaml: |
    apiVersion: kubescheduler.config.k8s.io/v1
    kind: KubeSchedulerConfiguration
    profiles:
      - schedulerName: my-scheduler
    leaderElection:
      leaderElect: false
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    component: scheduler
    tier: control-plane
  name: my-scheduler
  namespace: kube-system
spec:
  selector:
    matchLabels:
      component: scheduler
      tier: control-plane
  replicas: 1
  template:
    metadata:
      labels:
        component: scheduler
        tier: control-plane
        version: second
    spec:
      serviceAccountName: my-scheduler
      containers:
      - command:
        - /usr/local/bin/kube-scheduler
        - --config=/etc/kubernetes/my-scheduler/my-scheduler-config.yaml
        image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10259
            scheme: HTTPS
          initialDelaySeconds: 15
        name: kube-second-scheduler
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10259
            scheme: HTTPS
        resources:
          requests:
            cpu: '0.1'
        securityContext:
          privileged: false
        volumeMounts:
          - name: config-volume
            mountPath: /etc/kubernetes/my-scheduler
      hostNetwork: false
      hostPID: false
      volumes:
        - name: config-volume
          configMap:
            name: my-scheduler-config
上に示したマニフェストでは、[KubeSchedulerConfiguration](/docs/reference/scheduling/config/)を使用してあなたのスケジューラー実装の振る舞いを変更できます。 この設定ファイルは`kube-scheduler`の初期化時に`--config`オプションから渡されます。 この設定ファイルは`my-scheduler-config` ConfigMapに格納されており、`my-scheduler` DeploymentのPodは`my-scheduler-config` ConfigMapをボリュームとしてマウントします。 前述のスケジューラー設定において、あなたのスケジューラー実装は[KubeSchedulerProfile](/docs/reference/config-api/kube-scheduler-config.v1/#kubescheduler-config-k8s-io-v1-KubeSchedulerProfile)を使って表現されます。

備考:

特定のPodをどのスケジューラーが処理するかを指定するには、PodTemplateやPodのマニフェストにあるspec.schedulerNameフィールドをKubeSchedulerProfileのschedulerNameフィールドに一致させます。 クラスターで動作させるすべてのスケジューラーの名前は一意的である必要があります。
また、専用のサービスアカウント`my-scheduler`を作成して`system:kube-scheduler` ClusterRoleに紐づけを行い、スケジューラーに`kube-scheduler`と同じ権限を付与している点に注意します。 その他のコマンドライン引数の詳細は[kube-schedulerのドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)から、その他の変更可能な`kube-scheduler`の設定は[スケジューラー設定のリファレンス](/docs/reference/config-api/kube-scheduler-config.v1/)から確認できます。 ## クラスターで2つ目のスケジューラーを実行する 2つ目のスケジューラーをクラスター上で動かすには、前述のDeploymentをKubernetesクラスターに作成します: ```shell kubectl create -f my-scheduler.yaml ``` スケジューラーのPodが実行中であることを確認します: ```shell kubectl get pods --namespace=kube-system ``` ``` NAME READY STATUS RESTARTS AGE .... my-scheduler-lnf4s-4744f 1/1 Running 0 2m ... ``` このリストにはデフォルトのkube-schedulerのPodに加えて、my-schedulerのPodが「Running」になっているはずです。 ### リーダー選出を有効にする リーダー選出を有効にして複数のスケジューラーを実行するには、次の対応が必要です: YAMLファイルにある`my-scheduler-config` ConfigMap内の`KubeSchedulerConfiguration`の次のフィールドを更新します: * `leaderElection.leaderElect`を`true`に設定します * `leaderElection.resourceNamespace`を``に設定します * `leaderElection.resourceName`を``に設定します

備考:

ロックオブジェクトはコントロールプレーンが自動的に作成しますが、使用するNamespaceはあらかじめ存在している必要があります。 kube-system Namespaceを使うこともできます。
クラスターでRBACが有効になっている場合、`system:kube-scheduler` ClusterRoleを更新し、`endpoints`と`leases`リソースに適用されるルールのresourceNamesにスケジューラー名を追加します。 例を示します: ```shell kubectl edit clusterrole system:kube-scheduler ```
admin/sched/clusterrole.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-scheduler
rules:
  - apiGroups:
      - coordination.k8s.io
    resources:
      - leases
    verbs:
      - create
  - apiGroups:
      - coordination.k8s.io
    resourceNames:
      - kube-scheduler
      - my-scheduler
    resources:
      - leases
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resourceNames:
      - kube-scheduler
      - my-scheduler
    resources:
      - endpoints
    verbs:
      - delete
      - get
      - patch
      - update
## Podにスケジューラーを指定する 2つ目のスケジューラーが動作している状態で、Podをいくつか作成し、デフォルトのスケジューラーまたは新しいスケジューラーのどちらで配置するか指定します。 あるPodを特定のスケジューラーで配置するには、Podのspecにスケジューラー名を指定します。 3つの例を確認しましょう。 - スケジューラー名を指定しないPodの設定
admin/sched/pod1.yaml 
apiVersion: v1
  kind: Pod
  metadata:
    name: no-annotation
    labels:
      name: multischeduler-example
  spec:
    containers:
    - name: pod-with-no-annotation-container
      image: registry.k8s.io/pause:3.8
スケジューラー名が指定されていない場合、Podは自動的にdefault-schedulerによって配置されます。 このファイルを`pod1.yaml`として保存し、Kubernetesクラスターに投入します。 ```shell kubectl create -f pod1.yaml ``` - `default-scheduler`を指定するPodの設定
admin/sched/pod2.yaml 
apiVersion: v1
  kind: Pod
  metadata:
    name: annotation-default-scheduler
    labels:
      name: multischeduler-example
  spec:
    schedulerName: default-scheduler
    containers:
    - name: pod-with-default-annotation-container
      image: registry.k8s.io/pause:3.8
使用するスケジューラーは`spec.schedulerName`の値にスケジューラー名を与えることで指定します。 この場合、デフォルトのスケジューラーである`default-scheduler`を指定します。 このファイルを`pod2.yaml`として保存し、Kubernetesクラスターに投入します。 ```shell kubectl create -f pod2.yaml ``` - `my-scheduler`を指定するPodの設定
admin/sched/pod3.yaml 
apiVersion: v1
  kind: Pod
  metadata:
    name: annotation-second-scheduler
    labels:
      name: multischeduler-example
  spec:
    schedulerName: my-scheduler
    containers:
    - name: pod-with-second-annotation-container
      image: registry.k8s.io/pause:3.8
この場合、前述の手順でデプロイした`my-scheduler`を使用してPodを配置することを指定します。 `spec.schedulerName`の値は`KubeSchedulerProfile`の`schedulerName`フィールドに設定した名前と一致する必要があります。 このファイルを`pod3.yaml`として保存し、クラスターに投入します。 ```shell kubectl create -f pod3.yaml ``` 3つのPodがすべて実行中であることを確認します。 ```shell kubectl get pods ``` ### Podが目的のスケジューラーによって配置されたことを確認する わかりやすさのため、前述の例ではPodが実際に指定したスケジューラーによって配置されたことを確認していません。 確認したい場合はPodとDeploymentの設定の適用順序を変えてみてください。 もしPodの設定をすべて先に適用し、その後にスケジューラーのDeploymentを適用した場合、`annotation-second-scheduler` Podは「Pending」のままになり、他の2つのPodが先に配置されることを確認できます。 その後にスケジューラーのDeploymentを適用して新しいスケジューラーが動作すると、`annotation-second-scheduler` Podも配置されます。 あるいは、イベントログの「Scheduled」の項目を見ることで、どのPodがどのスケジューラーによって配置されたかを確認できます。 ```shell kubectl get events ``` クラスターのメインのスケジューラーについては、[独自のスケジューラー設定](/docs/reference/scheduling/config/#multiple-profiles)を適用することや、関連するコントロールプレーンノードにある静的Podのマニフェストを変更し独自のコンテナイメージを使うことができます。