HNで公開: Glasskube – Helmの代替となるオープンソース Kubernetes パッケージマネージャー

 (github.com/glasskube)
3 ポイント 投稿者 GN⁺ 2024-06-27 | 1件のコメント | WhatsAppで共有
  • GlasskubeはKubernetes向けのオープンソースパッケージマネージャーで、HelmやKustomizeのようなツールよりもデプロイ・アップデート・設定を20倍高速にすると紹介されている
  • ユーザーはGlasskube UI、CLI、またはGitOps方式でパッケージをデプロイでき、Homebrewやnpmのシンプルさに着想を得ている
  • 主な機能には、Helmリポジトリを検索しなくてもUIからパッケージをインストールできること、型安全な設定入力、パッケージ間での値の注入、依存関係を認識したインストール、事前テスト済みの安全なアップデートが含まれる
  • すべてのGlasskubeパッケージはカスタムリソースとして管理され、GitOpsで扱うことができ、複数のリポジトリやprivate packageの配布にも対応している
  • 現在はKubernetes Dashboard、cert-manager、Ingress-NGINX Controller、Kube Prometheus Stack、Cloud Native PGなどをサポートしており、ベータ版はHomebrewでインストールできる

Glasskubeが解決しようとしているKubernetesパッケージ管理の問題

  • GlasskubeはKubernetes向けオープンソースパッケージマネージャーである
  • Kubernetesでパッケージをデプロイし、アップデートし、設定する作業を、HelmやKustomizeのようなツールより20倍高速にすると紹介されている
  • Homebrewやnpmのシンプルさに着想を得ており、ユーザーは次のいずれかの方法を選べる
    • Glasskube UI
    • Glasskube CLI
    • GitOpsによる直接的なパッケージデプロイ
  • 開発の背景には、Kubernetesエコシステムで5年以上働く中で、パッケージ管理、設定、デプロイに継続的な難しさを感じてきた経験がある
  • 従来の作業では、理解しにくいコマンドや概念のためにテンプレートを作成し、ドキュメントを書くことに多くの時間が費やされていた
  • Homebrew、apt、dnfのようなツールは使いやすく問題が少なかったことが、Glasskube開発における比較対象となっている

インストールと設定の流れ

  • ベータ版はHomebrewでインストールできる
brew install glasskube/tap/glasskube
  • そのほかのインストール方法はinstallation guideにある
  • CLIをインストールした後は、クラスターに必要なコンポーネントをインストールするために次のコマンドを実行する
glasskube bootstrap
  • クラスターのブートストラップが完了すると、パッケージマネージャーUIを起動できる
glasskube serve
  • このコマンドはデフォルトのブラウザでhttp://localhost:8580を開き、ユーザーは利用可能なパッケージを閲覧してインストールできる

UI、設定、依存関係管理機能

  • Glasskube UIはすべてのパッケージを一か所に集約して提供し、ユーザーがHelmリポジトリを別途探さなくてもクラスターにパッケージをインストールできるようにする
  • パッケージ設定は、UIまたは対話型CLIの質問フォームを通じて、型安全な入力値として構成できる
    • 他のパッケージ、ConfigMap、Secretから値を簡単に注入できる
    • 型がなく文書化もされていないvalues.yamlファイルを使わない方向性を示している
  • 依存関係管理は、Glasskubeパッケージが複数の別パッケージから利用・参照されるよう処理する
    • 依存パッケージは正しいnamespaceにインストールされる
    • READMEではこれを「umbrella chartは最初からこう動くべきだった」という趣旨で表現している

アップデート、GitOps、リポジトリ対応

  • パッケージアップデートでは、希望するバージョンへのpending updateを事前に確認し、ワンクリックまたはCLIコマンドで実行できる
  • すべてのアップデートはGlasskubeのテストスイートで事前検証される
  • パッケージへの反応やコメントはGitHub discussionsまたはGlasskube UI内に残せる
  • GitOps統合は、すべてのGlasskubeパッケージをカスタムリソースとして管理する方式に基づいている
  • Renovate統合も進行中で、関連issueはrenovatebot/renovate#29322にある
  • 複数のリポジトリとprivate packageを利用できる
    • 社内サービスのパッケージを配布する用途に使える
    • 開発者が常に最新の社内サービスを簡単にセットアップできるシナリオを提示している

パッケージインストールのアーキテクチャ

  • glasskube install [package]の流れは、UIまたはCLIがClientを介してパッケージリポジトリとKubernetes APIを併用する構造になっている
  • UIはローカルサーバーhttp://localhost:8580を通じてClientに接続される
  • CLIはcobra CLIを通じてClientに接続される
  • Clientはまずパッケージ検証のためにPackage Repoを確認する
  • 検証後、Kubernetes APIにPackageカスタムリソースを作成する
  • クラスター内ではPackageControllerとPackageInfoControllerが調整（reconcile）を行う
    • PackageControllerはPackageを調整し、必要に応じてPackageInfoを作成する
    • PackageInfoControllerはパッケージリポジトリからパッケージmanifestを更新する
    • 更新されたmanifestはPackageInfoに反映される
    • その後PackageControllerがパッケージをKubernetesにデプロイする
  • Kubernetesはパッケージの状態をClientに返す

対応パッケージとプロジェクト情報

関連記事

1件のコメント

 
GN⁺ 2024-06-27
Hacker News の意見

  • 正しい方向への一歩かもしれないが、現在の Kubernetes のパッケージ管理における最大の問題は、パッケージマネージャーで解決するのは難しそうに見える
    日常でいちばんつらいのは、ネストした YAML が何段にも積み重なり、結果が予測不能になる点
    たとえば ArgoCD ApplicationSet が複数の Application を作り、その Application が Helm チャートをレンダリングし、そのチャートの中には Strimzi、Grafana、Vector のような任意のオペレーターが使う CRD が入っている
    YAML は構文が貧弱で、テンプレートのレンダリング標準もないため、最上位の変更を行ったときに実際に Kubernetes API に投入される YAML が何なのかを知るのはほぼ不可能
    結局、毎月の試行錯誤、高コストなブルーグリーンデプロイ、何百分ものデバッグにつながる

    • DevOps 周辺ツールで YAML が広く採用されたのは失敗だった
      きちんとしたプログラミング言語のサポートが進むべき方向だと思う
      理想的にはチューリング完全ではなく、終了が保証される静的型システムが必要で、型付きの Starlark のような形が適切に見える
    • レンダリング済みマニフェストのパターンを試したことがあるか気になる: https://akuity.io/blog/the-rendered-manifests-pattern/
    • これは Glasskube Cloud(https://glasskube.cloud/) が注力しようとしている問題
      glasskube[bot] が GitOps のプルリクエストに関連するすべてのクラスターで、実際に変わるリソースの正確な diffをコメントするようにしたい
      この diff はクラスター内で実行されるコントローラーが作成する
      codecov の解析に似ているが、リソース変更専用のものだと考えればよい
    • 解決策は Kubernetes を使わないこと

  • パッケージ管理に対する興味深いアプローチに見え、Homebrew 風のクラスターのような用途にはよさそう
    それでも個人的には、リポジトリ内で一貫性を保つためにも helmfile + Renovate + パイプライン の組み合わせを好む
    たとえば update all ボタンは、意味のあるクラスターではかなり怖く感じる
    個人プロジェクトのような場所では、今でもすばらしいツール
    パッケージコントローラーは昔の Helm の Tiller にかなり似ており、それが複数の企業で大きなセキュリティ問題となって Helm 3 で削除され、configmap ベースのクライアント側処理に変わったが、このプロジェクトがその問題をどう乗り越えるのか気になる

    • Glasskube パッケージは、すべてのパッケージが CR(custom resource) なので GitOps リポジトリに入れられる
      CLI で --dry-run と --output yaml フラグを設定してから Git に入れることも可能
      また Renovate でパッケージ更新をサポートするプルリクエストに取り組んでいる: https://github.com/renovatebot/renovate/issues/29322
      Helm 3 は今やクライアント側ツールなので、それ自体で RBAC を強制することはできない
      OLM は Operator Groups(https://olm.operatorframework.io/docs/advanced-tasks/operato...) を導入し、オペレーター単位の権限を提供した
      Glasskube パッケージにも似たものを導入でき、Glasskube 自体には依然としてかなり強い権限が必要だろうが、パッケージの範囲を制限し、細かい権限を入れられる

  • 従来、アプリケーションパッケージはインストール前後の手順を含むバージョン固定の不変バイナリであり、特定のプラットフォームと特定の依存関係を想定してビルドされ、インストール時の設定はごく限られている。
    パッケージがうまく動作する理由は、非常に具体的な環境を対象に設計され、インストール時に変更できる部分を最小限にしているからだ。
    それでもOSパッケージは、その狭い条件の中でもなお、膨大なテスト、開発、パッチを継続的に必要とする。
    今インストールするパッケージが簡単に感じられるのは、現在のプラットフォーム、現在の構成要素とバージョンに対して、何百時間も費やされている可能性があるからだ。
    Kubernetesの「パッケージ」は実際にはパッケージではなく、インストールして設定する構成要素についての指示の束に近く、しばしば複数の別個のアプリケーション群を含む。
    この違いは2つの形で現れる。K8sの「パッケージ」は定義が非常に緩く変動が大きいこと、そしてさまざまな人がさまざまな方法で作るため、インストール先システムの状態についてさまざまな仮定を置いていることだ。
    Kubernetesの「パッケージ」が動作するには、複数の層の依存関係と設定が合っていなければならない。
    K8s APIのバージョン、K8sコンポーネントのインストール方法と実行方法、ACL、衝突し得る既存コンポーネントが存在しないこと、パッケージがインストールするコンポーネントとコンテナのバージョン固定およびクラスタ内の他のものとの互換性、ユーザー設定まで、すべてが合っている必要がある。
    アップグレードも、安定リリースツリーやローリングリリースの概念がないため同様に混乱しており、OSに任意の.deb、.rpm、.dmgファイルをインストールして、うまくいくことを願うのに近い。
    現在、これらすべてを担うものは存在しない。
    Kubernetesのパッケージングをプラットフォーム別バイナリパッケージングのように滑らかにするには、メンテナーコミュニティ全体と、Homebrewのようなローリングリリース方式、または安定したバージョンリリースブランチが必要になる。
    結局、ArtifactHubやHomebrewのようなプロジェクトがすべてのパッケージを1つの方式で管理する必要があるが、それは大仕事で、収益性もまったくなさそうだ。

    • GlasskubeもHomebrewと同様に、「core」Glasskubeパッケージリポジトリ（https://github.com/glasskube/packages）の中にパッケージを置く方式で始めた。
      すべてのアップデートを中央に保存し、CI/CDワークフローでテストすることで、ユーザーがテスト済みの滑らかなアップグレードを享受できるようにする構造だ。
      ユーザーが個人リポジトリやパッケージをホストすることもできるが、基本的には意見の反映されたパッケージ集合を自分たちで提供したい。
      異なるKubernetesバージョンや環境に合わせてビルドすることもすでに考えており、より多くの設定をビルド段階に織り込むには、いずれ必要になるだろう。

  • K8sのパッケージマネージャーがbrewやaptほど単純になれるかはよく分からない。
    特に、対象環境ごとに値が異なり、ほぼすべてのユーザーがそれぞれ異なる「スノーフレーク」環境を持っている点が大きい。
    そうした値を設定するためにREPL式のプロンプトやWeb UIを使うのは魅力的ではない。
    核心的な痛みはまだ解決されていない。Helmチャートを書くのは苦痛で、環境ごとの値を管理しなければならず、チャート間で値をつながなくて済むようにしてほしい。

    • 実際の現場にはスノーフレーククラスタが非常に多く、最近参加したクラウドネイティブカンファレンスでもホットトピックだった。
      プラットフォームチームは、チームとクラスタ全体のKubernetes設定をより標準化するために内部開発者プラットフォームを作り、開発者が小さな修正だけを行えるようにしようとしている。
      経験上、こうしたバラバラの設定は減らすべきであり、そもそもGlasskubeを作った理由でもある。
      Helmチャートを書くのが苦痛だという点には100%同意しており、今後それを変えようとしている。
      Glasskubeパッケージは依然として設定可能だが、意味のあるデフォルト値を提供する。
      他のパッケージの設定値をGlasskubeで簡単に参照できるため、同じ値を何度も提供する必要がない。

  • Kubernetesオペレーターを多く作っており、HelmとOLMの問題を頻繁に扱っている。
    ドキュメントには「CRDのアップグレードはGlasskubeが処理し、CRとオペレーターが互いにずれないようにする」とあるが、ドキュメントで「CRD」を検索しても具体的な結果が出てこない。
    これは現在Helmで経験している最大の痛みの1つなので、計画を共有してもらえるか気になっている。
    [1] <https://stackable.tech/en/>
    [2] <https://www.youtube.com/watch?v=Q8OSYOgBdCc>

    • 公開Glasskubeリポジトリのパッケージは、CRDの変更が適用されるように設定されている。
      Manifestやhelm-controllerを通じて処理される。
      ドキュメントは更新する予定だ。

  • Kubernetesは、過度に単純なオペレーターモデルのために根本的に制約されていると思う。
    全体のアイデアは気に入っているが、モデル全体を「現在の状態、望ましい状態、次の行動」にまで縮約するのは実際には不可能だ。
    結局、ワークフロー全体が次の行動ロジックの中に入ってしまうが、同じシステム状態を見ているオペレーターが多すぎるため、複数の構成要素がどう相互作用するのか分かりにくい。
    Helmの問題は、このより大きな問題の下位ケースだ。
    例えるなら、フロントエンドプログラミングがDOMで直面する問題と同じだ。
    Reactのような仮想DOM/リデューサーパラダイムを導入すれば、こうした問題の解決に大いに役立つだろう。

    • 「現在の状態、望ましい状態、次の行動」は、基本的には一般的な制御理論が動作する仕組みだ。
      状態、目標、目標へ向かう際の外乱があり、強力で柔軟なツールを望むなら、この抽象化レベルが適切だと思う。
      問題は、機械の物理的特性と配置があまりに大きな差を生むため、それを意味のある形で仮想化したりシミュレーションしたりするコストが過大になる点だ。
      そのため代わりに、物理構造の部分集合として設定状態が機能するかを検証する。
      dev、staging、prod環境を用意し、ブルーグリーンデプロイ、カナリア分析、部分ロールアウトなどを使う方式だ。

  • K8sを使うのにこのようなツールが必要なら、おそらく別の解決策を使うほうがよい。
    Kubernetesは予備知識なしに使うように作られたものではなく、難しい。
    完全なPaaSを作らない限り、その複雑さから逃れるのは難しい。

  • このツールはマーケティングの方向性を誤っているように思う
    これは Helm とはあまり関係がない
    私にとって Helm は主にパッケージマネージャではなく テンプレート言語であり、kubeapps、Helm CLI、ArgoCD を通じて K8s クラスタに設定・インストールするためのもの
    このアプローチは優れた IaC のパラダイムも壊してしまう
    ArgoCD をブートストラップした後は、Git リポジトリだけを参照する構成がよいからだ
    デモは form サポートのようなテンプレート機能をどう使うのかを見せず、それ以外のものだけを見せている
    Helm には何か問題があるという感覚は今もあるので、このツール自体は正直気に入っているが、今のアプローチでは失敗しそうだ
    大企業はこのツールを必要としないため、十分な採用を得るのは難しいだろう
    Kubeapps も Helm もうまく機能しており、Helm を置き換えると言っても、おそらく Helm サポートは長く残す可能性が高い
    Helm の問題は、チャートが大きくなるほど複雑になることにある
    templates フォルダ 1 つに実質的にすべてが入る構造は混沌としており、YAML はテンプレートに向かず、values.yaml は肥大化しすぎる

    • デモはエンドユーザーにより焦点を当てたもの
      設定オプションの詳細はパッケージ設定ドキュメントで確認できる: https://glasskube.dev/docs/design/package-config/
    • 傲慢だったり見下した言い方に聞こえてほしくはないが、Helm が主に パッケージマネージャではないと思うなら、K8s にデプロイされたインフラをあまり扱ってきていないのだと思う

  • Helm より速いという売り文句にはあまり惹かれない
    Helm の問題が 速度だと感じたことはない

  • 面白そう
    既存ツールである ArgoCD とどう噛み合うのか、あるいはどう比較されるのかを短く説明してもらえると理解しやすいと思う
    動画は見たし、インストールするツールの 1 つが Argo だったので、明らかに別のニッチを占めているようだが、それが何なのかはまだよく分からない

    • ArgoCD は GitOps リポジトリの状態をクラスタに同期し、インストール済みリソースを可視化し、潜在的なエラーを示してくれる優れたツール
      開発者がクラスタへのアクセスなしに、会社の中核アプリケーションの状態を確認するためによく使われる
      Glasskube は中核アプリケーションが依存するパッケージに焦点を当てる
      インフラ構成要素のライフサイクルを管理し、更新をテストし、アップグレードパスを提供する
      Glasskube パッケージを GitOps リポジトリに入れて ArgoCD でクラスタに同期することもでき、残りは PackageController が処理する