CNPA — クラウドネイティブプラットフォームエンジニアリングアソシエイト
ゴールデンパスは強制ではなく、最も楽な道であるべきだ
一言でいうと
ゴールデンパス(golden path)は、「この道だけを通れ」という規定ではなく、「この道が一番楽なので、あえて別の道を行く理由がない」という状態です。強制して作った道はゴールデンパスではなくゲート(gate)であり、ゲートは迂回されます。
なぜ必要なのか
プラットフォームチームが標準を作る方式は、たいてい次の2つのうちのどちらかです。
禁止型: 「自前のDeploymentのデプロイは禁止、必ず自社のチャートを使うこと」。短期的には規定の準拠率が上がります。ところが、要求を満たせないチームが出てくると例外承認のプロセスができ、例外が積み重なると標準が無意味になります。何より、プラットフォームチームが審判になって、開発チームと敵対関係になります。
ゴールデンパス型: 「このテンプレートで始めれば、5分でオブザーバビリティ・セキュリティ・デプロイがすべて付いたサービスが起動します。ほかの方法も可能ですが、その場合はこの3つを自分で用意する必要があります」。強制がないのに、ほとんどのチームが使います。怠惰さが標準の遵守と同じ方向を向くように設計したからです。
核心となる洞察はこれです。人は規定に従うのではなく、摩擦の少ないほうに従います。プラットフォームの仕事は、正しい道の摩擦をゼロに近づけることです。
どう動くのか
ゴールデンパスの最小構成
ゴールデンパス1つは、次の4つが一体でなければなりません。1つでも欠けると、「サンプルリポジトリ」に転落します。
- スキャフォールディング: コマンド1つまたはフォーム1つで、リポジトリ・マニフェスト・パイプラインが生成されます。
- デフォルト値: リソースのrequest/limit、セキュリティコンテキスト、プローブ、ラベル規約、オブザーバビリティ用のアノテーションが、最初から入っています。
- ドキュメント: 生成されたコードのそばにあり、テンプレートが変わると一緒に変わります。
- オーナーシップ: 作った瞬間に、所有チームがカタログに記録されます。6か月後に「これ、誰のものだっけ」が出てきません。
ドキュメントがなぜ一体でなければならないのかは、しばしば過小評価されます。テンプレートは進化します。ドキュメントがWikiに別々にあると、3か月でずれてしまい、ずれたドキュメントは、ないドキュメントより悪いものです。そのため、docs-as-code(ドキュメントをコードと同じリポジトリ・同じPR・同じレビューで管理する方式)が、ゴールデンパスの必須要素です。
セルフサービスとガードレールのバランス
セルフサービスは権限を広げることであり、ガードレールは、その広がりが事故につながらないようにすることです。両者の配置が、開発者体験を左右します。
| ガードレールの位置 | 例 | フィードバックの速さ | 開発者体験 |
|---|---|---|---|
| スキーマ(APIサーバー) | CRDのmaximum: 10 |
即時 | 最高 |
| アドミッションポリシー | ポリシーエンジンの検証Webhook | 即時(適用時点) | 良い(メッセージが明確なら) |
| クォータ・リミット | ResourceQuota、LimitRange | 即時(作成時点) | 良い |
| CIチェック | パイプラインのリント・ポリシーチェック | 数分 | 普通 |
| 事後監査 | レポート、ダッシュボード | 数時間–数日 | 悪い |
原則はできるだけ左へです。同じルールなら、事後レポートよりスキーマのほうが優れています。失敗は、早く、近くで、人が読める言葉で起きる必要があります。
そして、ガードレールには必ず理由が付いている必要があります。「拒否: ポリシー違反」と、「拒否: 本番環境のネームスペースのコンテナにはメモリ制限が必要です。例: resources.limits.memory: 512Mi」との差が、そのままプラットフォームの評判になります。
何をゴールデンパスにするのか
すべてを作ることはできません。優先順位は頻度×摩擦です。月に1度行う難しい作業より、毎週行うイライラする作業が先です。典型的な候補は、新しいサービスのスキャフォールディング、新しい環境の追加、データベースの接続、ダッシュボード・アラートの作成、オンコール登録あたりです。
また、ゴールデンパスにはバージョンが必要です。v2を出すと、v1のユーザーをどう移行させるかがすぐに問題になります。マイグレーション計画のないv2は、標準をもう1つ増やすだけです。
現場での姿
筆者のホームラボは、ゴールデンパスがないと何が起きるかをよく示しています。Gateway APIにはCRDのv1.6.1が必要で、v1.2ではtlsroutesとreferencegrantsがv1ではなかったため、Ciliumのゲートウェイコントローラーが起動を拒否しました。KubeVirtはcontainerDiskの経路に欠陥があり、DataVolume(PVC)の経路で回避して初めてFedora VMが起動しました。GPU Operatorはcontainerdのランタイム設定でトラブルが起きました。
これらの出来事の共通点は、一度踏めば二度と踏まない落とし穴だということです。そして、その知識が人の頭の中にしかなければ、次の人がまた同じように踏みます。ゴールデンパスの本質はここにあります。プラットフォームチームが代わりに踏んだ落とし穴を、テンプレートのデフォルト値とドキュメントとして固めて、ほかの人が踏まないようにすることです。
もう1つ注目したいのは、kube-proxyなしのCilium構成です。--skip-phases=addon/kube-proxyで最初からインストールせず、あとで削除するのとは違うことを、iptablesのKUBE-チェインが0個であることで確認しました。「削除したもの」と「最初から作らなかったもの」は違う、というこの感覚は、ゴールデンパスにもそのまま当てはまります。悪いデフォルト値をあとで直すより、最初から良いデフォルト値で生成されるようにするほうが、常に安く済みます。
次のラボですること
/root/cnpa-path/にサービススキャフォールド一式(Deployment/Service/HPA/PDB/NetworkPolicy)を作成し、ガードレールのあるネームスペースに実際にデプロイします。続いてhelm createでローカルチャートを作成し、valuesで環境を分岐させ、helm templateのレンダリング結果をあらためてクラスターに適用してみます。