プラットフォームのアーキテクチャは何から決めるのか
一言でいうと
設計はツールを選ぶ作業ではなく、どんな失敗を許容し、何を保証するかを決める作業です。特にアドレス空間、データの所有権、障害時に残すべき容量は、デプロイツールより先に検討します。
なぜ必要なのか
次は練習用の状況です。注文サービスを新しいバージョンに切り替えようとしたところ、Pod1つがPendingのまま止まりました。ある担当者はノードを追加しようと言い、別の担当者はカナリアをブルー/グリーンに変えようと言います。しかし、まだ誰もPodのイベントとボリュームの位置を確認していません。原因がボリュームのノード制約なら、CPUを増やしても解決しませんし、2つのバージョンが同じデータに同時に書き込んではいけないという問題なら、トラフィックの切り替え方式を変えただけでは解決しません。
最初に設計の前提を書き出します。データは再生成できるか、新旧のバージョンが同時に書き込んでもよいか、ノードが1つなくなってもサービスを続ける必要があるか。答えがなければ、アーキテクチャ図にボックスが増えても復旧手順は出てきません。
どう動くのか
アドレス空間と候補ノード
たとえばPod用の/16をノードごとに/24に分けるアドレス割り当て方式なら、算術的には256個のブロックができます。実際のノード数の上限はCNI・予約・クラスター設定によって決まるため、これをそのまま運用可能なノード数として書きません。Service・Pod・社内ネットワーク・VPNのアドレスが重なっていないかも合わせて検討します。CIDRやCNIの変更は、実装によっては移行や再構築が必要になる場合があるため、初期に調べておく価値が大きいです。
PodがPendingの場合は、合計CPUよりも先に、スケジューラーが許可する候補とイベントを確認します。nodeSelectorだけでなく、affinity、taint/toleration、ボリュームtopology、requestsがそろって候補を絞り込みます。ラベルが合っているというだけでは、配置できることは保証できません。
kubectl get nodes --show-labels
kubectl -n team-a describe pod orders-canary
kubectl -n team-a get events --sort-by=.metadata.creationTimestamp
kubectl -n team-a get pvc
上のコマンドのteam-aとorders-canaryは説明用の名前です。実際のラボでは対象の名前に置き換え、エラーイベントの主体がschedulerなのか、ボリュームの接続・マウントの過程なのかを区別します。
RWOのOnceはPod1つという意味ではありません
ReadWriteOnce(RWO)は、1つのノードから読み書きできるアクセスモードです。同じノード上の複数のPodが同じボリュームを使えます。Pod1つだけを許可するReadWriteOncePod(RWOP)は別のモードで、CSIなどのサポート条件を確認する必要があります。RWXが可能だからといって、アプリケーションの同時書き込みまで安全になるわけでもありません。公式PVドキュメントのアクセスモードを読み、ノード数、Pod数、データ整合性を別々に書き出してください。
| 観察した状況 | 最初に確認すること | まだ結論を出せないこと |
|---|---|---|
| RWO PVCを2つのPodが参照している | 2つのPodのノードとドライバーの制約 | 2つ目のPodが必ず失敗する |
| 別のノードで接続エラーが出る | イベント、既存の接続、topology | ノードのCPUを増やせば解決する |
| 同じノードで両方Readyになっている | アプリケーションのロック・単一writer・スキーマの互換性 | 同時書き込みでもデータが安全である |
| ブルー/グリーンに切り替えた | プレビュー版の書き込み・バックグラウンド処理 | トラフィックの切り替えだけでwriterが1つになる |
ブルー/グリーンはデータアクセスの制御ではありません。Serviceがトラフィックを送らなくても、新バージョンのバッチ処理は書き込めます。アプリケーションの単一writer、新しいボリュームへのレプリケーションと検証、スキーマの互換性、必要なら明示的な中断を設計する必要があります。どの選択が正しいかは、RPO・RTOとデータモデルによって決まります。
現場での姿
練習状況の注文チームには、性質の異なる2つの問いが必要です。「新しいPodを起動できるか」にはスケジューリングとボリュームのイベントが答えます。「新しいPodを起動してよいか」には、同時書き込みの契約と互換性テストが答えます。最初の問いを通ったからといって、2つ目の問いを飛ばさないでください。
設計メモには、決定、前提、確認コマンド、失敗時の代替案の4つの欄を残します。たとえば「RWO共有」という決定の横に、「同じノードに配置できる」という前提と、「writerは1つ」という別の条件を書きます。これが、試験で暗記した用語を運用判断に変える練習です。
次の学習ですること
次は、テナントに与えたクォータが実際の容量予約とどう違うかを見ます。最後のクイズでは、同じRWOでも条件によって結論が変わる場合を判断します。ここでの読み物の例だけでは、CSIの複数ノード障害やデータ復旧を検証したとは主張しません。