inductor's blog

nothing but self note :)

開発者体験の構成要素: KubernetesのCLIからGitOpsへの進化

はじめに

お久しぶりです。inductorです。

今回はKatie Gamanji氏による記事「The Building Blocks of DX: K8s Evolution from CLI to GitOps」を翻訳しました。

この記事では主にKuberentesを管理するためのツールのこれまでの進歩について語られており、まだGitOpsに明るくない方にとって有益な話もいくつか含まれているかと思います。お楽しみください。

開発者体験の構成要素: KubernetesのCLIからGitOpsへの進化

過去数年間の動きによって、Kubernetesはコンテナオーケストレーターおよび分散システムにおけるアプリケーション基盤のデファクトスタンダードになりました。ツールの幅広い適応性によってエンドユーザーベースの多様化が促され、クラスターの相互作用のための一貫した開発者体験がKubernetesにおいて不可欠な要素になりました。コミュニティでは、クラスターCLIの拡張、ポータルの構築、および応答性の高いUIによる開発者体験の向上に向けて多大な努力が注がれています。

本記事では、クラスターにおける開発者体験のこれまでに焦点を当て、Kubernetesの採用率拡大に貢献したツールを紹介します。最初はクラスターCLIを中心に、プラグインとラッパーツールを使用してkubectlを拡張する方法に関して重点的に解説します。これに続いて、GitOps、ClickOps、さらにSheetOpsなどのメカニズムをカバーする広範なクラスター管理方法の紹介が続きます。

Cluster CLI

Kubernetesには、クラスタの状態を確認して管理するための多目的ツールがデフォルトで備わっています。kubectlとしても知られるこのCLIツールは、SIG-CLIによって管理されています。kubectlでは、アプリケーションのプロビジョニングを迅速に行うための幅広いオペレーション(40以上のサブコマンド)と70以上のフラグが提供されています。

クラスターCLIは、kubeconfigファイルを使用して実行中のクラスターにローカル端末を繋ぎます。このファイルには、APIサーバーエンドポイントの詳細と必須の認証データ（証明書やトークンなど）が含まれます。通常、kubectlは~/.kubeディレクトリにある構成ファイルを参照しますが、ユーザーは--kubeconfigフラグを使用するか、KUBECONFIGという環境変数を用いてコンテキストを設定することもできます。

さらに、kubectlは宣言型および命令型の管理手法を網羅していることで広く知られています。命令型のオブジェクト構成では、ユーザーはクラスター内に実在するリソースを操作して、1コマンドでアプリケーションをデプロイできます。命令型アプローチは導入が簡単ですが、この方法では設定の根拠となる情報源が保存されず監査証跡が利用できないため、開発環境のみを対象としています。

一方、宣言型のアプローチは、ローカルに保存された構成ファイルを操作し、変更を保持するメカニズムを提供します。1コマンドのデプロイとは対照的に、宣言型のアプローチは本番環境に反映する場合に特化しているため、オブジェクトのネストされた構成を包括的に理解しておく必要があります。

開発者体験の向上

kubectlは、クラスター内のリソースを探すための優れた場を提供します。実際のシナリオでは、さまざまな専門知識を持ち、Kubernetesに触れたエンジニアが対話のために利用します。これはクラスターにクエリを発行するためのネイティブメカニズムですが、その一方で、エンジニアがクラスターCLIの操作に精通しているだろうという、一般的だが誤った期待もあります。 この段階では、コミュニティーがクラスターにおける開発者体験の向上に集中し、すべてのレベルのエンジニアに適用可能にするためのの明確な道筋が概説されました。

次のセクションでは、kubectlプラグインとラッパーを使用してクラスターにおける開発者体験を向上する手法について説明します。

プラグインとラッパー

プラグイン

前述のように、kubectlは以下のような1コマンドでアプリケーションのデプロイを可能にする非常に用途の広いツールです。

$ kubectl run pod — image=nginx — restart=Never \
 — requests=cpu=0.5,memory=128Mi \
 — labels=foo=bar \
 — serviceaccount=test-sa

kubectlを使ってアプリケーションのトラブルシューティングとデバッグを行うと、複雑で時間のかかるコマンドが求められる場合があります。幸い、kubectlにはカスタムアクションを作成するための組み込みプロセスであるkubectlプラグインがあり、クラスターCLIの構成要素を抽象化しています。

kubectlプラグインは、一般には任意の言語で記述されたスタンドアロンの実行可能ファイルです。プラグインを検出してCLIと統合するには、プラグインが次の要件に準拠している必要があります。

  • 実行バイナリの名前にkubectl-のプレフィックスが付けられていること
  • 実行バイナリが$PATHに定義された任意のディレクトリの中に存在すること

命名規則の詳細については、公式ドキュメントを参照してください。

一般的なプラグインがどのように構築されるかについて、より詳細な概要を見てみましょう。単純なエコーコマンドを例に見ていきましょう（バイナリのパスに注意してください）。

$ cat /usr/local/bin/kubectl-hello-cloudnative
#!/bin/bash
echo "Hello Cloud Native eParty!"

プラグインを呼び出すには、以下のコマンドを使用します。

$ kubectl hello cloudnative
Hello Cloud Native eParty!

簡単ですよね。

時間の経過とともに、コミュニティではパターンと再利用可能なkubectlプラグインを識別しました。OSSとして公開されているアドオン(訳注: プラグインと同義)は、Krewを用いて集約・公開・配布されています。Krewを簡単に説明すると、SIG CLI傘下にあるプラグイン管理ツールで、90を超えるカスタムコマンドを提供しています。

まとめると、プラグインの導入によって、kubectlのエイリアスとプラグインを組み合わせるための広範な手法とともに、「いい感じに」クラスターにおけるより良い開発者体験を提供することがが容易になりました。既存のkubectlアクションを上書きすることはできませんが、Krewをインストールするだけで幅広い拡張機能が導入可能です。

ラッパー

ここまで、kubectlは高度にカスタマイズされたデプロイメント用の豊富なフラグを備えたツールとして説明しました。これによって、クラスターの可視化をさらに最適化するための完全な基盤を形成されました。kubectl getコマンドをラップするために複数のポータルが構築され、クラスターの状態をグラフィカルに表示し、トラブルシューティングとデバッグの方法を改善しました。

Kubernetesの状態を説明するために広く使用されているツールには、次のものがあります。

  • Octant - オープンソースの開発者中心のWebインターフェース

  • k9s - KubernetesクラスターのためのTUI

  • Lens - スタンドアロンアプリケーションとしてインストールできるKubernetes用IDE

  • Spekt8 - デプロイされたアプリケーションのネットワークトポロジを視覚化するための表示専用ポータル

ApplicationOps

ここまで、kubectlのビルディングブロックを使用して、クラスターオペレーションを拡張および視覚化しました。開発者体験の最適化パイプラインの次の有機的なステップは、アプリケーションデプロイメントのための操作を抽象化することです。

現在のエコシステムでは、これはHelmやKustomizeなどの構成管理ツール、ClickOps、GitOpsなどのアプリケーションオペレーションマネージャー、新しく発見されたSheetOps（必要な機会を想像してみてください！）の導入につながります。

HelmとKustomizeは、アプリケーションレベルの構成の抽象化を扱う業界のリーダーです。本質的には、これらのツールは根本的に異なる実装戦略を持っていますが、どちらもKubernetesリソースをテンプレート化するためのソリューションと、環境ごとの入力パラメーターの分離（values.yamlを使うHelmとオーバーレイによるKustomize）を提供します。

構成管理ツールからの出力は、クラスターにデプロイする準備ができているYAMLマニフェストの集合です。コマンドラインを介して作成されたマニフェストの適用を手で処理する代わりに、AppicationOpsを処理するためのさまざまなツール（例: ClickOps、GitOps、SheetOps）が構築されました。

次の段落では、ApplicationOpsの手法について詳しく説明します。

ClickOps

ClickOpsは、無数のメニュー設定を通じてアプリケーションのデプロイをボタンをぽちぽちするだけに作り直します。多くの場合、パブリッククラウドプロバイダーによってサービスとして提供されています。ユーザーに強力な開発者体験を提供する一方で、ClickOpsは実装された抽象化レイヤーと密接に結合しています。

バランスの取れたデプロイ体験は、構成する必要がある適切な量のパラメーターと、アプリケーションに到達してデバッグする方法をいずれも包括的に理解することで構成されます。ただし、ClickOps駆動のエコシステムでは、再利用可能な構成やロールバックなどのアクションの実装は困難です。

GitOps

一方で、GitOpsの利用率は最近エンドユーザーコミュニティで急増しています。GitOpsは、目的のアプリケーションの状態を表すものとしてgitリポジトリを持つアプリケーション配信メカニズムです。これは、IDEとクラスタデプロイメントの差分がPRから1つだけ離れていることを示しています。GitOpsはデータを自動化されたリコンサイルに紐付けます。つまり、GitOpsにはプル型のシステムがあり、常に新しいコミットを監視しています。

GitOpsの一般的な実装には、Flux（CNCFサンドボックスプロジェクト）およびArgoCD（CNCFインキュベーションプロジェクト）があります。

SheetOps

そして最後に、ApplicationOpsに最も新しく追加されたのがSheetOpsです。これは、YAMLをスプレッドシートで置き換えるという使命に捧げられています。みなさんも予想できる通り、この手法はGoogleスプレッドシートを使用してクラスターの状態を制御することを目的としており、現時点ではアプリケーションのレプリカ数のみを管理します。ただし、このプロジェクトは機能拡張するためのスポンサーを探しています。

SheetOpsがあなたの心に近いコンセプトである場合、今こそ行動する時です！

まとめ

Kubernetesの進化を通じて、コミュニティエンジンは、クラスター内のユーザージャーニーをさらに充実させ、簡素化することによって支えられてきました。基本的に、Kubernetes APIがシステムに宣言的な構成スキーマを提供し、ClickOps、GitOps、さらにはSheetOpsの実装さえ可能にするため、これは達成可能でした。

クラスターの相互作用の歴史は常に拡張されており、これまでのところ、kubectlプラグイン、クラスターの動作状態を示すUI、およびApplicationOps手法がカバーされています。ただし、これらのメカニズムはすべて将来のデプロイ手法における構成要素にすぎないため、この冒険はまだ終わりません。