GitOps のユーザビリティ向上にご協力ください

※この投稿は米国時間 2022 年 5 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

依然として困難な Kubernetes 構成の自動化

あらゆる規模の企業が Kubernetes を活用し、インフラストラクチャ上でのアプリケーションの構築、デプロイ、運用の方法をモダナイズしていますが、使用する開発クラスタや本番環境クラスタの数を増やすにつれて、拡張する環境に対して一貫した構成やセキュリティ ポリシーを作成し、適用することが難しくなっています。

この課題に対処するために、プラットフォーム チームが GitOps 手法を用いて、バージョン管理されたデプロイ処理によりクラスタや環境間で構成やポリシーを一貫してデプロイすることがますます一般的になっています。Kubernetes 自体と同じ原則を使用する GitOps は、クラスタの望ましい状態を、バージョン管理されたストレージ システム（通常は git）内にある Kubernetes の宣言型の構成ファイルのセットを使用して調整します。

しかし、git ワークフローを実装するには、リポジトリ、ブランチ、ディレクトリの組織、バージョニングとタグ付け、変更提案と認証の承認、統合前の検証チェックなどの作業が必要になる場合が多く、特に、大企業でデプロイされている 10～100 単位、あるいは 1,000 単位のアプリケーションの変更を管理する場合、適切に設定するのは難しい可能性があります。

さらに、構成は通常、テンプレート、ドメイン固有言語、汎用プログラミング言語などのコードやコードに似た形式で表現されるため、事実上、手作業によるオーサリングや編集が必要となります。以下は、Kubernetes RoleBindings を生成するための非常にシンプルなテンプレートです。

プラットフォーム チームやアプリケーション チーム間の共同作業は、特に個々のチームのニーズがそれぞれ異なる場合にボトルネックになりかねません。頻繁にテンプレートを変更する必要があり、テンプレートを使用している全員に影響が及ぶ可能性があります。たとえば、上述のテンプレートは、ServiceAccounts へのバインディングをサポートしていません。このオプションを追加すると、テンプレートのすべての使用に影響を与える可能性があります。

このような構成ツールは、目的の状態を排他的に生成して設定することを前提としているため、グラフィカル ユーザー インターフェース（GUI）やコマンドライン インターフェース（CLI）など、より使いやすいクライアント サーフェスとの相互運用性はありません。これらのツールの中には、リソースの YAML 表現をダウンロードまたは出力する機能を提供することで、構成ツールへの移行をサポートするものもあります。

しかし、これは一方通行で、一度移行するとその後は異なるプロセスを用いて手作業で別のフォーマットに編集する必要があります。GUI では数秒でできる変更も、構成ツールを使用すると数日かかってしまうというユーザーの声もあります。「簡単な方法」と「正しい方法」のどちらか一方のみを選ばなくて済むのなら、素晴らしいと思いませんか？

GitOps のユーザビリティを向上させるためには、任意のクライアント サーフェスと構成ツールの間に内在する二分性に対処する必要があります。

構成のオーサリングと編集の機能を向上させる

Google は、WYSIWYG GUI エクスペリエンスを提供する Backstage プラットフォーム ポータル フレームワーク用のオープンソース プラグインを作成しました。このプラグインはパッケージ オーケストレーター上に構築されており、プラットフォーム チームやアプリケーション チームは、ガードレールを適用しながら簡単に構成のオーサリングと編集ができます。YAML、パッチ、テンプレートの記述は必要なく、ブランチ、commit、タグ、push、マージの変更も不要です。

このアプローチは、GitOps の上に GUI を構築する際に、現在エコシステムで直面している多くの落とし穴を回避することができるという点で優れています。特に、一般的なアプローチでは、Kubernetes リソースモデルの上にカスタム構築する必要がある抽象化の作成（多くの場合、薄いレイヤ）が必須です。このため、プラットフォーム チームは Kubernetes の上に管理エクスペリエンスを作成するために多くの追加作業が必要となり、標準の Kubernetes（および拡張機能）のリソースタイプを中心に構築されたツールや教育コンテンツのエコシステムの価値が活かされない状況が生じています。

Configuration as Data とパッケージ オーケストレーションを活用することで、既存のエコシステムを補完する GUI を実現できます。薄い抽象化レイヤで悪影響を受けることはありません。この GUI は、Kubernetes でライブ状態で直接操作する GUI と非常によく似た方法で構成データを変更します。Kubernetes はネイティブに宣言型なので、リソース スキーマも同一です。

この GUI はまだ初期段階であるため、Namespace とそれに隣接する Kubernetes ポリシー リソースのプロビジョニングと管理という限定されたユースケースをサポートしています。今後、クラスタ管理者が現在直面しているその他の重要なユースケース（主に、追加されたリソースタイプのためのフォーム エディタや、カスタマイズされた追加シナリオのための transformer 関数を簡単に実装するなど）をサポートする予定です。

YAML を記述することなく、リソースの追加、編集、削除ができます。

バリアントを作成するために、kpt は kustomize のように KRM 関数を使用してリソースを変換します。カタログから関数を選び、その入力を選択できます。これで、同様のインスタンスを必要な数だけ作成するレシピができました。関数は、Kubernetes アドミッション コントロールと同様に、ブループリントとその派生インスタンスを検証するために使用することもできます。リソース グループのプロビジョニングを自動化するためだけに、まったく新しいオペレーターやモノリシックな構成ジェネレータを構築する必要はありません。コンポーズ可能な関数により、プラットフォーム構築者はローコードで、プラットフォーム ユーザーはノーコードで作業できます。

実際の動作は、デモ動画でご確認ください。

ストレージの構成をミューテーション可能にすることで実現する機能は GUI だけではありません。クラウドネイティブなネットワーク自動化プロジェクトの Nephio は、kpt、Porch、Config Sync で構築され、相互接続されたネットワーク機能およびそれらの機能を支える基盤インフラストラクチャの構成を完全に自動化します。Configuration as Data は、構成データ用の基盤 API を提供し、Nephio 自動化コントローラによるミューテーションを可能にします。

Configuration as Data は、再現性を実現するためにユーザビリティやより高度な自動化の可能性を犠牲にしない、新しいアプローチです。相互運用性があり、WYSIWYG で、自動化が可能な構成のオーサリングと編集をサポートします。Google は、この革新的なアプローチを実証し、さらに進化させるために、コミュニティと協力していきたいと考えています。

イノベーションにご協力ください

Google は、この技術を前進させるために、コミュニティとともに取り組んでいきたいと考えています。特に、GitOps 技術に取り組んでいるデベロッパー、または既存の GitOps 技術を中心に構築しようとしているデベロッパーとのコラボレーションに強く関心があります。Google 独自の GitOps リファレンス実装 Config Sync も kpt の一部に含まれますが、GitOps へのインターフェースは拡張可能であることを目的としています。Google のお問い合わせページからご連絡いただくか、直接投稿してください。誰もが GitOps を利用できるようにするために、皆様からのご意見とご協力をよろしくお願いいたします。

- 上級エンジニア Brian Grant