Kubernetes ベースのリリースシステムの設計

背景

Kubernetes クラスターへのサービス移行をデプロイする以前の作業では、CI/CD プロセスは主に .gitlab-ci.yml ファイルを記述することによって実装されていました。このプロセスを通じて、ユニットテスト、リンティング、コンパイル、イメージのパッケージ化、コード更新後のリリースを完了できます。

ただし、サービスが Kubernetes クラスターにデプロイされた後、各サービスは GitLab リポジトリでデプロイメント テンプレートを維持し、サービスの新しいバージョンをリリースする必要があります。各デプロイメント プロセスでは、いくつかのリリース パラメータとデプロイメント テンプレートを組み合わせて、リリースに必要な deploy.yml ファイルを生成し、それを kubectl コマンドを通じて Kubernetes クラスターに公開します。ただし、このソリューションには次の欠点があります。

• 各サービスは独自のデプロイメントテンプレートを維持しており、管理がある程度複雑になっています。
• 統一されたリリース履歴管理が欠如しているため、問題のトラブルシューティングやバックトラッキングが困難です。
• 効果的な権限管理が欠如しているため、一定のリスクがある

上記の問題を解決するために、CI/CDプロセスのリリース作業を抽出し、Kubernetesベースのリリースシステムを設計してサービスリリース作業を完結させました。

出版システムの基本機能

私たちが設計した出版システムには、次の基本機能があります。

• サービスレベルでリリース機能を完了する
• リリース記録の表示
• 各リリースレコードは詳細なリリースプロセスを照会できます
• 公開されたレコードごとにクイックロールバック操作を実行できます。
• リリース結果通知、サポートメール、DingTalk通知
• 一部のサービスはグレースケールのリリースをサポートしています

リリースプロセスの概要

リリース システムがリリース操作を実行する前に、CI 前のプロセスを完了する必要があります。具体的な操作は以下のとおりです。

1. GitLabでコードが更新されると、パイプラインをトリガーする特定のCIルールを設定できます。
2. Gitlab-ci はコードをプルし、ユニット テスト、リンティング、コード コンパイル、イメージ ビルドなどの操作を完了します。
3. イメージがビルドされたら、バージョン情報を含むDockerイメージをDocker Harborにアップロードします。
4. リリースシステムにDockerイメージのバージョン情報を入力する

上記の作業が完了すると、リリース システムは各サービスに基づいて対応するバージョンを選択し、各リリースに必要なデプロイメント ファイルを生成し、Kubernetes API サーバーを呼び出してサービスのローリング アップグレードを実装できます。

リリースプロセスの詳細

基本的な公開操作

公開システムでは、各公開操作は公開タスクと見なされます。したがって、サービスをアップグレードする必要がある場合は、このサービスに対して新しい公開タスクを作成する必要があります。具体的な操作は以下のとおりです。

• リリースする環境（テスト環境または正式環境）を選択します
• サービス名に基づいてイメージリストを取得し、バージョンを選択します
• リリースパラメータを確認し、リリースの説明を入力してください
• 情報を送信してバージョンリリースタスクを開始する

リリースタスクの作成が完了すると、各リリースタスクの情報を表示できるようになります。上記に記入した情報に加え、リリースタスクの開始時間、リリース期間、操作ユーザー、リリースの説明、リリースステータスなどの情報も含まれます。これにより、各リリース操作の記録が完了し、問題のトラブルシューティングと追跡に役立ちます。

さらに、各リリース タスクはロールバック操作もサポートしており、新しいバージョンのリリースに問題が発生した場合にバージョンをすばやくロールバックできます。最後に公開されたタスクを再送信できます。この機能には、次の 2 つの実用的なシナリオがあります。

リリースは外部要因により失敗したため、外部要因が解決された後に再リリースする必要があります。

コードの構成情報が更新された後、Kubernetes 内の Pod はこの構成情報を更新する必要があります。ロールバックと再送信の操作は、本質的には新しいリリース タスクです。リリース パラメータは、各リリース タスクの情報に基づいて自動的に選択されるため、より高速で便利です。

リリースデプロイメントファイルの生成

デプロイメント テンプレートのパラメータは、次の 2 つのカテゴリに分かれています。

基本パラメータ

リリースの基本的なパラメータには、Pod レプリカの数、ヘルスチェック パス、組織情報などが含まれており、実際の状況に応じて調整できますが、調整頻度は非常に低くなります。これらのパラメータはリリース構成を通じて管理されます。各サービスはリリース構成を維持し、それをデータベースに保存します。ページ上のリリース構成を編集することで、基本的なパラメータを変更できます。さらに、リリース構成では、サービスで使用されるリリース テンプレート情報が維持されます。

基本パラメータの調整には、新しいリリースタスクの作成よりも高い権限が必要です。

公開パラメータ

サービス名、バージョン番号、リリース環境、リリース方法などを含み、各リリースは必要に応じて記入されます。これらのパラメータは、新しいリリース タスクが作成されるときに決定されます。

リリースが行われるたびに、リリース システムは基本テンプレートと上記のパラメーター値を組み合わせて、このリリース タスクに必要なデプロイメント ファイルを生成し、kubectl apply を通じて Kubernetes API サーバーを呼び出して、対応するサービスのローリング アップグレードを実行します。

デプロイメントテンプレートの管理

私たちの実践では、サービスには共通点があります。特定のタイプのサービスに対してデプロイメント リリース テンプレートを抽象化し、複数のサービスで 1 つのリリース テンプレートを共有できるようにすることで、管理コストを大幅に削減します。現在リリースに使用されているデプロイメント テンプレートは GitLab に保存されています。テンプレートの管理と使用方法は次のとおりです。

1. テンプレートの追加はマージリクエストを送信することで行われます
2. GitLab に新しいテンプレート ファイルが追加されると、GitLab Pipeline がトリガーされ、デプロイメント テンプレート情報がリリース システムに同期されます。
3. テンプレートは公開システムに記録され、テンプレート ID が一意の識別子として使用されます。
4. 各サービスは、公開設定内の公開テンプレートIDに対応しています。
5. 新しい公開タスクを作成すると、公開システムは公開構成のテンプレート ID に基づいて対応するテンプレート ファイルの URL を取得し、コンテンツをダウンロードします。

Kubernetes リリース プロセスの追跡と結果の記録

Kubernetes は宣言型デプロイメント ファイルを定義し、非同期呼び出しを行うことでバージョンを更新するためです。 kubectl apply を呼び出した後、対応する Pod がローリング アップデートを正しく完了できるかどうかを判断することはできません。したがって、リリース プロセスを追跡するには、コマンド kubectl rollout status deployment $deployment_name を使用します。ここで、変数deployment_name はサービスと 1 対 1 で対応しています。

リリース プロセスの追跡に関する情報は、各リリース タスクの詳細で確認できます。ここには、Pod ローリング アップデートの詳細なプロセスが記録されます。

公開された Pod が正常に更新されると、 kubectl rollout status deployment $deployment_name が正常に終了し、リリース システムはリリース タスクが成功したと判断します。何らかの理由でローリング アップデート プロセス中に Pod の新しいバージョンがブロックされた場合、リリース システムで設定されたタイムアウト期間を超えると、リリース タスクは失敗したと見なされます。

公開に失敗したタスクについては、現在、シンプルな Pod ログの表示がサポートされています。主な原則は、公開プロセス中にステータスが実行中または終了中でないポッドのログを照会して、失敗した公開タスクの問題を特定することです。効果は以下のとおりです。

要約する

この記事では主にKubernetesをベースとしたリリースシステムについて紹介します。まず、Kubernetes ベースのリリース システムを設計する背景と必要性について説明します。次に、出版システムの基本機能について説明します。 3 番目の部分はこの記事の本文であり、リリース システムの原理を詳細に説明します。まず、新しいリリース タスクの作成から始め、デプロイメント ファイルの生成、リリース テンプレートの管理、リリース結果の追跡と記録、グレースケール リリースの実装について詳しく説明します。

著者: Wu Chongbin、VPGAME 運用保守開発エンジニア。 VPGAMEは、イベント運営、メディア情報、ビッグデータ分析、プレイヤーコミュニティ、ゲーム周辺機器を統合した総合的なeスポーツサービスプラットフォームです。