Merge branch 'master' into dev-1.19-ja.1
This commit is contained in:
inductor(Kohei)
@@ -0,0 +1,240 @@
|
||||
---
|
||||
title: Podの優先度とプリエンプション
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
[Pod](/ja/docs/concepts/workloads/pods/)は _priority_（優先度）を持つことができます。
|
||||
優先度は他のPodに対する相対的なPodの重要度を示します。
|
||||
もしPodをスケジューリングできないときには、スケジューラーはそのPodをスケジューリングできるようにするため、優先度の低いPodをプリエンプトする（追い出す）ことを試みます。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
||||
{{< warning >}}
|
||||
クラスターの全てのユーザーが信用されていない場合、悪意のあるユーザーが可能な範囲で最も高い優先度のPodを作成することが可能です。これは他のPodが追い出されたりスケジューリングできない状態を招きます。
|
||||
管理者はResourceQuotaを使用して、ユーザーがPodを高い優先度で作成することを防ぐことができます。
|
||||
|
||||
詳細は[デフォルトで優先度クラスの消費を制限する](/ja/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
|
||||
を参照してください。
|
||||
{{< /warning >}}
|
||||
|
||||
## 優先度とプリエンプションを使う方法
|
||||
|
||||
優先度とプリエンプションを使うには、
|
||||
|
||||
1. 1つまたは複数の[PriorityClass](#priorityclass)を追加します
|
||||
|
||||
1. 追加したPriorityClassを[`priorityClassName`](#pod-priority)に設定したPodを作成します。
|
||||
もちろんPodを直接作る必要はありません。
|
||||
一般的には`priorityClassName`をDeploymentのようなコレクションオブジェクトのPodテンプレートに追加します。
|
||||
|
||||
これらの手順のより詳しい情報については、この先を読み進めてください。
|
||||
|
||||
{{< note >}}
|
||||
Kubernetesには最初から既に2つのPriorityClassが設定された状態になっています。
|
||||
`system-cluster-critical`と`system-node-critical`です。
|
||||
これらは汎用のクラスであり、[重要なコンポーネントが常に最初にスケジュールされることを保証する](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)ために使われます。
|
||||
{{< /note >}}
|
||||
|
||||
## PriorityClass
|
||||
|
||||
PriorityClassはnamespaceによらないオブジェクトで、優先度クラスの名称から優先度を表す整数値への対応を定義します。
|
||||
PriorityClassオブジェクトのメタデータの`name`フィールドにて名称を指定します。
|
||||
値は`value`フィールドで指定し、必須です。
|
||||
値が大きいほど、高い優先度を示します。
|
||||
PriorityClassオブジェクトの名称は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)として適切であり、かつ`system-`から始まってはいけません。
|
||||
|
||||
PriorityClassオブジェクトは10億以下の任意の32ビットの整数値を持つことができます。
|
||||
それよりも大きな値は通常はプリエンプトや追い出すべきではない重要なシステム用のPodのために予約されています。
|
||||
クラスターの管理者は割り当てたい優先度に対して、PriorityClassオブジェクトを1つずつ作成すべきです。
|
||||
|
||||
PriorityClassは任意でフィールド`globalDefault`と`description`を設定可能です。
|
||||
`globalDefault`フィールドは`priorityClassName`が指定されないPodはこのPriorityClassを使うべきであることを示します。`globalDefault`がtrueに設定されたPriorityClassはシステムで一つのみ存在可能です。`globalDefault`が設定されたPriorityClassが存在しない場合は、`priorityClassName`が設定されていないPodの優先度は0に設定されます。
|
||||
|
||||
`description`フィールドは任意の文字列です。クラスターの利用者に対して、PriorityClassをどのような時に使うべきか示すことを意図しています。
|
||||
|
||||
### PodPriorityと既存のクラスターに関する注意
|
||||
|
||||
- もし既存のクラスターをこの機能がない状態でアップグレードすると、既存のPodの優先度は実質的に0になります。
|
||||
|
||||
- `globalDefault`が`true`に設定されたPriorityClassを追加しても、既存のPodの優先度は変わりません。PriorityClassのそのような値は、PriorityClassが追加された以後に作成されたPodのみに適用されます。
|
||||
|
||||
- PriorityClassを削除した場合、削除されたPriorityClassの名前を使用する既存のPodは変更されませんが、削除されたPriorityClassの名前を使うPodをそれ以上作成することはできなくなります。
|
||||
|
||||
### PriorityClassの例
|
||||
|
||||
```yaml
|
||||
apiVersion: scheduling.k8s.io/v1
|
||||
kind: PriorityClass
|
||||
metadata:
|
||||
name: high-priority
|
||||
value: 1000000
|
||||
globalDefault: false
|
||||
description: "この優先度クラスはXYZサービスのPodに対してのみ使用すべきです。"
|
||||
```
|
||||
|
||||
## 非プリエンプトのPriorityClass {#non-preempting-priority-class}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
`PreemptionPolicy: Never`と設定されたPodは、スケジューリングのキューにおいて他の優先度の低いPodよりも優先されますが、他のPodをプリエンプトすることはありません。
|
||||
スケジューリングされるのを待つ非プリエンプトのPodは、リソースが十分に利用可能になるまでスケジューリングキューに残ります。
|
||||
非プリエンプトのPodは、他のPodと同様に、スケジューラーのバックオフの対象になります。これは、スケジューラーがPodをスケジューリングしようと試みたものの失敗した場合、低い頻度で再試行するようにして、より優先度の低いPodが先にスケジューリングされることを許します。
|
||||
|
||||
非プリエンプトのPodは、他の優先度の高いPodにプリエンプトされる可能性はあります。
|
||||
|
||||
`PreemptionPolicy`はデフォルトでは`PreemptLowerPriority`に設定されており、これが設定されているPodは優先度の低いPodをプリエンプトすることを許容します。これは既存のデフォルトの挙動です。
|
||||
`PreemptionPolicy`を`Never`に設定すると、これが設定されたPodはプリエンプトを行わないようになります。
|
||||
|
||||
ユースケースの例として、データサイエンスの処理を挙げます。
|
||||
ユーザーは他の処理よりも優先度を高くしたいジョブを追加できますが、そのとき既存の実行中のPodの処理結果をプリエンプトによって破棄させたくはありません。
|
||||
`PreemptionPolicy: Never`が設定された優先度の高いジョブは、他の既にキューイングされたPodよりも先に、クラスターのリソースが「自然に」開放されたときにスケジューリングされます。
|
||||
|
||||
### 非プリエンプトのPriorityClassの例
|
||||
|
||||
```yaml
|
||||
apiVersion: scheduling.k8s.io/v1
|
||||
kind: PriorityClass
|
||||
metadata:
|
||||
name: high-priority-nonpreempting
|
||||
value: 1000000
|
||||
preemptionPolicy: Never
|
||||
globalDefault: false
|
||||
description: "この優先度クラスは他のPodをプリエンプトさせません。"
|
||||
```
|
||||
|
||||
## Podの優先度 {#pod-priority}
|
||||
|
||||
一つ以上のPriorityClassがあれば、仕様にPriorityClassを指定したPodを作成することができるようになります。優先度のアドミッションコントローラーは`priorityClassName`フィールドを使用し、優先度の整数値を設定します。PriorityClassが見つからない場合、そのPodの作成は拒否されます。
|
||||
|
||||
下記のYAMLは上記の例で作成したPriorityClassを使用するPodの設定の例を示します。優先度のアドミッションコントローラーは仕様を確認し、このPodの優先度は1000000であると設定します。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
env: test
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
imagePullPolicy: IfNotPresent
|
||||
priorityClassName: high-priority
|
||||
```
|
||||
|
||||
### スケジューリング順序におけるPodの優先度の効果
|
||||
|
||||
Podの優先度が有効な場合、スケジューラーは待機状態のPodをそれらの優先度順に並べ、スケジューリングキューにおいてより優先度の低いPodよりも前に来るようにします。その結果、その条件を満たしたときには優先度の高いPodは優先度の低いPodより早くスケジューリングされます。優先度の高いPodがスケジューリングできない場合は、スケジューラーは他の優先度の低いPodのスケジューリングも試みます。
|
||||
|
||||
## プリエンプション
|
||||
|
||||
Podが作成されると、スケジューリング待ちのキューに入り待機状態になります。スケジューラーはキューからPodを取り出し、ノードへのスケジューリングを試みます。Podに指定された条件を全て満たすノードが見つからない場合は、待機状態のPodのためにプリエンプションロジックが発動します。待機状態のPodをPと呼ぶことにしましょう。プリエンプションロジックはPよりも優先度の低いPodを一つ以上追い出せばPをスケジューリングできるようになるノードを探します。そのようなノードがあれば、優先度の低いPodはノードから追い出されます。Podが追い出された後に、Pはノードへスケジューリング可能になります。
|
||||
|
||||
### ユーザーへ開示される情報
|
||||
|
||||
Pod PがノードNのPodをプリエンプトした場合、ノードNの名称がPのステータスの`nominatedNodeName`フィールドに設定されます。このフィールドはスケジューラーがPod Pのために予約しているリソースの追跡を助け、ユーザーにクラスターにおけるプリエンプトに関する情報を与えます。
|
||||
|
||||
Pod Pは必ずしも「指名したノード」へスケジューリングされないことに注意してください。Podがプリエンプトされると、そのPodは終了までの猶予期間を得ます。スケジューラーがPodの終了を待つ間に他のノードが利用可能になると、スケジューラーは他のノードをPod Pのスケジューリング先にします。この結果、Podの`nominatedNodeName`と`nodeName`は必ずしも一致しません。また、スケジューラーがノードNのPodをプリエンプトさせた後に、Pod Pよりも優先度の高いPodが来た場合、スケジューラーはノードNをその新しい優先度の高いPodへ与えます。このような場合は、スケジューラーはPod Pの`nominatedNodeName`を消去します。これによって、スケジューラーはPod Pが他のノードのPodをプリエンプトさせられるようにします。
|
||||
|
||||
### プリエンプトの制限
|
||||
|
||||
#### プリエンプトされるPodの正常終了
|
||||
|
||||
Podがプリエンプトされると、[猶予期間](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)が与えられます。
|
||||
|
||||
Podは作業を完了し、終了するために十分な時間が与えられます。仮にそうでない場合、強制終了されます。この猶予期間によって、スケジューラーがPodをプリエンプトした時刻と、待機状態のPod Pがノード Nにスケジュール可能になるまでの時刻の間に間が開きます。この間、スケジューラーは他の待機状態のPodをスケジュールしようと試みます。プリエンプトされたPodが終了したら、スケジューラーは待ち行列にあるPodをスケジューリングしようと試みます。そのため、Podがプリエンプトされる時刻と、Pがスケジュールされた時刻には間が開くことが一般的です。この間を最小にするには、優先度の低いPodの猶予期間を0または小さい値にする方法があります。
|
||||
|
||||
#### PodDisruptionBudgetは対応するが、保証されない
|
||||
|
||||
[PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB)は、アプリケーションのオーナーが冗長化されたアプリケーションのPodが意図的に中断される数の上限を設定できるようにするものです。KubernetesはPodをプリエンプトする際にPDBに対応しますが、PDBはベストエフォートで考慮します。スケジューラーはプリエンプトさせたとしてもPDBに違反しないPodを探します。そのようなPodが見つからない場合でもプリエンプションは実行され、PDBに反しますが優先度の低いPodが追い出されます。
|
||||
|
||||
#### 優先度の低いPodにおけるPod間のアフィニティ
|
||||
|
||||
次の条件が真の場合のみ、ノードはプリエンプションの候補に入ります。
|
||||
「待機状態のPodよりも優先度の低いPodをノードから全て追い出したら、待機状態のPodをノードへスケジュールできるか」
|
||||
|
||||
{{< note >}}
|
||||
プリエンプションは必ずしも優先度の低いPodを全て追い出しません。
|
||||
優先度の低いPodを全て追い出さなくても待機状態のPodがスケジューリングできる場合、一部のPodのみ追い出されます。
|
||||
このような場合であったとしても、上記の条件は真である必要があります。偽であれば、そのノードはプリエンプションの対象とはされません。
|
||||
{{< /note >}}
|
||||
|
||||
待機状態のPodが、優先度の低いPodとの間でPod間のアフィニティを持つ場合、Pod間のアフィニティはそれらの優先度の低いPodがなければ満たされません。この場合、スケジューラーはノードのどのPodもプリエンプトしようとはせず、代わりに他のノードを探します。スケジューラーは適切なノードを探せる場合と探せない場合があります。この場合、待機状態のPodがスケジューリングされる保証はありません。
|
||||
|
||||
この問題に対して推奨される解決策は、優先度が同一または高いPodに対してのみPod間のアフィニティを作成することです。
|
||||
|
||||
#### 複数ノードに対するプリエンプション
|
||||
|
||||
Pod PがノードNにスケジューリングできるよう、ノードNがプリエンプションの対象となったとします。
|
||||
他のノードのPodがプリエンプトされた場合のみPが実行可能になることもあります。下記に例を示します。
|
||||
|
||||
* Pod PをノードNに配置することを検討します。
|
||||
* Pod QはノードNと同じゾーンにある別のノードで実行中です。
|
||||
* Pod Pはゾーンに対するQへのアンチアフィニティを持ちます (`topologyKey: topology.kubernetes.io/zone`)。
|
||||
* Pod Pと、ゾーン内の他のPodに対しては他のアンチアフィニティはない状態です。
|
||||
* Pod PをノードNへスケジューリングするには、Pod Qをプリエンプトすることが考えられますが、スケジューラーは複数ノードにわたるプリエンプションは行いません。そのため、Pod PはノードNへはスケジューリングできないとみなされます。
|
||||
|
||||
Pod Qがそのノードから追い出されると、Podアンチアフィニティに違反しなくなるので、Pod PはノードNへスケジューリング可能になります。
|
||||
|
||||
複数ノードに対するプリエンプションに関しては、十分な需要があり、合理的な性能を持つアルゴリズムを見つけられた場合に、追加することを検討する可能性があります。
|
||||
|
||||
## トラブルシューティング
|
||||
|
||||
Podの優先度とプリエンプションは望まない副作用をもたらす可能性があります。
|
||||
いくつかの起こりうる問題と、その対策について示します。
|
||||
|
||||
### Podが不必要にプリエンプトされる
|
||||
|
||||
プリエンプションは、リソースが不足している場合に優先度の高い待機状態のPodのためにクラスターの既存のPodを追い出します。
|
||||
誤って高い優先度をPodに割り当てると、意図しない高い優先度のPodはクラスター内でプリエンプションを引き起こす可能性があります。Podの優先度はPodの仕様の`priorityClassName`フィールドにて指定されます。優先度を示す整数値へと変換された後、`podSpec`の`priority`へ設定されます。
|
||||
|
||||
この問題に対処するには、Podの`priorityClassName`をより低い優先度に変更するか、このフィールドを未設定にすることができます。`priorityClassName`が未設定の場合、デフォルトでは優先度は0とされます。
|
||||
|
||||
Podがプリエンプトされたとき、プリエンプトされたPodのイベントが記録されます。
|
||||
プリエンプションはPodに必要なリソースがクラスターにない場合のみ起こるべきです。
|
||||
このような場合、プリエンプションはプリエンプトされるPodよりも待機状態のPodの優先度が高い場合のみ発生します。
|
||||
プリエンプションは待機状態のPodがない場合や待機状態のPodがプリエンプト対象のPod以下の優先度を持つ場合には決して発生しません。そのような状況でプリエンプションが発生した場合、問題を報告してください。
|
||||
|
||||
### Podはプリエンプトされたが、プリエンプトさせたPodがスケジューリングされない
|
||||
|
||||
Podがプリエンプトされると、それらのPodが要求した猶予期間が与えられます。そのデフォルトは30秒です。
|
||||
Podがその期間内に終了しない場合、強制終了されます。プリエンプトされたPodがなくなれば、プリエンプトさせたPodはスケジューリング可能です。
|
||||
|
||||
プリエンプトさせたPodがプリエンプトされたPodの終了を待っている間に、より優先度の高いPodが同じノードに対して作成されることもあります。この場合、スケジューラーはプリエンプトさせたPodの代わりに優先度の高いPodをスケジューリングします。
|
||||
|
||||
これは予期された挙動です。優先度の高いPodは優先度の低いPodに取って代わります。
|
||||
|
||||
### 優先度の高いPodが優先度の低いPodより先にプリエンプトされる
|
||||
|
||||
スケジューラーは待機状態のPodが実行可能なノードを探します。ノードが見つからない場合、スケジューラーは任意のノードから優先度の低いPodを追い出し、待機状態のPodのためのリソースを確保しようとします。
|
||||
仮に優先度の低いPodが動いているノードが待機状態のPodを動かすために適切ではない場合、スケジューラーは他のノードで動いているPodと比べると、優先度の高いPodが動いているノードをプリエンプションの対象に選ぶことがあります。この場合もプリエンプトされるPodはプリエンプトを起こしたPodよりも優先度が低い必要があります。
|
||||
|
||||
複数のノードがプリエンプションの対象にできる場合、スケジューラーは優先度が最も低いPodのあるノードを選ぼうとします。しかし、そのようなPodがPodDisruptionBudgetを持っており、プリエンプトするとPDBに反する場合はスケジューラーは優先度の高いPodのあるノードを選ぶこともあります。
|
||||
|
||||
複数のノードがプリエンプションの対象として利用可能で、上記の状況に当てはまらない場合、スケジューラーは優先度の最も低いノードを選択します。
|
||||
|
||||
## Podの優先度とQoSの相互作用 {#interactions-of-pod-priority-and-qos}
|
||||
|
||||
Podの優先度と{{< glossary_tooltip text="QoSクラス" term_id="qos-class" >}}は直交する機能で、わずかに相互作用がありますが、デフォルトではQoSクラスによる優先度の設定の制約はありません。スケジューラーのプリエンプションのロジックはプリエンプションの対象を決めるときにQoSクラスは考慮しません。
|
||||
プリエンプションはPodの優先度を考慮し、優先度が最も低いものを候補とします。より優先度の高いPodは優先度の低いPodを追い出すだけではプリエンプトを起こしたPodのスケジューリングに不十分な場合と、`PodDisruptionBudget`により優先度の低いPodが保護されている場合のみ対象になります。
|
||||
|
||||
QoSとPodの優先度の両方を考慮するコンポーネントは[リソース不足によりkubeletがPodを追い出す](/docs/tasks/administer-cluster/out-of-resource/)のみです。
|
||||
kubeletは追い出すPodの順位付けを次の順で行います。枯渇したリソースを要求以上に使用しているか、優先度、枯渇したリソースの消費量の複数のPodの要求に対する相対値。
|
||||
詳細は[エンドユーザーのPodの追い出し](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)を参照してください。
|
||||
|
||||
|
||||
kubeletによるリソース不足時のPodの追い出しでは、リソースの消費が要求を超えないPodは追い出されません。優先度の低いPodのリソースの利用量がその要求を超えていなければ、追い出されることはありません。より優先度が高く、要求を超えてリソースを使用しているPodが追い出されます。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* PriorityClassと関連付けてResourceQuotaを使用することに関して [デフォルトで優先度クラスの消費を制限する](/ja/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
|
||||
@@ -21,7 +21,7 @@ no_list: true
|
||||
## コンテナイメージ
|
||||
[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。
|
||||
|
||||
設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいコンテナをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。
|
||||
設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいイメージをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。
|
||||
|
||||
## コンテナランタイム
|
||||
|
||||
|
||||
@@ -20,8 +20,8 @@ weight: 10
|
||||
リソースクォータは下記のように働きます。
|
||||
|
||||
- 異なる名前空間で異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。
|
||||
- 管理者は各名前空間で1つのResourceQuotaを作成します。
|
||||
- ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムがResourceQuotaによって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。
|
||||
- 管理者は各名前空間で1つの`ResourceQuota`を作成します。
|
||||
- ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。
|
||||
- リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。
|
||||
- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)で参照できます。
|
||||
|
||||
@@ -525,7 +525,7 @@ ResourceQuotaはクラスター容量に依存しません。またユニット
|
||||
|
||||
リソースクォータは集約されたクラスターリソースを分割しますが、ノードに対しては何の制限も行わないことに注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。
|
||||
|
||||
## デフォルトで優先度クラスの消費を制限する
|
||||
## デフォルトで優先度クラスの消費を制限する {#limit-priority-class-consumption-by-default}
|
||||
|
||||
例えば"cluster-services"のように、条件に一致するクォータオブジェクトが存在する場合に限り、特定の優先度のPodを名前空間で許可することが望ましい場合があります。
|
||||
|
||||
|
||||
@@ -42,7 +42,7 @@ weight: 80
|
||||
|
||||
エフェメラルコンテナを利用する場合には、他のコンテナ内のプロセスにアクセスできるように、[プロセス名前空間の共有](/ja/docs/tasks/configure-pod-container/share-process-namespace/)を有効にすると便利です。
|
||||
|
||||
エフェメラルコンテナを利用してトラブルシューティングを行う例については、[デバッグ用のエフェメラルコンテナを使用してデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)を参照してください。
|
||||
エフェメラルコンテナを利用してトラブルシューティングを行う例については、[デバッグ用のエフェメラルコンテナを使用してデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)を参照してください。
|
||||
|
||||
## Ephemeral containers API
|
||||
|
||||
@@ -59,7 +59,7 @@ weight: 80
|
||||
"apiVersion": "v1",
|
||||
"kind": "EphemeralContainers",
|
||||
"metadata": {
|
||||
"name": "example-pod"
|
||||
"name": "example-pod"
|
||||
},
|
||||
"ephemeralContainers": [{
|
||||
"command": [
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: 新しいコンテンツの貢献
|
||||
weight: 20
|
||||
---
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: 新しいコンテンツの貢献の概要
|
||||
linktitle: 概要
|
||||
content_type: concept
|
||||
main_menu: true
|
||||
weight: 5
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
このセクションでは、新しいコンテンツの貢献を行う前に知っておくべき情報を説明します。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 貢献の基本
|
||||
|
||||
- KubernetesのドキュメントはMarkdownで書き、Kubernetesのウェブサイトは[Hugo](https://gohugo.io/)を使ってビルドします。
|
||||
- ソースは[GitHub](https://github.com/kubernetes/website)にあります。Kubernetesのドキュメントは`/content/en/docs/`にあります。リファレンスドキュメントの一部は、`update-imported-docs/`ディレクトリ内のスクリプトから自動的に生成されます。
|
||||
- [Page content types](/docs/contribute/style/page-content-types/)にHugoによるドキュメントのコンテンツの見え方を記述しています。
|
||||
- 標準のHugoのshortcodeに加えて、多数の[カスタムのHugo shortcode](/docs/contribute/style/hugo-shortcodes/)を使用してコンテンツの見え方をコントロールしています。
|
||||
- ドキュメントのソースは`/content/`内にある複数の言語で利用できます。各言語はそれぞれ[ISO 639-1標準](https://www.loc.gov/standards/iso639-2/php/code_list.php)で定義された2文字のコードの名前のフォルダを持ちます。たとえば、英語のドキュメントのソースは`/content/en/docs/`内に置かれています。
|
||||
- 複数言語でのドキュメントへの貢献や新しい翻訳の開始に関する情報については、[Kubernetesのドキュメントを翻訳する](/docs/contribute/localization)を参照してください。
|
||||
|
||||
## 始める前に {#before-you-begin}
|
||||
|
||||
### CNCF CLAに署名する {#sign-the-cla}
|
||||
|
||||
すべてのKubernetesのコントリビューターは、[コントリビューターガイド](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)を読み、[Contributor License Agreement(コントリビューターライセンス契約、CLA)への署名](https://github.com/kubernetes/community/blob/master/CLA.md)を**必ず行わなければなりません**。
|
||||
|
||||
CLAへの署名が完了していないコントリビューターからのpull requestは、自動化されたテストで失敗します。名前とメールアドレスは`git config`コマンドで表示されるものに一致し、gitの名前とメールアドレスはCNCF CLAで使われたものに一致しなければなりません。
|
||||
|
||||
### どのGitブランチを使用するかを選ぶ
|
||||
|
||||
pull requestをオープンするときは、どのブランチをベースにして作業するかをあらかじめ知っておく必要があります。
|
||||
|
||||
シナリオ | ブランチ
|
||||
:---------|:------------
|
||||
現在のリリースに対する既存または新しい英語のコンテンツ | `master`
|
||||
機能変更のリリースに対するコンテンツ | 機能変更が含まれるメジャーおよびマイナーバージョンに対応する、`dev-<version>`というパターンのブランチを使います。たとえば、機能変更が`v{{< skew nextMinorVersion >}}`に含まれる場合、ドキュメントの変更は``dev-{{< skew nextMinorVersion >}}``ブランチに追加します。
|
||||
他の言語内のコンテンツ(翻訳) | 各翻訳対象の言語のルールに従います。詳しい情報は、[翻訳のブランチ戦略](/docs/contribute/localization/#branching-strategy)を読んでください。
|
||||
|
||||
それでも選ぶべきブランチがわからないときは、Slack上の`#sig-docs`チャンネルで質問してください。
|
||||
|
||||
{{< note >}}
|
||||
すでにpull requestを作成していて、ベースブランチが間違っていたことに気づいた場合は、作成者であるあなただけがベースブランチを変更できます。
|
||||
{{< /note >}}
|
||||
|
||||
### 言語ごとのPR
|
||||
|
||||
pull requestはPRごとに1つの言語に限定してください。複数の言語に同一の変更を行う必要がある場合は、言語ごとに別々のPRを作成してください。
|
||||
|
||||
## コントリビューターのためのツール
|
||||
|
||||
`kubernetes/website`リポジトリ内の[doc contributors tools](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools)ディレクトリには、コントリビューターとしての旅を楽にしてくれるツールがあります。
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
title: SIG Docsへの参加
|
||||
content_type: concept
|
||||
weight: 60
|
||||
card:
|
||||
name: contribute
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
SIG Docsは、Kubernetesプロジェクト内の
|
||||
[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)の1つであり、
|
||||
Kubernetes全体のドキュメントの作成、更新、および保守に重点を置いています。
|
||||
SIGの詳細については、[SIG DocsのGithubリポジトリ](https://github.com/kubernetes/community/blob/master/sig-list.md)を参照してください。
|
||||
|
||||
SIG Docsは、すべての寄稿者からのコンテンツとレビューを歓迎します。
|
||||
誰でもPull Request(PR)を開くことができ、コンテンツに関するissueを提出したり、進行中のPull Requestにコメントしたりできます。
|
||||
|
||||
あなたは、[member](/docs/contribute/participate/roles-and-responsibilities/#members)や、
|
||||
[reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers)、
|
||||
[approver](/docs/contribute/participate/roles-and-responsibilities/#approvers)になることもできます。
|
||||
これらの役割にはより多くのアクセスが必要であり、変更を承認およびコミットするための特定の責任が伴います。
|
||||
Kubernetesコミュニティ内でメンバーシップがどのように機能するかについての詳細は、
|
||||
[community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
|
||||
をご覧ください。
|
||||
|
||||
このドキュメントの残りの部分では、kubernetesの中で最も広く公開されている
|
||||
Kubernetesのウェブサイトとドキュメントの管理を担当しているSIG Docsの中で、これらの役割がどのように機能するのかを概説します。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## SIG Docs chairperson
|
||||
|
||||
SIG Docsを含む各SIGは、議長として機能する1人以上のSIGメンバーを選択します。
|
||||
これらは、SIGDocsとKubernetes organizationの他の部分との連絡先です。
|
||||
それらには、Kubernetesプロジェクト全体の構造と、SIG Docsがその中でどのように機能するかについての広範な知識が必要です。
|
||||
現在のchairpersonのリストについては、
|
||||
[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)
|
||||
を参照してください。
|
||||
|
||||
## SIG Docs teamsと自動化
|
||||
|
||||
SIG Docsの自動化は、GitHub teamsとOWNERSファイルの2つの異なるメカニズムに依存しています。
|
||||
|
||||
### GitHub teams
|
||||
|
||||
GitHubには、二つのSIG Docs
|
||||
[teams](https://github.com/orgs/kubernetes/teams?query=sig-docs)
|
||||
カテゴリがあります:
|
||||
|
||||
- `@sig-docs-{language}-owners`は承認者かつリードです。
|
||||
- `@sig-docs-{language}-reviewers` はレビュアーです。
|
||||
|
||||
それぞれをGitHubコメントの`@name`で参照して、そのグループの全員とコミュニケーションできます。
|
||||
|
||||
ProwチームとGitHub teamsが完全に一致せずに重複する場合があります。
|
||||
問題の割り当て、Pull Request、およびPR承認のサポートのために、自動化ではOWNERSファイルからの情報を使用します。
|
||||
|
||||
### OWNERSファイルとfront-matter
|
||||
|
||||
Kubernetesプロジェクトは、GitHubのissueとPull Requestに関連する自動化のためにprowと呼ばれる自動化ツールを使用します。
|
||||
[Kubernetes Webサイトリポジトリ](https://github.com/kubernetes/website)
|
||||
は、2つの[prowプラグイン](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)を使用します：
|
||||
|
||||
- blunderbuss
|
||||
- approve
|
||||
|
||||
これらの2つのプラグインは`kubernetes.website`のGithubリポジトリのトップレベルにある
|
||||
[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)ファイルと、
|
||||
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)ファイルを使用して、
|
||||
リポジトリ内でのprowの動作を制御します。
|
||||
|
||||
OWNERSファイルには、SIG Docsのレビュー担当者および承認者であるユーザーのリストが含まれています。
|
||||
OWNERSファイルはサブディレクトリに存在することもでき、そのサブディレクトリとその子孫のファイルのレビュー担当者または承認者として機能できるユーザーを上書きできます。
|
||||
一般的なOWNERSファイルの詳細については、
|
||||
[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)を参照してください。
|
||||
|
||||
さらに、個々のMarkdownファイルは、個々のGitHubユーザー名またはGitHubグループを一覧表示することにより、そのfront-matterでレビュー担当者と承認者を一覧表示できます。
|
||||
|
||||
OWNERSファイルとMarkdownファイルのfront-matterの組み合わせにより、PRの技術的および編集上のレビューを誰に依頼するかについてPRの所有者が自動化システムから得るアドバイスが決まります。
|
||||
|
||||
## マージの仕組み
|
||||
|
||||
Pull Requestがコンテンツの公開に使用されるブランチにマージされると、そのコンテンツは http://kubernetes.io に公開されます。
|
||||
公開されたコンテンツの品質を高くするために、Pull RequestのマージはSIG Docsの承認者に限定しています。仕組みは次のとおりです。
|
||||
|
||||
- Pull Requestに`lgtm`ラベルと`approve`ラベルの両方があり、`hold`ラベルがなく、すべてのテストに合格すると、Pull Requestは自動的にマージされます。
|
||||
- Kubernetes organizationのメンバーとSIG Docsの承認者はコメントを追加して、特定のPull Requestが自動的にマージされないようにすることができます(`/hold`コメントを追加するか、`/lgtm`コメントを保留します)。
|
||||
- Kubernetesメンバーは誰でも、`/lgtm`コメントを追加することで`lgtm`ラベルを追加できます。
|
||||
- `/approve`コメントを追加してPull Requestをマージできるのは、SIG Docsの承認者だけです。一部の承認者は、[PR Wrangler](/docs/contribute/participate/pr-wranglers/)や[SIG Docsのchairperson](#sig-docs-chairperson)など、追加の特定の役割も実行します。
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Kubernetesドキュメントへの貢献の詳細については、以下を参照してください：
|
||||
|
||||
- [Contributing new content](/docs/contribute/new-content/overview/)
|
||||
- [Reviewing content](/docs/contribute/review/reviewing-prs)
|
||||
- [ドキュメントスタイルの概要](/ja/docs/contribute/style/)
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: プルリクエストのレビュー
|
||||
content_type: concept
|
||||
main_menu: true
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
ドキュメントのプルリクエストは誰でもレビューすることができます。Kubernetesのwebsiteリポジトリで[pull requests](https://github.com/kubernetes/website/pulls)のセクションに移動し、open状態のプルリクエストを確認してください。
|
||||
|
||||
ドキュメントのプルリクエストのレビューは、Kubernetesコミュニティに自分を知ってもらうためのよい方法の1つです。コードベースについて学んだり、他のコントリビューターとの信頼関係を築く助けともなるはずです。
|
||||
|
||||
レビューを行う前には、以下のことを理解しておくとよいでしょう。
|
||||
|
||||
- [コンテンツガイド](/docs/contribute/style/content-guide/)と[スタイルガイド](/docs/contribute/style/style-guide/)を読んで、有益なコメントを残せるようにする。
|
||||
- Kubernetesのドキュメントコミュニティにおける[役割と責任](/docs/contribute/participate/roles-and-responsibilities/)の違いを理解する。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## はじめる前に
|
||||
|
||||
レビューを始める前に、以下のことを心に留めてください。
|
||||
|
||||
- [CNCFの行動規範](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)を読み、いかなる時にも行動規範にしたがって行動するようにする。
|
||||
- 礼儀正しく、思いやりを持ち、助け合う気持ちを持つ。
|
||||
- 変更点だけでなく、PRのポジティブな側面についてもコメントする。
|
||||
- 相手の気持ちに共感して、自分のレビューが相手にどのように受け取られるのかをよく意識する。
|
||||
- 相手の善意を前提として、疑問点を明確にする質問をする。
|
||||
- 経験を積んだコントリビューターの場合、コンテンツに大幅な変更が必要な新規のコントリビューターとペアを組んで作業に取り組むことを考える。
|
||||
|
||||
## レビューのプロセス
|
||||
|
||||
一般に、コンテンツや文体に対するプルリクエストは、英語でレビューを行います。
|
||||
|
||||
1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)に移動します。Kubernetesのウェブサイトとドキュメントに対するopen状態のプルリクエスト一覧が表示されます。
|
||||
|
||||
2. open状態のPRに、以下に示すラベルを1つ以上使って絞り込みます。
|
||||
|
||||
- `cncf-cla: yes` (推奨): CLAにサインしていないコントリビューターが提出したPRはマージできません。詳しい情報は、[CLAの署名](/docs/contribute/new-content/overview/#sign-the-cla)を読んでください。
|
||||
- `language/en` (推奨): 英語のPRだけに絞り込みます。
|
||||
- `size/<size>`: 特定の大きさのPRだけに絞り込みます。レビューを始めたばかりの人は、小さなPRから始めてください。
|
||||
|
||||
さらに、PRがwork in progressとしてマークされていないことも確認してください。`work in progress`ラベルの付いたPRは、まだレビューの準備ができていない状態です。
|
||||
|
||||
3. レビューするPRを選んだら、以下のことを行い、変更点について理解します。
|
||||
- PRの説明を読み、行われた変更について理解し、関連するissueがあればそれも読みます。
|
||||
- 他のレビュアのコメントがあれば読みます。
|
||||
- **Files changed**タブをクリックし、変更されたファイルと行を確認します。
|
||||
- **Conversation**タブの下にあるPRのbuild checkセクションまでスクロールし、**deploy/netlify**の行の**Details**リンクをクリックして、Netlifyのプレビュービルドで変更点をプレビューします。
|
||||
|
||||
4. **Files changed**タブに移動してレビューを始めます。
|
||||
1. コメントしたい場合は行の横の`+`マークをクリックします。
|
||||
2. その行に関するコメントを書き、**Add single comment**(1つのコメントだけを残したい場合)または**Start a review**(複数のコメントを行いたい場合)のいずれかをクリックします。
|
||||
3. コメントをすべて書いたら、ページ上部の**Review changes**をクリックします。ここでは、レビューの要約を追加できます(コントリビューターにポジティブなコメントも書きましょう！)。必要に応じて、PRを承認したり、コメントしたり、変更をリクエストします。新しいコントリビューターの場合は**Comment**だけが行えます。
|
||||
|
||||
## レビューのチェックリスト
|
||||
|
||||
レビューするときは、最初に以下の点を確認してみてください。
|
||||
|
||||
### 言語と文法
|
||||
|
||||
- 言語や文法に明らかな間違いはないですか？ もっとよい言い方はないですか？
|
||||
- もっと簡単な単語に置き換えられる複雑な単語や古い単語はありませんか？
|
||||
- 使われている単語や専門用語や言い回しで差別的ではない別の言葉に置き換えられるものはありませんか？
|
||||
- 言葉選びや大文字の使い方は[style guide](/docs/contribute/style/style-guide/)に従っていますか？
|
||||
- もっと短くしたり単純な文に書き換えられる長い文はありませんか？
|
||||
- 箇条書きやテーブルでもっとわかりやすく表現できる長いパラグラフはありませんか？
|
||||
|
||||
### コンテンツ
|
||||
|
||||
- 同様のコンテンツがKubernetesのサイト上のどこかに存在しませんか？
|
||||
- コンテンツが外部サイト、特定のベンダー、オープンソースではないドキュメントなどに過剰にリンクを張っていませんか？
|
||||
|
||||
### ウェブサイト
|
||||
|
||||
- PRはページ名、slug/alias、アンカーリンクの変更や削除をしていますか？ その場合、このPRの変更の結果、リンク切れは発生しませんか？ ページ名を変更してslugはそのままにするなど、他の選択肢はありませんか？
|
||||
- PRは新しいページを作成するものですか？ その場合、次の点に注意してください。
|
||||
- ページは正しい[page content type](/docs/contribute/style/page-content-types/)と関係するHugoのshortcodeを使用していますか？
|
||||
- セクションの横のナビゲーション(または全体)にページは正しく表示されますか？
|
||||
- ページは[Docs Home](/docs/home/)に一覧されますか？
|
||||
- Netlifyのプレビューで変更は確認できますか？ 特にリスト、コードブロック、テーブル、備考、画像などに注意してください。
|
||||
|
||||
### その他
|
||||
|
||||
PRに関して誤字や空白などの小さな問題を指摘する場合は、コメントの前に`nit:`と書いてください。こうすることで、PRの作者は問題が深刻なものではないことが分かります。
|
||||
@@ -16,7 +16,7 @@ content_type: concept
|
||||
|
||||
## APIリファレンス
|
||||
|
||||
* [Kubernetes API概要](/docs/reference/using-api/api-overview/) - Kubernetes APIの概要です。
|
||||
* [Kubernetes API概要](/docs/reference/using-api/) - Kubernetes APIの概要です。
|
||||
* [Kubernetes APIリファレンス {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
|
||||
|
||||
## APIクライアントライブラリー
|
||||
@@ -30,9 +30,9 @@ content_type: concept
|
||||
|
||||
## CLIリファレンス
|
||||
|
||||
* [kubectl](/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
|
||||
* [kubectl](/ja/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
|
||||
* [JSONPath](/ja/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
|
||||
* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。
|
||||
* [kubeadm](ja/docs/reference/setup-tools/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。
|
||||
|
||||
## コンポーネントリファレンス
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ ClusterRolesにはいくつかの用途があります。ClusterRoleを利用し
|
||||
2. Namespaceに属するリソースに対する権限を定義し、すべてのNamespaceにわたって付与する
|
||||
3. クラスター単位でスコープされているリソースに対するアクセス許可を定義する
|
||||
|
||||
NamespaceでRoleを定義する場合は、Roleを使用します。クラスター全体でRoleを定義する婆は、ClusterRoleを使用します
|
||||
NamespaceでRoleを定義する場合は、Roleを使用します。クラスター全体でRoleを定義する場合は、ClusterRoleを使用します
|
||||
|
||||
#### Roleの例
|
||||
|
||||
|
||||
@@ -203,6 +203,7 @@ content_type: concept
|
||||
| `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
|
||||
| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
|
||||
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
|
||||
| `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - |
|
||||
| `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | 1.14 |
|
||||
| `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - |
|
||||
| `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | 1.12 |
|
||||
|
||||
@@ -75,7 +75,7 @@ kind: ClusterConfiguration
|
||||
kubernetesVersion: v1.16.0
|
||||
scheduler:
|
||||
extraArgs:
|
||||
address: 0.0.0.0
|
||||
bind-address: 0.0.0.0
|
||||
config: /home/johndoe/schedconfig.yaml
|
||||
kubeconfig: /home/johndoe/kubeconfig.yaml
|
||||
```
|
||||
|
||||
+1
-1
@@ -96,7 +96,7 @@ spec:
|
||||
* ネットワークを介したノードとPod間通信、LinuxマスターからのPod IPのポート80に向けて`curl`して、ウェブサーバーの応答をチェックします
|
||||
* docker execまたはkubectl execを使用したPod間通信、Pod間(および複数のWindowsノードがある場合はホスト間)へのpingします
|
||||
* ServiceからPodへの通信、Linuxマスターおよび個々のPodからの仮想Service IP(`kubectl get services`で表示される)に`curl`します
|
||||
* サービスディスカバリ、Kuberntesの[default DNS suffix](/ja/docs/concepts/services-networking/dns-pod-service/#services)と共にService名に`curl`します
|
||||
* サービスディスカバリ、Kubernetesの[default DNS suffix](/ja/docs/concepts/services-networking/dns-pod-service/#services)と共にService名に`curl`します
|
||||
* Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster
|
||||
* インバウンド接続、Linuxマスターまたはクラスター外のマシンからNodePortに`curl`します
|
||||
* アウトバウンド接続、kubectl execを使用したPod内からの外部IPに`curl`します
|
||||
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "Secretの管理"
|
||||
weight: 28
|
||||
description: Secretを使用した機密設定データの管理
|
||||
---
|
||||
|
||||
@@ -0,0 +1,183 @@
|
||||
---
|
||||
title: 設定ファイルを使用してSecretを管理する
|
||||
content_type: task
|
||||
weight: 20
|
||||
description: リソース設定ファイルを使用してSecretを作成する
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 設定ファイルを作成する
|
||||
|
||||
あらかじめYAMLまたはJSON形式でSecretのマニフェストを作成したうえで、オブジェクトを作成することができます。
|
||||
[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)リソースには、`data`と`stringData`の2つのマップが含まれています。
|
||||
`data`フィールドは任意のデータを格納するのに使用され、base64でエンコードされます。
|
||||
`stringData`フィールドは利便性のために用意されており、Secretデータをエンコードされていない文字列として提供することができます。
|
||||
`data`と`stringData`のキーは、英数字、`-`、`_`、`.`で構成されている必要があります。
|
||||
|
||||
たとえば、`data`フィールドを使用して2つの文字列をSecretに格納するには、次のように文字列をbase64に変換します:
|
||||
|
||||
```shell
|
||||
echo -n 'admin' | base64
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
YWRtaW4=
|
||||
```
|
||||
|
||||
```shell
|
||||
echo -n '1f2d1e2e67df' | base64
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
以下のようなSecret設定ファイルを記述します:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
password: MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
なお、Secretオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
|
||||
|
||||
{{< note >}}
|
||||
SecretデータのシリアライズされたJSONおよびYAMLの値は、base64文字列としてエンコードされます。
|
||||
文字列中の改行は不正で、含まれていてはなりません。
|
||||
Darwin/macOSで`base64`ユーティリティーを使用する場合、長い行を分割するために`-b`オプションを使用するのは避けるべきです。
|
||||
逆に、Linux ユーザーは、`base64` コマンドにオプション`-w 0`を追加するか、`-w`オプションが利用できない場合には、パイプライン`base64 | tr -d '\n'`を追加する*必要があります*。
|
||||
{{< /note >}}
|
||||
|
||||
特定のシナリオでは、代わりに`stringData`フィールドを使用できます。
|
||||
このフィールドでは、base64エンコードされていない文字列を直接Secretに入れることができ、Secretの作成時や更新時には、その文字列がエンコードされます。
|
||||
|
||||
たとえば、設定ファイルを保存するためにSecretを使用しているアプリケーションをデプロイする際に、デプロイプロセス中に設定ファイルの一部を入力したい場合などが考えられます。
|
||||
|
||||
たとえば、次のような設定ファイルを使用しているアプリケーションの場合:
|
||||
|
||||
```yaml
|
||||
apiUrl: "https://my.api.com/api/v1"
|
||||
username: "<user>"
|
||||
password: "<password>"
|
||||
```
|
||||
|
||||
次のような定義でSecretに格納できます:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
stringData:
|
||||
config.yaml: |
|
||||
apiUrl: "https://my.api.com/api/v1"
|
||||
username: <user>
|
||||
password: <password>
|
||||
```
|
||||
|
||||
## Secretを作成する
|
||||
|
||||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)でSecretを作成します:
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./secret.yaml
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
secret/mysecret created
|
||||
```
|
||||
|
||||
## Secretを確認する
|
||||
|
||||
`stringData`フィールドは、書き込み専用の便利なフィールドです。Secretを取得する際には決して出力されません。たとえば、次のようなコマンドを実行した場合:
|
||||
|
||||
```shell
|
||||
kubectl get secret mysecret -o yaml
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
creationTimestamp: 2018-11-15T20:40:59Z
|
||||
name: mysecret
|
||||
namespace: default
|
||||
resourceVersion: "7225"
|
||||
uid: c280ad2e-e916-11e8-98f2-025000000001
|
||||
type: Opaque
|
||||
data:
|
||||
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
|
||||
```
|
||||
|
||||
`kubectl get`と`kubectl describe`コマンドはデフォルトではSecretの内容を表示しません。
|
||||
これは、Secretが不用意に他人にさらされたり、ターミナルログに保存されたりしないようにするためです。
|
||||
エンコードされたデータの実際の内容を確認するには、[Secretのデコード](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret)を参照してください。
|
||||
|
||||
`username`などのフィールドが`data`と`stringData`の両方に指定されている場合は、`stringData`の値が使われます。
|
||||
たとえば、以下のようなSecretの定義の場合:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
stringData:
|
||||
username: administrator
|
||||
```
|
||||
|
||||
結果は以下の通りです:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
creationTimestamp: 2018-11-15T20:46:46Z
|
||||
name: mysecret
|
||||
namespace: default
|
||||
resourceVersion: "7579"
|
||||
uid: 91460ecb-e917-11e8-98f2-025000000001
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW5pc3RyYXRvcg==
|
||||
```
|
||||
|
||||
`YWRtaW5pc3RyYXRvcg==`をデコードすると`administrator`となります。
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
作成したSecretを削除するには次のコマンドを実行します:
|
||||
|
||||
```shell
|
||||
kubectl delete secret mysecret
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [Secretのコンセプト](/ja/docs/concepts/configuration/secret/)を読む
|
||||
- [kubectlを使用してSecretを管理する](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を知る
|
||||
- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を知る
|
||||
@@ -0,0 +1,146 @@
|
||||
---
|
||||
title: kubectlを使用してSecretを管理する
|
||||
content_type: task
|
||||
weight: 10
|
||||
description: kubectlコマンドラインを使用してSecretを作成する
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Secretを作成する
|
||||
|
||||
`Secret`はデータベースにアクセスするためにPodが必要とするユーザー資格情報を含めることができます。
|
||||
たとえば、データベース接続文字列はユーザー名とパスワードで構成されます。
|
||||
ユーザー名はローカルマシンの`./username.txt`に、パスワードは`./password.txt`に保存します。
|
||||
|
||||
```shell
|
||||
echo -n 'admin' > ./username.txt
|
||||
echo -n '1f2d1e2e67df' > ./password.txt
|
||||
```
|
||||
|
||||
上記の2つのコマンドの`-n`フラグは、生成されたファイルにテキスト末尾の余分な改行文字が含まれないようにします。
|
||||
`kubectl`がファイルを読み取り、内容をbase64文字列にエンコードすると、余分な改行文字もエンコードされるため、これは重要です。
|
||||
|
||||
`kubectl create secret`コマンドはこれらのファイルをSecretにパッケージ化し、APIサーバー上にオブジェクトを作成します。
|
||||
|
||||
```shell
|
||||
kubectl create secret generic db-user-pass \
|
||||
--from-file=./username.txt \
|
||||
--from-file=./password.txt
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
secret/db-user-pass created
|
||||
```
|
||||
|
||||
ファイル名がデフォルトのキー名になります。オプションで`--from-file=[key=]source`を使用してキー名を設定できます。たとえば:
|
||||
|
||||
```shell
|
||||
kubectl create secret generic db-user-pass \
|
||||
--from-file=username=./username.txt \
|
||||
--from-file=password=./password.txt
|
||||
```
|
||||
|
||||
`--from-file`に指定したファイルに含まれるパスワードの特殊文字をエスケープする必要はありません。
|
||||
|
||||
また、`--from-literal=<key>=<value>`タグを使用してSecretデータを提供することもできます。
|
||||
このタグは、複数のキーと値のペアを提供するために複数回指定することができます。
|
||||
`$`、`\`、`*`、`=`、`!`などの特殊文字は[シェル](https://en.wikipedia.org/wiki/Shell_(computing))によって解釈されるため、エスケープを必要とすることに注意してください。
|
||||
ほとんどのシェルでは、パスワードをエスケープする最も簡単な方法は、シングルクォート(`'`)で囲むことです。
|
||||
たとえば、実際のパスワードが`S!B\*d$zDsb=`の場合、次のようにコマンドを実行します:
|
||||
|
||||
```shell
|
||||
kubectl create secret generic dev-db-secret \
|
||||
--from-literal=username=devuser \
|
||||
--from-literal=password='S!B\*d$zDsb='
|
||||
```
|
||||
|
||||
## Secretを検証する
|
||||
|
||||
Secretが作成されたことを確認できます:
|
||||
|
||||
```shell
|
||||
kubectl get secrets
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
db-user-pass Opaque 2 51s
|
||||
```
|
||||
|
||||
`Secret`の説明を参照できます:
|
||||
|
||||
```shell
|
||||
kubectl describe secrets/db-user-pass
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
Name: db-user-pass
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password: 12 bytes
|
||||
username: 5 bytes
|
||||
```
|
||||
|
||||
`kubectl get`と`kubectl describe`コマンドはデフォルトでは`Secret`の内容を表示しません。
|
||||
これは、`Secret`が不用意に他人にさらされたり、ターミナルログに保存されたりしないようにするためです。
|
||||
|
||||
## Secretをデコードする {#decoding-secret}
|
||||
|
||||
先ほど作成したSecretの内容を見るには、以下のコマンドを実行します:
|
||||
|
||||
```shell
|
||||
kubectl get secret db-user-pass -o jsonpath='{.data}'
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```json
|
||||
{"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="}
|
||||
```
|
||||
|
||||
`password`のデータをデコードします:
|
||||
|
||||
```shell
|
||||
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
作成したSecretを削除するには次のコマンドを実行します:
|
||||
|
||||
```shell
|
||||
kubectl delete secret db-user-pass
|
||||
```
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [Secretのコンセプト](/ja/docs/concepts/configuration/secret/)を読む
|
||||
- [設定ファイルを使用してSecretを管理する](/ja/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を知る
|
||||
- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を知る
|
||||
@@ -365,7 +365,7 @@ kubectl get service hostnames -o json
|
||||
kubectl get pods -l app=hostnames
|
||||
```
|
||||
```none
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
hostnames-632524106-bbpiw 1/1 Running 0 1h
|
||||
hostnames-632524106-ly40y 1/1 Running 0 1h
|
||||
hostnames-632524106-tlaok 1/1 Running 0 1h
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: "Jobの実行"
|
||||
description: 並列処理を使用してJobを実行します。
|
||||
weight: 50
|
||||
---
|
||||
|
||||
@@ -0,0 +1,175 @@
|
||||
---
|
||||
title: CronJobを使用して自動化タスクを実行する
|
||||
min-kubernetes-server-version: v1.21
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
CronJobは、Kubernetes v1.21で一般利用(GA)に昇格しました。古いバージョンのKubernetesを使用している場合、正確な情報を参照できるように、使用しているバージョンのKubernetesのドキュメントを参照してください。古いKubernetesのバージョンでは、`batch/v1` CronJob APIはサポートされていません。
|
||||
|
||||
{{< glossary_tooltip text="CronJob" term_id="cronjob" >}}を使用すると、{{< glossary_tooltip text="Job" term_id="job" >}}を時間ベースのスケジュールで実行できるようになります。この自動化されたJobは、LinuxまたはUNIXシステム上の[Cron](https://ja.wikipedia.org/wiki/Cron)のように実行されます。
|
||||
|
||||
CronJobは、バックアップやメールの送信など、定期的なタスクや繰り返しのタスクを作成する時に便利です。CronJobはそれぞれのタスクを、たとえばアクティビティが少ない期間など、特定の時間にスケジューリングすることもできます。
|
||||
|
||||
CronJobには制限と特性があります。たとえば、特定の状況下では、1つのCronJobが複数のJobを作成する可能性があるため、Jobは冪等性を持つようにしなければいけません。
|
||||
|
||||
制限に関する詳しい情報については、[CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## CronJobを作成する
|
||||
|
||||
CronJobには設定ファイルが必要です。次の例のCronJobの`.spec`は、現在の時刻とhelloというメッセージを1分ごとに表示します。
|
||||
|
||||
{{< codenew file="application/job/cronjob.yaml" >}}
|
||||
|
||||
次のコマンドで例のCronJobを実行します。
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/application/job/cronjob.yaml
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
cronjob.batch/hello created
|
||||
```
|
||||
|
||||
CronJobを作成したら、次のコマンドで状態を取得します。
|
||||
|
||||
```shell
|
||||
kubectl get cronjob hello
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
|
||||
hello */1 * * * * False 0 <none> 10s
|
||||
```
|
||||
|
||||
コマンドの結果からわかるように、CronJobはまだスケジュールされておらず、まだ何のJobも実行していません。約1分以内にJobが作成されるのを見てみましょう。
|
||||
|
||||
```shell
|
||||
kubectl get jobs --watch
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME COMPLETIONS DURATION AGE
|
||||
hello-4111706356 0/1 0s
|
||||
hello-4111706356 0/1 0s 0s
|
||||
hello-4111706356 1/1 5s 5s
|
||||
```
|
||||
|
||||
"hello"CronJobによってスケジュールされたJobが1つ実行中になっていることがわかります。Jobを見るのをやめて、再度CronJobを表示して、Jobがスケジュールされたことを確認してみます。
|
||||
|
||||
```shell
|
||||
kubectl get cronjob hello
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
|
||||
hello */1 * * * * False 0 50s 75s
|
||||
```
|
||||
|
||||
CronJob`hello`が、`LAST SCHEDULE`で指定された時間にJobを正しくスケジュールしたことが確認できるはずです。現在、activeなJobの数は0です。つまり、Jobは完了または失敗したことがわかります。
|
||||
|
||||
それでは、最後にスケジュールされたJobの作成と、Podの1つの標準出力を表示してみましょう。
|
||||
|
||||
{{< note >}}
|
||||
Jobの名前とPodの名前は異なります。
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
# "hello-4111706356" の部分は、あなたのシステム上のJobの名前に置き換えてください。
|
||||
pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name})
|
||||
```
|
||||
|
||||
Podのログを表示します。
|
||||
|
||||
```shell
|
||||
kubectl logs $pods
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
Fri Feb 22 11:02:09 UTC 2019
|
||||
Hello from the Kubernetes cluster
|
||||
```
|
||||
|
||||
## CronJobの削除
|
||||
|
||||
CronJobが必要なくなったときは、`kubectl delete cronjob <cronjob name>`で削除します。
|
||||
|
||||
```shell
|
||||
kubectl delete cronjob hello
|
||||
```
|
||||
|
||||
CronJobを削除すると、すべてのJobと、そのJobが作成したPodが削除され、追加のJobの作成が停止されます。Jobの削除について詳しく知りたい場合は、[ガベージコレクション](/ja/docs/concepts/workloads/controllers/garbage-collection/)を読んでください。
|
||||
|
||||
## CronJobのspecを書く {#writing-a-cron-job-spec}
|
||||
|
||||
すべてのKubernetesの設定と同じように、CronJobにも`apiVersion`、`kind`、`metadata`のフィールドが必要です。設定ファイルの扱い方についての一般的な情報については、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)と[kubectlを使用してリソースを管理する](/ja/docs/concepts/overview/working-with-objects/object-management/)を読んでください。
|
||||
|
||||
CronJobの設定には、[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
|
||||
|
||||
{{< note >}}
|
||||
CronJobの特に`spec`へのすべての修正は、それ以降の実行にのみ適用されます。
|
||||
{{< /note >}}
|
||||
|
||||
### Schedule
|
||||
|
||||
`.spec.schedule`は、`.spec`には必須のフィールドです。`0 * * * *`や`@hourly`などの[Cron](https://ja.wikipedia.org/wiki/Cron)形式の文字列を取り、Jobの作成と実行のスケジュール時間を指定します。
|
||||
|
||||
フォーマットにはVixie cronのステップ値(step value)も指定できます。[FreeBSDのマニュアル](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)では次のように説明されています。
|
||||
|
||||
> ステップ値は範囲指定と組み合わせて使用できます。範囲の後ろに`/<number>`を付けると、範囲全体で指定したnumberの値ごとにスキップすることを意味します。たとえば、`0-23/2`をhoursフィールドに指定すると、2時間毎にコマンド実行を指定することになります(V7標準では代わりに`0,2,4,6,8,10,12,14,16,18,20,22`と指定する必要があります)。ステップはアスタリスクの後ろにつけることもできます。そのため、「2時間毎に実行」したい場合は、単純に`*/2`と指定できます。
|
||||
|
||||
{{< note >}}
|
||||
スケジュール内の疑問符`?`はアスタリスク`*`と同じ意味を持ちます。つまり、与えられたフィールドには任意の値が使えるという意味になります。
|
||||
{{< /note >}}
|
||||
|
||||
### Job Template
|
||||
|
||||
`.spec.jobTemplate`はJobのテンプレートであり、必須です。[Job](/docs/concepts/workloads/controllers/job/)と完全に同一のスキーマを持ちますが、フィールドがネストされている点と、`apiVersion`と`kind`が存在しない点だけが異なります。Jobの`.spec`を書くための情報については、[JobのSpecを書く](/docs/concepts/workloads/controllers/job/#writing-a-job-spec)を参照してください。
|
||||
|
||||
### Starting Deadline
|
||||
|
||||
`.spec.startingDeadlineSeconds`フィールドはオプションです。何かの理由でスケジュールに間に合わなかった場合に適用される、Jobの開始のデッドライン(締め切り)を秒数で指定します。デッドラインを過ぎると、CronJobはJobを開始しません。この場合にデッドラインに間に合わなかったJobは、失敗したJobとしてカウントされます。もしこのフィールドが指定されなかった場合、Jobはデッドラインを持ちません。
|
||||
|
||||
`.spec.startingDeadlineSeconds`フィールドがnull以外に設定された場合、CronJobコントローラーはJobの作成が期待される時間と現在時刻との間の時間を計測します。もしその差が制限よりも大きかった場合、その実行はスキップされます。
|
||||
|
||||
たとえば、この値が`200`に設定された場合、実際のスケジュールの最大200秒後までに作成されるJobだけが許可されます。
|
||||
|
||||
### Concurrency Policy
|
||||
|
||||
`.spec.concurrencyPolicy`フィールドもオプションです。このフィールドは、このCronJobで作成されたJobの並列実行をどのように扱うかを指定します。specには以下のconcurrency policyのいずれかを指定します。
|
||||
|
||||
* `Allow` (デフォルト): CronJobがJobを並列に実行することを許可します。
|
||||
* `Forbid`: CronJobの並列実行を禁止します。もし新しいJobの実行時に過去のJobがまだ完了していなかった場合、CronJobは新しいJobの実行をスキップします。
|
||||
* `Replace`: もし新しいJobの実行の時間になっても過去のJobの実行が完了していなかった場合、CronJobは現在の実行中のJobを新しいJobで置換します。
|
||||
|
||||
concurrency policyは、同じCronJobが作成したJobにのみ適用されます。もし複数のCronJobがある場合、それぞれのJobの並列実行は常に許可されます。
|
||||
|
||||
### Suspend
|
||||
|
||||
`.spec.suspend`フィールドもオプションです。このフィールドを`true`に設定すると、すべての後続の実行がサスペンド(一時停止)されます。この設定はすでに実行開始したJobには適用されません。デフォルトはfalseです。
|
||||
|
||||
{{< caution >}}
|
||||
スケジュールされた時間中にサスペンドされた実行は、見逃されたJob(missed job)としてカウントされます。[starting deadline](#starting-deadline)が設定されていない既存のCronJob`.spec.suspend`が`true`から`false`に変更されると、見逃されたJobは即座にスケジュールされます。
|
||||
{{< /caution >}}
|
||||
|
||||
### Job History Limit
|
||||
|
||||
`.spec.successfulJobsHistoryLimit`と`.spec.failedJobsHistoryLimit`フィールドはオプションです。これらのフィールドには、完了したJobと失敗したJobをいくつ保持するかを指定します。デフォルトでは、それぞれ3と1に設定されます。リミットを`0`に設定すると、対応する種類のJobを実行完了後に何も保持しなくなります。
|
||||
@@ -33,7 +33,7 @@ kubectl delete pods <pod>
|
||||
|
||||
上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前にPodが[適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)ことを保証します。
|
||||
|
||||
Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/concepts/architecture/nodes/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
|
||||
Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/ja/docs/concepts/architecture/nodes/#condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです:
|
||||
|
||||
* (ユーザーまたは[Node Controller](/ja/docs/concepts/architecture/nodes/)によって)Nodeオブジェクトが削除されます。
|
||||
* 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。
|
||||
@@ -76,4 +76,3 @@ StatefulSet Podの強制削除は、常に慎重に、関連するリスクを
|
||||
|
||||
[StatefulSetのデバッグ](/docs/tasks/debug-application-cluster/debug-stateful-set/)の詳細
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,403 @@
|
||||
---
|
||||
title: Horizontal Pod Autoscalerウォークスルー
|
||||
content_type: task
|
||||
weight: 100
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Horizontal Pod Autoscalerは、Deployment、ReplicaSetまたはStatefulSetといったレプリケーションコントローラ内のPodの数を、観測されたCPU使用率（もしくはベータサポートの、アプリケーションによって提供されるその他のメトリクス）に基づいて自動的にスケールさせます。
|
||||
|
||||
このドキュメントはphp-apacheサーバーに対しHorizontal Pod Autoscalerを有効化するという例に沿ってウォークスルーで説明していきます。Horizontal Pod Autoscalerの動作についてのより詳細な情報を知りたい場合は、[Horizontal Pod Autoscalerユーザーガイド](/docs/tasks/run-application/horizontal-pod-autoscale/)をご覧ください。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
この例ではバージョン1.2以上の動作するKubernetesクラスターおよびkubectlが必要です。
|
||||
[Metrics API](https://github.com/kubernetes/metrics)を介してメトリクスを提供するために、[Metrics server](https://github.com/kubernetes-sigs/metrics-server)によるモニタリングがクラスター内にデプロイされている必要があります。
|
||||
Horizontal Pod Autoscalerはメトリクスを収集するためにこのAPIを利用します。metrics-serverをデプロイする方法を知りたい場合は[metrics-server ドキュメント](https://github.com/kubernetes-sigs/metrics-server#deployment)をご覧ください。
|
||||
|
||||
Horizontal Pod Autoscalerで複数のリソースメトリクスを利用するためには、バージョン1.6以上のKubernetesクラスターおよびkubectlが必要です。カスタムメトリクスを使えるようにするためには、あなたのクラスターがカスタムメトリクスAPIを提供するAPIサーバーと通信できる必要があります。
|
||||
最後に、Kubernetesオブジェクトと関係のないメトリクスを使うにはバージョン1.10以上のKubernetesクラスターおよびkubectlが必要で、さらにあなたのクラスターが外部メトリクスAPIを提供するAPIサーバーと通信できる必要があります。
|
||||
詳細については[Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)をご覧ください。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## php-apacheの起動と公開
|
||||
|
||||
Horizontal Pod Autoscalerのデモンストレーションのために、php-apacheイメージをもとにしたカスタムのDockerイメージを使います。
|
||||
このDockerfileは下記のようになっています。
|
||||
|
||||
```dockerfile
|
||||
FROM php:5-apache
|
||||
COPY index.php /var/www/html/index.php
|
||||
RUN chmod a+rx index.php
|
||||
```
|
||||
|
||||
これはCPU負荷の高い演算を行うindex.phpを定義しています。
|
||||
|
||||
```php
|
||||
<?php
|
||||
$x = 0.0001;
|
||||
for ($i = 0; $i <= 1000000; $i++) {
|
||||
$x += sqrt($x);
|
||||
}
|
||||
echo "OK!";
|
||||
?>
|
||||
```
|
||||
|
||||
まず最初に、イメージを動かすDeploymentを起動し、Serviceとして公開しましょう。
|
||||
下記の設定を使います。
|
||||
|
||||
{{< codenew file="application/php-apache.yaml" >}}
|
||||
|
||||
以下のコマンドを実行してください。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
|
||||
```
|
||||
|
||||
```
|
||||
deployment.apps/php-apache created
|
||||
service/php-apache created
|
||||
```
|
||||
|
||||
## Horizontal Pod Autoscalerを作成する
|
||||
|
||||
サーバーが起動したら、[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)を使ってautoscalerを作成しましょう。以下のコマンドで、最初のステップで作成したphp-apache deploymentによって制御されるPodレプリカ数を1から10の間に維持するHorizontal Pod Autoscalerを作成します。
|
||||
簡単に言うと、HPAは（Deploymentを通じて）レプリカ数を増減させ、すべてのPodにおける平均CPU使用率を50%（それぞれのPodは`kubectl run`で200 milli-coresを要求しているため、平均CPU使用率100 milli-coresを意味します）に保とうとします。
|
||||
このアルゴリズムについての詳細は[こちら](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)をご覧ください。
|
||||
|
||||
```shell
|
||||
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
|
||||
```
|
||||
|
||||
```
|
||||
horizontalpodautoscaler.autoscaling/php-apache autoscaled
|
||||
```
|
||||
|
||||
以下を実行して現在のAutoscalerの状況を確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s
|
||||
```
|
||||
|
||||
現在はサーバーにリクエストを送っていないため、CPU使用率が0%になっていることに注意してください（`TARGET`カラムは対応するDeploymentによって制御される全てのPodの平均値を示しています。）。
|
||||
|
||||
## 負荷の増加
|
||||
|
||||
Autoscalerがどのように負荷の増加に反応するか見てみましょう。
|
||||
コンテナを作成し、クエリの無限ループをphp-apacheサーバーに送ってみます（これは別のターミナルで実行してください）。
|
||||
|
||||
```shell
|
||||
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
|
||||
```
|
||||
|
||||
数分以内に、下記を実行することでCPU負荷が高まっていることを確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 305% / 50% 1 10 1 3m
|
||||
```
|
||||
|
||||
ここでは、CPU使用率はrequestの305%にまで高まっています。
|
||||
結果として、Deploymentはレプリカ数7にリサイズされました。
|
||||
|
||||
```shell
|
||||
kubectl get deployment php-apache
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
php-apache 7/7 7 7 19m
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
レプリカ数が安定するまでは数分かかることがあります。負荷量は何らかの方法で制御されているわけではないので、最終的なレプリカ数はこの例とは異なる場合があります。
|
||||
{{< /note >}}
|
||||
|
||||
## 負荷の停止
|
||||
|
||||
ユーザー負荷を止めてこの例を終わらせましょう。
|
||||
|
||||
私たちが`busybox`イメージを使って作成したコンテナ内のターミナルで、`<Ctrl> + C`を入力して負荷生成を終了させます。
|
||||
|
||||
そして結果の状態を確認します（数分後）。
|
||||
|
||||
```shell
|
||||
kubectl get hpa
|
||||
```
|
||||
|
||||
```
|
||||
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
|
||||
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get deployment php-apache
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
php-apache 1/1 1 1 27m
|
||||
```
|
||||
|
||||
ここでCPU使用率は0に下がり、HPAによってオートスケールされたレプリカ数は1に戻ります。
|
||||
|
||||
{{< note >}}
|
||||
レプリカのオートスケールには数分かかることがあります。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## 複数のメトリクスやカスタムメトリクスを基にオートスケーリングする
|
||||
|
||||
`autoscaling/v2beta2` APIバージョンと使うと、`php-apache` Deploymentをオートスケーリングする際に使う追加のメトリクスを導入することが出来ます。
|
||||
|
||||
まず、`autoscaling/v2beta2`内のHorizontalPodAutoscalerのYAMLファイルを入手します。
|
||||
|
||||
```shell
|
||||
kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
|
||||
```
|
||||
|
||||
`/tmp/hpa-v2.yaml`ファイルをエディタで開くと、以下のようなYAMLファイルが見えるはずです。
|
||||
|
||||
```yaml
|
||||
apiVersion: autoscaling/v2beta2
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: php-apache
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: php-apache
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
target:
|
||||
type: Utilization
|
||||
averageUtilization: 50
|
||||
status:
|
||||
observedGeneration: 1
|
||||
lastScaleTime: <some-time>
|
||||
currentReplicas: 1
|
||||
desiredReplicas: 1
|
||||
currentMetrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
current:
|
||||
averageUtilization: 0
|
||||
averageValue: 0
|
||||
```
|
||||
|
||||
`targetCPUUtilizationPercentage`フィールドは`metrics`と呼ばれる配列に置換されています。
|
||||
CPU使用率メトリクスは、Podコンテナで定められたリソースの割合として表されるため、*リソースメトリクス*です。CPU以外のリソースメトリクスを指定することもできます。デフォルトでは、他にメモリだけがリソースメトリクスとしてサポートされています。これらのリソースはクラスター間で名前が変わることはなく、そして`metrics.k8s.io` APIが利用可能である限り常に利用可能です。
|
||||
|
||||
さらに`target.type`において`Utilization`の代わりに`AverageValue`を使い、`target.averageUtilization`フィールドの代わりに対応する`target.averageValue`フィールドを設定することで、リソースメトリクスをrequest値に対する割合に代わり、直接的な値に設定することも可能です。
|
||||
|
||||
PodメトリクスとObjectメトリクスという2つの異なる種類のメトリクスが存在し、どちらも*カスタムメトリクス*とみなされます。これらのメトリクスはクラスター特有の名前を持ち、利用するにはより発展的なクラスター監視設定が必要となります。
|
||||
|
||||
これらの代替メトリクスタイプのうち、最初のものが*Podメトリクス*です。これらのメトリクスはPodを説明し、Podを渡って平均され、レプリカ数を決定するためにターゲット値と比較されます。
|
||||
これらはほとんどリソースメトリクス同様に機能しますが、`target`の種類としては`AverageValue`*のみ*をサポートしている点が異なります。
|
||||
|
||||
Podメトリクスはmetricブロックを使って以下のように指定されます。
|
||||
|
||||
```yaml
|
||||
type: Pods
|
||||
pods:
|
||||
metric:
|
||||
name: packets-per-second
|
||||
target:
|
||||
type: AverageValue
|
||||
averageValue: 1k
|
||||
```
|
||||
|
||||
2つ目のメトリクスタイプは*Objectメトリクス*です。これらのメトリクスはPodを説明するかわりに、同一Namespace内の異なったオブジェクトを説明します。このメトリクスはオブジェクトから取得される必要はありません。単に説明するだけです。Objectメトリクスは`target`の種類として`Value`と`AverageValue`をサポートします。`Value`では、ターゲットはAPIから返ってきたメトリクスと直接比較されます。`AverageValue`では、カスタムメトリクスAPIから返ってきた値はターゲットと比較される前にPodの数で除算されます。以下の例は`requests-per-second`メトリクスのYAML表現です。
|
||||
|
||||
```yaml
|
||||
type: Object
|
||||
object:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
target:
|
||||
type: Value
|
||||
value: 2k
|
||||
```
|
||||
|
||||
もしこのようなmetricブロックを複数提供した場合、HorizontalPodAutoscalerはこれらのメトリクスを順番に処理します。
|
||||
HorizontalPodAutoscalerはそれぞれのメトリクスについて推奨レプリカ数を算出し、その中で最も多いレプリカ数を採用します。
|
||||
|
||||
例えば、もしあなたがネットワークトラフィックについてのメトリクスを収集する監視システムを持っているなら、`kubectl edit`を使って指定を次のように更新することができます。
|
||||
|
||||
```yaml
|
||||
apiVersion: autoscaling/v2beta2
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: php-apache
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: php-apache
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
target:
|
||||
type: Utilization
|
||||
averageUtilization: 50
|
||||
- type: Pods
|
||||
pods:
|
||||
metric:
|
||||
name: packets-per-second
|
||||
target:
|
||||
type: AverageValue
|
||||
averageValue: 1k
|
||||
- type: Object
|
||||
object:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
target:
|
||||
type: Value
|
||||
value: 10k
|
||||
status:
|
||||
observedGeneration: 1
|
||||
lastScaleTime: <some-time>
|
||||
currentReplicas: 1
|
||||
desiredReplicas: 1
|
||||
currentMetrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
current:
|
||||
averageUtilization: 0
|
||||
averageValue: 0
|
||||
- type: Object
|
||||
object:
|
||||
metric:
|
||||
name: requests-per-second
|
||||
describedObject:
|
||||
apiVersion: networking.k8s.io/v1beta1
|
||||
kind: Ingress
|
||||
name: main-route
|
||||
current:
|
||||
value: 10k
|
||||
```
|
||||
|
||||
この時、HorizontalPodAutoscalerはそれぞれのPodがCPU requestの50%を使い、1秒当たり1000パケットを送信し、そしてmain-route
|
||||
Ingressの裏にあるすべてのPodが合計で1秒当たり10000パケットを送信する状態を保持しようとします。
|
||||
|
||||
### より詳細なメトリクスをもとにオートスケーリングする
|
||||
|
||||
多くのメトリクスパイプラインは、名前もしくは _labels_ と呼ばれる追加の記述子の組み合わせによって説明することができます。全てのリソースメトリクス以外のメトリクスタイプ（Pod、Object、そして下で説明されている外部メトリクス）において、メトリクスパイプラインに渡す追加のラベルセレクターを指定することができます。例えば、もしあなたが`http_requests`メトリクスを`verb`ラベルとともに収集しているなら、下記のmetricブロックを指定してGETリクエストにのみ基づいてスケールさせることができます。
|
||||
|
||||
```yaml
|
||||
type: Object
|
||||
object:
|
||||
metric:
|
||||
name: http_requests
|
||||
selector: {matchLabels: {verb: GET}}
|
||||
```
|
||||
|
||||
このセレクターは完全なKubernetesラベルセレクターと同じ文法を利用します。もし名前とセレクターが複数の系列に一致した場合、この監視パイプラインはどのようにして複数の系列を一つの値にまとめるかを決定します。このセレクターは付加的なもので、ターゲットオブジェクト（`Pods`タイプの場合は対象Pod、`Object`タイプの場合は説明されるオブジェクト）では**ない**オブジェクトを説明するメトリクスを選択することは出来ません。
|
||||
|
||||
### Kubernetesオブジェクトと関係ないメトリクスに基づいたオートスケーリング
|
||||
|
||||
Kubernetes上で動いているアプリケーションを、Kubernetes Namespaceと直接的な関係がないサービスを説明するメトリクスのような、Kubernetesクラスター内のオブジェクトと明確な関係が無いメトリクスを基にオートスケールする必要があるかもしれません。Kubernetes 1.10以降では、このようなユースケースを*外部メトリクス*によって解決できます。
|
||||
|
||||
外部メトリクスを使うにはあなたの監視システムについての知識が必要となります。この設定はカスタムメトリクスを使うときのものに似ています。外部メトリクスを使うとあなたの監視システムのあらゆる利用可能なメトリクスに基づいてクラスターをオートスケールできるようになります。上記のように`metric`ブロックで`name`と`selector`を設定し、`Object`のかわりに`External`メトリクスタイプを使います。
|
||||
もし複数の時系列が`metricSelector`により一致した場合は、それらの値の合計がHorizontalPodAutoscalerに使われます。
|
||||
外部メトリクスは`Value`と`AverageValue`の両方のターゲットタイプをサポートしています。これらの機能は`Object`タイプを利用するときとまったく同じです。
|
||||
|
||||
例えばもしあなたのアプリケーションがホストされたキューサービスからのタスクを処理している場合、あなたは下記のセクションをHorizontalPodAutoscalerマニフェストに追記し、未処理のタスク30個あたり1つのワーカーを必要とすることを指定します。
|
||||
|
||||
```yaml
|
||||
- type: External
|
||||
external:
|
||||
metric:
|
||||
name: queue_messages_ready
|
||||
selector: "queue=worker_tasks"
|
||||
target:
|
||||
type: AverageValue
|
||||
averageValue: 30
|
||||
```
|
||||
|
||||
可能なら、クラスター管理者がカスタムメトリクスAPIを保護することを簡単にするため、外部メトリクスのかわりにカスタムメトリクスを用いることが望ましいです。外部メトリクスAPIは潜在的に全てのメトリクスへのアクセスを許可するため、クラスター管理者はこれを公開する際には注意が必要です。
|
||||
|
||||
## 付録: Horizontal Pod Autoscaler status conditions
|
||||
|
||||
`autoscaling/v2beta2`形式のHorizontalPodAutoscalerを使っている場合は、KubernetesによるHorizontalPodAutoscaler上の*status conditions*セットを見ることができます。status conditionsはHorizontalPodAutoscalerがスケール可能かどうか、そして現時点でそれが何らかの方法で制限されているかどうかを示しています。
|
||||
|
||||
このconditionsは`status.conditions`フィールドに現れます。HorizontalPodAutoscalerに影響しているconditionsを確認するために、`kubectl describe hpa`を利用できます。
|
||||
|
||||
```shell
|
||||
kubectl describe hpa cm-test
|
||||
```
|
||||
|
||||
```
|
||||
Name: cm-test
|
||||
Namespace: prom
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
CreationTimestamp: Fri, 16 Jun 2017 18:09:22 +0000
|
||||
Reference: ReplicationController/cm-test
|
||||
Metrics: ( current / target )
|
||||
"http_requests" on pods: 66m / 500m
|
||||
Min replicas: 1
|
||||
Max replicas: 4
|
||||
ReplicationController pods: 1 current / 1 desired
|
||||
Conditions:
|
||||
Type Status Reason Message
|
||||
---- ------ ------ -------
|
||||
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
|
||||
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from pods metric http_requests
|
||||
ScalingLimited False DesiredWithinRange the desired replica count is within the acceptable range
|
||||
Events:
|
||||
```
|
||||
|
||||
このHorizontalPodAutoscalerにおいて、いくつかの正常な状態のconditionsを見ることができます。まず最初に、`AbleToScale`は、HPAがスケール状況を取得し、更新させることが出来るかどうかだけでなく、何らかのbackoffに関連した状況がスケーリングを妨げていないかを示しています。2番目に、`ScalingActive`は、HPAが有効化されているかどうか（例えば、レプリカ数のターゲットがゼロでないこと）や、望ましいスケールを算出できるかどうかを示します。もしこれが`False`の場合、大体はメトリクスの取得において問題があることを示しています。最後に、一番最後の状況である`ScalingLimited`は、HorizontalPodAutoscalerの最大値や最小値によって望ましいスケールがキャップされていることを示しています。この指標を見てHorizontalPodAutoscaler上の最大・最小レプリカ数制限を増やす、もしくは減らす検討ができます。
|
||||
|
||||
## 付録: 数量
|
||||
|
||||
全てのHorizontalPodAutoscalerおよびメトリクスAPIにおけるメトリクスは{{< glossary_tooltip term_id="quantity" text="quantity">}}として知られる特殊な整数表記によって指定されます。例えば、`10500m`という数量は10進数表記で`10.5`と書くことができます。メトリクスAPIは可能であれば接尾辞を用いない整数を返し、そうでない場合は基本的にミリ単位での数量を返します。これはメトリクス値が`1`と`1500m`の間で、もしくは10進法表記で書かれた場合は`1`と`1.5`の間で変動するということを意味します。
|
||||
|
||||
## 付録: その他の起きうるシナリオ
|
||||
|
||||
### Autoscalerを宣言的に作成する
|
||||
|
||||
`kubectl autoscale`コマンドを使って命令的にHorizontalPodAutoscalerを作るかわりに、下記のファイルを使って宣言的に作成することができます。
|
||||
|
||||
{{< codenew file="application/hpa/php-apache.yaml" >}}
|
||||
|
||||
下記のコマンドを実行してAutoscalerを作成します。
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
|
||||
```
|
||||
|
||||
```
|
||||
horizontalpodautoscaler.autoscaling/php-apache created
|
||||
```
|
||||
@@ -49,7 +49,6 @@ Kubernetes Deploymentオブジェクトを作成することでアプリケー
|
||||
|
||||
出力はこのようになります:
|
||||
|
||||
user@computer:~/website$ kubectl describe deployment nginx-deployment
|
||||
Name: nginx-deployment
|
||||
Namespace: default
|
||||
CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700
|
||||
|
||||
@@ -33,7 +33,7 @@ Helmをインストールし、以下のコマンドを実行することでロ
|
||||
|
||||
|
||||
```shell
|
||||
helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
|
||||
helm repo add svc-cat https://kubernetes-sigs.github.io/service-catalog
|
||||
```
|
||||
|
||||
以下のコマンドを実行し、インストールに成功していることを確認します。
|
||||
|
||||
Executable
+4
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "クラスター"
|
||||
weight: 60
|
||||
---
|
||||
@@ -0,0 +1,375 @@
|
||||
---
|
||||
title: AppArmorを使用してコンテナのリソースへのアクセスを制限する
|
||||
content_type: tutorial
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.4" state="beta" >}}
|
||||
|
||||
AppArmorは、Linux標準のユーザー・グループをベースとしたパーミッションを補完するLinuxカーネルのセキュリティモジュールであり、プログラムのアクセスを限定されたリソースセットに制限するために利用されます。AppArmorを設定することで、任意のアプリケーションの攻撃サーフェイスとなりうる面を減らしたり、より優れた多重の防御を提供できます。AppArmorは、たとえばLinuxのcapability、ネットワークアクセス、ファイルのパーミッションなど、特定のプログラムやコンテナに必要なアクセスを許可するようにチューニングされたプロファイルにより設定を行います。各プロファイルは、許可されなかったリソースへのアクセスをブロックする*enforcing*モードと、ルール違反を報告するだけの*complain*モードのいずれかで実行できます。
|
||||
|
||||
AppArmorを利用すれば、コンテナに許可することを制限したりシステムログを通してよりよい監査を提供することで、デプロイをよりセキュアにする助けになります。しかし、AppArmorは銀の弾丸ではなく、アプリケーションコードの悪用からの防御を強化できるだけであることを心に留めておくことが重要です。制限の強い優れたプロファイルを提供し、アプリケーションとクラスターを別の角度から強化することが重要です。
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
* プロファイルをノードに読み込む方法の例を見る
|
||||
* Pod上でプロファイルを矯正する方法を学ぶ
|
||||
* プロファイルが読み込まれたかを確認する方法を学ぶ
|
||||
* プロファイルに違反した場合に何が起こるのかを見る
|
||||
* プロファイルが読み込めなかった場合に何が起こるのかを見る
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
以下のことを確認してください。
|
||||
|
||||
1. Kubernetesのバージョンがv1.4以上であること。KubernetesのAppArmorのサポートはv1.4で追加されました。v1.4より古いバージョンのKubernetesのコンポーネントは、新しいAppArmorのアノテーションを認識できないため、AppArmorの設定を与えたとしても**黙って無視されてしまいます**。Podが期待した保護を確実に受けられるようにするためには、次のようにノードのKubeletのバージョンを確認することが重要です。
|
||||
|
||||
```shell
|
||||
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}\n{end}'
|
||||
```
|
||||
```
|
||||
gke-test-default-pool-239f5d02-gyn2: v1.4.0
|
||||
gke-test-default-pool-239f5d02-x1kf: v1.4.0
|
||||
gke-test-default-pool-239f5d02-xwux: v1.4.0
|
||||
```
|
||||
|
||||
2. AppArmorカーネルモジュールが有効であること。LinuxカーネルがAppArmorプロファイルを強制するためには、AppArmorカーネルモジュールのインストールと有効化が必須です。UbuntuやSUSEなどのディストリビューションではデフォルトで有効化されますが、他の多くのディストリビューションでのサポートはオプションです。モジュールが有効になっているかチェックするには、次のように`/sys/module/apparmor/parameters/enabled`ファイルを確認します。
|
||||
|
||||
```shell
|
||||
cat /sys/module/apparmor/parameters/enabled
|
||||
Y
|
||||
```
|
||||
|
||||
KubeletがAppArmorをサポートしていれば(>= v1.4)、カーネルモジュールが有効になっていない場合にはAppArmorオプションが付いたPodを拒否します。
|
||||
|
||||
{{< note >}}
|
||||
UbuntuはAppArmorに対して、アップストリームのLinuxにマージしていない多数のパッチを当てています。その中には、追加のフックや機能を加えるパッチも含まれます。Kubernetesはアップストリームのバージョンでのみテストされており、その他の機能に対するサポートを約束していません。
|
||||
{{< /note >}}
|
||||
|
||||
3. コンテナランタイムがAppArmorをサポートしていること。現在、Kubernetesがサポートするすべての一般的なコンテナランタイム、{{< glossary_tooltip term_id="docker">}}、{{< glossary_tooltip term_id="cri-o" >}}、{{< glossary_tooltip term_id="containerd" >}}などは、AppArmorをサポートしています。関連するランタイムのドキュメントを参照して、クラスターがAppArmorを利用するための要求を満たしているかどうかを検証してください。
|
||||
|
||||
4. プロファイルが読み込まれていること。AppArmorがPodに適用されるのは、各コンテナが実行されるべきAppArmorプロファイルを指定したときです。もし指定されたプロファイルがまだカーネルに読み込まれていなければ、Kubelet(>= v1.4)はPodを拒否します。どのプロファイルがノードに読み込まれているのかを確かめるには、次のようなコマンドを実行して`/sys/kernel/security/apparmor/profiles`をチェックします。
|
||||
|
||||
```shell
|
||||
ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort"
|
||||
```
|
||||
```
|
||||
apparmor-test-deny-write (enforce)
|
||||
apparmor-test-audit-write (enforce)
|
||||
docker-default (enforce)
|
||||
k8s-nginx (enforce)
|
||||
```
|
||||
|
||||
ノード上でのプロファイルの読み込みの詳細については、[プロファイルを使用したノードのセットアップ](#setting-up-nodes-with-profiles)を参照してください。
|
||||
|
||||
KubeletのバージョンがAppArmorサポートに対応しているもの(>= v1.4)である限り、Kubeletは必要条件を1つでも満たさないAppArmorオプションが付けられたPodをリジェクトします。また、ノード上のAppArmorのサポートは、次のようにready conditionのメッセージで確認することもできます(ただし、この機能は将来のリリースで削除される可能性があります)。
|
||||
|
||||
```shell
|
||||
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}'
|
||||
```
|
||||
```
|
||||
gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled
|
||||
gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor enabled
|
||||
gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled
|
||||
```
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## Podをセキュアにする
|
||||
|
||||
{{< note >}}
|
||||
AppArmorは現在beta版であるため、オプションはアノテーションとして指定します。将来サポートが一般利用可能(GA)になれば、アノテーションは第1級のフィールドで置き換えられます(詳細については、[一般利用可能(General Availability)への更新パス](#upgrade-path-to-general-availability)を参照してください)。
|
||||
{{< /note >}}
|
||||
|
||||
AppArmorのプロファイルは*各コンテナごとに*指定します。Podのコンテナで実行するAppArmorのプロファイルを指定するには、Podのメタデータに次のようなアノテーションを追加します。
|
||||
|
||||
```yaml
|
||||
container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref>
|
||||
```
|
||||
|
||||
ここで、`<container_name>`はプロファイルを適用するコンテナの名前であり、`<profile_ref>`には適用するプロファイルを指定します。`profile_ref`は次の値のうち1つを指定します。
|
||||
|
||||
* `runtime/default`: ランタイムのデフォルトのプロファイルを適用する
|
||||
* `localhost/<profile_name>`: `<profile_name>`という名前でホストにロードされたプロファイルを適用する
|
||||
* `unconfined`: いかなるプロファイルもロードされないことを示す
|
||||
|
||||
アノテーションとプロファイルの名前のフォーマットの詳細については、[APIリファレンス](#api-reference)を参照してください。
|
||||
|
||||
KubernetesのAppArmorの強制では、まずはじめにすべての前提条件が満たされているかどうかをチェックします。その後、強制を行うためにプロファイルの選択をコンテナランタイムに委ねます。前提条件が満たされなかった場合、Podはリジェクトされ、実行されません。
|
||||
|
||||
プロファイルが適用されたかどうか確認するには、AppArmor securityオプションがコンテナ作成イベントに一覧されているかどうかを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get events | grep Created
|
||||
```
|
||||
```
|
||||
22s 22s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet e2e-test-stclair-node-pool-31nt} Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
|
||||
```
|
||||
|
||||
proc attrを調べることで、コンテナのルートプロセスが正しいプロファイルで実行されているかどうかを直接確認することもできます。
|
||||
|
||||
```shell
|
||||
kubectl exec <pod_name> cat /proc/1/attr/current
|
||||
```
|
||||
```
|
||||
k8s-apparmor-example-deny-write (enforce)
|
||||
```
|
||||
|
||||
## 例 {#example}
|
||||
|
||||
*この例は、クラスターがすでにAppArmorのサポート付きでセットアップ済みであることを前提としています。*
|
||||
|
||||
まず、使用したいプロファイルをノード上に読み込む必要があります。このプロファイルは、すべてのファイル書き込みを拒否します。
|
||||
|
||||
```shell
|
||||
#include <tunables/global>
|
||||
|
||||
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
|
||||
#include <abstractions/base>
|
||||
|
||||
file,
|
||||
|
||||
# Deny all file writes.
|
||||
deny /** w,
|
||||
}
|
||||
```
|
||||
|
||||
Podがどのノードにスケジュールされるかは予測できないため、プロファイルはすべてのノードに読み込ませる必要があります。この例では、単純にSSHを使ってプロファイルをインストールしますが、[プロファイルを使用したノードのセットアップ](#setting-up-nodes-with-profiles)では、他のアプローチについて議論しています。
|
||||
|
||||
```shell
|
||||
NODES=(
|
||||
# SSHでアクセス可能なノードのドメイン名
|
||||
gke-test-default-pool-239f5d02-gyn2.us-central1-a.my-k8s
|
||||
gke-test-default-pool-239f5d02-x1kf.us-central1-a.my-k8s
|
||||
gke-test-default-pool-239f5d02-xwux.us-central1-a.my-k8s)
|
||||
for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
|
||||
#include <tunables/global>
|
||||
|
||||
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
|
||||
#include <abstractions/base>
|
||||
|
||||
file,
|
||||
|
||||
# Deny all file writes.
|
||||
deny /** w,
|
||||
}
|
||||
EOF'
|
||||
done
|
||||
```
|
||||
|
||||
次に、deny-writeプロファイルを使用した単純な "Hello AppArmor" Podを実行します。
|
||||
|
||||
{{< codenew file="pods/security/hello-apparmor.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl create -f ./hello-apparmor.yaml
|
||||
```
|
||||
|
||||
Podイベントを確認すると、PodコンテナがAppArmorプロファイル "k8s-apparmor-example-deny-write" を使用して作成されたことがわかります。
|
||||
|
||||
```shell
|
||||
kubectl get events | grep hello-apparmor
|
||||
```
|
||||
```
|
||||
14s 14s 1 hello-apparmor Pod Normal Scheduled {default-scheduler } Successfully assigned hello-apparmor to gke-test-default-pool-239f5d02-gyn2
|
||||
14s 14s 1 hello-apparmor Pod spec.containers{hello} Normal Pulling {kubelet gke-test-default-pool-239f5d02-gyn2} pulling image "busybox"
|
||||
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Pulled {kubelet gke-test-default-pool-239f5d02-gyn2} Successfully pulled image "busybox"
|
||||
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet gke-test-default-pool-239f5d02-gyn2} Created container with docker id 06b6cd1c0989; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
|
||||
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Started {kubelet gke-test-default-pool-239f5d02-gyn2} Started container with docker id 06b6cd1c0989
|
||||
```
|
||||
|
||||
コンテナがこのプロファイルで実際に実行されていることを確認するために、コンテナのproc attrをチェックします。
|
||||
|
||||
```shell
|
||||
kubectl exec hello-apparmor cat /proc/1/attr/current
|
||||
```
|
||||
```
|
||||
k8s-apparmor-example-deny-write (enforce)
|
||||
```
|
||||
|
||||
最後に、ファイルへの書き込みを行おうとすることで、プロファイルに違反すると何が起こるか見てみましょう。
|
||||
|
||||
```shell
|
||||
kubectl exec hello-apparmor touch /tmp/test
|
||||
```
|
||||
```
|
||||
touch: /tmp/test: Permission denied
|
||||
error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1
|
||||
```
|
||||
|
||||
まとめとして、読み込まれていないプロファイルを指定しようとするとどうなるのか見てみましょう。
|
||||
|
||||
```shell
|
||||
kubectl create -f /dev/stdin <<EOF
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: hello-apparmor-2
|
||||
annotations:
|
||||
container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-allow-write
|
||||
spec:
|
||||
containers:
|
||||
- name: hello
|
||||
image: busybox
|
||||
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
|
||||
EOF
|
||||
pod/hello-apparmor-2 created
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl describe pod hello-apparmor-2
|
||||
```
|
||||
```
|
||||
Name: hello-apparmor-2
|
||||
Namespace: default
|
||||
Node: gke-test-default-pool-239f5d02-x1kf/
|
||||
Start Time: Tue, 30 Aug 2016 17:58:56 -0700
|
||||
Labels: <none>
|
||||
Annotations: container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write
|
||||
Status: Pending
|
||||
Reason: AppArmor
|
||||
Message: Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
|
||||
IP:
|
||||
Controllers: <none>
|
||||
Containers:
|
||||
hello:
|
||||
Container ID:
|
||||
Image: busybox
|
||||
Image ID:
|
||||
Port:
|
||||
Command:
|
||||
sh
|
||||
-c
|
||||
echo 'Hello AppArmor!' && sleep 1h
|
||||
State: Waiting
|
||||
Reason: Blocked
|
||||
Ready: False
|
||||
Restart Count: 0
|
||||
Environment: <none>
|
||||
Mounts:
|
||||
/var/run/secrets/kubernetes.io/serviceaccount from default-token-dnz7v (ro)
|
||||
Conditions:
|
||||
Type Status
|
||||
Initialized True
|
||||
Ready False
|
||||
PodScheduled True
|
||||
Volumes:
|
||||
default-token-dnz7v:
|
||||
Type: Secret (a volume populated by a Secret)
|
||||
SecretName: default-token-dnz7v
|
||||
Optional: false
|
||||
QoS Class: BestEffort
|
||||
Node-Selectors: <none>
|
||||
Tolerations: <none>
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
23s 23s 1 {default-scheduler } Normal Scheduled Successfully assigned hello-apparmor-2 to e2e-test-stclair-node-pool-t1f5
|
||||
23s 23s 1 {kubelet e2e-test-stclair-node-pool-t1f5} Warning AppArmor Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
|
||||
```
|
||||
|
||||
PodのステータスはPendingとなり、`Pod Cannot enforce AppArmor: profile
|
||||
"k8s-apparmor-example-allow-write" is not loaded`(PodはAppArmorを強制できません: プロファイル "k8s-apparmor-example-allow-write" はロードされていません)という役に立つエラーメッセージが表示されています。同じメッセージのイベントも記録されています。
|
||||
|
||||
## 管理
|
||||
|
||||
### プロファイルを使用したノードのセットアップ {#setting-up-nodes-with-profiles}
|
||||
|
||||
現在、KubernetesはAppArmorのプロファイルをノードに読み込むネイティブの仕組みは提供していません。しかし、プロファイルをセットアップする方法は、以下のように様々な方法があります。
|
||||
|
||||
* 各ノード上に正しいプロファイルがロードされていることを保証するPodを実行する[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)を利用する方法。[ここ](https://git.k8s.io/kubernetes/test/images/apparmor-loader)に実装例があります。
|
||||
* ノードの初期化時に初期化スクリプト(例: Salt、Ansibleなど)や初期化イメージを使用する。
|
||||
* [例](#example)で示したような方法で、プロファイルを各ノードにコピーし、SSHで読み込む。
|
||||
|
||||
スケジューラーはどのプロファイルがどのノードに読み込まれているのかがわからないため、すべてのプロファイルがすべてのノードに読み込まれていなければなりません。もう1つのアプローチとしては、各プロファイル(あるいはプロファイルのクラス)ごとにノードラベルを追加し、[node selector](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)を用いてPodが必要なプロファイルを読み込んだノードで実行されるようにする方法もあります。
|
||||
|
||||
### PodSecurityPolicyを使用したプロファイルの制限
|
||||
|
||||
PodSecurityPolicy extensionが有効になっている場合、クラスタ全体でAppArmorn制限が適用されます。PodSecurityPolicyを有効にするには、`apiserver`上で次のフラグを設定する必要があります。
|
||||
|
||||
```
|
||||
--enable-admission-plugins=PodSecurityPolicy[,others...]
|
||||
```
|
||||
|
||||
AppArmorのオプションはPodSecurityPolicy上でアノテーションとして指定します。
|
||||
|
||||
```yaml
|
||||
apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
|
||||
apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others...]
|
||||
```
|
||||
|
||||
defaultProfileNameオプションには、何も指定されなかった場合にコンテナにデフォルトで適用されるプロファイルを指定します。allowedProfileNamesオプションには、Podコンテナの実行が許可されるプロファイルのリストを指定します。両方のオプションが指定された場合、デフォルトは許可されなければいけません。プロファイルはコンテナ上で同じフォーマットで指定されます。完全な仕様については、[APIリファレンス](#api-reference)を参照してください。
|
||||
|
||||
### AppArmorの無効化
|
||||
|
||||
クラスタ上でAppArmorを利用可能にしたくない場合、次のコマンドラインフラグで無効化できます。
|
||||
|
||||
```
|
||||
--feature-gates=AppArmor=false
|
||||
```
|
||||
|
||||
無効化すると、AppArmorプロファイルを含むPodは"Forbidden"エラーで検証に失敗します。ただし、デフォルトのdockerは非特権Pod上では"docker-default"というプロファイルを常に有効化し(AppArmorカーネルモジュールが有効である場合)、フィーチャーゲートで無効化したとしても有効化し続けることに注意してください。AppArmorを無効化するオプションは、AppArmorが一般利用(GA)になったときに削除される予定です。
|
||||
|
||||
### AppArmorを使用するKubernetes v1.4にアップグレードする
|
||||
|
||||
クラスタをv1.4にアップグレードするために、AppArmorに関する操作は必要ありません。ただし、既存のPodがAppArmorのアノテーションを持っている場合、検証(またはPodSecurityPolicy admission)は行われません。もしpermissiveなプロファイルがノードに読み込まれていた場合、悪意のあるユーザーがPodの権限を上述のdocker-defaultより昇格させるために、permissiveなプロファイルを再適用する恐れがあります。これが問題となる場合、`apparmor.security.beta.kubernetes.io`のアノテーションを含むすべてのPodのクラスターをクリーンアップすることを推奨します。
|
||||
|
||||
### 一般利用可能(General Availability)への更新パス {#upgrade-path-to-general-availability}
|
||||
|
||||
AppArmorが一般利用可能(GA)になったとき、現在アノテーションで指定しているオプションはフィールドに変換されます。移行中のすべてのアップグレードとダウングレードの経路をサポートするのは非常に微妙であるため、以降が必要になったときに詳細に説明する予定です。最低2リリースの間はフィールドとアノテーションの両方がサポートされるようにする予定です。最低2リリースの後は、アノテーションは明示的に拒否されるようになります。
|
||||
|
||||
## Profilesの作成
|
||||
|
||||
AppArmorのプロファイルを正しく指定するのはやっかいな作業です。幸い、その作業を補助するツールがいくつかあります。
|
||||
|
||||
* `aa-genprof`および`aa-logprof`は、アプリケーションの動作とログを監視することによりプロファイルのルールを生成します。詳しい説明については、[AppArmor documentation](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools)を参照してください。
|
||||
* [bane](https://github.com/jfrazelle/bane)は、Docker向けのAppArmorのプロファイル・ジェネレータです。簡略化されたプロファイル言語を使用しています。
|
||||
|
||||
プロファイルの生成には、アプリケーションを開発用ワークステーション上でDockerで実行することを推奨します。しかし、実際にPodが実行されるKubernetesノード上でツールを実行してはいけない理由はありません。
|
||||
|
||||
AppArmorに関する問題をデバッグするには、システムログをチェックして、特に何が拒否されたのかを確認できます。AppArmorのログは`dmesg`にverboseメッセージを送り、エラーは通常システムログまたは`journalctl`で確認できます。詳しい情報は、[AppArmor failures](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)で提供されています。
|
||||
|
||||
## APIリファレンス {#api-reference}
|
||||
|
||||
### Podアノテーション
|
||||
|
||||
コンテナが実行するプロファイルを指定します。
|
||||
|
||||
- **key**: `container.apparmor.security.beta.kubernetes.io/<container_name>`
|
||||
ここで、`<container_name>`はPod内のコンテナの名前を一致させます。Pod内の各コンテナごとに別々のプロファイルを指定できます。
|
||||
- **value**: 下で説明するプロファイルのリファレンス
|
||||
|
||||
### プロファイルのリファレンス
|
||||
|
||||
- `runtime/default`: デフォルトのランタイムプロファイルを指します。
|
||||
- (PodSecurityPolicyのデフォルトを設定せずに)プロファイルを指定しない場合と同等ですが、AppArmorを有効化する必要があります。
|
||||
- Dockerの場合、非特権コンテナでは[`docker-default`](https://docs.docker.com/engine/security/apparmor/)プロファイルが選択され、特権コンテナではunconfined(プロファイルなし)が選択されます。
|
||||
- `localhost/<profile_name>`: 名前で指定されたノード(localhost)に読み込まれたプロファイルを指します。
|
||||
- 利用できるプロファイル名の詳細は[core policy reference](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications)で説明されています。
|
||||
- `unconfined`: これは実質的にコンテナ上のAppArmorを無効化します。
|
||||
|
||||
これ以外のプロファイルリファレンスはすべて無効です。
|
||||
|
||||
### PodSecurityPolicyアノテーション
|
||||
|
||||
何も指定されなかった場合にコンテナに適用するデフォルトのプロファイルは、以下のように指定します。
|
||||
|
||||
* **key**: `apparmor.security.beta.kubernetes.io/defaultProfileName`
|
||||
* **value**: 上で説明したプロファイルのリファレンス
|
||||
|
||||
Podコンテナが指定することを許可するプロファイルのリストは、以下のように指定します。
|
||||
|
||||
* **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames`
|
||||
* **value**: カンマ区切りの上述のプロファイルリファレンスのリスト
|
||||
- プロファイル名ではエスケープしたカンマは不正な文字ではありませんが、ここでは明示的に許可されません。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
追加のリソースとしては以下のものがあります。
|
||||
|
||||
* [Quick guide to the AppArmor profile language](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage)
|
||||
* [AppArmor core policy reference](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout)
|
||||
@@ -272,7 +272,7 @@ graph TD;
|
||||
|
||||
## `Type=LoadBalancer`を使用したServiceでの送信元IP
|
||||
|
||||
[`Type=LoadBalancer`](/ja/docs/concepts/services-networking/service/#loadbalancer)を使用したServiceに送られたパケットは、デフォルトでは送信元のNATは行われません。`Ready`状態にあるすべてのスケジュール可能なKubernetesのNodeは、ロードバランサーからのトラフィックを受付可能であるためです。そのため、エンドポイントが存在しないノードにパケットが到達した場合、システムはエンドポイントが*存在する*ノードにパケットをプロシキーします。このとき、(前のセクションで説明したように)パケットの送信元IPがノードのIPに置換されます。
|
||||
[`Type=LoadBalancer`](/ja/docs/concepts/services-networking/service/#loadbalancer)を使用したServiceに送られたパケットは、デフォルトで送信元のNATが行われます。`Ready`状態にあるすべてのスケジュール可能なKubernetesのNodeは、ロードバランサーからのトラフィックを受付可能であるためです。そのため、エンドポイントが存在しないノードにパケットが到達した場合、システムはエンドポイントが*存在する*ノードにパケットをプロシキーします。このとき、(前のセクションで説明したように)パケットの送信元IPがノードのIPに置換されます。
|
||||
|
||||
ロードバランサー経由でsource-ip-appを公開することで、これをテストできます。
|
||||
|
||||
@@ -399,7 +399,7 @@ client_address=198.51.100.79
|
||||
Serviceを削除します。
|
||||
|
||||
```shell
|
||||
kubectl delete svc -l run=source-ip-app
|
||||
kubectl delete svc -l app=source-ip-app
|
||||
```
|
||||
|
||||
Deployment、ReplicaSet、Podを削除します。
|
||||
|
||||
@@ -185,7 +185,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい
|
||||
1. Podのリストを問い合わせて、3つのフロントエンドのレプリカが実行中になっていることを確認します。
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=guestbook -l tier=frontend
|
||||
kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend
|
||||
```
|
||||
|
||||
結果は次のようになるはずです。
|
||||
@@ -199,7 +199,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい
|
||||
|
||||
### フロントエンドのServiceを作成する
|
||||
|
||||
適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。
|
||||
適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/docs/concepts/services-networking/service/#publishing-services-service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。
|
||||
|
||||
もしゲストの人にゲストブックにアクセスしてほしいのなら、フロントエンドServiceを外部から見えるように設定しなければなりません。そうすれば、クライアントはコンテナクラスターの外部からServiceにリクエストを送れるようになります。Minikubeでは、Serviceを`NodePort`でのみ公開できます。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user