• 요약
• 동기
  • 목표
  • 비목표
• 제안
  • 개요
  • 기존 컴포넌트 및 관계
  • 문제점
  • 예시
  • 추가 세부 정보
    • 다중 프로젝트 배포 파이프라인
• 디자인 및 구현 세부 정보
  • 에이전트와 환경 연결
  • user_access를 통한 리소스 가져오기
  • 의존성 그래프
  • 리소스의 상태

GitLab 에이전트를 통해 배포된 리소스 보기 및 관리

요약

GitLab Kubernetes 대시보드 epic의 일환으로, 사용자들은 GitLab 에이전트를 통해 배포된 리소스를 볼 수 있으며 관리하고 싶어합니다. 사용자들은 환경 인덱스/상세 페이지와 같은 GitLab UI를 통해 해당 리소스와 상호작용할 수 있어야 합니다.

이 청사진은 어떻게 이 연관성이 설정되고, 이 도메인 모델들이 서로 상호작용하는지에 대해 설명합니다.

동기

목표

• 제안된 아키텍처는 GitLab Kubernetes 대시보드에서 사용될 수 있어야 합니다.
• 제안된 아키텍처는 조직 수준 환경 대시보드에서 사용될 수 있어야 합니다.
• 클러스터 리소스 및 이벤트는 GitLab 환경당 시각화될 수 있어야 합니다. 배포 커밋에 의해 직접적 또는 간접적으로 관리되는 리소스를 위한 환경별 뷰.
• GitOps 모드 및 CI Access 모드 모두 지원

비목표

• GitLab Kubernetes 대시보드 및 조직 수준 환경 대시보드의 디자인 세부사항
• GitLab CI/CD 파이프라인에 의존하는 환경/배포 기능 지원: 보호된 환경, 배포 승인, 배포 안전성 및 환경 롤백. 이러한 기능들은 CI Access 모드에서 이미 사용 가능하지만, GitOps 모드에서는 사용 불가능합니다.

제안

개요

• GitLab 환경과 GitLab 에이전트 간에 1:1 관계가 있습니다.
• GitLab 환경은 연결된 에이전트에 의해 생성된 모든 리소스를 추적합니다. 이는 매니패스트 파일에 작성된 리소스뿐만 아니라 나중에 생성된 리소스(예: 배포 매니페스트 파일에 의해 생성된 Pod)도 포함됩니다.
• GitLab 환경은 배포 => 복제본 세트 => Pod와 같은 의존성 그래프를 렌더링합니다. 이는 ArgoCD 스타일의 리소스 뷰를 제공하기 위함입니다.
• GitLab 환경에는 건강한, 진행 중, 또는 저하된과 같은 리소스 상태의 요약을 나타내는 리소스 상태가 있습니다.

기존 컴포넌트 및 관계

• GitLab 프로젝트 및 GitLab 환경은 1:N 관계가 있습니다.
• GitLab 프로젝트와 에이전트는 1:N 직접 관계가 있습니다. 특정 에이전트를 소유할 수 있는 프로젝트는 하나뿐입니다.
• GitOps 모드
  • GitLab 프로젝트와 에이전트는 아직 많대많 간접 관계를 가지지 않습니다. 이는 에이전트 구성 프로젝트 외의 Manifest 프로젝트에서 지원될 것입니다.
• CI Access 모드
  • GitLab 프로젝트와 에이전트는 많대많 간접 관계를 가지고 있습니다. 에이전트를 소유한 프로젝트는 그룹 내의 프로젝트에 액세스 권한을 공유할 수 있습니다. (참고: 기술적으로는 프로젝트 내에서 실행되는 작업만 작업 토큰 인증에 의해 클러스터에 액세스할 수 있습니다.)

문제점

• GitLab 환경은 GitLab 에이전트 For Kubernetes의 ID를 외래 키로 가져야 합니다.
• GitLab 환경은 연결된 클러스터에 속하는 리소스를 그룹화하는 방법을 정의해야 합니다. 예를 들어, namespace, label, 그리고 inventory-id (GitOps 모드에서만)가 매개변수로 전달될 수 있어야 합니다.
• GitLab 환경은 연관 리소스를 모두 가져올 수 있어야 합니다. 이에는 기본 리소스 종류뿐만 아니라 다른 사용자 정의 리소스도 포함됩니다.
• GitLab 환경은 의존성 그래프를 이해할 수 있어야 합니다.
• GitLab 환경은 연관 리소스에서 리소스 상태를 계산할 수 있어야 합니다.

예시

이는 푸시 기반 배포에서 아키텍처가 동작하는 예시입니다. 이 기능은 여기에 CI Access 모드로 문서화되어 있습니다.

추가 세부 정보

다중 프로젝트 배포 파이프라인

multi-project 배포 파이프라인을 통해 마이크로서비스 프로젝트 설정을 개선할 수 있습니다:

• 배포 프로젝트는 상위 응용 프로그램 프로젝트 및 환경을위한 공유 배포 엔진으로 작동할 수 있습니다.
• 응용 프로그램 프로젝트 내에서 환경을 생성할 수 있습니다. 이는 개발자에게 환경의 더 많은 가시성을 제공합니다.
• 배포 프로젝트는 Operator 그룹에서 관리할 수 있습니다. 근무의 분리가 가능합니다.
• 사용자는 RBAC를 설정하지 않아도 CI/CD 작업을 제한할 필요가 없습니다.
• 이는 리뷰 앱과 같은 동적 환경에 특히 유용합니다.

디자인 및 구현 세부 정보

에이전트와 환경 연결

사용자는 설정 UI에서 명시적으로 Kubernetes에 대한 GitLab 에이전트를 GitLab 환경에 지정할 수 있습니다. Frontend는 이러한 연관된 에이전트를 사용하여 사용자 액세스를 인증/권한 부여 할 것입니다. 이에 관한 설명은 이후 섹션에서 설명됩니다.

우리는 DeclarivePolicy에서 외부 프로젝트(에이전트 관리 프로젝트라고도 함)에 의해 공유되는 에이전트를 지원하기 위해 read_cluster_agent 권한을 조정해야 합니다.

user_access를 통한 리소스 가져오기

사용자가 환경 페이지를 방문할 때, GitLab Frontend는 GraphQL을 통해 환경을 가져옵니다. Frontend는 추가로 연관된 에이전트 ID 및 네임스페이스를 가져옵니다.

다음은 GraphQL 쿼리의 예시입니다:

{
  project(fullPath: "group/project") {
    id
    environment(name: "<environment-name>") {
      slug
      kubernetesNamespace
      clusterAgent {
        id
        name
        project {
          name
        }
      }
    }
  }
}

GitLab Frontend는 브라우저 쿠키로 사용자 액세스를 인증/권한 부여합니다. 액세스가 금지된 경우 Frontend는 “이 환경에 배포 한 에이전트에 액세스 권한이 없습니다. “user_access”에서 허용되는 경우 에이전트 관리자에게 문의하십시오. <해결 방법="" 문서="" 링크="">를 참조하십시오"라는 오류 메시지를 표시합니다.해결>

사용자가 에이전트에 액세스 권한을 획들한 후, GitLab Frontend는 쿠버네티스의 특정 리소스 유형(예: Deployment, Pod)을 다음과 같은 매개변수로 가져옵니다:

• namespace … #{environment.kubernetesNamespace}

리소스가 없는 경우, 사용자가 이러한 label을 자원에 포함시키지 않았을 가능성이 높습니다. 이 경우 Frontend는 “환경에 대한 리소스를 찾을 수 없습니다. 리소스에 GitLab 보존 레이블이 있는지 확인하십시오. <해결 방법="" 문서="" 링크="">를 참조하십시오"라는 경고 메시지를 표시합니다.해결>

의존성 그래프

• GitLab Frontend는 리소스 간의 의존성을 식별하기 위해 Owner References를 사용합니다. 이것들은 metadata.ownerReferences 필드에 리소스에 포함됩니다.
• 소유자 참조가 없는 리소스의 경우, Well-Known Labels, Annotations and Taints를 보완하여 사용할 수 있습니다. 예를 들어 EndpointSlice는 metadata.ownerReferences를 가지고 있지 않지만 부모 Service 리소스를 참조하는 kubernetes.io/service-name를 사용할 수 있습니다.

리소스의 상태

• GitLab Frontend는 가져온 리소스에서 상태 요약을 계산합니다. 예를 들어 ArgoCD의 리소스 상태와 유사하게 정상, 진행 중, 장애, 중지됨 등이 있을 수 있습니다. 이 공식은 아직 결정되지 않았습니다.