commit first work from 1.19 milestone
This commit is contained in:
inductor
@@ -22,12 +22,18 @@ ConfigMapは機密性や暗号化を提供しません。保存したいデー
|
||||
|
||||
こうすることで、必要であればクラウド上で実行しているコンテナイメージを取得することで、ローカルでも完全に同じコードを使ってデバッグができるようになります。
|
||||
|
||||
ConfigMapは、大量のデータを保持するようには設計されていません。ConfigMapに保存されるデータは1MiBを超えることはできません。この制限を超える設定を保存する必要がある場合は、ボリュームのマウントを検討するか、別のデータベースまたはファイルサービスを使用することを検討してください。
|
||||
|
||||
## ConfigMapオブジェクト
|
||||
|
||||
ConfigMapは、他のオブジェクトが使うための設定を保存できるAPI[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)です。ほとんどのKubernetesオブジェクトに`spec`セクションがあるのとは違い、ConfigMapにはアイテム(キー)と値を保存するための`data`セクションがあります。
|
||||
ConfigMapは、他のオブジェクトが使うための設定を保存できるAPI[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)です。ほとんどのKubernetesオブジェクトに`spec`セクションがあるのとは違い、ConfigMapには`data`および`binaryData`フィールドがあります。これらのフィールドは、キーとバリューのペアを値として受け入れます。`data`フィールドと`binaryData`フィールドはどちらもオプションです。`data`フィールドはUTF-8バイトシーケンスを含むように設計されていますが、`binaryData`フィールドはバイナリデータを含むように設計されています。
|
||||
|
||||
ConfigMapの名前は、有効な[DNSのサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
|
||||
|
||||
`data`または`binaryData`フィールドの各キーは、英数字、`-`、`_`、または`.`で構成されている必要があります。`data`に格納されているキーは、`binaryData`フィールドのキーと重複することはできません。
|
||||
|
||||
v1.19以降、ConfigMapの定義に`immutable`フィールドを追加して、[イミュータブルなConfigMap](#configmap-immutable)を作成できます。
|
||||
|
||||
## ConfigMapとPod
|
||||
|
||||
ConfigMapを参照して、ConfigMap内のデータを元にしてPod内のコンテナの設定をするPodの`spec`を書くことができます。このとき、PodとConfigMapは同じ{{< glossary_tooltip text="名前空間" term_id="namespace" >}}内に存在する必要があります。
|
||||
@@ -43,7 +49,7 @@ data:
|
||||
# プロパティーに似たキー。各キーは単純な値にマッピングされている
|
||||
player_initial_lives: "3"
|
||||
ui_properties_file_name: "user-interface.properties"
|
||||
#
|
||||
|
||||
# ファイルに似たキー
|
||||
game.properties: |
|
||||
enemy.types=aliens,monsters
|
||||
@@ -56,7 +62,7 @@ data:
|
||||
|
||||
ConfigMapを利用してPod内のコンテナを設定する方法には、次の4種類があります。
|
||||
|
||||
1. コマンドライン引数をコンテナのエントリーポイントに渡す
|
||||
1. コンテナ内のコマンドと引数
|
||||
1. 環境変数をコンテナに渡す
|
||||
1. 読み取り専用のボリューム内にファイルを追加し、アプリケーションがそのファイルを読み取る
|
||||
1. Kubernetes APIを使用してConfigMapを読み込むコードを書き、そのコードをPod内で実行する
|
||||
@@ -75,7 +81,8 @@ metadata:
|
||||
spec:
|
||||
containers:
|
||||
- name: demo
|
||||
image: game.example/demo-game
|
||||
image: alpine
|
||||
command: ["sleep", "3600"]
|
||||
env:
|
||||
# 環境変数を定義します。
|
||||
- name: PLAYER_INITIAL_LIVES # ここではConfigMap内のキーの名前とは違い
|
||||
@@ -117,11 +124,9 @@ ConfigMapは1行のプロパティの値と複数行のファイルに似た形
|
||||
|
||||
ConfigMapは、データボリュームとしてマウントできます。ConfigMapは、Podへ直接公開せずにシステムの他の部品として使うこともできます。たとえば、ConfigMapには、システムの他の一部が設定のために使用するデータを保存できます。
|
||||
|
||||
{{< note >}}
|
||||
ConfigMapの最も一般的な使い方では、同じ名前空間にあるPod内で実行されているコンテナに設定を構成します。ConfigMapを独立して使用することもできます。
|
||||
|
||||
たとえば、ConfigMapに基づいて動作を調整する{{< glossary_tooltip text="アドオン" term_id="addons" >}}や{{< glossary_tooltip text="オペレーター" term_id="operator-pattern" >}}を見かけることがあるかもしれません。
|
||||
{{< /note >}}
|
||||
|
||||
### ConfigMapをPodからファイルとして使う
|
||||
|
||||
@@ -161,14 +166,17 @@ Pod内に複数のコンテナが存在する場合、各コンテナにそれ
|
||||
|
||||
ボリューム内で現在使用中のConfigMapが更新されると、射影されたキーも最終的に(eventually)更新されます。kubeletは定期的な同期のたびにマウントされたConfigMapが新しいかどうか確認します。しかし、kubeletが現在のConfigMapの値を取得するときにはローカルキャッシュを使用します。キャッシュの種類は、[KubeletConfiguration構造体](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)の中の`ConfigMapAndSecretChangeDetectionStrategy`フィールドで設定可能です。ConfigMapは、監視(デフォルト)、ttlベース、またはすべてのリクエストを直接APIサーバーへ単純にリダイレクトする方法のいずれかによって伝搬されます。その結果、ConfigMapが更新された瞬間から、新しいキーがPodに射影されるまでの遅延の合計は、最長でkubeletの同期期間+キャッシュの伝搬遅延になります。ここで、キャッシュの伝搬遅延は選択したキャッシュの種類に依存します(監視の伝搬遅延、キャッシュのttl、または0に等しくなります)。
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
|
||||
環境変数として使用されるConfigMapは自動的に更新されないため、ポッドを再起動する必要があります。
|
||||
## イミュータブルなConfigMap {#configmap-immutable}
|
||||
|
||||
Kubernetesのアルファ版の機能である _イミュータブルなSecretおよびConfigMap_ は、個別のSecretやConfigMapをイミュータブルに設定するオプションを提供します。ConfigMapを広範に使用している(少なくとも数万のConfigMapがPodにマウントされている)クラスターでは、データの変更を防ぐことにより、以下のような利点が得られます。
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
Kubernetesのベータ版の機能である _イミュータブルなSecretおよびConfigMap_ は、個別のSecretやConfigMapをイミュータブルに設定するオプションを提供します。ConfigMapを広範に使用している(少なくとも数万のConfigMapがPodにマウントされている)クラスターでは、データの変更を防ぐことにより、以下のような利点が得られます。
|
||||
|
||||
- アプリケーションの停止を引き起こす可能性のある予想外の(または望まない)変更を防ぐことができる
|
||||
- ConfigMapをイミュータブルにマークして監視を停止することにより、kube-apiserverへの負荷を大幅に削減し、クラスターの性能が向上する
|
||||
|
||||
この機能を使用するには、`ImmutableEmphemeralVolumes`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretやConfigMapの`immutable`フィールドを`true`に設定してください。次に例を示します。
|
||||
この機能は、`ImmutableEmphemeralVolumes`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)によって管理されます。`immutable`フィールドを`true`に設定することで、イミュータブルなConfigMapを作成できます。次に例を示します。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -180,9 +188,7 @@ data:
|
||||
immutable: true
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
一度ConfigMapやSecretがイミュータブルに設定すると、この変更を元に戻したり、`data`フィールドのコンテンツを変更することは*できません*。既存のPodは削除されたConfigMapのマウントポイントを保持するため、こうしたPodは再作成することをおすすめします。
|
||||
{{< /note >}}
|
||||
一度ConfigMapがイミュータブルに設定されると、この変更を元に戻したり、`data`または`binaryData`フィールドのコンテンツを変更することは*できません*。ConfigMapの削除と再作成のみ可能です。既存のPodは削除されたConfigMapのマウントポイントを保持するため、こうしたPodは再作成することをおすすめします。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
@@ -29,6 +29,10 @@ Podが動作しているNodeに利用可能なリソースが十分にある場
|
||||
制限は、違反が検出されるとシステムが介入するように事後的に、またはコンテナーが制限を超えないようにシステムが防ぐように強制的に、実装できます。
|
||||
異なるランタイムは、同じ制限を実装するために異なる方法をとることができます。
|
||||
|
||||
{{< note >}}
|
||||
コンテナが自身のメモリー制限を指定しているが、メモリー要求を指定していない場合、Kubernetesは制限に一致するメモリー要求を自動的に割り当てます。同様に、コンテナが自身のCPU制限を指定しているが、CPU要求を指定していない場合、Kubernetesは制限に一致するCPU要求を自動的に割り当てます。
|
||||
{{< /note >}}
|
||||
|
||||
## リソースタイプ
|
||||
|
||||
*CPU*と*メモリー*はいずれも*リソースタイプ*です。リソースタイプには基本単位があります。
|
||||
@@ -84,7 +88,7 @@ CPUは常に相対量としてではなく、絶対量として要求されま
|
||||
### メモリーの意味
|
||||
|
||||
`メモリー`の制限と要求はバイト単位で測定されます。
|
||||
E、P、T、G、M、Kのいずれかのサフィックスを使用して、メモリーを整数または固定小数点整数として表すことができます。
|
||||
E、P、T、G、M、Kのいずれかのサフィックスを使用して、メモリーを整数または固定小数点数として表すことができます。
|
||||
また、Ei、Pi、Ti、Gi、Mi、Kiのような2の累乗の値を使用することもできます。
|
||||
たとえば、以下はほぼ同じ値を表しています。
|
||||
|
||||
@@ -104,11 +108,8 @@ metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: db
|
||||
image: mysql
|
||||
env:
|
||||
- name: MYSQL_ROOT_PASSWORD
|
||||
value: "password"
|
||||
- name: app
|
||||
image: images.my-company.example/app:v4
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
@@ -116,8 +117,8 @@ spec:
|
||||
limits:
|
||||
memory: "128Mi"
|
||||
cpu: "500m"
|
||||
- name: wp
|
||||
image: wordpress
|
||||
- name: log-aggregator
|
||||
image: images.my-company.example/log-aggregator:v6
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
@@ -185,7 +186,7 @@ kubeletは、ローカルのエフェメラルストレージを使用して、P
|
||||
また、kubeletはこの種類のストレージを使用して、[Nodeレベルのコンテナログ](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)、コンテナイメージ、実行中のコンテナの書き込み可能なレイヤーを保持します。
|
||||
|
||||
{{< caution >}}
|
||||
Nodeに障害が発生すると、そのエフェメラルストレージ内のデータが失われる可能性があります。
|
||||
Nodeに障害が発生すると、そのエフェメラルストレージ内のデータが失われる可能性があります。
|
||||
アプリケーションは、ローカルのエフェメラルストレージにパフォーマンスのサービス品質保証(ディスクのIOPSなど)を期待することはできません。
|
||||
{{< /caution >}}
|
||||
|
||||
@@ -242,7 +243,7 @@ Podの各コンテナは、次の1つ以上を指定できます。
|
||||
* `spec.containers[].resources.requests.ephemeral-storage`
|
||||
|
||||
`ephemeral-storage`の制限と要求はバイト単位で記します。
|
||||
ストレージは、次のいずれかの接尾辞を使用して、通常の整数または固定小数点整数として表すことができます。
|
||||
ストレージは、次のいずれかの接尾辞を使用して、通常の整数または固定小数点数として表すことができます。
|
||||
E、P、T、G、M、K。Ei、Pi、Ti、Gi、Mi、Kiの2のべき乗を使用することもできます。
|
||||
たとえば、以下はほぼ同じ値を表しています。
|
||||
|
||||
@@ -262,18 +263,15 @@ metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: db
|
||||
image: mysql
|
||||
env:
|
||||
- name: MYSQL_ROOT_PASSWORD
|
||||
value: "password"
|
||||
- name: app
|
||||
image: images.my-company.example/app:v4
|
||||
resources:
|
||||
requests:
|
||||
ephemeral-storage: "2Gi"
|
||||
limits:
|
||||
ephemeral-storage: "4Gi"
|
||||
- name: wp
|
||||
image: wordpress
|
||||
- name: log-aggregator
|
||||
image: images.my-company.example/log-aggregator:v6
|
||||
resources:
|
||||
requests:
|
||||
ephemeral-storage: "2Gi"
|
||||
@@ -300,6 +298,7 @@ kubeletがローカルのエフェメラルストレージをリソースとし
|
||||
Podが許可するよりも多くのエフェメラルストレージを使用している場合、kubeletはPodの排出をトリガーするシグナルを設定します。
|
||||
|
||||
コンテナレベルの分離の場合、コンテナの書き込み可能なレイヤーとログ使用量がストレージの制限を超えると、kubeletはPodに排出のマークを付けます。
|
||||
|
||||
Podレベルの分離の場合、kubeletはPod内のコンテナの制限を合計し、Podの全体的なストレージ制限を計算します。
|
||||
このケースでは、すべてのコンテナからのローカルのエフェメラルストレージの使用量とPodの`emptyDir`ボリュームの合計がPod全体のストレージ制限を超過する場合、
|
||||
kubeletはPodをまた排出対象としてマークします。
|
||||
@@ -345,7 +344,7 @@ Kubernetesでは、`1048576`から始まるプロジェクトIDを使用しま
|
||||
Kubernetesが使用しないようにする必要があります。
|
||||
|
||||
クォータはディレクトリスキャンよりも高速で正確です。
|
||||
ディレクトリがプロジェクトに割り当てられると、ディレクトリ配下に作成されたファイルはすべてそのプロジェクト内に作成され、カーネルはそのプロジェクト内のファイルによって使用されているブロックの数を追跡するだけです。
|
||||
ディレクトリがプロジェクトに割り当てられると、ディレクトリ配下に作成されたファイルはすべてそのプロジェクト内に作成され、カーネルはそのプロジェクト内のファイルによって使用されているブロックの数を追跡するだけです。
|
||||
ファイルが作成されて削除されても、開いているファイルディスクリプタがあれば、スペースを消費し続けます。
|
||||
クォータトラッキングはそのスペースを正確に記録しますが、ディレクトリスキャンは削除されたファイルが使用するストレージを見落としてしまいます。
|
||||
|
||||
@@ -354,7 +353,7 @@ Kubernetesが使用しないようにする必要があります。
|
||||
* kubelet設定で、`LocalocalStorpactionCapactionIsolationFSQuotaMonitoring=true`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gate/)を有効にします。
|
||||
|
||||
* ルートファイルシステム(またはオプションのランタイムファイルシステム))がプロジェクトクォータを有効にしていることを確認してください。
|
||||
すべてのXFSファイルシステムはプロジェクトクォータをサポートしています。
|
||||
すべてのXFSファイルシステムはプロジェクトクォータをサポートしています。
|
||||
ext4ファイルシステムでは、ファイルシステムがマウントされていない間は、プロジェクトクォータ追跡機能を有効にする必要があります。
|
||||
```bash
|
||||
# ext4の場合、/dev/block-deviceがマウントされていません
|
||||
|
||||
@@ -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)
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Secrets
|
||||
title: Secret
|
||||
content_type: concept
|
||||
feature:
|
||||
title: Secretと構成管理
|
||||
@@ -11,18 +11,18 @@ weight: 30
|
||||
<!-- overview -->
|
||||
|
||||
KubernetesのSecretはパスワード、OAuthトークン、SSHキーのような機密情報を保存し、管理できるようにします。
|
||||
Secretに機密情報を保存することは、それらを{{< glossary_tooltip text="Pod" term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載するより、安全で柔軟です。詳しくは[Secretの設計文書](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)を参照してください。
|
||||
Secretに機密情報を保存することは、それらを{{< glossary_tooltip text="Pod" term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載するより、安全で柔軟です。
|
||||
詳しくは[Secretの設計文書](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)を参照してください。
|
||||
|
||||
Secretはパスワード、トークン、キーのような小容量の機密データを含むオブジェクトです。
|
||||
他の方法としては、そのような情報はPodの定義やイメージに含めることができます。
|
||||
ユーザーはSecretを作ることができ、またシステムが作るSecretもあります。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Secretの概要
|
||||
|
||||
Secretはパスワード、トークン、キーのような小容量の機密データを含むオブジェクトです。
|
||||
他の方法としては、そのような情報はPodの定義やイメージに含めることができます。
|
||||
ユーザーはSecretを作ることができ、またシステムが作るSecretもあります。
|
||||
|
||||
Secretを使うには、PodはSecretを参照することが必要です。
|
||||
PodがSecretを使う方法は3種類あります。
|
||||
|
||||
@@ -30,392 +30,292 @@ PodがSecretを使う方法は3種類あります。
|
||||
- [コンテナの環境変数](#using-secrets-as-environment-variables)として利用する
|
||||
- Podを生成するために[kubeletがイメージをpullする](#using-imagepullsecrets)ときに使用する
|
||||
|
||||
### 内蔵のSecret
|
||||
|
||||
#### 自動的にサービスアカウントがAPIの認証情報のSecretを生成し、アタッチする
|
||||
|
||||
KubernetesはAPIにアクセスするための認証情報を含むSecretを自動的に生成し、この種のSecretを使うように自動的にPodを改変します。
|
||||
|
||||
必要であれば、APIの認証情報が自動生成され利用される機能は無効化したり、上書きしたりすることができます。しかし、安全にAPIサーバーでアクセスすることのみが必要なのであれば、これは推奨されるワークフローです。
|
||||
|
||||
サービスアカウントがどのように機能するのかについては、[サービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
のドキュメントを参照してください。
|
||||
|
||||
### Secretを作成する
|
||||
|
||||
#### `kubectl`を利用してSecretを作成する
|
||||
|
||||
SecretにはPodがデータベースにアクセスするために必要な認証情報を含むことができます。
|
||||
例えば、ユーザー名とパスワードからなる接続文字列です。
|
||||
ローカルマシンのファイル`./username.txt`にユーザー名を、ファイル`./password.txt`にパスワードを保存することができます。
|
||||
|
||||
```shell
|
||||
# この後の例で使用するファイルを作成します
|
||||
echo -n 'admin' > ./username.txt
|
||||
echo -n '1f2d1e2e67df' > ./password.txt
|
||||
```
|
||||
|
||||
`kubectl create secret`コマンドはそれらのファイルをSecretに格納して、APIサーバー上でオブジェクトを作成します。
|
||||
Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
|
||||
シークレットの構成ファイルを作成するときに、`data`および/または`stringData`フィールドを指定できます。`data`フィールドと`stringData`フィールドはオプションです。
|
||||
`data`フィールドのすべてのキーの値は、base64でエンコードされた文字列である必要があります。
|
||||
base64文字列への変換が望ましくない場合は、代わりに`stringData`フィールドを指定することを選択できます。これは任意の文字列を値として受け入れます。
|
||||
|
||||
|
||||
`data`と`stringData`のキーは、英数字、`-`、`_`、または`.`で構成されている必要があります。
|
||||
`stringData`フィールドのすべてのキーと値のペアは、内部で`data`フィールドにマージされます。
|
||||
キーが`data`フィールドと`stringData`フィールドの両方に表示される場合、`stringData`フィールドで指定された値が優先されます。
|
||||
|
||||
## Secretの種類 {#secret-types}
|
||||
|
||||
Secretを作成するときは、[`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)の`type`フィールド、または特定の同等の`kubectl`コマンドラインフラグ（使用可能な場合）を使用して、その型を指定できます。
|
||||
Secret型は、Secret dataのプログラムによる処理を容易にするために使用されます。
|
||||
|
||||
Kubernetesは、いくつかの一般的な使用シナリオに対応するいくつかの組み込み型を提供します。
|
||||
これらの型は、実行される検証とKubernetesが課す制約の点で異なります。
|
||||
|
||||
| Builtin Type | Usage |
|
||||
|--------------|-------|
|
||||
| `Opaque` | arbitrary user-defined data |
|
||||
| `kubernetes.io/service-account-token` | service account token |
|
||||
| `kubernetes.io/dockercfg` | serialized `~/.dockercfg` file |
|
||||
| `kubernetes.io/dockerconfigjson` | serialized `~/.docker/config.json` file |
|
||||
| `kubernetes.io/basic-auth` | credentials for basic authentication |
|
||||
| `kubernetes.io/ssh-auth` | credentials for SSH authentication |
|
||||
| `kubernetes.io/tls` | data for a TLS client or server |
|
||||
| `bootstrap.kubernetes.io/token` | bootstrap token data |
|
||||
|
||||
Secretオブジェクトの`type`値として空でない文字列を割り当てることにより、独自のSecret型を定義して使用できます。空の文字列は`Opaque`型として扱われます。Kubernetesは型名に制約を課しません。ただし、組み込み型の1つを使用している場合は、その型に定義されているすべての要件を満たす必要があります。
|
||||
|
||||
### Opaque secrets
|
||||
|
||||
`Opaque`は、Secret構成ファイルから省略された場合のデフォルトのSecret型です。
|
||||
`kubectl`を使用してSecretを作成する場合、`generic`サブコマンドを使用して`Opaque`Secret型を示します。 たとえば、次のコマンドは、`Opaque`型の空のSecretを作成します。
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`$`、`\`、`*`、`=`、`!`のような特殊文字は[シェル](https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%A7%E3%83%AB)に解釈されるので、エスケープする必要があります。
|
||||
ほとんどのシェルではパスワードをエスケープする最も簡単な方法はシングルクォート(`'`)で囲むことです。
|
||||
例えば、実際のパスワードが`S!B\*d$zDsb=`だとすると、実行すべきコマンドは下記のようになります。
|
||||
|
||||
```shell
|
||||
kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='
|
||||
```
|
||||
|
||||
`--from-file`を使ってファイルからパスワードを読み込む場合、ファイルに含まれるパスワードの特殊文字をエスケープする必要はありません。
|
||||
{{< /note >}}
|
||||
|
||||
Secretが作成されたことを確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get secrets
|
||||
kubectl create secret generic empty-secret
|
||||
kubectl get secret empty-secret
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
db-user-pass Opaque 2 51s
|
||||
NAME TYPE DATA AGE
|
||||
empty-secret Opaque 0 2m6s
|
||||
```
|
||||
|
||||
Secretの説明を参照することができます。
|
||||
`DATA`列には、Secretに保存されているデータ項目の数が表示されます。
|
||||
この場合、`0`は空のSecretを作成したことを意味します。
|
||||
|
||||
```shell
|
||||
kubectl describe secrets/db-user-pass
|
||||
```
|
||||
### Service account token Secrets
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
Name: db-user-pass
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password.txt: 12 bytes
|
||||
username.txt: 5 bytes
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`kubectl get`や`kubectl describe`コマンドはデフォルトではSecretの内容の表示を避けます。
|
||||
これはSecretを誤って盗み見られたり、ターミナルのログへ記録されてしまったりすることがないよう保護するためです。
|
||||
{{< /note >}}
|
||||
|
||||
Secretの内容を参照する方法は[Secretのデコード](#decoding-a-secret)を参照してください。
|
||||
|
||||
#### 手動でSecretを作成する
|
||||
|
||||
SecretをJSONまたはYAMLフォーマットのファイルで作成し、その後オブジェクトを作成することができます。
|
||||
Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
|
||||
[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)は、`data`と`stringData`の2つの連想配列を持ちます。
|
||||
`data`フィールドは任意のデータの保存に使われ、Base64でエンコードされています。
|
||||
`stringData`は利便性のために存在するもので、機密データをエンコードされない文字列で扱えます。
|
||||
|
||||
例えば、`data`フィールドを使って1つのSecretに2つの文字列を保存するには、次のように文字列をBase64エンコードします。
|
||||
|
||||
```shell
|
||||
echo -n 'admin' | base64
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
YWRtaW4=
|
||||
```
|
||||
|
||||
```shell
|
||||
echo -n '1f2d1e2e67df' | base64
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
このようなSecretを書きます。
|
||||
`kubernetes.io/service-account-token`型のSecretは、サービスアカウントを識別するトークンを格納するために使用されます。 このSecret型を使用する場合は、`kubernetes.io/service-account.name`アノテーションが既存のサービスアカウント名に設定されていることを確認する必要があります。Kubernetesコントローラーは、`kubernetes.io/service-account.uid`アノテーションや実際のトークンコンテンツに設定された`data`フィールドの`token`キーなど、他のいくつかのフィールドに入力します。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
name: secret-sa-sample
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: "sa-name"
|
||||
type: kubernetes.io/service-account-token
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
password: MWYyZDFlMmU2N2Rm
|
||||
# You can include additional key value pairs as you do with Opaque Secrets
|
||||
extra: YmFyCg==
|
||||
```
|
||||
|
||||
これでSecretを[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)コマンドで作成できるようになりました。
|
||||
`Pod`を作成すると、Kubernetesはservice account Secretを自動的に作成し、このSecretを使用するようにPodを自動的に変更します。service account token Secretには、APIにアクセスするための資格情報が含まれています。
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./secret.yaml
|
||||
```
|
||||
API証明の自動作成と使用は、必要に応じて無効にするか、上書きすることができます。 ただし、API Serverに安全にアクセスするだけの場合は、これが推奨されるワークフローです。
|
||||
|
||||
出力は次のようになります。
|
||||
ServiceAccountの動作の詳細については、[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)のドキュメントを参照してください。
|
||||
PodからServiceAccountを参照する方法については、[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)の`automountServiceAccountToken`フィールドと`serviceAccountName`フィールドを確認することもできます。
|
||||
|
||||
```
|
||||
secret "mysecret" created
|
||||
```
|
||||
### Docker config Secrets
|
||||
|
||||
状況によっては、代わりに`stringData`フィールドを使いたいときもあるでしょう。
|
||||
このフィールドを使えばBase64でエンコードされていない文字列を直接Secretに書くことができて、その文字列はSecretが作られたり更新されたりするときにエンコードされます。
|
||||
次の`type`値のいずれかを使用して、イメージのDockerレジストリにアクセスするための資格情報を格納するSecretを作成できます。
|
||||
|
||||
実用的な例として、設定ファイルの格納にSecretを使うアプリケーションをデプロイすることを考えます。
|
||||
デプロイプロセスの途中で、この設定ファイルの一部のデータを投入したいとしましょう。
|
||||
- `kubernetes.io/dockercfg`
|
||||
- `kubernetes.io/dockerconfigjson`
|
||||
|
||||
例えば、アプリケーションは次のような設定ファイルを使用するとします。
|
||||
|
||||
`kubernetes.io/dockercfg`型は、Dockerコマンドラインを構成するためのレガシー形式であるシリアル化された`~/.dockercfg`を保存するために予約されています。
|
||||
このSecret型を使用する場合は、Secretの`data`フィールドに`.dockercfg`キーが含まれていることを確認する必要があります。このキーの値は、base64形式でエンコードされた`~/.dockercfg`ファイルの内容です。
|
||||
|
||||
`kubernetes.io/dockerconfigjson`型は、`~/.dockercfg`の新しいフォーマットである`~/.docker/config.json`ファイルと同じフォーマットルールに従うシリアル化されたJSONを保存するために設計されています。
|
||||
このSecret型を使用する場合、Secretオブジェクトの`data`フィールドには`.dockerconfigjson`キーが含まれている必要があります。このキーでは、`~/.docker/config.json`ファイルのコンテンツがbase64でエンコードされた文字列として提供されます。
|
||||
|
||||
以下は、`kubernetes.io/dockercfg`型のSecretの例です。
|
||||
|
||||
```yaml
|
||||
apiUrl: "https://my.api.com/api/v1"
|
||||
username: "user"
|
||||
password: "password"
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
name: secret-dockercfg
|
||||
type: kubernetes.io/dockercfg
|
||||
data:
|
||||
.dockercfg: |
|
||||
"<base64 encoded ~/.dockercfg file>"
|
||||
```
|
||||
|
||||
次のような定義を使用して、この設定ファイルをSecretに保存することができます。
|
||||
{{< note >}}
|
||||
base64エンコーディングを実行したくない場合は、代わりに`stringData`フィールドを使用することを選択できます。
|
||||
{{< /note >}}
|
||||
|
||||
マニフェストを使用してこれらの型のSecretを作成すると、APIserverは期待されるキーが`data`フィールドに存在するかどうかを確認し、提供された値を有効なJSONとして解析できるかどうかを確認します。APIサーバーは、JSONが実際にDocker configファイルであるかどうかを検証しません。
|
||||
|
||||
|
||||
Docker configファイルがない場合、または`kubectl`を使用してDockerレジストリSecretを作成する場合は、次の操作を実行できます。
|
||||
|
||||
```shell
|
||||
kubectl create secret docker-registry secret-tiger-docker \
|
||||
--docker-username=tiger \
|
||||
--docker-password=pass113 \
|
||||
--docker-email=tiger@acme.com
|
||||
```
|
||||
|
||||
このコマンドは、`kubernetes.io/dockerconfigjson`型のSecretを作成します。
|
||||
`data`フィールドから`.dockerconfigjson`コンテンツをダンプすると、その場で作成された有効なDocker configである次のJSONコンテンツを取得します。
|
||||
|
||||
```json
|
||||
{
|
||||
"auths": {
|
||||
"https://index.docker.io/v1/": {
|
||||
"username": "tiger",
|
||||
"password": "pass113",
|
||||
"email": "tiger@acme.com",
|
||||
"auth": "dGlnZXI6cGFzczExMw=="
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Basic authentication Secret
|
||||
|
||||
`kubernetes.io/basic-auth`型は、Basic認証に必要な認証を保存するために提供されています。このSecret型を使用する場合、Secretの`data`フィールドには次の2つのキーが含まれている必要があります。
|
||||
|
||||
- `username`: 認証のためのユーザー名
|
||||
- `password`: 認証のためのパスワードかトークン
|
||||
|
||||
上記の2つのキーの両方の値は、base64でエンコードされた文字列です。もちろん、Secretの作成に`stringData`を使用してクリアテキストコンテンツを提供することもできます。
|
||||
|
||||
次のYAMLは、Basic authentication Secretの設定例です。
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
name: secret-basic-auth
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
config.yaml: |-
|
||||
apiUrl: "https://my.api.com/api/v1"
|
||||
username: {{username}}
|
||||
password: {{password}}
|
||||
username: admin
|
||||
password: t0p-Secret
|
||||
```
|
||||
|
||||
デプロイツールは`kubectl apply`を実行する前に`{{username}}`と`{{password}}`のテンプレート変数を置換することができます。
|
||||
|
||||
`stringData`フィールドは利便性のための書き込み専用フィールドです。
|
||||
Secretを取得するときに出力されることは決してありません。
|
||||
例えば、次のコマンドを実行すると、
|
||||
Basic認証Secret型は、ユーザーの便宜のためにのみ提供されています。Basic認証に使用される資格情報の`Opaque`を作成できます。
|
||||
ただし、組み込みのSecret型を使用すると、認証の形式を統一するのに役立ち、APIserverは必要なキーがSecret configurationで提供されているかどうかを確認します。
|
||||
|
||||
|
||||
### SSH authentication secrets
|
||||
|
||||
組み込みのタイプ`kubernetes.io/ssh-auth`は、SSH認証で使用されるデータを保存するために提供されています。このSecret型を使用する場合、使用するSSH認証として`data`（または`stringData`）フィールドに`ssh-privatekey`キーと値のペアを指定する必要があります。
|
||||
|
||||
次のYAMLはSSH authentication Secretの設定例です：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-ssh-auth
|
||||
type: kubernetes.io/ssh-auth
|
||||
data:
|
||||
# the data is abbreviated in this example
|
||||
ssh-privatekey: |
|
||||
MIIEpQIBAAKCAQEAulqb/Y ...
|
||||
```
|
||||
|
||||
SSH authentication Secret型は、ユーザーの便宜のためにのみ提供されています。
|
||||
SSH認証に使用される資格情報の`Opaque`を作成できます。
|
||||
ただし、組み込みのSecret型を使用すると、認証の形式を統一するのに役立ち、APIserverは必要なキーがSecret configurationで提供されているかどうかを確認します。
|
||||
|
||||
### TLS secrets
|
||||
|
||||
Kubernetesは、TLSに通常使用される証明書とそれに関連付けられたキーを保存するための組み込みのSecret型`kubernetes.io/tls`を提供します。このデータは、主にIngressリソースのTLS terminationで使用されますが、他のリソースで使用されることも、ワークロードによって直接使用されることもあります。
|
||||
このSecret型を使用する場合、APIサーバーは各キーの値を実際には検証しませんが、`tls.key`および`tls.crt`キーをSecret configurationの`data`（または`stringData`）フィールドに指定する必要があります。
|
||||
|
||||
|
||||
次のYAMLはTLS Secretの設定例です：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: secret-tls
|
||||
type: kubernetes.io/tls
|
||||
data:
|
||||
# the data is abbreviated in this example
|
||||
tls.crt: |
|
||||
MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
|
||||
tls.key: |
|
||||
MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
|
||||
```
|
||||
|
||||
TLS Secret型は、ユーザーの便宜のために提供されています。 TLSサーバーやクライアントに使用される資格情報の`Opaque`を作成できます。ただし、組み込みのSecret型を使用すると、プロジェクトでSecret形式の一貫性を確保できます。APIserverは、必要なキーがSecret configurationで提供されているかどうかを確認します。
|
||||
|
||||
`kubectl`を使用してTLS Secretを作成する場合、次の例に示すように`tls`サブコマンドを使用できます。
|
||||
|
||||
```shell
|
||||
kubectl get secret mysecret -o yaml
|
||||
kubectl create secret tls my-tls-secret \
|
||||
--cert=path/to/cert/file \
|
||||
--key=path/to/key/file
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
公開鍵と秘密鍵のペアは、事前に存在している必要があります。`--cert`の公開鍵証明書は.PEMエンコード（Base64エンコードDER形式）であり、`--key`の指定された秘密鍵と一致する必要があります。
|
||||
秘密鍵は、一般にPEM秘密鍵形式と呼ばれる暗号化されていない形式である必要があります。どちらの場合も、PEMの最初と最後の行（たとえば、`-------- BEGIN CERTIFICATE -----`と`------- END CERTIFICATE ----`）は含まれて*いません*。
|
||||
|
||||
### Bootstrap token Secrets
|
||||
|
||||
Bootstrap token Secretは、Secretの`type`を`bootstrap.kubernetes.io/token`に明示的に指定することで作成できます。このタイプのSecretは、ノードのブートストラッププロセス中に使用されるトークン用に設計されています。よく知られているConfigMapに署名するために使用されるトークンを格納します。
|
||||
|
||||
Bootstrap toke Secretは通常、`kube-system`namespaceで作成され`bootstrap-token-<token-id>`の形式で名前が付けられます。ここで`<token-id>`はトークンIDの6文字の文字列です。
|
||||
|
||||
Kubernetesマニフェストとして、Bootstrap token Secretは次のようになります。
|
||||
|
||||
```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
|
||||
name: bootstrap-token-5emitj
|
||||
namespace: kube-system
|
||||
type: bootstrap.kubernetes.io/token
|
||||
data:
|
||||
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
|
||||
auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
|
||||
expiration: MjAyMC0wOS0xM1QwNDozOToxMFo=
|
||||
token-id: NWVtaXRq
|
||||
token-secret: a3E0Z2lodnN6emduMXAwcg==
|
||||
usage-bootstrap-authentication: dHJ1ZQ==
|
||||
usage-bootstrap-signing: dHJ1ZQ==
|
||||
```
|
||||
|
||||
`username`のようなフィールドを`data`と`stringData`の両方で指定すると、`stringData`の値が使用されます。
|
||||
例えば、次のSecret定義からは
|
||||
|
||||
Bootstrap type Secretには、`data`で指定された次のキーがあります。
|
||||
|
||||
- `token_id`：トークン識別子としてのランダムな6文字の文字列。必須。
|
||||
- `token-secret`：実際のtoken secretとしてのランダムな16文字の文字列。必須。
|
||||
- `description`：トークンの使用目的を説明する人間が読める文字列。オプション。
|
||||
- `expiration`：トークンの有効期限を指定するRFC3339を使用した絶対UTC時間。オプション。
|
||||
- `usage-bootstrap-<usage>`：Bootstrap tokenの追加の使用法を示すブールフラグ。
|
||||
- `auth-extra-groups`：`system：bootstrappers`グループに加えて認証されるグループ名のコンマ区切りのリスト。
|
||||
|
||||
上記のYAMLは、値がすべてbase64でエンコードされた文字列であるため、混乱しているように見える場合があります。実際、次のYAMLを使用して同一のSecretを作成できます。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: mysecret
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
# Note how the Secret is named
|
||||
name: bootstrap-token-5emitj
|
||||
# A bootstrap token Secret usually resides in the kube-system namespace
|
||||
namespace: kube-system
|
||||
type: bootstrap.kubernetes.io/token
|
||||
stringData:
|
||||
username: administrator
|
||||
auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token"
|
||||
expiration: "2020-09-13T04:39:10Z"
|
||||
# This token ID is used in the name
|
||||
token-id: "5emitj"
|
||||
token-secret: "kq4gihvszzgn1p0r"
|
||||
# This token can be used for authentication
|
||||
usage-bootstrap-authentication: "true"
|
||||
# and it can be used for signing
|
||||
usage-bootstrap-signing: "true"
|
||||
```
|
||||
|
||||
次のようなSecretが生成されます。
|
||||
## Secretの作成
|
||||
|
||||
```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==
|
||||
```
|
||||
Secretを作成するには、いくつかのオプションがあります。
|
||||
|
||||
`YWRtaW5pc3RyYXRvcg==`をデコードすると`administrator`になります。
|
||||
- [create Secret using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- [create Secret from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [create Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
|
||||
`data`や`stringData`のキーは英数字または'-'、'_'、'.'からなる必要があります。
|
||||
|
||||
{{< note >}}
|
||||
シリアライズされたJSONやYAMLの機密データはBase64エンコードされています。
|
||||
文字列の中の改行は不正で、含まれていてはなりません。
|
||||
Darwin/macOSの`base64`ユーティリティーを使うときは、長い行を分割する`-b`オプションを指定するのは避けるべきです。
|
||||
反対に、Linuxユーザーは`base64`コマンドに`-w 0`オプションを指定するか、`-w`オプションが使えない場合は`base64 | tr -d '\n'`のようにパイプ*すべき*です。
|
||||
{{< /note >}}
|
||||
|
||||
#### ジェネレーターからSecretを作成する
|
||||
|
||||
Kubernetes v1.14から、`kubectl`は[Kustomizeを使ったオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/)に対応しています。
|
||||
KustomizeはSecretやConfigMapを生成するリソースジェネレーターを提供します。
|
||||
Kustomizeのジェネレーターはディレクトリの中の`kustomization.yaml`ファイルにて指定されるべきです。
|
||||
Secretが生成された後には、`kubectl apply`コマンドを使用してAPIサーバー上にSecretを作成することができます。
|
||||
|
||||
#### ファイルからのSecretの生成
|
||||
|
||||
./username.txtと./password.txtのファイルから生成するように`secretGenerator`を定義することで、Secretを生成することができます。
|
||||
|
||||
```shell
|
||||
cat <<EOF >./kustomization.yaml
|
||||
secretGenerator:
|
||||
- name: db-user-pass
|
||||
files:
|
||||
- username.txt
|
||||
- password.txt
|
||||
EOF
|
||||
```
|
||||
|
||||
Secretを生成するには、`kustomization.yaml`を含むディレクトリをapplyします。
|
||||
|
||||
```shell
|
||||
kubectl apply -k .
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
secret/db-user-pass-96mffmfh4k created
|
||||
```
|
||||
|
||||
Secretが生成されたことを確認できます。
|
||||
|
||||
```shell
|
||||
kubectl get secrets
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
db-user-pass-96mffmfh4k Opaque 2 51s
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl describe secrets/db-user-pass-96mffmfh4k
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
Name: db-user-pass
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password.txt: 12 bytes
|
||||
username.txt: 5 bytes
|
||||
```
|
||||
|
||||
#### 文字列リテラルからのSecretの生成
|
||||
|
||||
リテラル`username=admin`と`password=secret`から生成するように`secretGenerator`を定義して、Secretを生成することができます。
|
||||
|
||||
```shell
|
||||
cat <<EOF >./kustomization.yaml
|
||||
secretGenerator:
|
||||
- name: db-user-pass
|
||||
literals:
|
||||
- username=admin
|
||||
- password=secret
|
||||
EOF
|
||||
```
|
||||
|
||||
Secretを生成するには、`kustomization.yaml`を含むディレクトリをapplyします。
|
||||
|
||||
```shell
|
||||
kubectl apply -k .
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
secret/db-user-pass-dddghtt9b5 created
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Secretが生成されるとき、Secretのデータからハッシュ値が算出され、Secretの名称にハッシュ値が加えられます。
|
||||
これはデータが更新されたときに毎回新しいSecretが生成されることを保証します。
|
||||
{{< /note >}}
|
||||
|
||||
#### Secretのデコード
|
||||
|
||||
Secretは`kubectl get secret`を実行することで取得可能です。
|
||||
例えば、前のセクションで作成したSecretは次のコマンドを実行することで参照できます。
|
||||
|
||||
```shell
|
||||
kubectl get secret mysecret -o yaml
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
creationTimestamp: 2016-01-22T18:41:56Z
|
||||
name: mysecret
|
||||
namespace: default
|
||||
resourceVersion: "164619"
|
||||
uid: cfee02d6-c137-11e5-8d73-42010af00002
|
||||
type: Opaque
|
||||
data:
|
||||
username: YWRtaW4=
|
||||
password: MWYyZDFlMmU2N2Rm
|
||||
```
|
||||
|
||||
`password`フィールドをデコードします。
|
||||
|
||||
```shell
|
||||
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
|
||||
```
|
||||
|
||||
出力は次のようになります。
|
||||
|
||||
```
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
#### Secretの編集
|
||||
## Secretの編集
|
||||
|
||||
既存のSecretは次のコマンドで編集することができます。
|
||||
|
||||
@@ -457,7 +357,7 @@ Secretは直接Podが参照できるようにはされず、システムの別
|
||||
PodのボリュームとしてSecretを使うには、
|
||||
|
||||
1. Secretを作成するか既存のものを使用します。複数のPodが同一のSecretを参照することができます。
|
||||
1. ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下をを書き換えます。ボリュームに命名し、`.spec.volumes[].secret.secretName`フィールドはSecretオブジェクトの名称と同一にします。
|
||||
1. ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下を書き換えます。ボリュームに命名し、`.spec.volumes[].secret.secretName`フィールドはSecretオブジェクトの名称と同一にします。
|
||||
1. Secretを必要とするそれぞれのコンテナに`.spec.containers[].volumeMounts[]`を追加します。`.spec.containers[].volumeMounts[].readOnly = true`を指定して`.spec.containers[].volumeMounts[].mountPath`をSecretをマウントする未使用のディレクトリ名にします。
|
||||
1. イメージやコマンドラインを変更し、プログラムがそのディレクトリを参照するようにします。連想配列`data`のキーは`mountPath`以下のファイル名になります。
|
||||
|
||||
@@ -491,7 +391,7 @@ Podに複数のコンテナがある場合、それぞれのコンテナが`volu
|
||||
#### Secretのキーの特定のパスへの割り当て
|
||||
|
||||
Secretのキーが割り当てられるパスを制御することができます。
|
||||
それぞれのキーがターゲットとするパスは`.spec.volumes[].secret.items`フィールドによって指定てきます。
|
||||
それぞれのキーがターゲットとするパスは`.spec.volumes[].secret.items`フィールドによって指定できます。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -668,32 +568,6 @@ Secretはwatch（デフォルト）、TTLベース、単に全てのリクエス
|
||||
Secretを[subPath](/docs/concepts/storage/volumes#using-subpath)を指定してボリュームにマウントしているコンテナには、Secretの更新が反映されません。
|
||||
{{< /note >}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
|
||||
|
||||
Kubernetesのアルファ機能である _Immutable Secrets and ConfigMaps_ は各SecretやConfigMapが不変であると設定できるようにします。
|
||||
Secretを広範に利用しているクラスター（PodにマウントされているSecretが1万以上）においては、データが変更されないようにすることで次のような利点が得られます。
|
||||
|
||||
- 意図しない（または望まない）変更によってアプリケーションの停止を引き起こすことを防ぎます
|
||||
- 不変であると設定されたSecretの監視を停止することにより、kube-apiserverの負荷が著しく軽減され、クラスターのパフォーマンスが改善されます
|
||||
|
||||
この機能を利用するには、`ImmutableEphemeralVolumes`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretまたはConfigMapの`immutable`フィールドに`true`を指定します。例えば、次のようにします。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
...
|
||||
data:
|
||||
...
|
||||
immutable: true
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
一度SecretやConfigMapを不変であると設定すると、この変更を戻すことや`data`フィールドの内容を書き換えることは _できません_ 。
|
||||
Secretを削除して、再生成することだけができます。
|
||||
既存のPodは削除されたSecretへのマウントポイントを持ち続けるため、Podを再生成することが推奨されます。
|
||||
{{< /note >}}
|
||||
|
||||
### Secretを環境変数として使用する {#using-secrets-as-environment-variables}
|
||||
|
||||
SecretをPodの{{< glossary_tooltip text="環境変数" term_id="container-env-variables" >}}として使用するには、
|
||||
@@ -753,12 +627,38 @@ echo $SECRET_PASSWORD
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
## Immutable Secrets {#secret-immutable}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
Kubernetesベータ機能*ImmutableSecrets and ConfigMaps*は、個々のSecretsとConfigMapsをimutableとして設定するオプションを提供します。Secret（少なくとも数万の、SecretからPodへの一意のマウント）を広範囲に使用するクラスターの場合、データの変更を防ぐことには次の利点があります。
|
||||
|
||||
- アプリケーションの停止を引き起こす可能性のある偶発的な（または不要な）更新からユーザーを保護します
|
||||
- imutableとしてマークされたSecretのウォッチを閉じることで、kube-apiserverの負荷を大幅に削減することができ、クラスターのパフォーマンスを向上させます。
|
||||
|
||||
この機能は、`ImmutableEphemeralVolumes`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)によって制御されます。これは、v1.19以降デフォルトで有効になっています。`immutable`フィールドを`true`に設定することで、imutableのSecretを作成できます。例えば、
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
...
|
||||
data:
|
||||
...
|
||||
immutable: true
|
||||
```
|
||||
{{< note >}}
|
||||
SecretまたはConfigMapがimutableとしてマークされると、この変更を元に戻したり、`data`フィールドの内容を変更したりすることは*できません*。Secretを削除して再作成することしかできません。
|
||||
既存のPodは、削除されたSecretへのマウントポイントを維持します。これらのPodを再作成することをお勧めします。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
### imagePullSecretsを使用する {#using-imagepullsecrets}
|
||||
|
||||
`imagePullSecrets`フィールドは同一のネームスペース内のSecretの参照のリストです。
|
||||
kubeletにDockerやその他のイメージレジストリのパスワードを渡すために、`imagePullSecrets`にそれを含むSecretを指定することができます。
|
||||
kubeletはこの情報をPodのためにプライベートイメージをpullするために使います。
|
||||
`imagePullSecrets`の詳細は[PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)を参照してください。
|
||||
`imagePullSecrets`の詳細は[PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core)を参照してください。
|
||||
|
||||
#### imagePullSecretを手動で指定する
|
||||
|
||||
@@ -1028,8 +928,8 @@ kubectl apply -k .
|
||||
|
||||
2つのサービスアカウントを使用すると、ベースのPod仕様をさらに単純にすることができます。
|
||||
|
||||
1. `prod-user` と `prod-db-secret`
|
||||
1. `test-user` と `test-db-secret`
|
||||
1. `prod-user`と`prod-db-secret`
|
||||
1. `test-user`と`test-db-secret`
|
||||
|
||||
簡略化されたPod仕様は次のようになります。
|
||||
|
||||
@@ -1155,3 +1055,10 @@ Podに複数のコンテナが含まれることもあります。しかし、Po
|
||||
- Secretを利用するPodを作成できるユーザーはSecretの値を見ることができます。たとえAPIサーバーのポリシーがユーザーにSecretの読み取りを許可していなくても、ユーザーはSecretを晒すPodを実行することができます。
|
||||
- 現在、任意のノードでルート権限を持つ人は誰でも、kubeletに偽装することで _任意の_ SecretをAPIサーバーから読み取ることができます。
|
||||
単一のノードのルート権限を不正に取得された場合の影響を抑えるため、実際に必要としているノードに対してのみSecretを送る機能が計画されています。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [`kubectl`を使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を学ぶ
|
||||
- [config fileを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を学ぶ
|
||||
- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を学ぶ
|
||||
|
||||
Reference in New Issue
Block a user