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. The development, release, and timing of any products, features, or functionality may be subject to change or delay and 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은 직접 또는 간접적으로 Kubernetes의 API 엔드포인트를 호출하여 통신합니다. 이는 GitLab과 클러스터 간에 네트워크 경로가 있는 경우에는 잘 작동하지만 항상 그렇지는 않습니다.

GitLab.com과 Self-Managed형 클러스터, 클러스터가 인터넷에 노출되지 않는 경우
GitLab.com과 클라우드 공급업체에서 관리하는 클러스터, 클러스터가 인터넷에 노출되지 않는 경우
Self-Managed형 GitLab 및 클라우드 공급업체에서 관리하는 클러스터, 클러스터가 인터넷에 노출되지 않고 클라우드 네트워크와 고객 네트워크 간에 사설 피어링이 없는 경우

마지막 항목은 네트워크 경로를 생성하려면 어떤 것이 허용되어야 한다는 것이 가장 어려운 문제입니다. 이 기능은 기존 옵션(네트워크 피어링 또는 두 사이드 중 하나를 노출하는 것)에 추가하여 고객에게 추가 옵션(gitlab-kas 도메인을 노출시키지만 전체 GitLab은 노출시키지 않음)을 제공합니다.

기술적으로 가능하더라도 Kubernetes 클러스터의 API를 보안상의 이유로 인터넷에 노출하는 것은 거의 항상 바람직하지 않습니다. 결과적으로 고객은 그렇게 하기를 꺼려하고 연결된 클러스터에 대한 GitLab이 제공하는 기능과 보안 사이에서 선택을 해야 합니다.

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

클러스터 관리자 권한

현재의 통합인 고객 자체 클러스터(인증서 기반) 구축 및 클라우드에서 관리하는 GitLab 클러스터는 모두 GitLab에 대한 완전한 클러스터 관리자 액세스를 요구합니다. 자격 증명은 GitLab 측에 저장되며 이는 우리 고객들에게 또 다른 보안상의 고려사항이 됩니다.

이러한 문제에 대한 더 많은 논의는 이슈 #212810을 참조하세요.

GitLab 에이전트 epic

이러한 도전 과제를 해결하고 일부 새로운 기능을 제공하기 위해 구성 그룹은 클러스터 내 액티브한 컴포넌트인 에이전트를 구축 중입니다. 이를 통해 통신 방향이 역전됩니다:

고객은 자신들의 클러스터에 에이전트를 설치합니다.
에이전트는 GitLab.com이나 고객 Self-Managed형 GitLab 인스턴스에 연결하여 명령을받습니다.

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

자세한 정보는 GitLab 에이전트 리포지터리 또는 epic을 방문하세요.

요청 라우팅

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

기존 및 새로운 기능은 클러스터 및(선택적으로) 클러스터 내에서 실행되는 컴포넌트의 API에 대한 실시간 액세스를 필요로 합니다. 결과적으로 전통적인 폴링 접근 방식을 사용하여 정보를 왔다갔다하는 것이 어렵습니다.

실시간 필요성을 설명하는 좋은 예는 Prometheus 통합입니다. 실시간 그래프를 그리고 싶다면 빠르게 결과를 돌려받기 위해 Prometheus API에 직접 액세스해야 합니다. gitlab-kas는 GitLab에 Prometheus API를 노출하고 현재 올바른 에이전트 중 하나로 트래픽을 투명하게 라우팅할 수 있습니다. 그런 다음 에이전트는 요청을 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

반복

반복 작업은 전용 에픽에서 추적됩니다.