Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ja] Translate content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md into Japanese #49584

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions content/ja/docs/tasks/extend-kubernetes/_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
---
title: "Kubernetesを拡張する"
description: 作業環境の要求にKubernetesクラスターを適応させるための高度な方法を理解します。
weight: 110
---

Original file line number Diff line number Diff line change
@@ -0,0 +1,163 @@
---
title: 複数のスケジューラーを設定する
content_type: task
weight: 20
---

<!-- overview -->

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の実装が参照できます。

## {{% heading "prerequisites" %}}

{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

<!-- steps -->

## スケジューラーをパッケージ化する

スケジューラーのバイナリをコンテナイメージとしてパッケージ化します。例として、標準のスケジューラー(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は次のとおりです:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
kube-schedulerバイナリを含むコンテナイメージを作成します。そのためのDockerfileは次のとおりです:
kube-schedulerバイナリを含むコンテナイメージを作成します。そのための`Dockerfile`は次のとおりです:

Create a container image containing the kube-scheduler binary. Here is the Dockerfile to build the image:

訳した際に、バッククォートが抜けたようです。


```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](/ja/docs/concepts/workloads/controllers/deployment/)を使用します。[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)は[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)を管理し、そのReplicaSetがPodを管理することで、スケジューラーを障害に対して堅牢にします。`my-scheduler.yaml`として保存するDeploymentの設定を示します:

{{% code_sample file="admin/sched/my-scheduler.yaml" %}}

上に示したマニフェストでは、[KubeSchedulerConfiguration](/ja/docs/reference/scheduling/config/)を使用してあなたのスケジューラー実装の振る舞いを変更できます。この設定ファイルは`kube-scheduler`の起動時に`--config`オプションから渡されます。この設定ファイルは`my-scheduler-config`ConfigMapに格納されており、`my-scheduler`DeploymentのPodは`my-scheduler-config`ConfigMapをボリュームとしてマウントします。
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
上に示したマニフェストでは、[KubeSchedulerConfiguration](/ja/docs/reference/scheduling/config/)を使用してあなたのスケジューラー実装の振る舞いを変更できます。この設定ファイルは`kube-scheduler`の起動時に`--config`オプションから渡されます。この設定ファイルは`my-scheduler-config`ConfigMapに格納されており、`my-scheduler`DeploymentのPodは`my-scheduler-config`ConfigMapをボリュームとしてマウントします。
上に示したマニフェストでは、[KubeSchedulerConfiguration](/ja/docs/reference/scheduling/config/)を使用してあなたのスケジューラー実装の振る舞いを変更できます。この設定ファイルは`kube-scheduler`の初期化時に`--config`オプションから渡されます。この設定ファイルは`my-scheduler-config`ConfigMapに格納されており、`my-scheduler`DeploymentのPodは`my-scheduler-config`ConfigMapをボリュームとしてマウントします。

"during initialization"と書かれているため、「初期化時」としておいたほうが正確かと思いました。


前述のスケジューラー設定において、あなたのスケジューラー実装は[KubeSchedulerProfile](/docs/reference/config-api/kube-scheduler-config.v1/#kubescheduler-config-k8s-io-v1-KubeSchedulerProfile)を使って表現されます。
{{< note >}}
特定のPodをどのスケジューラーが処理するかを指定するには、PodTemplateやPodのマニフェストにある`spec.schedulerName`フィールドを`KubeSchedulerProfile`の`schedulerName`フィールドに一致させます。クラスターで動作させるすべてのスケジューラーの名前は一意的である必要があります。
{{< /note >}}

また、専用のサービスアカウント`my-scheduler`を作成して`system:kube-scheduler`ClusterRoleに紐づけを行い、スケジューラーに`kube-scheduler`と同じ権限を付与している点に注意します。

その他のコマンドライン引数の詳細は[kube-schedulerのドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)から、その他の変更可能な`kube-scheduler`の設定は[Scheduler Configurationの仕様](/docs/reference/config-api/kube-scheduler-config.v1/)から確認できます。
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
その他のコマンドライン引数の詳細は[kube-schedulerのドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)から、その他の変更可能な`kube-scheduler`の設定は[Scheduler Configurationの仕様](/docs/reference/config-api/kube-scheduler-config.v1/)から確認できます。
その他のコマンドライン引数の詳細は[kube-schedulerのドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)から、その他の変更可能な`kube-scheduler`の設定は[スケジューラー設定のリファレンス](/docs/reference/config-api/kube-scheduler-config.v1/)から確認できます。

"Scheduler Configuration" は固有の用語でもなさそうですので、訳していいと思います。
Scheduling PoliciesのページにもScheduler Configurationというリンクがあり、日本語ページではスケジューラー設定と訳していました。


## クラスターで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」になっているはずです。

### リーダー選出を有効にする

複数のスケジューラーをリーダー選出を有効にして実行するには、次の対応が必要です:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
複数のスケジューラーをリーダー選出を有効にして実行するには、次の対応が必要です:
リーダー選出を有効にして複数のスケジューラーを実行するには、次の対応が必要です:

順番を入れ替えただけですが、このようにすると、2回出てくる「を」が離れて読みやすくなる気がしました。


YAMLファイルにある`my-scheduler-config`ConfigMap内の`KubeSchedulerConfiguration`の次のフィールドを更新します:

* `leaderElection.leaderElect` を `true` に設定します
* `leaderElection.resourceNamespace` を `<lock-object-namespace>` に設定します
* `leaderElection.resourceName` を `<lock-object-name>` に設定します
Comment on lines +89 to +91
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* `leaderElection.leaderElect``true` に設定します
* `leaderElection.resourceNamespace``<lock-object-namespace>` に設定します
* `leaderElection.resourceName``<lock-object-name>` に設定します
* `leaderElection.leaderElect``true`に設定します
* `leaderElection.resourceNamespace``<lock-object-namespace>`に設定します
* `leaderElection.resourceName``<lock-object-name>`に設定します

空白の削除。


{{< note >}}
ロックオブジェクトはコントロールプレーンが自動的に作成しますが、使用するNamespaceはあらかじめ存在している必要があります。`kube-system`Namespaceを使うこともできます。
{{< /note >}}

クラスターでRBACが有効になっている場合、`system:kube-scheduler`ClusterRoleを更新し、`endpoints`と`leases`リソースに適用されるルールのresourceNamesにスケジューラー名を追加します。例を示します:

```shell
kubectl edit clusterrole system:kube-scheduler
```

{{% code_sample file="admin/sched/clusterrole.yaml" %}}

## Podにスケジューラーを指定する

2つ目のスケジューラーが動作している状態で、Podを標準のスケジューラーまたは新しいスケジューラーのどちらで配置するか指定します。あるPodを特定のスケジューラーで配置するには、Podのspecにスケジューラー名を指定します。3つの例を確認しましょう。
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
2つ目のスケジューラーが動作している状態で、Podを標準のスケジューラーまたは新しいスケジューラーのどちらで配置するか指定します。あるPodを特定のスケジューラーで配置するには、Podのspecにスケジューラー名を指定します。3つの例を確認しましょう。
2つ目のスケジューラーが動作している状態で、Podをいくつか作成し、標準のスケジューラーまたは新しいスケジューラーのどちらで配置するか指定します。あるPodを特定のスケジューラーで配置するには、Podのspecにスケジューラー名を指定します。3つの例を確認しましょう。

Now that your second scheduler is running, create some pods, and direct them to be scheduled by either the default scheduler or the one you deployed.

Podを作成する旨を足しました。


- スケジューラー名を指定しないPodの設定

{{% code_sample file="admin/sched/pod1.yaml" %}}

スケジューラー名が指定されていない場合、Podは自動的にdefault-schedulerによって配置されます。

このファイルを`pod1.yaml`として保存し、Kubernetesクラスターに投入します。

```shell
kubectl create -f pod1.yaml
```

- `default-scheduler`を指定するPodの設定

{{% code_sample file="admin/sched/pod2.yaml" %}}

使用するスケジューラーは`spec.schedulerName`の値にスケジューラー名を与えることで指定します。この場合、標準のスケジューラーである`default-scheduler`を指定します。

このファイルを`pod2.yaml`として保存し、Kubernetesクラスターに投入します。

```shell
kubectl create -f pod2.yaml
```

- `my-scheduler`を指定するPodの設定

{{% code_sample file="admin/sched/pod3.yaml" %}}

この場合、前述の手順でデプロイした`my-scheduler`を使用してPodを配置することを指定します。`spec.schedulerName`の値は`KubeSchedulerProfile`の`schedulerName`フィールドに設定した名前と一致する必要があります。

このファイルを`pod3.yaml`として保存し、クラスターに投入します。

```shell
kubectl create -f pod3.yaml
```

3つのPodがすべて実行中であることを確認します。

```shell
kubectl get pods
```

<!-- discussion -->

### Podが目的のスケジューラーによって配置されたことを確認する

わかりやすさのため、前述の例ではPodが実際に指定したスケジューラーによって配置されたことを確認していません。確認したい場合はPodとDeploymentの設定の適用順序を変えてみてください。もしPodの設定をすべて先に適用し、その後にスケジューラーのDeploymentを適用した場合、`annotation-second-scheduler`Podは「Pending」のままになり、他の2つのPodが先に配置されることを確認できます。その後にスケジューラーのDeploymentを適用して新しいスケジューラーが動作すると、`annotation-second-scheduler`Podも配置されます。

あるいは、イベントログの「Scheduled」の項目を見ることで、どのPodがどのスケジューラーによって配置されたかを確認できます。

```shell
kubectl get events
```

クラスターのメインのスケジューラーについては、[独自のスケジューラー設定](/ja/docs/reference/scheduling/config/#multiple-profiles)を適用することや、関連するコントロールプレーンノードにある静的Podのマニフェストを変更し独自のコンテナイメージを使うことができます。
37 changes: 37 additions & 0 deletions content/ja/examples/admin/sched/clusterrole.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
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
56 changes: 50 additions & 6 deletions content/ja/examples/admin/sched/my-scheduler.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,8 @@ metadata:
name: my-scheduler
namespace: kube-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: my-scheduler-as-kube-scheduler
subjects:
Expand All @@ -17,6 +17,47 @@ roleRef:
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/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: my-scheduler
leaderElection:
leaderElect: false
---
apiVersion: apps/v1
kind: Deployment
metadata:
Expand All @@ -42,9 +83,7 @@ spec:
containers:
- command:
- /usr/local/bin/kube-scheduler
- --address=0.0.0.0
- --leader-elect=false
- --scheduler-name=my-scheduler
- --config=/etc/kubernetes/my-scheduler/my-scheduler-config.yaml
image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
livenessProbe:
httpGet:
Expand All @@ -63,7 +102,12 @@ spec:
cpu: '0.1'
securityContext:
privileged: false
volumeMounts: []
volumeMounts:
- name: config-volume
mountPath: /etc/kubernetes/my-scheduler
hostNetwork: false
hostPID: false
volumes: []
volumes:
- name: config-volume
configMap:
name: my-scheduler-config
2 changes: 1 addition & 1 deletion content/ja/examples/admin/sched/pod1.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -7,4 +7,4 @@ metadata:
spec:
containers:
- name: pod-with-no-annotation-container
image: registry.k8s.io/pause:2.0
image: registry.k8s.io/pause:3.8
2 changes: 1 addition & 1 deletion content/ja/examples/admin/sched/pod2.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -8,4 +8,4 @@ spec:
schedulerName: default-scheduler
containers:
- name: pod-with-default-annotation-container
image: registry.k8s.io/pause:2.0
image: registry.k8s.io/pause:3.8
2 changes: 1 addition & 1 deletion content/ja/examples/admin/sched/pod3.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -8,4 +8,4 @@ spec:
schedulerName: my-scheduler
containers:
- name: pod-with-second-annotation-container
image: registry.k8s.io/pause:2.0
image: registry.k8s.io/pause:3.8