K8sツール選定｜ADRの書き方と判断基準

第5回で、何を禁止し何を許可するかが決まりました。次に決めるのは、それを実現する道具です。

ここで多くのプロジェクトが、CNCF Landscape を開いて選択肢の多さで判断できなくなります。あるいは「よく聞くものを入れる」で先に進みます。どちらの場合も、3年後に「なぜこれを選んだのか」を説明できる人がいなくなります。

そして問題が起きるのは、選定の直後ではありません。数年後、そのツールを乗り換えるべきかを判断する場面です。当時の選定理由が残っていなければ、いま前提が変わったのかどうかを確かめる方法がありません。結果として、変えるべきものを変えられず、変えなくてよいものを気分で変えることになります。

本記事が扱うのは、ツールの機能比較ではありません。3年後に判断を見直す人が読んで納得できる決定録（ADR）の書き方と、その判断に使う測定可能な基準です。本記事も第1回以降と同様、Google Cloud（GKE）を前提に数値と製品名を記載します。

目次

1. 道具を選ぶ前に、ルールが確定していること
2. ADRに何を書くか
   1. 5つの必須項目
   2. 却下理由の書き方
   3. 見直しのトリガーを書く
   4. 誰が書き、誰が承認し、どこに置くか
3. GKEでは「マネージド版があるか」を先に確認する
   1. GKEに追加料金なしで含まれるもの
   2. マネージドを却下してよい条件
   3. マネージドの費用はPod数に比例する
4. 選定基準を測定可能にする
   1. コミュニティ活性度はCNCFの成熟度で測る
   2. コストは3つの費目に分ける
   3. 学習コストは「2名」で判定する
   4. 決め手は1つに絞る
5. カテゴリ別の判断
   1. CNI ― GKEでは選定項目ではない
   2. ポリシーエンジン ― 第5回のルール一覧が入力になる
   3. GitOps ― Config Sync か Argo CD か
   4. 監視 ― 保存期間が判断材料になる
   5. シークレット連携 ― 成熟度が実際に効くカテゴリ
   6. サービスメッシュ ― 入れない判断が最も多い
6. 【実務テンプレート】アーキテクチャ決定記録（ADR）
7. 次回予告

道具を選ぶ前に、ルールが確定していること#

順序を確認します。ルールが先で、道具が後です。

第5回でポリシールール一覧を作りました。そのうち何行が標準機能（PodSecurity と ValidatingAdmissionPolicy）で書けるかを数えた時点で、外部エンジンの要否はほぼ決まっています。本記事は、そこで「要る」と判定されたカテゴリについてだけ道具を選びます。

順序を逆にすると何が起きるか。その道具で書けることが、そのままルールになります。これは設計ではなく、製品仕様への追従です。そして「なぜこのルールなのか」と問われたときに、「使っているツールがそう書けるから」としか答えられなくなります。

本記事で扱うのは、第5回までに要否が判定済みの6カテゴリに限ります。CNI、ポリシーエンジン、GitOps、監視、シークレット連携、サービスメッシュです。CNCF Landscape を上から順に見る作業はしません。要件から降りてこないカテゴリは、そもそも検討の対象になりません。

この絞り込みには、もう1つの効果があります。検討しなかったカテゴリを、検討しなかったと記録できることです。

数年後、「なぜサービスメッシュを入れていないのか」と問われる場面が来ます。そのとき「要件が無かったので検討していません」と答えられるのと、「覚えていません」しか言えないのとでは、意味がまったく違います。前者は判断ですが、後者は漏れです。選定しなかったことも決定であり、記録の対象になります。

逆に、要件が先にあるのに検討していないカテゴリが見つかったら、それは第5回までの設計に抜けがあるということです。本記事の作業は、そこまでの設計の点検も兼ねています。

ADRに何を書くか#

ADR（Architecture Decision Record）は、選定の記録ではありません。将来の見直しのための記録です。この違いが、書く内容を決めます。

5つの必須項目#

広く使われている形式は Status / Context / Decision / Consequences の4項目ですが、本記事ではAlternatives を必須項目として足します。理由は次のとおりです。

AlternativesとConsequencesが書けていないADRは、ただの導入報告です。採用したツール名は、クラスタを見れば分かります。マニフェストにもリポジトリにも残ります。ADRにしか残らないのは、この2つだけです。

3年後にその判断を見直す人が必要としているのは、採用したツールの名前ではありません。当時どの選択肢を検討し、なぜ落としたのかです。落とした理由が「当時は機能が無かった」なら、いま再検討する価値があります。「思想が合わない」なら、いまも合いません。却下理由の質が、そのADRの寿命を決めます。

却下理由の書き方#

却下理由は、書き方で価値が大きく変わります。

そのうえで、却下理由を2つに分類します。「時間が経てば変わるもの」と「変わらないもの」です。

分類の判定方法まで決めておきます。その理由を、開発元が次のリリースで解消できるかで判定します。

「変わる」に分類した却下理由には、再検討の条件を必ず併記してください。条件のない「変わる」理由は、次の見直しで誰も再評価しません。「機能が足りなかった」とだけ書かれた3年前のADRを前に、いま足りているのかを誰も確認しないまま、同じツールを使い続けることになります。

見直しのトリガーを書く#

日付での見直し（四半期・年次）だけでは形骸化します。期日が来ても、変化がなければ「変更なし」と書いて終わるためです。「この条件が起きたら再検討する」という条件を書いてください。

• 追加料金なしのマネージド版が、却下理由になっていた機能を実装したとき
• Pod数やクラスタ数が増え、従量課金の月額が想定の2倍を超えたとき（想定額を具体的な金額で書いておく）
• そのツールの一次対応ができる人が1名になったとき

3つ目は、第1回の条件4（専任2名未満）と同じ考え方です。人が減ったことは障害として認識されませんが、選定の前提が崩れたという意味では設定変更と同じ重みを持ちます。

日付のトリガーと条件のトリガーは併用します。第2回で責任境界定義書に四半期の見直しを設定したのと同じ形で、日付は「条件に該当していないかを点検する日」として使ってください。

誰が書き、誰が承認し、どこに置くか#

ADRは書式を決めただけでは運用に乗りません。3つを決めてください。

1つ目、書く人と承認する人を分けます。提案者が承認者を兼ねると、Alternatives欄が形式的になります。自分で選んだものを自分で承認する構造では、却下した候補を真剣に評価する動機が働きません。第2回のRACIに照らすと、ツール選定のAは運用チームです。セキュリティ要件に関わるカテゴリでは、セキュリティチームがCとして関与します。第2回で決めたとおり、セキュリティチームにAを持たせないでください。

2つ目、粒度を決めます。本記事は1カテゴリ1枚を推奨します。ツール1つに1枚だと、却下した候補のADRが存在しないことになり、検討の記録が残りません。逆に「基盤全体で1枚」にすると、個別の見直しができなくなります。見直しの単位と、ADRの単位を一致させてください。

3つ目、置き場所を決めます。ADRはコードと同じリポジトリに置き、プルリクエストでレビューする形が最も運用に乗ります。決定の履歴がGitに残り、いつ誰が変更したかを追えるためです。どのリポジトリに置くかは、第8回のIaC・リポジトリ構成設計で扱います。

Statusの遷移も決めておきます。承認済みのADRは書き換えません。判断が変わったら、新しいADRを起こして古いものを「置き換え済み」にし、置き換え先の番号を書きます。書き換えてしまうと、当時なぜその判断だったのかが消えます。ADRの価値は履歴そのものにあります。

GKEでは「マネージド版があるか」を先に確認する#

ここが本記事で最も実務的な指摘です。

GKEに追加料金なしで含まれるもの#

GKEの料金ページには、次のように記載されています。

「GKE には、完全に自動化されたクラスタ ライフサイクル管理、Pod とクラスタの自動スケーリング、費用の可視化、インフラストラクチャ費用の自動最適化、フリート、チーム、Config Management、Policy Controller、フリート ダッシュボードなどのマルチクラスタ管理機能が含まれます。追加料金はかかりません。」

読み落とさないでください。Config Management（Config Sync）と Policy Controller が、追加料金なしで含まれています。つまりGitOpsとポリシーエンジンについては、追加費用ゼロの選択肢が既にクラスタに付いています。

この事実が、ADRの書き方を変えます。この2カテゴリで Argo CD や Kyverno を選ぶ場合、Alternatives 欄には「追加料金なしの選択肢を却下してまで、これを選ぶ理由」を書く必要があります。書けないなら、それは選定ではなく、単に知らなかっただけです。

第5回でポリシーエンジンの選定理由を保留したのは、この確認を先にすべきだったからです。ルールの一覧を作り、標準機能で書けない行を数え、それでも外部エンジンが要ると判定できて初めて、追加料金なしの Policy Controller が第一候補になります。

マネージドを却下してよい条件#

追加料金なしのマネージドを却下してよい条件は、限られます。

1. 既に別クラウドや自社データセンターに同じ仕組みを運用しており、統一したほうが総コストが下がる
2. 必要な機能がマネージド版に無く、その機能が要件として確定している
3. マネージド版の変更管理（提供元による自動更新）を受け入れられない規制要件がある

「使い慣れているから」は却下理由になりません。慣れは移行コストであって、恒久的な優位ではないためです。ADRには移行コストを一度きりの費用として計上し、恒久的な運用コストと分けて書いてください。この2つを混ぜると、移行を避ける判断が永久に正当化され続けます。

公平のために、マネージドを選ぶ側の代償も書いておきます。Consequences欄に必ず入れるべき項目が3つあります。

• 変更管理を握られる。提供元の判断で機能が変わり、更新の時期を自分では決められません。第1回の条件4で扱った「自動化されるのは上げる作業だけで、上げてよいかの検証は自動化されない」という論点が、ここにも当てはまります
• 機能追加のペースを自分で決められない。OSSなら自分でパッチを当てるか、フォークするか、上流に提案する道があります。マネージドにその道はありません
• そのクラウドから出にくくなる。移行時の作業量が、選定時点では見積もれません

これらを承知したうえで選ぶのが「決定」です。代償を書かずに「マネージドだから安心」と書いたADRは、3年後に読む人に何も伝えません。

マネージドの費用はPod数に比例する#

ただし、すべてのマネージドが追加料金なしではありません。従量課金のものは、規模に比例して増えます。

Cloud Service Mesh を例に取ります。料金はクライアントの数に基づき、クライアントにはGKEでCloud Service Meshが有効になっているPodインスタンス、Cloud Runインスタンス、プロキシレスgRPCインスタンスが含まれます。単価は1クライアントあたり1時間 $0.0006945、1か月あたり約 $0.50です。レプリカを増やせば、インスタンスごとに課金されます。

第1回で確定したK8s税は、3環境（Prod・Stgリージョン／Devゾーン）で月約$407でした。Pod数が1,000を超えると、サービスメッシュだけでクラスタ基盤そのものより高くなります。「入れるかどうか」の判断が、規模によって重みを変えるということです。

ここで、比較の仕方に注意が必要です。

「セルフホストのIstioは無料」と書いてはいけません。利用料がないだけで、アップグレードと障害対応の工数が発生します。しかしその工数を人件費に換算して、マネージドの費用と同じ表に並べるのも誤りです。

第1回の条件4で確立した教訓がここでも効きます。人件費とサービス費用を金額で並べると、人件費のほうが大きく上回るため、常に「人を雇わない」が合理的な結論になってしまいます。そしてその結論は、実際には誰も運用できない構成を正当化します。

ADRには2つを別の欄に分け、「この金額を払うか、この体制を維持するか」という二者択一として書いてください。金額の大小で決める問題ではありません。

選定基準を測定可能にする#

選定基準としてよく挙がるのは、コスト、学習コスト、コミュニティ活性度、既存資産との親和性です。どれも抽象語です。測れない基準は、書いても審査に使えません。すべてに測定方法を紐づけます。

コミュニティ活性度はCNCFの成熟度で測る#

CNCFには公式の成熟度レベルがあり、定義も公開されています。

本記事で扱う候補の現在のレベルは次のとおりです。

この表を見て、重要なことに気づいてください。この軸では、ほとんどの候補で差がつきません。

ポリシーエンジンの候補（Kyverno と Open Policy Agent）も、GitOpsの候補（Argo と Flux）も、どちらも Graduated です。成熟度は「候補に入れてよいかのふるい」であって、「どちらを選ぶかの決め手」ではありません。決め手にしようとすると、根拠のない優劣を書くことになります。

ふるいとして機能するのは、レベルが分かれるときです。シークレット連携では、Google のマネージドなSecret Managerアドオン（一般提供）に対して、External Secrets Operator はSandbox、つまり「本番で広くは検証されていない実験的なプロジェクト」という位置づけになります。ここでは成熟度が実際に判断材料になります。

使い方をまとめます。本番の基盤にSandboxのプロジェクトを採用する場合、ADRに「実験段階のプロジェクトを本番に採用する理由」を明記させてください。採用してはいけないという話ではありません。理由を書けるかどうかが問題です。

コストは3つの費目に分ける#

②の計算手順は、第5回でポリシーエンジンについて示したものと同じです。第4回で確認したノード単価を使い、第3回で決めたクラスタ数を掛けます。候補ごとに②を出し、その差分を比較してください。

「OSSだから無料」と書いた時点で、②と③が抜けています。①がゼロでも、②は常駐Podの分だけ確実に発生します。そして③は、そのツールが動かなくなった夜に現れます。

学習コストは「2名」で判定する#

学習コストは「チームの何人が、何週間で、誰の助けなしに一次対応できるようになるか」で書きます。「高い / 低い」では審査に使えません。

そのうえで合格ラインを置きます。一次対応できる人が2名以上です。1名なら、その人の不在時に対応手段が消えます。

第1回の条件4で「1名体制はSPOF」と判定したのと同じ基準ですが、適用の単位が違います。第1回では組織全体の体制を見ましたが、ここではツールごとに数えます。10個のツールを2名で担当するのと、2個を2名で担当するのは別物だからです。前者では、1人が1つのツールしか深く見られません。

既存資産との親和性も、同じ枠で測ります。社内で既に運用している同種のツールがあるか、そのチームから支援を受けられるか。第2回で定義した運用チームの人数が、ここでの上限です。第1回の条件4に該当する組織（専任2名未満）は、選択肢を「マネージドのみ」に絞るのが妥当な判断になります。

決め手は1つに絞る#

基準を4つ用意したので、次は使い方です。よく見かけるのは、基準ごとに5点満点で採点し、合計点の高い候補を選ぶ方式です。この方式は採らないでください。

理由は2つあります。

1つ目、点数化すると決め手が薄まります。4つの基準で候補Aが18点、候補Bが17点だったとして、その1点差が何だったのかを3年後に説明できる人はいません。合計点は根拠のように見えて、根拠を消す働きをします。

2つ目、点数は後から調整できます。結論が先にある場合、配点を変えれば望む結果を出せます。採点表は、決定を正当化する道具として使われやすい形式です。

代わりに、ADRのDecision欄には「決め手になった基準」を1つだけ書いてください。「保存期間の要件が24か月であり、これを自前で満たす設計コストが見合わなかった」のように、1文で書ける形にします。

残りの基準は、Alternativesの却下理由として使います。決め手を1つに絞れないなら、まだ要件が絞れていないということです。その状態で選定を進めても、後から要件が動くたびに結論がひっくり返ります。

これは第5回で「ルールごとに強制手段を1つに決める」と書いたのと同じ構造です。2つの理由で決めた判断は、どちらが崩れたときに見直すべきかが分かりません。

ここまでの判断を1枚にまとめます。

カテゴリ別の判断#

6カテゴリについて、候補と判断と却下理由を示します。各ツールの機能紹介はしません。判断の形だけを見てください。

CNI ― GKEでは選定項目ではない#

候補は GKE Dataplane V2（Cilium ベース）と Calico です。Dataplane V2 はAutopilotでは既定で有効で、Calico とは排他です。

判断: 特段の理由がなければ Dataplane V2。Calico の却下理由は、第5回で扱った ipBlock の挙動差です。Calico では ipBlock がPodのトラフィックにも一致するため、広いCIDRを許可する場合にPod CIDRの明示的な除外が必要になり、設計の複雑さが増えます。

このカテゴリで重要なのは、ADRに「選定の余地がないため選定しない」と記録することです。空欄にしないでください。空欄のADRは、検討したのか忘れたのかが後から区別できません。

そして、この決定は第3回に遡って効きます。Autopilotを選んだ時点でDataplane V2が既定になるため、CNIの選択は運用モードの選択に含まれていたことになります。ADRのContext欄には「第3回で運用モードを決めた時点で、この選択は実質的に終わっていた」と書いてください。後から選定したように見せかけないことが、記録の誠実さです。

ポリシーエンジン ― 第5回のルール一覧が入力になる#

候補は「標準機能のみ」「Policy Controller」「Kyverno」です。判断は次の順序で行います。

1. 第5回のルール一覧のうち、標準機能で書けない行を数える
2. ゼロなら外部エンジンを入れない
3. 1行以上あるなら、追加料金なしの Policy Controller を第一候補にする
4. それを却下する理由が書けるときだけ、他を選ぶ

Policy Controller には、PCI DSS、CIS Kubernetes Benchmark、Pod Security Standards、NIST SP 800-53、NSA・CISAのKubernetesハードニングといったポリシーバンドルが用意されています（第5回で触れたとおりです）。準拠を証明すべき基準が決まっている組織では、自前でルールを書くよりバンドルを当てるほうが速いという判断が成立します。

GitOps ― Config Sync か Argo CD か#

Config Management（Config Sync）は追加料金なしで含まれ、信頼できる情報源としてGitリポジトリ、OCIイメージ、Helmチャートを使えます。Argo CD は Graduated で、GKEのフリートとの連携も提供されています。

判断軸は3つです。開発者にデプロイ状況のUIを提供する必要があるか、マルチクラスタへの一括配布が要るか、既存のCI/CDとどう接続するか。

ここで1つ注意があります。「Argo CDのUIが要る」は正当な却下理由になりますが、そのUIを誰が使うのかを第2回のRACIで確認してください。運用チームしか使わないのであれば、UIのために追加のツールを運用する価値があるかは別の話になります。開発者にセルフサービスを提供する設計なら、それは第10回のIDP設計と一体で判断する論点です。

もう1つ、このカテゴリに固有の論点があります。GitOpsのコントローラは、第5回で確認したとおり全Namespaceにリソースを適用できる必要があり、実質的にどの人間よりも強い権限を持ちます。ADRのConsequences欄には、「このコントローラのServiceAccountが、クラスタで最も強い権限を持つ主体になる」と明記してください。ツールを増やすほど、その主体が増えます。GitOpsツールを2つ併用する構成は、クラスタで最も強い権限を持つ主体を2つ作ることを意味します。

選んだツールの構成設計そのものは第9回です。

監視 ― 保存期間が判断材料になる#

Google Cloud Managed Service for Prometheus には、判断を左右する数値があります。データは追加費用なしで24か月保存されます。保持中の粒度は、1週間が完全粒度、その後5週間が1分間隔、残期間が10分間隔です。課金は取り込まれたメトリクスのサンプル数に基づきます。既存のGrafanaダッシュボードとPromQLベースのアラートは、そのまま使えます。

セルフホストのPrometheusで24か月分を保持するには、そのストレージを自分で用意し、ダウンサンプリングを自分で設計することになります。保存期間の要件が長い組織ほど、マネージドの相対的な優位が大きくなります。

注意点もあります。課金が取り込みサンプル数に基づくため、メトリクスを増やすと費用が増えます。第4回のラベル設計と同じ構造です。粒度を上げると按分コストが増えるのと同様に、監視の粒度を上げると取り込み費用が増えます。閾値とダッシュボードの設計は第15回で扱います。

シークレット連携 ― 成熟度が実際に効くカテゴリ#

第5回で Secret Manager アドオン（CSIでボリュームマウント）を既定解としました。本記事ではその選定理由を書きます。

却下した代替は2つです。外部ストアからK8s Secretへ同期する方式は、最終的にK8s Secretになるため読み取り制御の問題が残ります（第5回の層1で確認した、edit ロールでSecretが読めるという問題）。これは「変わらない」却下理由です。方式そのものの帰結だからです。

もう1つは自前のシークレットストアを運用する方式で、可用性の責任を自分で負うことになります。シークレットストアが落ちると、Podが起動できなくなります。

このカテゴリは、前章で述べた「成熟度がふるいとして機能する」例です。代表的な同期ツールである External Secrets Operator はCNCF Sandboxであり、本番の基盤に採用するなら、その理由をADRに明記する必要があります。

再検討のトリガー: マルチクラウドで同一のシークレットを共有する要件が出たとき。その時点で、単一クラウドのマネージドサービスという前提が崩れます。

サービスメッシュ ― 入れない判断が最も多い#

候補は Cloud Service Mesh とセルフホストのIstioですが、その前に入れるかどうかを判断します。

判断基準は、mTLSによる相互認証、L7の細かなトラフィック制御、サービス間の詳細な可観測性のうち、要件として確定しているものがあるかどうかです。「あると便利」では入れません。自組織が準拠する基準のどの要求に対応するのかを、ADRに書いてください。

コストは前章のとおり、クライアントあたり月約$0.50です。Pod数に比例するため、規模が大きい組織ほど判断が重くなります。そして規模が大きい組織ほど、サービス間通信の可視化を求める声も大きくなります。この2つは同じ方向に動くため、判断が難しくなる構造があります。

却下する場合に書くことがあります。mTLSが要件なら、メッシュ以外の実現手段で代替できないかを検討した記録を残してください。アプリケーション側でのTLS終端や、第5回のNetworkPolicyによる到達範囲の限定が候補になります。「メッシュを入れなかった」だけでは、要件を満たしていないのか、別の手段で満たしたのかが区別できません。

【実務テンプレート】アーキテクチャ決定記録（ADR）#

1カテゴリにつき1枚作成してください。第1回から第5回の成果物が入力になります。

次回予告#

道具が決まりました。次に決めるのは、その上で扱うデータをどこに置くかです。

次回の第7回「データ・ストレージ設計書」では、StatefulSet とマネージドDBの選定判断フロー、CSIドライバーの選定、StorageClassの設計、PV/PVCのアクセスモードとReclaimPolicy、そしてステートフルデータの日常バックアップ方針を扱います。

第1回の条件1（ローカルI/O依存）で「K8sに載せない」と判定したワークロードの行き先を、第7回で具体的に決めます。第1回では判定までを行い、StatefulSet とマネージドDBのどちらを選ぶかは第7回の管轄だと明記しました。7回分の設計を経て、ようやくその判断に必要な材料が揃います。