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.35 (GitLabバージョン19.10がリリースされるか、1.38がサポート対象になるまでサポートされます)
• 1.34 (GitLabバージョン19.7がリリースされるか、1.37がサポート対象になるまでサポートされます)
• 1.33（GitLabバージョン19.2のリリース時、または1.36がサポートされるようになったときにサポートが終了）

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

新しいKubernetesのバージョンがリリースされると:

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

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

非推奨のAPIのサポートは、GitLabが非推奨のAPIのみをサポートするKubernetesバージョンをサポートしなくなった場合に、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からクラスターにリクエストをプッシュするため、このワークフローはプッシュベースと見なされます。

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

• パイプライン駆動型のプロセスがある場合。
• エージェントに移行する必要があるが、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
• エージェントの開発にコントリビュートする