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 및 클라우드 공급업체 관리 클러스터: 클러스터가 인터넷에 노출되지 않고 클라우드 네트워크와 고객 네트워크 간의 개인 피어링이 없는 경우
마지막으로 언급된 항목은 네트워크 경로를 만들기 위해 어떤 것이 헌트되어야 한다는 점에서 가장 어려운 문제입니다. 이 기능은 기존 옵션들(네트워크 피어링 또는 두 가지 중 하나를 노출시키는 것)에 추가로(customer에게 ‘gitlab-kas’ 도메인을 노출시키지만 GitLab 전체를 노출시키지는 않음) 고객에게 추가 옵션을 제공합니다.

기술적으로 가능하더라도 보안상의 이유로 거의 항상 Kubernetes 클러스터 API를 인터넷에 노출하는 것은 바람직하지 않습니다. 따라서 우리의 고객들은 이를 하기를 꺼리며 연결된 클러스터를 위해 GitLab이 제공하는 기능 대비 보안 선택 사항을 직면하고 있습니다.

이 결정은 Kubernetes의 API뿐만 아니라 GitLab이 액세스해야 하는 고객 클러스터에서 실행 중인 서비스들에 의해 노출된 모든 API에 대해 옳습니다. 예를 들어 클러스터에서 실행 중인 Prometheus는 GitLab 통합이 액세스하기 위해 노출되어야 합니다.

클러스터 관리자 권한

현재 사용 가능한 통합(인증서 기반으로 직접 클러스터 구축 및 GitLab에서 관리하는 클라우드 클러스터)은 모두 GitLab에 대한 전체 cluster-admin 액세스 권한 부여를 요구합니다. 자격 증명은 GitLab 측에 저장되며, 이것은 우리의 고객들에게 또 다른 보안 관련 우려 사항입니다.

이러한 문제에 대한 자세한 논의에 대해서는 이슈 #212810을 읽어보세요.

GitLab 에이전트 이픽

이러한 과제들을 해결하고 새로운 기능을 제공하기 위해 구성 그룹은 클러스터에 액티브한 인클러스터 컴포넌트를 구축 중입니다. 이 요소는 통신의 방향을 반전시키는 것입니다:

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

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

더 많은 정보를 원하시면 GitLab 에이전트 리포지터리 또는 이 이픽을 방문하세요.

요청 라우팅

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

기존 및 새로운 기능은 클러스터의 API 및(선택적으로) 클러스터 내에서 실행 중인 컴포넌트들의 API에 대한 실시간 액세스를 요구합니다. 결과적으로, 보다 전통적인 폴링 방식을 사용하여 정보를 왕래시키는 것은 어려워집니다.

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

제안

gitlab-kas에서 요청 라우팅을 구현합니다. 모든 기술적 세부 사항을 제공하여 주요 응용 프로그램에서 모든 관련 복잡성을 캡슐화하고 숨깁니다.

위와 같은 것은 반드시 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

반복

반복 사항은 특별한 이픽에서 추적됩니다.