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.

Sign up for GitHub

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] Set heading IDs in daemonset.md and assign-pods-nodes.md #39484

Merged
merged 1 commit into from
Mar 10, 2023
Merged

[ja] Set heading IDs in daemonset.md and assign-pods-nodes.md #39484

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
32 changes: 16 additions & 16 deletions content/ja/docs/concepts/workloads/controllers/daemonset.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,9 +22,9 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。

<!-- body -->

## DaemonSet Specの記述
## DaemonSet Specの記述 {#writing-a-daemonset-spec}

### DaemonSetの作成
### DaemonSetの作成 {#create-a-daemonset}

ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。

Expand All @@ -36,7 +36,7 @@ YAMLファイルに基づいてDaemonSetを作成します。
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
```

### 必須のフィールド
### 必須のフィールド {#required-fields}

他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。設定ファイルの活用法に関する一般的な情報は、[ステートレスアプリケーションの稼働](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。

Expand All @@ -45,7 +45,7 @@ DaemonSetオブジェクトの名前は、有効な

また、DaemonSetにおいて[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)セクションも必須となります。

### Podテンプレート
### Podテンプレート {#pod-template}

`.spec.template`は`.spec`内での必須のフィールドの1つです。

Expand All @@ -55,7 +55,7 @@ Podに対する必須のフィールドに加えて、DaemonSet内のPodテン

DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。

### Podセレクター
### Podセレクター {#pod-selector}

`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。

Expand All @@ -70,14 +70,14 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ

もし`spec.selector`が指定されたとき、`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。

### 選択したNode上でPodを稼働させる
### 選択したNode上でPodを稼働させる {#running-pods-on-select-nodes}

もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node selector](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にマッチするNode上にPodを作成します。同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にマッチするNode上にPodを作成します。
もしユーザーがどちらも指定しないとき、DaemonSetコントローラーは全てのNode上にPodを作成します。

## Daemon Podがどのようにスケジューリングされるか
## Daemon Podがどのようにスケジューリングされるか {#how-daemon-pods-are-scheduled}

### デフォルトスケジューラーによってスケジューリングされる場合
### デフォルトスケジューラーによってスケジューリングされる場合 {#scheduled-by-default-scheduler}
Copy link
Contributor

Choose a reason for hiding this comment

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

This header line was already removed in en.
"scheduled-by-default-scheduler" was correct in older page, I think that it is OK.
I think that this line will be removed in the near future.

Copy link
Contributor

@atoato88 atoato88 Mar 7, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Agree with the comment of @s-kawamura-w664 .


{{< feature-state for_k8s_version="1.17" state="stable" >}}

Expand All @@ -102,7 +102,7 @@ nodeAffinity:

さらに、`node.kubernetes.io/unschedulable:NoSchedule`というtolarationがDaemonSetのPodに自動的に追加されます。デフォルトスケジューラーは、DaemonSetのPodのスケジューリングのときに、`unschedulable`なNodeを無視します。

### TaintsとTolerations
### TaintsとTolerations {#taints-and-tolerations}

DaemonSetのPodは[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。

Expand All @@ -115,7 +115,7 @@ DaemonSetのPodは[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/t
| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。 |
| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | ホストネットワークを使うDaemonSetのPodはデフォルトスケジューラーによってネットワーク利用不可能な属性を許容(tolerate)します。 |

## Daemon Podとのコミュニケーション
## Daemon Podとのコミュニケーション {#communicating-with-daemon-pods}

DaemonSet内のPodとのコミュニケーションをする際に考えられるパターンは以下の通りです。:

Expand All @@ -124,7 +124,7 @@ DaemonSet内のPodとのコミュニケーションをする際に考えられ
- **DNS**: 同じPodセレクターを持つ[HeadlessService](/ja/docs/concepts/services-networking/service/#headless-service)を作成し、`endpoints`リソースを使ってDaemonSetを探すか、DNSから複数のAレコードを取得します。
- **Service**: 同じPodセレクターを持つServiceを作成し、複数のうちのいずれかのNode上のDaemonに疎通させるためにそのServiceを使います。

## DaemonSetの更新
## DaemonSetの更新 {#updating-a-daemonset}

もしNodeラベルが変更されたとき、そのDaemonSetは直ちに新しくマッチしたNodeにPodを追加し、マッチしなくなったNodeからPodを削除します。

Expand All @@ -134,25 +134,25 @@ DaemonSet内のPodとのコミュニケーションをする際に考えられ

ユーザーはDaemonSet上で[ローリングアップデートの実施](/docs/tasks/manage-daemon/update-daemon-set/)が可能です。

## DaemonSetの代替案
## DaemonSetの代替案 {#alternatives-to-daemonset}

### Initスクリプト
### Initスクリプト {#init-scripts}

Node上で直接起動することにより(例: `init`、`upstartd`、`systemd`を使用する)、デーモンプロセスを稼働することが可能です。この方法は非常に良いですが、このようなプロセスをDaemonSetを介して起動することはいくつかの利点があります。

- アプリケーションと同じ方法でデーモンの監視とログの管理ができる。
- デーモンとアプリケーションで同じ設定用の言語とツール(例: Podテンプレート、`kubectl`)を使える。
- リソースリミットを使ったコンテナ内でデーモンを稼働させることにより、デーモンとアプリケーションコンテナの分離を促進します。しかし、これはPod内でなく、コンテナ内でデーモンを稼働させることにより可能です(Dockerを介して直接起動する)。

### ベアPod
### ベアPod {#bare-pods}

特定のNode上で稼働するように指定したPodを直接作成することは可能です。しかし、DaemonSetはNodeの故障やNodeの破壊的なメンテナンスやカーネルのアップグレードなど、どのような理由に限らず、削除されたもしくは停止されたPodを置き換えます。このような理由で、ユーザーはPod単体を作成するよりもむしろDaemonSetを使うべきです。

### 静的Pod Pods
### 静的Pod Pods {#static-pods}

Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/ja/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。

### Deployment
### Deployment {#deployments}

DaemonSetは、Podの作成し、そのPodが停止されることのないプロセスを持つことにおいて[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)と同様です(例: webサーバー、ストレージサーバー)。

Expand Down
8 changes: 4 additions & 4 deletions content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,13 +7,13 @@ weight: 120
<!-- overview -->
このページでは、KubernetesのPodをKubernetesクラスター上の特定のノードに割り当てる方法を説明します。

## {{% heading "prerequisites" %}}
## {{% heading "prerequisites" %}} {#before-you-begin}
Copy link
Contributor

Choose a reason for hiding this comment

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

Currently, the anchor of heading shortcode will be specified like this. I think It is currect.
In the future, I think it would be good to generate the anchor in the headering shortcode.


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

<!-- steps -->

## ラベルをノードに追加する
## ラベルをノードに追加する {#add-a-label-to-a-node}

1. クラスター内の{{< glossary_tooltip term_id="node" text="ノード" >}}のリストをラベル付きで表示します。

Expand Down Expand Up @@ -54,7 +54,7 @@ weight: 120

上の出力を見ると、`worker0`に`disktype=ssd`というラベルがあることがわかります。

## 選択したノードにスケジューリングされるPodを作成する
## 選択したノードにスケジューリングされるPodを作成する {#create-a-pod-that-gets-scheduled-to-your-chosen-node}

以下のPodの構成ファイルには、nodeSelectorに`disktype: ssd`を持つPodが書かれています。これにより、Podは`disktype: ssd`というラベルを持っているノードにスケジューリングされるようになります。

Expand All @@ -79,7 +79,7 @@ weight: 120
nginx 1/1 Running 0 13s 10.200.0.4 worker0
```

## 特定のノードにスケジューリングされるPodを作成する
## 特定のノードにスケジューリングされるPodを作成する {#create-a-pod-that-gets-scheduled-to-specific-node}

`nodeName`という設定を使用して、Podを特定のノードにスケジューリングすることもできます。

Expand Down