Kubernetesクラスター

クラスターをGitLabに接続するには、Kubernetes向けGitLabエージェントを使用します。

証明書ベースのKubernetesインテグレーション（非推奨）

GitLabとの証明書ベースのKubernetesインテグレーションは非推奨です。これには次の問題がありました:

• GitLabによるKubernetes APIへの直接アクセスが必要なため、セキュリティ上の問題がありました。
• 設定オプションに柔軟性がありませんでした。
• インテグレーションがFlakyでした。
• ユーザーは、このモデルに基づく機能に関する問題を常に報告していました。

このため、新しいモデルであるKubernetes向けGitLabエージェントに基づく機能の構築を開始しました。両方の方法を並行して維持すると、多くの混乱が生じ、使用、開発、維持、およびドキュメント化が著しく複雑になりました。このため、新しいモデルに注力するために、それらを非推奨にすることにしました。

証明書ベースの機能は、セキュリティと重大な修正を引き続き受け取り、その上に構築された機能は、サポートされているKubernetesバージョンで引き続き動作します。GitLabからのこれらの機能の削除はまだスケジュールされていません。更新については、このepicに従ってください。

Kubernetes用GitLabエージェントへの移行により多くの時間が必要な場合は、certificate_based_clustersという名前の機能フラグを有効にすることができます。これはGitLab 15.0で導入されました。この機能フラグは、証明書ベースのKubernetesインテグレーションを再度有効にします。

非推奨機能

• クラスター証明書を介して既存のクラスターを接続
• アクセス制御
• GitLab管理対象クラスター
• 証明書ベースの接続を介してアプリケーションをデプロイ
• クラスター管理プロジェクト
• クラスター環境
• デプロイボードにカナリアIngressデプロイを表示
• デプロイボード
• Webターミナル

クラスターレベル

プロジェクトレベル 、グループレベル 、およびインスタンスレベルクラスターの概念は、機能はいくらか残っていますが、新しいモデルでは廃止されます。

エージェントは常に単一のGitLabプロジェクトで設定され、他のプロジェクトやグループにクラスター接続を公開してGitLab CI/CDからアクセスできます。そうすることで、これらのプロジェクトとグループに同じクラスターへのアクセス権を付与することになり、これはグループレベルクラスターのユースケースと同様です。