KubernetesクラスターをGitLabに接続する

KubernetesクラスターをGitLabに接続して、クラウドネイティブソリューションをデプロイ、管理、およびMonitorできます。

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

エージェントはクラスター内で実行され、これを使用して次のことができます:

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

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

GitLabに接続するすべてのクラスターに、個別のエージェントをデプロイする必要があります。エージェントは、強力なマルチテナンシーサポートを念頭に置いてデザインされました。メンテナンスとオペレーションを簡素化するために、クラスターごとに1つのエージェントのみを実行する必要があります。

エージェントは常にGitLabプロジェクトに登録されます。エージェントが登録およびインストールされると、クラスターへのエージェント接続は、他のプロジェクト、グループ、およびユーザーと共有できます。このアプローチは、GitLab自体からエージェントインスタンスを管理および設定できること、および単一のインストールを複数のテナントにスケールできることを意味します。

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

GitLabは、次のKubernetesバージョンをサポートしています。KubernetesクラスターでGitLabを実行する場合は、異なるバージョンのKubernetesが必要になる場合があります:

• Helm Chartの場合。
• GitLab Operatorの場合。

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

• 1.33（GitLabバージョン19.2のリリース時、または1.36がサポートされるようになったときにサポートが終了）
• 1.32（GitLabバージョン18.10のリリース時、または1.35がサポートされるようになったときにサポートが終了）
• 1.31（GitLabバージョン18.7のリリース時、または1.34がサポートされるようになったときにサポートが終了）

GitLabは、新しいマイナーKubernetesバージョンの初期リリース後、3か月以内にサポートすることを目指しています。GitLabは、常に少なくとも3つの本番環境対応のKubernetesマイナーバージョンをサポートしています。

新しいバージョンのKubernetesがリリースされると、以下を行います:

• 約4週間以内に、初期スモークテストの結果をこのページで更新します。
• 新しいバージョンサポートのリリースが遅れることが予想される場合は、約8週間以内に、このページで予想されるGitLabサポートバージョンを更新します。

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

非推奨のAPIのサポートのみを行うKubernetesバージョンのサポートを終了すると、非推奨のAPIのサポートをGitLabコードベースから削除できます。

一部のGitLab機能は、ここにリストされていないバージョンでも動作する可能性があります。このエピックでは、Kubernetesバージョンのサポートを追跡します。

Kubernetesのデプロイワークフロー

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

GitOpsワークフロー

GitLabでは、GitOpsにFluxを使用することをお勧めします。開始するには、チュートリアルを参照してください: GitOps用のFluxをセットアップします。

GitLab CI/CDワークフロー

CI/CDワークフローでは、Kubernetes APIを使用してクラスターをクエリおよび更新するようにGitLab CI/CDを設定します。

GitLab CI/CDからクラスターにリクエストをプッシュするため、このワークフローはpush-based（プッシュベース）と見なされます。

このワークフローは次の場合に使用します:

• パイプライン駆動型のプロセスがある場合。
• エージェントに移行する必要があるが、GitOpsワークフローがユースケースをサポートしていない場合。

このワークフローは、セキュリティーモデルが脆弱です。本番環境へのデプロイにはCI/CDワークフローを使用しないでください。

エージェントの接続に関する技術的な詳細

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

• 各エージェントは、アクティブストリームとアイドルストリームを含め、最大500の論理gRPCストリームを維持できます。
• gRPCストリームで使用されるTCP接続の数は、gRPC自体によって決定されます。
• 各接続の最大ライフタイムは2時間で、1時間の猶予期間があります。
  • KASの前にあるプロキシは、接続の最大ライフタイムに影響を与える可能性があります。GitLab.comでは、これは2時間です。猶予期間は、最大ライフタイムの50%です。

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

受信エージェント

受容エージェントを使用すると、GitLabはGitLabインスタンスへのネットワーク接続を確立できないものの、GitLabから接続できるKubernetesクラスターと統合できます。たとえば、これは次の場合に発生する可能性があります:

1. GitLabがプライベートネットワーク内またはファイアウォールの内側で実行されており、VPN経由でのみアクセスできる。
2. Kubernetesクラスターがクラウドプロバイダーによってホストされているが、インターネットに公開されているか、プライベートネットワークから到達可能である。

この機能が有効になっている場合、GitLabは提供されたURLを使用してエージェントに接続します。エージェントと受容エージェントを同時に使用できます。

Kubernetesインテグレーション用語集

この用語集では、GitLab Kubernetesインテグレーションに関連する用語の定義を提供します。

関連トピック

• GitOpsワークフロー
• GitOpsの例と学習資料
• GitLab CI/CDワークフロー
• エージェントをインストール
• エージェントの操作
• 従来の証明書ベースのインテグレーションからKubernetes用エージェントへの移行
• トラブルシューティング
• 本番環境に対応したGitOpsセットアップのためのガイド付き探索
• Kubernetesの例と学習資料のCI/CD
• エージェントの開発にコントリビュートする