どんな場面で検討するか
複数のコンテナをKubernetesのマニフェストで配布し、Podの増減・段階的更新・障害時の再配置を揃えたい場合。AzureのID・ネットワーク・監視へ接続する既存基盤で候補になる。
組織で使う条件
Kubernetesとノードの更新、Podのrequests/limits、readiness、権限とネットワークポリシーを管理する。ワークロード用IDと管理者IDを分け、永続データのバックアップと復元を試す。
採用前に試すこと
- 小規模クラスターへ受注APIを2Podで配備し、requests/limits・readiness・最小権限のIDを設定する。
- 合成要求100件を送り、1Podの削除と新イメージへの更新を実施し、成功件数・重複・応答遅延を記録する。
- 旧イメージへ戻し、不要リソースを削除して課金明細と残存ディスク・IPを照合する。
合格と判断する条件
- 100要求の結果が照合でき、再配置・更新で失敗した要求は再試行で回復する。旧版へ戻せ、権限外リソースへの接続が拒否される。
- 運用担当が変更・監視・復旧を再現でき、クラスター料金とノード等の費用を区別できる。
見落としたくない点
- 単一のHTTPアプリを公開するだけでKubernetesの移植性や制御が不要なら、App ServiceやContainer Appsと運用負担を比較する。マネージド制御プレーンだけでアプリ・ノードの運用まで不要になるとは判断しない。
- 単一のHTTPアプリを公開するだけでKubernetesの移植性や制御が不要なら、App ServiceやContainer Appsと運用負担を比較する。マネージド制御プレーンだけでアプリ・ノードの運用まで不要になるとは判断しない。