KubernetesクラスターとGitLabの接続

  • GitLab 13.4 で導入されました。
  • grpcs が GitLab 13.6 でサポートされました。
  • GitLab13.10のEarly Adopter Programを通じて、wss://kas.gitlab.com 、GitLab.comにエージェントサーバを導入。
  • GitLab 13.11で導入され、GitLabエージェントはGitLab.comで利用可能になりました。
  • 14.5でGitLab PremiumからGitLab Freeに移行。
  • GitLab 14.6で “GitLab Kubernetesエージェント “から “GitLab agent for Kubernetes “に名称変更。
  • GitLab 15.10でFluxをGitOpsソリューションとして推奨。

KubernetesクラスターとGitLabを接続し、クラウドネイティブなソリューションのデプロイ、管理、監視を行うことができます。

KubernetesクラスタをGitLabに接続するには、まずクラスタにエージェントをインストールする必要があります。

エージェントはクラスター内で実行され、次のようなことができます：

  • ファイアウォールやNATの背後にあるクラスターと通信します。
  • クラスター内のAPIエンドポイントにリアルタイムでアクセス。
  • クラスターで発生したイベントに関する情報をプッシュします。
  • Kubernetesオブジェクトのキャッシュを有効にし、非常に低いレイテンシで最新の状態に保ちます。

エージェントの目的とアーキテクチャの詳細については、アーキテクチャドキュメントを参照してください。

ワークフロー

2つの主要なワークフローから選択できます。GitOpsワークフローをお勧めします。

GitOpsワークフロー

GitOpsにはFluxを使うべきです。始めるには、チュートリアルをご覧ください：Flux for GitOpsのセットアップ

GitLab CI/CDワークフロー

CI/CDワークフローで

  • GitLab CI/CDがKubernetes APIを使用してクラスターをクエリし更新するように設定します。

GitLabはGitLab CI/CDからのリクエストをクラスターにプッシュするので、このワークフローはプッシュベースと考えられます。

このワークフローを使います：

  • パイプライン指向のプロセスが多い場合。
  • エージェントにマイグレーションする必要があるが、GitOps ワークフローでは必要なユースケースをサポートできない場合。

このワークフローはセキュリティ・モデルが弱く、本番デプロイにはお勧めできません。

GitLabの機能でサポートされているKubernetesのバージョン

GitLabは以下のKubernetesバージョンをサポートしています。KubernetesクラスターでGitLabを実行したい場合は、別のバージョンのKubernetesが必要な場合があります：

Kubernetesのバージョンはいつでもサポートされているバージョンにアップグレードできます：

  • 1.27 (サポートは2024年7月22日または1.30がサポートされるようになった時点で終了します)
  • 1.26（2024年3月22日または1.29がサポートされるようになった時点でサポート終了）
  • 1.25（サポート終了は2023年10月22日または1.28サポート開始時）

GitLabは、Kubernetesの新しいマイナーバージョンを最初のリリースから3ヶ月後にサポートすることを目指しています。GitLabは、いつでも少なくとも3つの本番稼働可能なKubernetesマイナーバージョンをサポートしています。

エージェントをインストールする際は、Kubernetesのバージョンと互換性のあるHelmバージョンを使用してください。他のバージョンのHelmは動作しない可能性があります。互換性のあるバージョンのリストについては、Helmのバージョンサポートポリシーを参照してください。

非推奨APIのサポートは、非推奨APIのみをサポートするKubernetesバージョンのサポートを終了した時点で、GitLabコードベースから削除される可能性があります。

GitLabのいくつかの機能は、ここに記載されていないバージョンでも動作するかもしれません。このエピックはKubernetesバージョンのサポートを追跡します。

レガシー証明書ベースのインテグレーションからエージェントへのマイグレーション

証明書ベースのインテグレーションからKubernetes用エージェントにマイグレーションする方法についてお読みください。

エージェント接続

エージェントは通信のために KAS に双方向チャネルを開きます。このチャネルはエージェントと KAS 間のすべての通信に使用されます：

  • 各エージェントは、アクティビティストリームとアイドルストリームを含め、最大500の論理gRPCストリームをメンテナーすることができます。
  • gRPCストリームが使用するTCP接続の数は、gRPC自身が決定します。
  • 各接続の最大寿命は2時間で、1時間の猶予期間があります。
    • KASの前のプロキシが接続の最大有効時間に影響を与えるかもしれません。GitLab.comでは2時間です。猶予期間は最大有効期間の50%です。

チャネルルーティングの詳細については、エージェントのKASリクエストのルーティングを参照してください。