ローカルで作るアプリケーション全体像
API、DB、バッチをKubernetes上の別々のワークロードとして分ける理由を理解する。
この章で学ぶこと
- API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。
- ローカルでもクラスタ内通信と手元からの接続を区別する。
- 構成全体を先に描くと、各チャプターのリソースの役割がつながる。
01API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない
なぜ必要か:API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。

API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。 実装では、対象リソース・設定値・実行結果を別々に確認する。
判断できるようになること:API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。
02ローカルでもクラスタ内通信と手元からの接続を区別する
設計の境界:ローカルでもクラスタ内通信と手元からの接続を区別する。

ローカルでもクラスタ内通信と手元からの接続を区別する。 そのため、更新対象と依存先を同時に変えず、差分を確認してから反映する。
判断できるようになること:API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。
03構成全体を先に描くと、各チャプターのリソースの役割がつながる
運用で確認する証跡:構成全体を先に描くと、各チャプターのリソースの役割がつながる。

構成全体を先に描くと、各チャプターのリソースの役割がつながる。 障害時は画面の表示だけで判断せず、状態・イベント・ログを順番に照合する。
判断できるようになること:API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。
章のまとめ
- API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。
- ローカルでもクラスタ内通信と手元からの接続を区別する。
- 構成全体を先に描くと、各チャプターのリソースの役割がつながる。