翻訳
このドキュメントは The Kubectl Book の翻訳です。翻訳の GitHub リポジトリはこちら。
Experimental
TL;DR
- ディレクトリの階層を分けることでリソース構成を構造化する
- 環境とクラスタの構成バリエーションを分離するためにディレクトリを分離する
ディレクトリ構造をベースとしたレイアウト
動機
どの方法が正しいのですか？
この章ではディレクトリを使った方法を扱いますが、必要に応じてブランチとリポジトリを使う方法も併用してください。
構成の専用レポジトリかモノレポか
この章で説明する方法は、デプロイするソースコードと同じリポジトリにリソース構成を置いても、別の専用リポジトリに切り分けても、どちらでも実行できます。
ディレクトリ構想
| ディレクトリのタイプ | クラスタへのデプロイ | 内容 | ディレクトリ名の例 |
|---|---|---|---|
| ベース | No - ベースとして使用 | 共有の構成 | base/ |
| 環境 | No - 他のディレクトリを含む | ベースとクラスタのディレクトリ | test/, staging/, prod/ |
| クラスタ | Yes - 手動でまたは継続的にデプロイ | デプロイ可能な構成 | us-west1, us-east1, us-central1 |
ベース
Kustomize ベース (例えば bases:) は kustomization.yaml をいくらか利用することでカスタマイズされた共有の構成を提供します。
この章で概説されるディレクトリ構造はベースを app-bases/environment-bases/cluster として階層化します。
ワークフローの例
- env/cluster/ に対して行われた変更は、特定の環境の特定のクラスタにのみロールアウトされる
- env>/bases/ に対して行われた変更は、その環境のすべてのクラスタにロールアウトされる
- bases/ に対して行われた変更は、すべての環境のすべてのクラスタにロールアウトされる
図
graph TD;
B("bases/ ")---|base|P("prod/bases/ ");
B("bases/ ")---|base|S("staging/bases/ ");
B("bases/ ")---|base|T("test/bases/ ");
P("prod/bases/ ")---|base|PUW("prod/us-west/ ");
P("prod/bases/ ")---|base|PUE("prod/us-east/ ");
P("prod/bases/ ")---|base|PUC("prod/us-central/ ");
S("staging/bases/ ")---|base|SUW("staging/us-west/ ");
T("test/bases/ ")---|base|TUW("test/us-west/ ");
シナリオ
- アリスは prod/us-west1 に変更 A を行う
- 変更は継続的デプロイメントによって prod 環境の us-west1 クラスタにプッシュされる
- アリスは prod/bases に変更 B を行う
- 変更は継続的デプロイメントによって prod 環境のすべてのクラスタにプッシュされる
- アリスは bases に変更 C を行う
- 変更は継続的デプロイメントによってすべてのクラスタにプッシュされる
テクニック:
- 各レイヤーには namePrefix と commonLabels を追加する
- 各レイヤーにはラベルとアノテーションを追加する
- デプロイ可能な各対象は名前空間には設定する
- Pod の環境変数と引数を
configMapGeneratorのbehavior: mergeを使って上書きする - カスタマイズの最後の微調整は patch / overlay で行う
構造:
- 再利用可能な base は
*/bases/下に置く<project-name>/bases/<project-name>/<environment>/bases/
- デプロイ可能な対象は
<project-name>/<environment>/<cluster>/下に置く
tree
.
├── bases # Used as a Base only
│ ├── kustomization.yaml
│ ├── backend
│ │ ├── deployment.yaml
│ │ └── service.yaml
│ ├── frontend
│ │ ├── deployment.yaml
│ │ ├── ingress.yaml
│ │ └── service.yaml
│ └── storage
│ ├── service.yaml
│ └── statefulset.yaml
├── prod # Production
│ ├── bases
│ │ ├── kustomization.yaml # Uses bases: ["../../bases"]
│ │ ├── backend
│ │ │ └── deployment-patch.yaml # Production Env specific backend overrides
│ │ ├── frontend
│ │ │ └── deployment-patch.yaml # Production Env specific frontend overrides
│ │ └── storage
│ │ └── statefulset-patch.yaml # Production Env specific storage overrides
│ ├── us-central
│ │ ├── kustomization.yaml # Uses bases: ["../bases"]
│ │ └── backend
│ │ └── deployment-patch.yaml # us-central cluster specific backend overrides
│ ├── us-east
│ │ └── kustomization.yaml # Uses bases: ["../bases"]
│ └── us-west
│ └── kustomization.yaml # Uses bases: ["../bases"]
├── staging # Staging
│ ├── bases
│ │ ├── kustomization.yaml # Uses bases: ["../../bases"]
│ └── us-west
│ └── kustomization.yaml # Uses bases: ["../bases"]
└── test # Test
├── bases
│ ├── kustomization.yaml # Uses bases: ["../../bases"]
└── us-west
└── kustomization.yaml # Uses bases: ["../bases"]
環境 + クラスタの Apply
ディレクトリ構造にはクラスタがパスに含まれますが、これは Apply 時にクラスタのコンテキストを決定するために使われはしません。特定のクラスタを Apply するには、そのクラスタを kubectl 設定に追加し、Apply 実行時に対応するコンテキストを指定します。
詳細はマルチクラスタを参照。
Code Owners
git のホスティングサービスには、きめ細かい権限モデルを提供するためにコードオーナーを設定できるものがあります。コードオーナーは分離された各環境 (たとえば dev、test、prod) のために権限を分離するためにも利用できます。