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이 Kubernetes 및 클러스터 내 서비스와 어떻게 통신할 수 있는지를 정의하는 것입니다 GitLab 에이전트를 통해.

도전 과제

네트워크 연결 부재

오늘날 존재하는 다양한 기능을 위해 GitLab은 직접이나 간접적으로 Kubernetes의 API 엔드포인트를 호출하여 통신합니다. 이는 GitLab에서 클러스터로의 네트워크 경로가 항상 존재하는 경우에는 잘 작동하지만 항상 그렇지는 않습니다.

GitLab.com 및 자체 관리 클러스터의 경우 클러스터가 인터넷에 노출되어 있지 않을 수 있습니다.
GitLab.com 및 클라우드 공급 업체의 관리 클러스터의 경우 클러스터가 인터넷에 노출되어 있지 않을 수 있습니다.
자체 관리 GitLab 및 클라우드 공급 업체의 관리 클러스터의 경우 클러스터가 인터넷에 노출되어 있지 않을 수 있으며 클라우드 네트워크와 고객 네트워크 간의 사설 피어링이 없을 수 있습니다.
마지막 항목이 가장 해결하기 어려운 문제로서 네트워크 경로를 만들기 위해 어떤 것이 희생되어야 합니다. 이 기능은 고객에게 기존 옵션(네트워크 피어링, 두 쪽 중 하나 노출)에 추가하여 고객에게 추가 옵션(gitlab-kas 도메인을 노출하지만 전체 GitLab은 노출하지 않음)을 제공합니다.

기술적으로 가능하더라도 보안상의 이유로 Kubernetes 클러스터의 API를 인터넷에 노출하는 것은 거의 항상 바람직하지 않습니다. 결과적으로 고객은 이를 원치 않으며, 연결된 클러스터에 대한 GitLab에서 제공하는 기능에 대한 안전 대 비보안 선택을 직면하게 됩니다.

이 선택은 Kubernetes의 API뿐만 아니라 GitLab이 액세스해야 할 고객 클러스터에서 실행되는 서비스들이 노출된 모든 API에도 동일합니다. 예를 들어, 클러스터에서 실행 중인 Prometheus는 GitLab 통합이 액세스하기 위해 노출되어야 합니다.

클러스터 관리자 권한

현재의 통합 - 자체 클러스터 빌드(인증서 기반) 및 클라우드에서 관리되는 GitLab 클러스터 - 모두 GitLab에게 전체 cluster-admin 액세스 권한을 부여해야 합니다. 자격 증명은 GitLab 측에 저장되며 이는 고객들에게 또 다른 보안 관련 문제입니다.

이러한 문제에 대한 자세한 논의는 다음을 참조하세요 issue #212810.

GitLab 에이전트 Epic(위대한)

이러한 도전 과제를 해결하고 새로운 기능을 제공하기 위해, Configure 그룹은 클러스터 내에서 활성화된 인클러스터 구성 요소를 구축 중입니다. 이 요소는 통신 방향을 반전시키는 역할을 합니다.

고객이 자체 클러스터에 에이전트를 설치합니다.
에이전트는 GitLab.com 또는 자체 관리 GitLab 인스턴스에 연결하여 명령을 받습니다.

고객은 GitLab에 어떤 자격 증명도 제공할 필요가 없으며, 에이전트가 가지는 권한을 완전히 제어할 수 있습니다.

자세한 정보는 방문하여 GitLab 에이전트 저장소 또는 에픽을 참조하세요.

요청 라우팅

에이전트는 GitLab 에이전트 서버(gitlab-kas)라고 불리는 서버측 구성 요소에 연결하고 명령을 기다리는 열린 연결을 유지합니다. 이 방식의 어려움은 GitLab에서 올바른 에이전트로 요청을 라우팅하는 데 있습니다. 각 클러스터에는 여러 논리적 에이전트가 있을 수 있으며, 각각은 여러 복제본(Pod)으로 실행될 수 있으며 임의의 gitlab-kas 인스턴스에 연결될 수 있습니다.

기존 및 새로운 기능은 클러스터의 API 및 (옵션) 클러스터 내에서 실행되는 구성 요소들의 API에 대한 실시간 액세스를 요구합니다. 결과적으로 보다 전통적인 폴링 접근 방식을 사용하여 정보를 수신 및 발신하는 것이 어려워집니다.

실시간 필요성을 설명하기 위한 좋은 예는 Prometheus 통합입니다. 우리가 실시간 그래프를 그리고 싶다면, 빠르게 결과를 반환하기 위해 Prometheus API에 직접 액세스해야 합니다. gitlab-kas는 Prometheus API를 GitLab에 노출하고 현재 연결된 올바른 에이전트로 트래픽을 투명하게 라우팅할 수 있습니다. 그런 다음, 에이전트가 Prometheus로 요청을 스트리밍하고 응답을 다시 스트리밍합니다.

제안

gitlab-kas에서 요청 라우팅을 구현합니다. 쿠버네티스와 에이전트와 작업하기 위한 깨끗한 API를 제공함으로써 관련 복잡성을 캡슐화하고 숨깁니다.

위의 내용은 반드시 Kubernetes의 API를 직접 프록시하는 것을 의미하는 것은 아니지만 필요한 경우 가능합니다.

gitlab-kas가 제공하는 API는 개발된 기능에 따라 다르지만 먼저 요청 라우팅 문제를 해결해야 합니다. 에이전트, Kubernetes 또는 클러스터 내 서비스와 직접 통신을 필요로하는 모든 기능을 차단합니다.

모든 기술적 세부 정보와 함께 상세한 구현 제안은 kas_request_routing.md에 있습니다.

flowchart LR subgraph "Kubernetes 1" agentk1p1["에이전트k 1, Pod1"] agentk1p2["에이전트k 1, Pod2"] end subgraph "Kubernetes 2" agentk2p1["에이전트k 2, Pod1"] end subgraph "Kubernetes 3" agentk3p1["에이전트k 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

이터레이션

이터레이션은 전용 에픽에서 추적됩니다.