This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Status	Authors	Coach	DRIs	Owning Stage	Created
implemented	`@ash2k`	`@andrewn`	`@nicholasklick` `@nagyv-gitlab`	devops configure	2020-12-03

GitLabからKubernetesへの通信

このドキュメントのゴールは、GitLabエージェントを通してGitLabがKubernetesやクラスター内サービスとどのように通信できるかを定義することです。

課題

ネットワーク接続の欠如

現在存在する様々な機能において、GitLabはKubernetesのAPIエンドポイントを直接または間接的に呼び出すことでKubernetesと通信します。これは、GitLabからクラスターへのネットワークパスが存在する限り、うまく機能します：

GitLab.comとセルフマネージドクラスターは、クラスターがインターネットに公開されていません。
GitLab.comと、クラスターがインターネットに公開されていないクラウドベンダーのマネージドクラスター。
セルフマネージドGitLabとクラウドベンダーのマネージドクラスター。クラスターがインターネットに公開されておらず、クラウドネットワークと顧客のネットワークの間に非公開ピアリングがない場合。
この最後の項目は最もアドレスが難しいもので、ネットワーク経路を作るためには何かを与えなければなりません。この機能は、既存のオプション（ネットワークのピアリング、もしくはどちらか一方を公開する）に加えて、顧客に追加のオプション（gitlab-kas ドメインを公開するが GitLab 全体は公開しない）を提供します。

技術的に可能であっても、セキュリティ上の理由からKubernetesクラスターのAPIをインターネットに公開することはほとんどの場合望ましくありません。その結果、私たちの顧客はそうすることに消極的で、セキュリティとGitLabが接続されたクラスタのために提供する機能の選択に迫られています。

この選択はKubernetesのAPIだけでなく、顧客のクラスターで稼働しているサービスによって公開され、GitLabがアクセスする必要があるすべてのAPIに当てはまります。例えば、クラスターで稼働しているPrometheusは、GitLabインテグレーションがアクセスするために公開する必要があります。

クラスター管理権限

現在のインテグレーション（証明書ベースのクラスター構築とクラウド上のGitLab管理クラスター）はどちらも、GitLabに完全なcluster-admin アクセスを許可する必要があります。認証情報はGitLab側に保存されるため、これはまた別のセキュリティ上の懸念となります。

これらの問題の詳細については、イシュー#212810をお読みください。

GitLab エージェントエピック

これらの課題にアドレスし、いくつかの新機能を提供するために、Configureグループは通信の方向を反転させるアクティブなクラスタ内コンポーネントを構築しています：

顧客はエージェントをクラスターにインストールします。
エージェントはGitLab.comや自分で管理するGitLabインスタンスに接続し、そこからコマンドを受け取ります。

顧客はGitLabに認証情報を提供する必要はなく、エージェントが持つ権限を完全にコントロールすることができます。

詳細については、GitLabエージェントのリポジトリまたはエピックをご覧ください。

リクエストルーティング

エージェントはGitLabエージェントサーバ(gitlab-kas)と呼ばれるサーバ側のコンポーネントに接続し、コマンドを待つオープンな接続を維持します。このアプローチで難しいのは、GitLabからのリクエストを適切なエージェントにルーティングすることです。各クラスターには複数の論理エージェントが含まれ、それぞれが複数のレプリカ(Pods)として実行され、任意のgitlab-kas インスタンスに接続されている可能性があります。

既存の機能や新しい機能には、クラスターのAPIや、（オプションとして）クラスターで動作するコンポーネントのAPIにリアルタイムでアクセスする必要があります。そのため、従来のポーリング・アプローチで情報をやり取りするのは困難です。

リアルタイムの必要性を示す良い例がPrometheusインテグレーションです。もしリアルタイムのグラフを描きたいのであれば、クエリを発行して素早く結果を返すために Prometheus API に直接アクセスする必要があります。gitlab-kas は Prometheus API を GitLab に公開し、その時点で接続されている適切なエージェントの一つに透過的にトラフィックをルーティングすることができます。エージェントはリクエストをPrometheusに流し、レスポンスを返します。

提案

gitlab-kas でリクエストルーティングを実装します。Kubernetesとエージェントを操作するためのクリーンなAPIを提供することで、メインアプリケーションから関連するすべての複雑さをカプセル化して隠します。

上記は必ずしもKubernetesのAPIを直接プロキシすることを意味しませんが、必要であれば可能です。

gitlab-kas どのようなAPIを提供するかは開発者次第ですが、まずはリクエストルーティングの問題を解決しなければなりません。エージェント、Kubernetes、クラスター内サービスとの直接通信を必要とするあらゆる機能をブロックします。

全ての技術的詳細を含む詳細な実装案はkas_request_routing.md にあります。

flowchart LR subgraph "Kubernetes 1" agentk1p1["agentk 1, Pod1"] agentk1p2["agentk 1, Pod2"] end subgraph "Kubernetes 2" agentk2p1["agentk 2, Pod1"] end subgraph "Kubernetes 3" agentk3p1["agentk 3, Pod1"] end subgraph kas kas1["kas 1"] kas2["kas 2"] kas3["kas 3"] end GitLab["GitLab Rails"] Redis GitLab -- "gRPC to any kas" --> kas kas1 -- register connected agents --> Redis kas2 -- register connected agents --> Redis kas1 -- lookup agent --> Redis agentk1p1 -- "gRPC" --> kas1 agentk1p2 -- "gRPC" --> kas2 agentk2p1 -- "gRPC" --> kas1 agentk3p1 -- "gRPC" --> kas2

イテレーション

イテレーションは専用のエピックで追跡されます。