Kubernetes 入門コース / Chapter 03

ローカルで作るアプリケーション全体像

API、DB、バッチをKubernetes上の別々のワークロードとして分ける理由を理解する。

この章で学ぶこと

  1. API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。
  2. ローカルでもクラスタ内通信と手元からの接続を区別する。
  3. 構成全体を先に描くと、各チャプターのリソースの役割がつながる。

01API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない

なぜ必要か:API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。

API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。
図の読み方:宣言した状態から、実際の動作へ矢印を追う。

API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。 実装では、対象リソース・設定値・実行結果を別々に確認する。

判断できるようになること:API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。

02ローカルでもクラスタ内通信と手元からの接続を区別する

設計の境界:ローカルでもクラスタ内通信と手元からの接続を区別する。

ローカルでもクラスタ内通信と手元からの接続を区別する。
図の読み方:責務を混ぜず、設定と実行の境界を確認する。

ローカルでもクラスタ内通信と手元からの接続を区別する。 そのため、更新対象と依存先を同時に変えず、差分を確認してから反映する。

判断できるようになること:API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。

03構成全体を先に描くと、各チャプターのリソースの役割がつながる

運用で確認する証跡:構成全体を先に描くと、各チャプターのリソースの役割がつながる。

構成全体を先に描くと、各チャプターのリソースの役割がつながる。
図の読み方:正常時だけでなく、確認・復旧の順番を追う。

構成全体を先に描くと、各チャプターのリソースの役割がつながる。 障害時は画面の表示だけで判断せず、状態・イベント・ログを順番に照合する。

判断できるようになること:API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。

章のまとめ

  1. API・DB・バッチはライフサイクルが違うため、同じリソースに混ぜない。
  2. ローカルでもクラスタ内通信と手元からの接続を区別する。
  3. 構成全体を先に描くと、各チャプターのリソースの役割がつながる。