Kubernetesの主要リソースを、AWSの経験から読み解く
Kubernetesは未知の部品の寄せ集めではなく、アプリを動かすための責務を宣言する仕組みです。AWSで触れた実行・公開・設定・保存を対応づけると、リソース名を暗記せずに読めます。
TL;DR
- Podは実行単位、Deploymentは望む台数を保つ管理者、Serviceは到達先を安定させる窓口。
- ConfigMap・Secret・PVCは、コードから設定・認証情報・保存領域を分離する。
- AWSとの対応は理解の足場。完全に同じものではないため、責務で捉える。
01まずは「何を動かすか」
Pod・Node・コンテナの入れ子構造を、AWS ECSとの対応を添えて示す
Podはコンテナを動かす最小単位です。複数コンテナが同じPodに入る場合は、ネットワークとライフサイクルを共有します。NodeはPodを載せる実行基盤で、スケジューラがどのNodeで動かすかを決めます。
押さえること：Podは実行単位、Deploymentは望む台数を保つ管理者、Serviceは到達先を安定させる窓口。
02望む状態を保つコントローラ
Deployment→ReplicaSet→Podの制御ループを、目標台数と実際台数の比較で示す
Deploymentに「このPod仕様をこの台数」と書くと、DeploymentがReplicaSetを作り、ReplicaSetがPod数を維持します。Podを直接増減するのではなく、上位の宣言を変えるのが基本です。
押さえること：ConfigMap・Secret・PVCは、コードから設定・認証情報・保存領域を分離する。
03接続・設定・保存を外へ出す
Service・ConfigMap・Secret・PVCがPodを支える全体図
Serviceは入れ替わるPod群への安定した接続先です。ConfigMapとSecretは設定値を、PV/PVCはデータの保存先と利用要求を分離します。各リソースは「実行するもの」と「実行に必要なもの」を切り離すためにあります。
押さえること：AWSとの対応は理解の足場。完全に同じものではないため、責務で捉える。
結論
- Podは実行単位、Deploymentは望む台数を保つ管理者、Serviceは到達先を安定させる窓口。
- ConfigMap・Secret・PVCは、コードから設定・認証情報・保存領域を分離する。
- AWSとの対応は理解の足場。完全に同じものではないため、責務で捉える。