GitLab Relay (KAS) 설치

GitLab Relay (KAS)를 관리합니다.

GitLab Relay (KAS)는 GitLab과 함께 설치되는 컴포넌트입니다. GitLab과 외부 시스템 사이의 양방향 gRPC 통신을 중계하는 중앙 통신 릴레이 역할을 하며, 대상 시스템은 다음과 같습니다: 러너: Job Router 와 Runner Controllers 를 사용하려면 필요합니다. Kubernetes 클러스터: Kubernetes용 에이전트 를 사용하려면 필요합니다. KAS는 이전에 Kubernetes Agent Server로 불렸습니다. Kubernetes를 넘어 확장된 역할을 반영하기 위해 이름이 변경되었습니다. GitLab Relay (KAS)는 GitLab.com에 설치되어 grpcs://kas.gitlab.com 에서 사용할 수 있습니다. WebSocket 주소 wss://kas.gitlab.com 도 사용할 수 있습니다. GitLab Self-Managed를 사용하는 경우 기본적으로 GitLab Relay (KAS)가 설치되어 사용할 수 있습니다. 설치 옵션 # GitLab 관리자는 GitLab Relay (KAS) 설치를 다음과 같이 제어할 수 있습니다: Linux 패키지 설치 의 경우. GitLab Helm 차트 설치 의 경우. Linux 패키지 설치의 경우 # 히스토리 GitLab 호스트의 KAS로 가는 네이티브 gRPC 라우팅이 GitLab 18.7에서 추가되었습니다 . 기본 에이전트 주소가 GitLab 19.5에서 ws://gitlab.example.com/-/kubernetes-agent/ 또는 wss://gitlab.example.com/-/kubernetes-agent/ 에서 grpcs://gitlab.example.com 으로 변경되었습니다 . Linux 패키지 설치의 GitLab Relay (KAS)는 단일 노드에서 활성화할 수도 있고 여러 노드에서 한 번에 활성화할 수도 있습니다. 기본적으로 GitLab Relay (KAS)는 활성화되어 있습니다. external_url 이 상대 URL 루트 없이 HTTPS를 사용하고 번들 NGINX가 HTTP/2로 TLS를 종료하면 에이전트는 grpcs://gitlab.example.com 에서 KAS에 연결합니다. 그 외의 경우, 예를 들어 TLS가 로드 밸런서에서 종료되는 경우 에는 에이전트가 wss://gitlab.example.com/-/kubernetes-agent/ 또는 ws://gitlab.example.com/-/kubernetes-agent/ 에서 WebSocket으로 연결합니다. 두 경우 모두 WebSocket을 계속 사용할 수 있습니다. 단일 노드에서 비활성화 # 단일 노드에서 GitLab Relay (KAS)를 비활성화하려면 다음 단계를 따릅니다. /etc/gitlab/gitlab.rb 를 편집합니다: gitlab_kas[ 'enable' ] = false GitLab을 재구성 합니다. 여러 노드에서 KAS 활성화 # KAS 인스턴스는 잘 알려진 위치의 Redis에 자신의 사설 주소를 등록해 서로 통신합니다. 각 KAS는 다른 인스