クラウド開発環境のプラットフォームであるGitpodは、6年間の使用と実験を経て、最近になってKubernetesからの移行を決定した。この決断は、150万人のユーザーの開発環境を管理し、毎日多数の環境を扱ってきた経験から生まれた。
GitpodのCTO兼共同設立者であるChristian Weichel氏とスタッフ・エンジニアのAlejandro de Brito Fontes氏は、この決断に至るまでの道のりをブログ投稿で詳しく説明している。Gitpodは、Kubernetesが本番環境のワークロードに適している一方で、開発環境で使用する際には大きな課題があることを発見した。
開発環境の性質も、こうした課題の一因となっている。本番ワークロードとは異なり、開発環境は非常にステートフルでインタラクティブであり、開発者はソースコードや変更に深く関与する。開発環境は予測不可能なリソース使用パターンを示し、精巧なパーミッションと機能を必要とし、しばしばrootアクセスとパッケージのインストール能力を必要とする。これらの要素が、開発環境を一般的なアプリケーションのワークロードとは異なる形にしており、Gitpodのインフラストラクチャの決定に影響を与えている。
当初、Kubernetesはそのスケーラビリティ、コンテナ・オーケストレーション、豊富なエコシステムにより、Gitpodのインフラにとって理想的だった。しかし、規模を拡大すると、特にセキュリティと状態管理で多くの課題に直面した。リソース管理にも課題が生じ始め、特に環境ごとのCPUとメモリの割り当てが問題となった。開発環境におけるCPUの要件は突発的であるため、CPUの使用時間がいつ必要になるかを予測するのは難しく、CPUのスケジューリングと優先順位付けに関するさまざまな実験が行われた。
ストレージ・パフォーマンスの最適化は、もうひとつの重要な焦点だった。Gitpodは、SSD RAID 0、ブロック・ストレージ、Persistent Volume Claims（PVC）など、様々なセットアップを実験した。それぞれのアプローチには、パフォーマンス、信頼性、柔軟性の面でトレードオフがあった。ローカルディスクのバックアップとリストアは、I/O、ネットワーク帯域幅、CPU使用量のバランスを慎重に取る必要があり、コストのかかる作業であることが判明した。
オートスケールと起動時間の最適化は、Gitpodにとって重要な目標だった。彼らは、スケールアップと前進のために、「ゴースト・ワークスペース」やバラスト・ポッド、そして最終的にはクラスタ・オートスケーラ・プラグインなど、様々なアプローチを模索した。イメージのプルの最適化もはもう1つの重要な側面で、Gitpodはイメージのプルを高速化するために、Daemonsetの事前プル、レイヤーの再利用の最大化、事前構築済みイメージなど、数多くの戦略を試した。
Kubernetesのネットワーキングは、特に開発環境のアクセス制御とネットワーク帯域幅の共有という点で、独自の複雑さをもたらした。Gitpodは、ユーザーに開発に必要な柔軟性を与えつつ、セキュアな環境を提供する必要があったため、セキュリティと分離が重要な課題を提起した。Gitpodはこれらの課題を解決するために、ファイルシステムのUIDシフト、マスクされたprocのマウント、カスタムネットワーク機能などの複雑なコンポーネントを含む、特有なユーザーネームスペース・ソリューションを実装した。
Hacker Newsで、Gitpodの道のりに関連した興味深い会話があった。HNユーザーの一人であるdatadeft氏は、回答の中でoriginal k8s論文を参照して次のように述べた。
唯一のユースケースは、低レイテンシと高レイテンシのワークフローの組み合わせで、リソースの割り当てはそれに基づいています。一般的な考え方は、低レイテンシの仕事をノード間で簡単に移動させることができ、高レイテンシのジョブが失敗しても深刻な影響はないというものです。この情報に基づくと、gitpodが抱えている問題に対してk8sを検討することさえ正当化するのは難しいです。
より良い解決策を求めて、GitpodはFirecracker、Cloud Hypervisor、QEMUのようなマイクロVM技術を試してみた。これらは、リソース分離の強化やセキュリティ境界の改善といった有望な機能を提供する一方で、オーバーヘッドやイメージ変換、技術固有の制限といった新たな課題ももたらした。
最終的にGitpodは、Kubernetesで目標を達成可能だが、セキュリティと運用のオーバーヘッドという点でトレードオフになると結論づけた。この学習により、彼らは新しいアーキテクチャであるGitpod Flexを開発することになった。このアーキテクチャは、制御理論や宣言型APIといったKubernetesの重要な側面を引き継ぎつつ、アーキテクチャを簡素化し、セキュリティ基盤を改善したものだ。
Gitpod Flexは、開発環境に関連する抽象化レイヤーを導入し、不要なインフラの多くを排除している。この新しいアーキテクチャにより、開発コンテナをスムーズに統合し、開発環境をデスクトップ・マシン上で実行できるようになる。また、セルフホストで素早く、いくつものリージョンにデプロイでき、コンプライアンスをよりコントロールし、組織の境界を柔軟にモデル化できる。
結論として、Gitpodの道のりは、単にKubernetesとその代替案の選択にとどまらず、開発者のエクスペリエンスを向上させ、運用負担を軽減し、最終的な成果を改善する能力に基づいてシステムを選択することの重要性を強調した。Gitpod Flexアーキテクチャの詳細については、興味を持った読者の方々はこのディープ・ダイブ・セッションをご覧いただきたい。