GitLab.com から Kubernetes への XNUMX 年間の移行からの発見

ノート。 翻訳。: GitLab での Kubernetes の導入は、同社の成長に貢献する 8 つの主な要因の XNUMX つであると考えられています。 ただし、最近まで、GitLab.com オンライン サービスのインフラストラクチャは仮想マシン上に構築されており、わずか XNUMX 年ほど前に KXNUMXs への移行が始まりましたが、まだ完了していません。 これがどのようにして起こるのか、そしてプロジェクトに参加しているエンジニアがどのような結論を出したのかについて、GitLab SRE エンジニアによる最近の記事の翻訳を紹介します。

約 XNUMX 年前から、当社のインフラストラクチャ部門は、GitLab.com で実行されているすべてのサービスを Kubernetes に移行してきました。 この間、サービスを Kubernetes に移行するだけでなく、移行中のハイブリッド デプロイメントの管理にも関連する課題に直面しました。 私たちが学んだ貴重な教訓については、この記事で説明します。

GitLab.com の設立当初から、そのサーバーはクラウド上の仮想マシンで実行されていました。 これらの仮想マシンは Chef によって管理され、弊社の 公式Linuxパッケージ. 導入戦略 アプリケーションを更新する必要がある場合は、CI パイプラインを使用して調整された順次方法でサーバー フリートを更新するだけで済みます。 この方法は少し時間がかかりますが、 つまらない - GitLab.com がオフライン ユーザーと同じインストールおよび構成方法を使用することを保証します。 (自己管理) このために Linux パッケージを使用して GitLab をインストールします。

私たちがこの方法を使用するのは、コミュニティの一般メンバーが GitLab のコピーをインストールして構成するときに経験するすべての悲しみと喜びを経験することが非常に重要であるためです。 このアプローチはしばらくはうまくいきましたが、GitLab 上のプロジェクトの数が 10 万を超えたとき、これではスケーリングとデプロイメントのニーズを満たせなくなったことに気づきました。

Kubernetes とクラウドネイティブ GitLab への第一歩

プロジェクトは 2017 年に作成されました GitLab チャート GitLab をクラウド展開用に準備し、ユーザーが Kubernetes クラスターに GitLab をインストールできるようにします。 そのとき、GitLab を Kubernetes に移行すると、SaaS プラットフォームのスケーラビリティが向上し、デプロイが簡素化され、コンピューティング リソースの効率が向上することがわかりました。 同時に、アプリケーションの機能の多くはマウントされた NFS パーティションに依存していたため、仮想マシンからの移行が遅くなりました。

クラウド ネイティブと Kubernetes への移行により、当社のエンジニアは段階的な移行を計画することができ、その間、新機能の開発を継続しながら、アプリケーションのネットワーク ストレージへの依存関係の一部を放棄しました。 2019 年の夏に移行の計画を開始して以来、これらの制限の多くは解決され、GitLab.com から Kubernetes への移行プロセスは現在順調に進んでいます。

Kubernetes の GitLab.com の機能

GitLab.com の場合、すべてのアプリケーション トラフィックを処理する単一のリージョン GKE クラスタを使用します。 (すでに難しい) 移行の複雑さを最小限に抑えるために、ローカル ストレージや NFS に依存しないサービスに焦点を当てています。 GitLab.com は主にモノリシックな Rails コードベースを使用しており、ワークロードの特性に基づいて、独自のノード プールに分離されたさまざまなエンドポイントにトラフィックをルーティングします。

フロントエンドの場合、これらのタイプは Web、API、Git SSH/HTTPS、およびレジストリへのリクエストに分類されます。 バックエンドの場合、キュー内のジョブをさまざまな特性に従って分割します。 事前定義されたリソース境界を使用すると、さまざまなワークロードのサービス レベル目標 (SLO) を設定できます。

これらの GitLab.com サービスはすべて、未変更の GitLab Helm チャートを使用して構成されています。 構成はサブチャートで実行され、サービスをクラスターに徐々に移行するときに選択的に有効にすることができます。 Redis、Postgres、GitLab Pages、Gitaly などの一部のステートフル サービスを移行に含めないことを決定しましたが、Kubernetes を使用することで、現在 Chef が管理している VM の数を大幅に減らすことができます。

Kubernetes 構成の可視化と管理

すべての設定は GitLab 自体によって管理されます。 このために、Terraform と Helm に基づく XNUMX つの構成プロジェクトが使用されます。 GitLab を実行するには可能な限り GitLab 自体を使用するようにしていますが、運用タスクのために別の GitLab インストールが必要です。 これは、GitLab.com のデプロイメントと更新を実行するときに、GitLab.com の可用性に依存しないようにするために必要です。

Kubernetes クラスターのパイプラインは別の GitLab インストール上で実行されますが、コード リポジトリのミラーが次のアドレスで公開されています。

• k8s-workloads/gitlab-com — GitLab Helm チャート用の GitLab.com 構成フレームワーク。
• k8s-workloads/gitlab-helmfiles - GitLab アプリケーションに直接関連付けられていないサービスの構成が含まれています。 これらには、ロギングとクラスター監視の構成に加え、PlantUML などの統合ツールが含まれます。
• Gitlab-com インフラストラクチャ — Kubernetes およびレガシー VM インフラストラクチャ用の Terraform 構成。 ここでは、クラスター自体、ノード プール、サービス アカウント、IP アドレスの予約など、クラスターの実行に必要なすべてのリソースを構成します。

変更が行われるとパブリック ビューが表示されます。 短い要約 クラスターに変更を加える前に SRE が分析する詳細な差分へのリンクが含まれています。

SRE の場合、リンクは GitLab インストール内の詳細な差分につながります。これは運用に使用され、アクセスは制限されています。 これにより、従業員とコミュニティは、運用プロジェクト (SRE のみが公開) にアクセスしなくても、提案された構成変更を表示できるようになります。 コード用のパブリック GitLab インスタンスと CI パイプライン用のプライベート インスタンスを組み合わせることで、構成更新に関して GitLab.com からの独立性を確保しながら、単一のワークフローを維持します。

移行中にわかったこと

移行中に得られた経験は、Kubernetes での新しい移行とデプロイメントに適用されます。

1. アベイラビリティゾーン間のトラフィックによるコストの増加

GitLab.com の Git リポジトリ フリートの毎日の送信統計 (XNUMX 日あたりのバイト数)

Google はネットワークを地域に分割しています。 これらは、アクセシビリティ ゾーン (AZ) に分割されます。 Git ホスティングには大量のデータが関連付けられているため、ネットワークの出力を制御することが重要です。 内部トラフィックの場合、下りは同じアベイラビリティ ゾーン内に留まる場合にのみ無料になります。 この記事の執筆時点では、通常の勤務日で約 100 TB のデータを提供しています (これは Git リポジトリのみの場合です)。 古い VM ベースのトポロジでは同じ仮想マシンに存在していたサービスが、別の Kubernetes ポッドで実行されるようになりました。 これは、以前は VM に対してローカルであった一部のトラフィックが可用性ゾーンの外に移動する可能性があることを意味します。

リージョン GKE クラスタを使用すると、複数のアベイラビリティ ゾーンにまたがって冗長性を確保できます。 可能性を検討中です リージョン GKE クラスタを単一ゾーン クラスタに分割する 大量のトラフィックを生成するサービス向け。 これにより、クラスターレベルの冗長性を維持しながら、下りコストが削減されます。

2. 制限、リソース要求、およびスケーリング

registry.gitlab.com で本番トラフィックを処理するレプリカの数。 トラフィックのピークは約 15:00 UTC です。

私たちの移行ストーリーは、最初のサービスである GitLab Container Registry を Kubernetes に移行した 2019 年 XNUMX 月に始まりました。 このミッション クリティカルな高トラフィック サービスは、外部依存関係がほとんどないステートレス アプリケーションであるため、最初の移行には適切な選択でした。 私たちが最初に遭遇した問題は、ノード上のメモリ不足により大量のポッドが削除されることでした。 このため、リクエストと制限を変更する必要がありました。

時間の経過とともにメモリ消費が増加するアプリケーションの場合、リクエストの低い値（各ポッドのメモリ予約）と使用量の「寛大な」ハード制限が飽和につながることが判明しました。 （飽和） ノードと高レベルのエビクション。 この問題に対処するために行われたのが、 リクエストを増やし、制限を下げることが決定されました。 これにより、ノードへの負担が軽減され、ポッドのライフサイクルがノードに過度の負担をかけないようになりました。 ここで、寛大な (そしてほぼ同じ) リクエストと制限値を使用して移行を開始し、必要に応じて調整します。

3. メトリクスとログ

インフラストラクチャ部門は、レイテンシー、エラー率、およびインストールされているシステムの飽和に重点を置いています。 サービスレベルの目標 (SLO) にリンクされています 私たちのシステムの一般提供.

過去 XNUMX 年間、インフラストラクチャ部門における重要な出来事の XNUMX つは、SLO の監視と連携の改善でした。 SLO により、移行中に綿密に監視した個々のサービスの目標を設定できるようになりました。 しかし、このように可観測性が向上したとしても、メトリクスやアラートを使用して問題をすぐに確認できるとは限りません。 たとえば、レイテンシとエラー率に焦点を当てても、移行中のサービスのすべてのユースケースを完全にカバーしているわけではありません。

この問題は、一部のワークロードをクラスターに移行した直後に発見されました。 この問題は、リクエストの数は少ないものの、非常に特殊な構成の依存関係がある関数をチェックする必要がある場合に特に深刻になりました。 移行からの重要な教訓の XNUMX つは、監視時にメトリクスだけでなく、ログと「ロングテール」も考慮する必要があるということでした。 (これは約 そのような分布 チャート上 - 約。 翻訳） エラー。 各移行に、ログ クエリの詳細なリストが含まれるようになりました。 (ログクエリ) また、問題が発生した場合に、あるシフトから次のシフトに移行できる明確なロールバック手順を計画します。

古い VM インフラストラクチャと新しい Kubernetes ベースのインフラストラクチャで同じリクエストを並行して処理することには、特有の課題がありました。 リフトアンドシフト移行とは異なります (アプリケーションを「そのまま」新しいインフラストラクチャに迅速に移行。詳細については、たとえば、 ここで — 約翻訳）「古い」VM と Kubernetes で並行して作業するには、監視ツールが両方の環境と互換性があり、メトリクスを XNUMX つのビューに結合できる必要があります。 移行期間中に一貫した可観測性を実現するには、同じダッシュボードとログ クエリを使用することが重要です。

4. トラフィックを新しいクラスターに切り替える

GitLab.com の場合、サーバーの一部は専用です。 カナリアステージ。 Canary Park は社内プロジェクトに役立つだけでなく、 ユーザーによって有効化される。 ただし、これは主に、インフラストラクチャとアプリケーションに加えられた変更をテストするように設計されています。 最初に移行されたサービスは、限られた量の内部トラフィックを受け入れることによって開始され、すべてのトラフィックをクラスターに送信する前に SLO が満たされていることを確認するためにこの方法を引き続き使用します。

移行の場合、これは、内部プロジェクトへのリクエストが最初に Kubernetes に送信され、次に HAProxy を介してバックエンドの重みを変更することで、残りのトラフィックを徐々にクラスターに切り替えることを意味します。 VM から Kubernetes への移行中に、古いインフラストラクチャと新しいインフラストラクチャの間でトラフィックをリダイレクトする簡単な方法があり、したがって移行後の最初の数日間は古いインフラストラクチャをロールバックできる状態にしておくことは非常に有益であることが明らかになりました。

5. ポッドの予約容量とその使用方法

すぐに次の問題が特定されました。レジストリ サービスのポッドはすぐに起動しましたが、Sidekiq のポッドの起動には最大で時間がかかりました。 XNUMX分。 ジョブを迅速に処理し、迅速に拡張する必要があるワーカーのためにワークロードを Kubernetes に移行し始めたとき、Sidekiq ポッドの起動時間が長いことが問題になりました。

この場合の教訓は、Kubernetes の 水平ポッド オートスケーラー (HPA) はトラフィックの増加にうまく対処しますが、ワークロードの特性を考慮して予備のキャパシティーをポッドに割り当てることが重要であるということでした (特に需要が不均等に分散されている場合)。 私たちの場合、ジョブが突然急増し、急速なスケーリングが発生し、ノード プールをスケーリングする前に CPU リソースが飽和してしまいました。

クラスターから可能な限り多くのものを絞り出したいという誘惑が常にありますが、最初はパフォーマンスの問題に遭遇したため、現在は十分なポッド予算で開始し、SLO を注意深く監視しながら、後で削減することにしています。 Sidekiq サービスのポッドの起動は大幅に高速化され、平均で約 40 秒かかるようになりました。 ポッドの起動時間の短縮から GitLab.com と、公式 GitLab Helm チャートを使用する自己管理型インストールのユーザーの両方を獲得しました。

まとめ

各サービスを移行した後、私たちは本番環境で Kubernetes を使用することの利点、つまりより高速かつ安全なアプリケーションのデプロイメント、スケーリング、より効率的なリソース割り当てに喜びを感じました。 さらに、移行の利点は GitLab.com サービスだけにとどまりません。 公式 Helm チャートのあらゆる改善はユーザーに利益をもたらします。

Kubernetes 移行の冒険のストーリーを楽しんでいただければ幸いです。 すべての新しいサービスをクラスターに移行し続けます。 追加情報については、次の出版物を参照してください。

• «なぜKubernetesに移行するのでしょうか?";
• «Kubernetes 上の GitLab.com";
• GitLab.com から Kubernetes への移行に関する壮大な記事.

翻訳者からの追伸

私たちのブログもお読みください:

• «Kubernetes を本番環境で使用して 3 年間: 私たちが理解していることは次のとおりです";
• «Kubernetes 使用時によくある 10 の間違い";
• «運用環境における Kubernetes の成功事例。 パート 3: GitHub";
• «Tinder から Kubernetes への移行'。

出所： habr.com