|
| 1 | +--- |
| 2 | +title: 複数のスケジューラーを設定する |
| 3 | +content_type: task |
| 4 | +weight: 20 |
| 5 | +--- |
| 6 | + |
| 7 | +<!-- overview --> |
| 8 | + |
| 9 | +Kubernetesには[こちら](/docs/reference/command-line-tools-reference/kube-scheduler/)で説明されているデフォルトのスケジューラーが付属します。 |
| 10 | +もしデフォルトのスケジューラーがあなたの要求を満たさない場合、独自にスケジューラーを実装できます。 |
| 11 | +さらに、デフォルトのスケジューラーと一緒に複数のスケジューラーを同時に実行し、どのPodにどのスケジューラーを使うかKubernetesに指示できます。 |
| 12 | +具体例を見ながらKubernetesで複数のスケジューラーを実行する方法を学びましょう。 |
| 13 | + |
| 14 | +スケジューラーの実装方法の詳細は本ドキュメントの範囲外です。 |
| 15 | +標準的な例としてKubernetesのソースディレクトリの[pkg/scheduler](http://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler)にあるkube-schedulerの実装が参照できます。 |
| 16 | + |
| 17 | +## {{% heading "prerequisites" %}} |
| 18 | + |
| 19 | +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} |
| 20 | + |
| 21 | +<!-- steps --> |
| 22 | + |
| 23 | +## スケジューラーをパッケージ化する |
| 24 | + |
| 25 | +スケジューラーのバイナリをコンテナイメージとしてパッケージ化します。 |
| 26 | +例として、デフォルトのスケジューラー(kube-scheduler)を2つ目のスケジューラーとして使用します。 |
| 27 | +[GitHubからKubernetesのソースコード](http://github.com/kubernetes/kubernetes)をクローンし、ビルドします。 |
| 28 | + |
| 29 | +```shell |
| 30 | +git clone http://github.com/kubernetes/kubernetes.git |
| 31 | +cd kubernetes |
| 32 | +make |
| 33 | +``` |
| 34 | + |
| 35 | +kube-schedulerバイナリを含むコンテナイメージを作成します。 |
| 36 | +そのための`Dockerfile`は次のとおりです: |
| 37 | + |
| 38 | +```docker |
| 39 | +FROM busybox |
| 40 | +ADD ./_output/local/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler |
| 41 | +``` |
| 42 | + |
| 43 | +これを`Dockerfile`として保存し、イメージをビルドしてレジストリにプッシュします。 |
| 44 | +次の例では[Google Container Registry (GCR)](http://cloud.google.com/container-registry/)を使用します。 |
| 45 | +詳細はGCRの[ドキュメント](http://cloud.google.com/container-registry/docs/)から確認できます。 |
| 46 | +代わりに[Docker Hub](http://hub.docker.com/search?q=)を使用することもできます。 |
| 47 | +Docker Hubの詳細は[ドキュメント](http://docs.docker.com/docker-hub/repos/create/#create-a-repository)から確認できます。 |
| 48 | + |
| 49 | +```shell |
| 50 | +docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 . # The image name and the repository |
| 51 | +gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0 # used in here is just an example |
| 52 | +``` |
| 53 | + |
| 54 | +## スケジューラー用のKubernetes Deploymentを定義する |
| 55 | + |
| 56 | +スケジューラーをコンテナイメージとして用意できたら、それ用のPodの設定を作成してクラスター上で動かします。 |
| 57 | +この例では、直接Podをクラスターに作成する代わりに、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)を使用します。 |
| 58 | +[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)は[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)を管理し、そのReplicaSetがPodを管理することで、スケジューラーを障害に対して堅牢にします。 |
| 59 | +`my-scheduler.yaml`として保存するDeploymentの設定を示します: |
| 60 | + |
| 61 | +{{% code_sample file="admin/sched/my-scheduler.yaml" %}} |
| 62 | + |
| 63 | +上に示したマニフェストでは、[KubeSchedulerConfiguration](/ja/docs/reference/scheduling/config/)を使用してあなたのスケジューラー実装の振る舞いを変更できます。 |
| 64 | +この設定ファイルは`kube-scheduler`の初期化時に`--config`オプションから渡されます。 |
| 65 | +この設定ファイルは`my-scheduler-config` ConfigMapに格納されており、`my-scheduler` DeploymentのPodは`my-scheduler-config` ConfigMapをボリュームとしてマウントします。 |
| 66 | + |
| 67 | +前述のスケジューラー設定において、あなたのスケジューラー実装は[KubeSchedulerProfile](/docs/reference/config-api/kube-scheduler-config.v1/#kubescheduler-config-k8s-io-v1-KubeSchedulerProfile)を使って表現されます。 |
| 68 | +{{< note >}} |
| 69 | +特定のPodをどのスケジューラーが処理するかを指定するには、PodTemplateやPodのマニフェストにある`spec.schedulerName`フィールドを`KubeSchedulerProfile`の`schedulerName`フィールドに一致させます。 |
| 70 | +クラスターで動作させるすべてのスケジューラーの名前は一意的である必要があります。 |
| 71 | +{{< /note >}} |
| 72 | + |
| 73 | +また、専用のサービスアカウント`my-scheduler`を作成して`system:kube-scheduler` ClusterRoleに紐づけを行い、スケジューラーに`kube-scheduler`と同じ権限を付与している点に注意します。 |
| 74 | + |
| 75 | +その他のコマンドライン引数の詳細は[kube-schedulerのドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)から、その他の変更可能な`kube-scheduler`の設定は[スケジューラー設定のリファレンス](/docs/reference/config-api/kube-scheduler-config.v1/)から確認できます。 |
| 76 | + |
| 77 | +## クラスターで2つ目のスケジューラーを実行する |
| 78 | + |
| 79 | +2つ目のスケジューラーをクラスター上で動かすには、前述のDeploymentをKubernetesクラスターに作成します: |
| 80 | + |
| 81 | +```shell |
| 82 | +kubectl create -f my-scheduler.yaml |
| 83 | +``` |
| 84 | + |
| 85 | +スケジューラーのPodが実行中であることを確認します: |
| 86 | + |
| 87 | +```shell |
| 88 | +kubectl get pods --namespace=kube-system |
| 89 | +``` |
| 90 | + |
| 91 | +``` |
| 92 | +NAME READY STATUS RESTARTS AGE |
| 93 | +.... |
| 94 | +my-scheduler-lnf4s-4744f 1/1 Running 0 2m |
| 95 | +... |
| 96 | +``` |
| 97 | + |
| 98 | +このリストにはデフォルトのkube-schedulerのPodに加えて、my-schedulerのPodが「Running」になっているはずです。 |
| 99 | + |
| 100 | +### リーダー選出を有効にする |
| 101 | + |
| 102 | +リーダー選出を有効にして複数のスケジューラーを実行するには、次の対応が必要です: |
| 103 | + |
| 104 | +YAMLファイルにある`my-scheduler-config` ConfigMap内の`KubeSchedulerConfiguration`の次のフィールドを更新します: |
| 105 | + |
| 106 | +* `leaderElection.leaderElect`を`true`に設定します |
| 107 | +* `leaderElection.resourceNamespace`を`<lock-object-namespace>`に設定します |
| 108 | +* `leaderElection.resourceName`を`<lock-object-name>`に設定します |
| 109 | + |
| 110 | +{{< note >}} |
| 111 | +ロックオブジェクトはコントロールプレーンが自動的に作成しますが、使用するNamespaceはあらかじめ存在している必要があります。 |
| 112 | +`kube-system` Namespaceを使うこともできます。 |
| 113 | +{{< /note >}} |
| 114 | + |
| 115 | +クラスターでRBACが有効になっている場合、`system:kube-scheduler` ClusterRoleを更新し、`endpoints`と`leases`リソースに適用されるルールのresourceNamesにスケジューラー名を追加します。 |
| 116 | +例を示します: |
| 117 | + |
| 118 | +```shell |
| 119 | +kubectl edit clusterrole system:kube-scheduler |
| 120 | +``` |
| 121 | + |
| 122 | +{{% code_sample file="admin/sched/clusterrole.yaml" %}} |
| 123 | + |
| 124 | +## Podにスケジューラーを指定する |
| 125 | + |
| 126 | +2つ目のスケジューラーが動作している状態で、Podをいくつか作成し、デフォルトのスケジューラーまたは新しいスケジューラーのどちらで配置するか指定します。 |
| 127 | +あるPodを特定のスケジューラーで配置するには、Podのspecにスケジューラー名を指定します。 |
| 128 | +3つの例を確認しましょう。 |
| 129 | + |
| 130 | +- スケジューラー名を指定しないPodの設定 |
| 131 | + |
| 132 | + {{% code_sample file="admin/sched/pod1.yaml" %}} |
| 133 | + |
| 134 | + スケジューラー名が指定されていない場合、Podは自動的にdefault-schedulerによって配置されます。 |
| 135 | + |
| 136 | + このファイルを`pod1.yaml`として保存し、Kubernetesクラスターに投入します。 |
| 137 | + |
| 138 | + ```shell |
| 139 | + kubectl create -f pod1.yaml |
| 140 | + ``` |
| 141 | + |
| 142 | +- `default-scheduler`を指定するPodの設定 |
| 143 | + |
| 144 | + {{% code_sample file="admin/sched/pod2.yaml" %}} |
| 145 | + |
| 146 | + 使用するスケジューラーは`spec.schedulerName`の値にスケジューラー名を与えることで指定します。 |
| 147 | + この場合、デフォルトのスケジューラーである`default-scheduler`を指定します。 |
| 148 | + |
| 149 | + このファイルを`pod2.yaml`として保存し、Kubernetesクラスターに投入します。 |
| 150 | + |
| 151 | + ```shell |
| 152 | + kubectl create -f pod2.yaml |
| 153 | + ``` |
| 154 | + |
| 155 | +- `my-scheduler`を指定するPodの設定 |
| 156 | + |
| 157 | + {{% code_sample file="admin/sched/pod3.yaml" %}} |
| 158 | + |
| 159 | + この場合、前述の手順でデプロイした`my-scheduler`を使用してPodを配置することを指定します。 |
| 160 | + `spec.schedulerName`の値は`KubeSchedulerProfile`の`schedulerName`フィールドに設定した名前と一致する必要があります。 |
| 161 | + |
| 162 | + このファイルを`pod3.yaml`として保存し、クラスターに投入します。 |
| 163 | + |
| 164 | + ```shell |
| 165 | + kubectl create -f pod3.yaml |
| 166 | + ``` |
| 167 | + |
| 168 | + 3つのPodがすべて実行中であることを確認します。 |
| 169 | + |
| 170 | + ```shell |
| 171 | + kubectl get pods |
| 172 | + ``` |
| 173 | + |
| 174 | +<!-- discussion --> |
| 175 | + |
| 176 | +### Podが目的のスケジューラーによって配置されたことを確認する |
| 177 | + |
| 178 | +わかりやすさのため、前述の例ではPodが実際に指定したスケジューラーによって配置されたことを確認していません。 |
| 179 | +確認したい場合はPodとDeploymentの設定の適用順序を変えてみてください。 |
| 180 | +もしPodの設定をすべて先に適用し、その後にスケジューラーのDeploymentを適用した場合、`annotation-second-scheduler` Podは「Pending」のままになり、他の2つのPodが先に配置されることを確認できます。 |
| 181 | +その後にスケジューラーのDeploymentを適用して新しいスケジューラーが動作すると、`annotation-second-scheduler` Podも配置されます。 |
| 182 | + |
| 183 | +あるいは、イベントログの「Scheduled」の項目を見ることで、どのPodがどのスケジューラーによって配置されたかを確認できます。 |
| 184 | + |
| 185 | +```shell |
| 186 | +kubectl get events |
| 187 | +``` |
| 188 | + |
| 189 | +クラスターのメインのスケジューラーについては、[独自のスケジューラー設定](/ja/docs/reference/scheduling/config/#multiple-profiles)を適用することや、関連するコントロールプレーンノードにある静的Podのマニフェストを変更し独自のコンテナイメージを使うことができます。 |
0 commit comments