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 @shinya.maeda @DylanGriffith @nagyv-gitlab @cbalane @hustewart @hfyngvason devops deploy 2022-11-23

GitLab 에이전트 For Kubernetes로 배포된 리소스 보기 및 관리하기

요약

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

이 설계안은 어떻게 연관이 설정되고 이러한 도메인 모델이 서로 상호 작용하는지에 대해 설명합니다.

동기

목표

비목표

제안

개요

  • GitLab 환경과 GitLab 에이전트 For Kubernetes는 1:1 관계를 갖습니다.
  • GitLab 환경은 연결된 에이전트에 의해 생성된 모든 자원을 추적합니다. 이는 매니페스트 파일에 작성된 자원 뿐만 아니라 이후 생성된 자원(예: Deployment 매니페스트 파일에 의해 생성된 Pod들)을 모두 포함합니다.
  • GitLab 환경은 Deployment => ReplicaSet => Pod와 같은 종속성 그래프를 렌더링합니다. 이는 ArgoCD 스타일의 자원 뷰를 제공하기 위함입니다.
  • GitLab 환경에는 건강한(Healthy), 진행 중(Progressing), 또는 저하(Degraded)와 같은 자원 상태의 요약인 Resource Health 상태가 있습니다.
flowchart LR subgraph Kubernetes["Kubernetes"] subgraph ResourceGroupProduction["Production"] direction LR ResourceGroupProductionService(["Service"]) ResourceGroupProductionDeployment(["Deployment"]) ResourceGroupProductionPod1(["Pod1"]) ResourceGroupProductionPod2(["Pod2"]) end subgraph ResourceGroupStaging["Staging"] direction LR ResourceGroupStagingService(["Service"]) ResourceGroupStagingDeployment(["Deployment"]) ResourceGroupStagingPod1(["Pod1"]) ResourceGroupStagingPod2(["Pod2"]) end end subgraph GitLab subgraph Organization subgraph Project environment1["production environment"] environment2["staging environment"] end end end environment1 --- ResourceGroupProduction environment2 --- ResourceGroupStaging ResourceGroupProductionService -.- ResourceGroupProductionDeployment ResourceGroupProductionDeployment -.- ResourceGroupProductionPod1 ResourceGroupProductionDeployment -.- ResourceGroupProductionPod2 ResourceGroupStagingService -.- ResourceGroupStagingDeployment ResourceGroupStagingDeployment -.- ResourceGroupStagingPod1 ResourceGroupStagingDeployment -.- ResourceGroupStagingPod2

기존 구성 요소 및 관계

  • GitLab 프로젝트와 GitLab 환경은 1:N 관계를 갖습니다.
  • GitLab 프로젝트와 에이전트는 1:N 직접 관계를 갖습니다. 특정 에이전트를 하나의 프로젝트만 소유할 수 있습니다.
  • GitOps 모드
  • CI Access 모드
    • GitLab 프로젝트와 에이전트는 많대많 간접 관계를 갖습니다. 에이전트를 소유한 프로젝트는 다른 프로젝트에서 액세스 권한을 공유할 수 있습니다. (참고: 기술적으로는 프로젝트 내에서 실행 중인 작업만이 작업 토큰 인증으로 인해 클러스터에 액세스할 수 있습니다.)

이슈

  • GitLab 환경은 Kubernetes를 위한 GitLab 에이전트의 ID를 외래 키로 가져야 합니다.
  • GitLab 환경은 연관된 클러스터에서 리소스를 그룹화하는 방법에 대한 매개변수를 가져야 합니다. 예를 들어 namespace, lableinventory-id (GitOps 모드 전용)는 매개변수로 전달될 수 있습니다.
  • GitLab 환경은 기본 리소스 유형뿐만 아니라 다른 사용자 정의 리소스를 포함한 모든 관련 리소스를 가져올 수 있어야 합니다.
  • GitLab 환경은 의존성 그래프를 인식해야 합니다.
  • GitLab 환경은 연관된 리소스로부터 리소스 헬스 상태를 계산할 수 있어야 합니다.

예제

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

flowchart LR subgraph ProductionKubernetes["Production Kubernetes"] subgraph ResourceGroupProductionFrontend["Production"] direction LR ResourceGroupProductionFrontendService(["Service"]) ResourceGroupProductionFrontendDeployment(["Deployment"]) ResourceGroupProductionFrontendPod1(["Pod1"]) ResourceGroupProductionFrontendPod2(["Pod2"]) end subgraph ResourceGroupProductionBackend["Staging"] direction LR ResourceGroupProductionBackendService(["Service"]) ResourceGroupProductionBackendDeployment(["Deployment"]) ResourceGroupProductionBackendPod1(["Pod1"]) ResourceGroupProductionBackendPod2(["Pod2"]) end subgraph ResourceGroupProductionPrometheus["Monitoring"] direction LR ResourceGroupProductionPrometheusService(["Service"]) ResourceGroupProductionPrometheusDeployment(["Deployment"]) ResourceGroupProductionPrometheusPod1(["Pod1"]) ResourceGroupProductionPrometheusPod2(["Pod2"]) end end subgraph GitLab subgraph Organization subgraph OperationGroup subgraph AgentManagementProject AgentManagementAgentProduction["Production agent"] AgentManagementManifestFiles["Kubernetes Manifest Files"] AgentManagementEnvironmentProductionPrometheus["production prometheus environment"] AgentManagementPipelines["CI/CD pipelines"] end end subgraph DevelopmentGroup subgraph FrontendAppProject FrontendAppCode["VueJS"] FrontendDockerfile["Dockerfile"] end subgraph BackendAppProject BackendAppCode["Golang"] BackendDockerfile["Dockerfile"] end subgraph DeploymentProject DeploymentManifestFiles["Kubernetes Manifest Files"] DeploymentPipelines["CI/CD pipelines"] DeploymentEnvironmentProductionFrontend["production frontend environment"] DeploymentEnvironmentProductionBackend["production backend environment"] end end end end DeploymentEnvironmentProductionFrontend --- ResourceGroupProductionFrontend DeploymentEnvironmentProductionBackend --- ResourceGroupProductionBackend AgentManagementEnvironmentProductionPrometheus --- ResourceGroupProductionPrometheus ResourceGroupProductionFrontendService -.- ResourceGroupProductionFrontendDeployment ResourceGroupProductionFrontendDeployment -.- ResourceGroupProductionFrontendPod1 ResourceGroupProductionFrontendDeployment -.- ResourceGroupProductionFrontendPod2 ResourceGroupProductionBackendService -.- ResourceGroupProductionBackendDeployment ResourceGroupProductionBackendDeployment -.- ResourceGroupProductionBackendPod1 ResourceGroupProductionBackendDeployment -.- ResourceGroupProductionBackendPod2 ResourceGroupProductionPrometheusService -.- ResourceGroupProductionPrometheusDeployment ResourceGroupProductionPrometheusDeployment -.- ResourceGroupProductionPrometheusPod1 ResourceGroupProductionPrometheusDeployment -.- ResourceGroupProductionPrometheusPod2 AgentManagementAgentProduction -- Shared with --- DeploymentProject DeploymentPipelines -- "Deploy" --> ResourceGroupProductionFrontend DeploymentPipelines -- "Deploy" --> ResourceGroupProductionBackend AgentManagementPipelines -- "Deploy" --> ResourceGroupProductionPrometheus

추가 세부 정보

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

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

  • 배포 프로젝트는 상류 응용 프로그램 프로젝트 및 환경에 대한 공유 배포 엔진 역할을 할 수 있습니다.
  • 환경은 응용 프로그램 프로젝트 내에서 생성될 수 있습니다. 이는 개발자에게 환경에 대한 더 많은 가시성을 제공합니다.
  • 배포 프로젝트는 Operator 그룹에서 관리될 수 있습니다. 권한을 더욱 분리할 수 있습니다.
  • 사용자는 CI/CD 작업 제한을 위한 RBAC 설정을 설정할 필요가 없습니다.
  • 이는 Review Apps와 같은 동적 환경에 특히 유용합니다.
flowchart LR subgraph ProductionKubernetes["Production Kubernetes"] subgraph ResourceGroupProductionFrontend["Frontend"] direction LR ResourceGroupProductionFrontendService(["Service"]) ResourceGroupProductionFrontendDeployment(["Deployment"]) ResourceGroupProductionFrontendPod1(["Pod1"]) ResourceGroupProductionFrontendPod2(["Pod2"]) end subgraph ResourceGroupProductionBackend["Backend"] direction LR ResourceGroupProductionBackendService(["Service"]) ResourceGroupProductionBackendDeployment(["Deployment"]) ResourceGroupProductionBackendPod1(["Pod1"]) ResourceGroupProductionBackendPod2(["Pod2"]) end subgraph ResourceGroupProductionPrometheus["Monitoring"] direction LR ResourceGroupProductionPrometheusService(["Service"]) ResourceGroupProductionPrometheusDeployment(["Deployment"]) ResourceGroupProductionPrometheusPod1(["Pod1"]) ResourceGroupProductionPrometheusPod2(["Pod2"]) end end subgraph GitLab subgraph Organization subgraph OperationGroup subgraph DeploymentProject DeploymentAgentProduction["Production agent"] DeploymentManifestFiles["Kubernetes Manifest Files"] DeploymentEnvironmentProductionPrometheus["production prometheus environment"] DeploymentPipelines["CI/CD pipelines"] end end subgraph DevelopmentGroup subgraph FrontendAppProject FrontendDeploymentPipelines["CI/CD pipelines"] FrontendEnvironmentProduction["production environment"] end subgraph BackendAppProject BackendDeploymentPipelines["CI/CD pipelines"] BackendEnvironmentProduction["production environment"] end end end end FrontendEnvironmentProduction --- ResourceGroupProductionFrontend BackendEnvironmentProduction --- ResourceGroupProductionBackend DeploymentEnvironmentProductionPrometheus --- ResourceGroupProductionPrometheus ResourceGroupProductionFrontendService -.- ResourceGroupProductionFrontendDeployment ResourceGroupProductionFrontendDeployment -.- ResourceGroupProductionFrontendPod1 ResourceGroupProductionFrontendDeployment -.- ResourceGroupProductionFrontendPod2 ResourceGroupProductionBackendService -.- ResourceGroupProductionBackendDeployment ResourceGroupProductionBackendDeployment -.- ResourceGroupProductionBackendPod1 ResourceGroupProductionBackendDeployment -.- ResourceGroupProductionBackendPod2 ResourceGroupProductionPrometheusService -.- ResourceGroupProductionPrometheusDeployment ResourceGroupProductionPrometheusDeployment -.- ResourceGroupProductionPrometheusPod1 ResourceGroupProductionPrometheusDeployment -.- ResourceGroupProductionPrometheusPod2 FrontendDeploymentPipelines -- "Trigger downstream pipeline" --> DeploymentProject BackendDeploymentPipelines -- "Trigger downstream pipeline" --> DeploymentProject DeploymentPipelines -- "Deploy" --> ResourceGroupProductionFrontend DeploymentPipelines -- "Deploy" --> ResourceGroupProductionBackend

디자인 및 구현 세부 정보

에이전트와 환경 연결

사용자는 설정 UI에서 GitLab 에이전트를 명시적으로 GitLab 환경에 설정할 수 있습니다. 프론트엔드는 이러한 연관된 에이전트를 사용하여 사용자 액세스의 인증 및 권한 부여를 위해 기술되어 있는 후속 섹션에서 설명합니다.

우리는 DeclarivePolicy에서 외부 프로젝트(또는 에이전트 관리 프로젝트로 알려진)에서 공유하는 에이전트를 지원하기 위해 read_cluster_agent 권한을 조정해야 합니다.

user_access를 통해 리소스 가져오기

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

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

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

GitLab 프론트엔드는 브라우저 쿠키로 사용자 액세스를 인증/승인합니다. 액세스가 거부된 경우, 프론트엔드는 ‘이 환경으로 배포된 에이전트에 액세스할 수 없습니다. “user_access”에 허용되었는지 에이전트 관리자에게 문의하십시오. <문제 해결="" 문서="" 링크="">를 참조하세요.'라는 오류 메시지를 표시합니다.문제>

사용자가 에이전트에 액세스한 후, GitLab 프론트엔드는 Kubernetes에서 다음 매개변수로 특정 리소스 종류(예: Deployment, Pod)를 가져옵니다.

  • namespace#{environment.kubernetesNamespace}

리소스를 찾을 수 없는 경우, 사용자가 이러한 라벨을 자원에 삽입하지 않았을 가능성이 높습니다. 이 경우, 프론트엔드는 ‘환경에 대한 리소스를 찾을 수 없습니다. 리소스에 GitLab이 보존한 라벨이 있습니까? <문제 해결="" 문서="" 링크="">를 참조하세요.'라는 경고 메시지를 표시합니다.문제>

종속성 그래프

  • GitLab 프론트엔드는 Owner References를 사용하여 리소스간의 종속성을 식별합니다. 이들은 metadata.ownerReferences 필드에 임베드됩니다.
  • Owner References가 없는 리소스의 경우, 부가적으로 Well-Known Labels, Annotations and Taints를 사용할 수 있습니다. 예를 들어, EndpointSlicemetadata.ownerReferences가 없지만 부모 Service 리소스에 대한 참조로 kubernetes.io/service-name을 사용합니다.

리소스의 헬스 상태

  • GitLab 프론트엔드는 가져온 리소스에서 상태 요약을 계산합니다. 예를 들어 ArgoCD의 Resource Health와 유사한 방식으로 Healthy, Progressing, Degraded, Suspended 등이 있습니다. 이에 대한 공식은 미정입니다.