Kubernetesクラスタ
クラスターをGitLabに接続するには、GitLabエージェントを使います。
証明書ベースのKubernetesインテグレーション（非推奨）
GitLabとの証明書ベースのKubernetesインテグレーションは非推奨となります。以下のイシューがありました：
- GitLabがKubernetes APIに直接アクセスする必要があったため、セキュリティ上の問題がありました。
- 設定オプションが柔軟ではありませんでした。
- インテグレーションが不安定。
- ユーザーは、このモデルに基づく機能のイシューを常に報告していました。
このため、私たちはGitLab エージェントという新しいモデルに基づいて機能を作り始めました。両方のメソッドを並行してメンテナーすることは多くの混乱を引き起こし、使用、開発、保守、文書化の複雑さを著しく増大させました。このため、私たちは新しいモデルに集中するために、これらの方法を非推奨とすることにしました。
証明書ベースの機能は引き続きセキュリティとクリティカルな修正を受け、その上に構築された機能はサポートされているKubernetesのバージョンで引き続き動作します。GitLabからこれらの機能が削除される予定はまだありません。アップデートについてはこのエピックに従ってください。
クラスター証明書からGitLabエージェントモデルに移行した理由についての技術的な情報は、エージェントのブループリントのドキュメントに記載されています。
GitLabエージェントへのマイグレーションに時間が必要な場合は、GitLab 15.0で導入されたcertificate_based_clustersという機能フラグを有効にすることができます。この機能フラグは、証明書ベースのKubernetesインテグレーションを再有効化します。
非推奨機能
- クラスター証明書による既存クラスターの接続
- アクセス制御
- GitLab が管理するクラスター
- 証明書ベースの接続によるアプリケーションのデプロイ
- クラスター管理プロジェクト
- クラスターのインテグレーション
- クラスターのコスト管理
- クラスター環境
- デプロイボードにCanary Ingressのデプロイを表示
- デプロイボード
- クラスターの健全性
- ウェブ端末
クラスターのレベル
新しいモデルでは、プロジェクトレベル、グループレベル、インスタンスレベルのクラスターの概念はなくなりますが、機能はある程度残ります。
エージェントは常に単一のGitLabプロジェクトに設定され、GitLab CI/CDからアクセスするために他のプロジェクトやグループにクラスター接続を公開することができます。そうすることで、これらのプロジェクトやグループに同じクラスターへのアクセスを許可することになり、グループレベルクラスターのユースケースに似ています。