Gitpod、Kubernetesを離れる決断 + Gitpod Flexを発表

• Gitpodは6年間Kubernetesを使って「リモート開発環境プラットフォーム」を構築してきており、150万人のユーザーを支え、毎日数千件の開発環境を提供中
• しかしKubernetesは開発環境の構築には適していないことに気づいた
• これは本番ワークロードにKubernetesを使うべきかどうかの話ではなく、K8sにアプリケーションをデプロイするための開発者体験をどう作るかという話でもない
  → クラウドで開発環境を構築する方法（あるいは構築しない方法）についての話である

[開発環境が特別な理由]

• 状態を多く持ち、インタラクションが活発
  • ノード間を移動できない
  • 大量のソースコード、ビルドキャッシュ、Dockerコンテナ、テストデータなどが頻繁に変化し、移行コストが高い
  • 本番サービスと違い、開発者と環境の間で1対1のインタラクションが発生する
• 開発者はソースコードと変更内容に深く結びついている
  • ソースコードの変更を失ったり、システムによってブロックされたりすることを好まない
  • 開発環境は障害に特に敏感
• 予測不能なリソース使用パターンを持つ
  • ほとんどの時間はCPU帯域をあまり必要としないが、数百ms以内に複数コアを必要とすることがある
  • それより遅いと容認できない遅延や無応答として現れる
• 広範な権限と機能が必要
  • 本番ワークロードと違い、rootアクセスとパッケージのダウンロード/インストール能力が必要
  • 本番ワークロードではセキュリティ問題となることが、開発環境では想定される挙動である（rootアクセス、拡張されたネットワーク機能、追加のファイルシステムマウントなど）
• こうした特性により一般的なアプリケーションワークロードとは区別され、インフラの判断に大きな影響を与える

[現在のシステム: Kubernetes]

• Gitpod初期には、Kubernetesはインフラとして理想的な選択に見えた
  • 拡張性、コンテナオーケストレーション、豊富なエコシステムなどがクラウド開発環境のビジョンとよく合っていた
• しかし規模が大きくなり、ユーザーベースが増えるにつれて、セキュリティと状態管理の面で課題に直面した
  • Kubernetesは適切に制御されたアプリケーションワークロードを実行するよう設計されており、扱いにくい開発環境のためのものではない
• 大規模でKubernetesを管理するのは複雑
  • GKE、EKSのようなマネージドサービスが一部の問題を和らげてくれるが、それ固有の制約や限界もある
• CDEを運用しようとする多くのチームは、Kubernetesの複雑さを過小評価しがち
  • これは以前のセルフマネージドGitpod製品でかなりのサポート負荷につながった

リソース管理の難しさ

• CPUとメモリの割り当てが最大の難題
• ノード上で環境を共有するのは魅力的だが、実際にはnoisy neighbor効果が大きく現れる
• CPUの問題
  • 開発環境は普段はCPUをあまり必要としない一方、瞬間的に大量に必要とする
  • CFSベースのソリューションやカスタムコントローラなどを試したが、予測が難しい
  • 静的なCPU制限を使っても、複数プロセスが競合する問題が発生
• メモリ管理
  • 固定メモリを割り当てるのは簡単だが制限が大きい
  • オーバーブッキングはプロセス終了につながりうる
  • スワップ領域の導入でオーバーブッキングの必要性はやや緩和された

ストレージ性能の最適化

• IOPSとレイテンシが開発環境の体験に影響する
• さまざまな構成を試しながら、速度、安定性、コスト、性能のバランスを探った
  • SSD RAID 0
  • EBS、永続ディスクなどのブロックストレージ
  • PVC
• バックアップ/復元はコストの高い処理

オートスケーリングと起動時間の最適化

• 起動時間の最小化が最優先目標
• 1つのノードで複数ワークスペースを実行すれば共有キャッシュによって起動時間が改善すると考えたが、そうではなかった
• Kubernetesが起動時間に下限を課していた
• スケールアウト手法の進化
  • ゴーストワークスペース、バラストPodなどを使ってスケールアウトを実験
  • オートスケーラープラグイン導入により拡張戦略が大きく改善した
• ピーク負荷対応のための比例オートスケーリング
  • 空のPodを起動して需要急増に迅速に対応
• イメージpull最適化のためのさまざまな試み
  • DaemonSetによる事前pull、レイヤー再利用の最大化、事前焼き込み済みイメージ、Stargazerと遅延pull、Registry-facade + IPFS

ネットワークの複雑さ

• 開発環境のアクセス制御
  • 環境間で完全に分離されていなければならない
  • Network Policyは役立つが、サービス数が増えると信頼性の問題が発生する
• ネットワーク帯域の共有
  • CNIがトラフィックシェーピングをサポートすることもあるが、また別の制御対象になる

セキュリティと分離: 柔軟性と保護のバランス

• ユーザーに柔軟性を与えつつ、安全な環境を提供することが最大の挑戦
• ユーザーにroot権限を与えるのは問題が多い
• ユーザー名前空間がより細かな解決策
  • ファイルシステムUID変換、マスクされたprocマウント、FUSEサポート、ネットワーク機能の提供、Docker有効化
• ユーザー名前空間実装の難しさ
  • 性能への影響、互換性の問題、複雑さ、Kubernetesバージョン対応

[Micro VMの実験]

• Kubernetesの限界を感じ、Firecracker、Cloud Hypervisor、QEMUなどのマイクロVM（uVM）技術を中間地点として探り始めた
• リソース分離の改善、他ワークロード（Kubernetesなど）との互換性、セキュリティ強化を期待しつつ、コンテナ化の利点も維持できるのではという期待があった
• マイクロVMの利点
  • クラウド開発環境の目標によく合う魅力的な利点を提供する
  • リソース分離の向上: オーバーブッキング能力は下がるが、コンテナに比べてリソース分離が改善される。共有カーネルリソースの競合がなくなり、開発環境ごとの性能予測可能性が高まる
  • メモリスナップショットと高速再開: Firecrackerのuserfaultfd機能はメモリスナップショットをサポートする。これにより実行中プロセスを含めてマシン全体をほぼ即座に再開できる。開発者の立場では環境起動がはるかに速くなり、作業を中断した地点からすぐ再開できる
  • セキュリティ境界の改善: uVMは強力なセキュリティ境界として機能でき、Kubernetesで実装した複雑なユーザー名前空間メカニズムが不要になる。これにより入れ子のコンテナ化（開発環境内でDockerやKubernetesを実行すること）を含む、より広いワークロードと完全に互換になりうる
• マイクロVMの課題
  • しかしマイクロVMの実験では、いくつかの重大な課題が明らかになった
  • オーバーヘッド: 軽量VMであっても、uVMはコンテナより大きなオーバーヘッドを生む。性能とリソース活用の両方に影響し、これはクラウド開発環境プラットフォームにおいて重要な検討事項となる
  • イメージ変換: OCIイメージをuVMで使えるファイルシステムへ変換するにはカスタムソリューションが必要。イメージ管理パイプラインが複雑になり、起動時間にも潜在的な影響が出る
  • 技術ごとの制約
    • Firecracker: GPUサポートがない（いくつかの開発ワークフローでますます重要になっている）、virtiofsサポートがない（効率的なファイルシステム共有オプションが制限される）
    • Cloud Hypervisor: userfaultfdサポートがないためスナップショットと復元プロセスが遅くなる（uVMの主要な利点を相殺してしまう）
  • データ移動の問題: uVMでは大容量のメモリスナップショットを扱う必要があり、データ移動がより難しくなる。スケジューリングと起動時間の両方に影響し、これはクラウド開発環境のユーザー体験の中核要素である
  • ストレージに関する考慮事項: マイクロVMにEBSボリュームを接続する実験は新しい可能性を開いた一方で、新たな疑問も生んだ
    • 永続ストレージ: 接続ボリュームにワークスペースの内容を保持すれば、S3からデータを繰り返し取得する必要がなくなり、起動時間の改善とネットワーク使用量の削減が期待できる
    • 性能面の考慮: ワークスペース間で高スループットのボリュームを共有すればI/O性能の改善が見込めるが、効果的なクォータ実装、レイテンシ管理、スケーラビリティ確保への懸念も生じる
• マイクロVM実験の教訓
  • マイクロVMが最終的に主要インフラの解決策にはならなかったものの、実験を通じて貴重な洞察を得た
  • 開発環境のためのワークスペース全体バックアップと、ランタイム状態の一時停止/再開という体験は気に入っていた
  • 初めてKubernetesから離れることを検討するようになった。KVMとuVMをPodに統合しようとする取り組みの末に、Kubernetes外の選択肢を探ることになった
  • 安定した起動性能、安定したワークスペース（データ損失防止）、最適なマシン活用という3つすべてを実現するための重要要素として、ストレージをあらためて認識した

Kubernetesは開発環境プラットフォームとして非常に難しい

• 前述のとおり、開発環境にはその固有の状態性を尊重するシステムが必要
• 開発者が生産性を発揮するために必要な権限を与えつつ、安全な境界を保証しなければならない
• これらすべてを、運用オーバーヘッドを低く保ち、セキュリティを妥協せずに実現しなければならない
• 今日のKubernetesでこれをすべて達成することは可能だが、相当なコストがかかる
• アプリケーションワークロードとシステムワークロードの違いを、厳しい形で学ぶことになった
• Kubernetesは驚くほど優れている
• 情熱的なコミュニティに支えられ、非常に豊かなエコシステムを築いてきた
• アプリケーションワークロードを実行するなら、Kubernetesは今でも良い選択肢
• しかし開発環境のようなシステムワークロードでは、Kubernetesはセキュリティと運用オーバーヘッドの面で非常に大きな課題をもたらす
• マイクロVMと明確なリソース予算は助けになるが、コストがより支配的な要因になる
• そこで、長年にわたって開発環境をKubernetesプラットフォームに事実上逆算で当てはめ、無理に適用してきたあと、一歩引いて未来の開発アーキテクチャがどうあるべきかを考えるようになった
• 2024年1月にこれの構築を始め、10月にGitpod Flexをリリースした
• インターネット規模で開発環境を安全に実行するために6年以上かけて得た非常に困難な洞察が、そのアーキテクチャの土台に組み込まれている

開発環境の未来

• Gitpod Flexでは、Kubernetesの基本的な側面、つまり制御理論の自由な適用と宣言的APIを引き継ぎつつ、アーキテクチャを単純化し、セキュリティ基盤を改善した
• Kubernetesに強く触発されたコントロールプレーンを使って開発環境をオーケストレーションする
• 開発環境に特化して必要な抽象化レイヤーを導入し、不要なインフラの複雑さの大半を取り除いた
• これらすべてをゼロトラストセキュリティ最優先で進めている
• この新しいアーキテクチャによってDev Containerをシームレスに統合できるようになった
• さらにデスクトップで開発環境を実行する能力も開けた
• もはやKubernetesプラットフォームの重い負担を背負う必要がないため、Gitpod Flexは3分以内にセルフホストでデプロイでき、望む数のリージョンに展開可能
• これによりコンプライアンスをより細かく制御でき、組織境界やドメインをモデル化する際の柔軟性も高まる

（元は別の記事だが、一緒にまとめたほうがよさそうなので併せて移す。）

Gitpod Flex

• ゼロトラスト開発環境のための最初の自動化プラットフォーム
• ノートPC、クラウド、オンプレミスで動作するよう設計されており、ソースコード、データ、知的財産をプライベートネットワーク内に保持
• 開発環境から始めて、ソフトウェア開発ライフサイクル自動化のためのビルディングブロックを提供
• Automations
  • リポジトリやAPIを通じて定義された、プログラム可能なタスクとサービス
  • 開発者が自力で解決できるよう支援し、開発者生産性チームが開発環境改善を中央集権的に進められるよう助ける
  • 単なるスクリプト実行以上の機能を提供
  • データベースのプロビジョニングとシーディング、開発者ワークフローのカスタマイズ、一時クラスタの実行、LLMベースのエージェントワークフロー設定、グローバル/地域セキュリティおよびコンプライアンスの中央適用などが可能
• ゼロトラスト環境（Zero-trust environments）
  • すべてのアクターとサービスを「決して信頼せず、常に検証する」
  • 悪意あるアクターを完全に遮断し、攻撃露出面を大幅に縮小し、マルウェアやコード流出のリスクを低減
  • 継続的評価と明示的検証、検証済みエンタープライズ級暗号化、細粒度アクセス制御、ネットワーキングの完全制御、完全な監査ログを含む
  • ソースコード、データ、知的財産権をプライベートネットワーク内に保持することが最重要
• Gitpod Desktop
  • ローカル開発環境の標準化と自動化が可能
  • Apple Siliconからサポート開始
  • レイテンシのゼロ化、開発向けDocker Desktopのより高速・軽量・シンプルな代替、ローカルコンピューティングを活用したコスト最適化、クラウドやエンドポイント停止への災害復旧支援を提供
• Development Container対応
  • Dev Container仕様を完全に統合
  • 既存のDev Container設定を変更なしで利用可能
  • VS Codeおよびその他の対応ツールとの互換性を提供
  • ローカルでもクラウドでも一貫して作業できる
  • Dev Container標準の採用により、開発環境の定義、共有、管理がより容易になる

今後10年間のソフトウェア開発自動化の土台になる

• 私たちは開発環境をあまりにも狭く捉えてきた
• 開発環境はIDE、依存関係、ツール以上のものであり、ソフトウェアが作られる根本的な空間
• コードのプロトタイピング、人と機械による形成、テスト、リファクタリング、コンパイル、パッケージング、署名、デプロイが行われる場所
• 開発コンテキスト、ワークフロー、洞察への比類ないアクセス性を提供し、他の開発プラットフォームと差別化された機能を実現する
• 製品ビジョン
  • 継続的インテグレーション（CI）が開発環境と融合
  • ソフトウェア開発のSystem of recordとして機能
  • 次世代開発者ツールのためのプラットフォーム
• 単にコーディング慣行を改善するだけでなく、スタートアップからFortune 50企業まで、今後10年間にわたって企業がスケールし成功できる最速かつ最も安全な方法を構築する

[ahwjdekf]

セキュリティを口実に、8GBメモリ仕様の仮想デスクトップを強制的に使わせる国内企業たち。やるせない。

[bus710]

Kubernetesに詳しい人を見つけるのも難しいのに、ここで代替案として示されているものを理解して試そうとする人を見つけるのは、さらに難しそうだと思います。

[xguru]

Hacker Newsのコメント

• 開発者は、自分が使う開発用デバイスを所有すべきだ。一貫した環境が必要なら、開発者が自分のデバイスを所有し、安定したVMイメージの提供を受けるべきだ。開発環境をリモートホストへ移そうとする試みは、たいてい失敗する。開発者に適切なハードウェアを提供する方が、リモートリソースより費用対効果が高い。ローカルスタックの実行をサポートすべきであり、それはコンテナを通じて一貫性を保つ助けになる。ローカル環境にデータを生成するツールが必要で、これは自動化できる。データ管理には欠点もあるが、ほとんどの企業ではソースコードよりもチームの実行力の方が重要だ。

• Kubernetesを本番ワークロードに使うことは別問題であり、これはクラウド上で開発環境をどう構築するかという話だ。Kubernetesの複雑なエンジニアリング上のトレードオフについての興味深い記事。

• Kubernetesの問題点と試した解決策は説明されているが、最終的に選んだ代替案についての説明が不足している。Gitpod Flexという新しいソリューションに触れているが、それに関する情報はあまりない。

• Kubernetesはステートレスなワークロードには向いているが、ステートフルな場合はLXCの方が適している。LXCはK8Sと同様にクラスタ化でき、データプレーンにツールを公開する。VMのようにシステムインスタンスを提供し、Dockerコンテナに近い性能を持つ。宣言的な文法を使い、Kubernetesクラスターの基盤レイヤーとして利用できる。

• CIソリューションを構築しながらKubernetesを選んだのは、問題をきちんと理解していなかったということだ。セキュリティ目的ならFirecrackerのようなツールを使うべきだ。

• Kubernetesは開発環境に向いていない。開発環境は常に変化する状態にある。クラウド開発環境の必要性が理解できない。コンテナ化されたアプリの目的は、チーム間で開発環境を同期する必要を避けることだ。

• Kubernetesの論文では、低遅延と高遅延のワークフローの組み合わせを唯一のユースケースとして挙げている。Gitpodの問題にKubernetesを検討するのは正当化しにくい。

• Gitpodに似たプロジェクトを進めたことがあるが、Kubernetesの代わりにマイクロVMを使う理由が理解できない。Kubernetesは外部コンテナをオーケストレーションでき、マイクロVMの実行にも使える。最大の問題はストレージ関連の問題だ。

• Kubernetes上で開発環境を構築するのは無駄が多い。製品が顧客のインフラ上でセルフホストされる場合、デバッグやサポートが難しい。ネットワーク、メモリ、コンピュート、ストレージの問題をエンジニアに可視化するのが効果的だ。Kubernetesは大きなチームにとってはアップグレードだ。