이 문서에서는 Google Distributed Cloud (GDC) 에어 갭 리소스 계층 구조와 에어 갭 인스턴스에서 리소스가 관리되는 방식을 설명합니다. 여러 영역에서 리소스를 관리하는 개념은 다중 영역 개요를 참고하세요.
GDC 리소스 계층 구조의 목적은 두 가지입니다.
- 리소스 수명 주기를 계층 구조의 직속 상위 요소에 결합하는 소유권 계층 구조 제공
- 액세스 제어 및 조직 정책의 연결 지점 및 상속 제공
GDC 리소스 계층 구조는 항목을 계층적으로 구성하고 관리하는 방식으로, 운영체제의 파일 시스템과 유사합니다. 일반적으로 각 리소스는 단 하나의 상위 요소만 가집니다. 리소스의 이러한 계층적 조직을 사용하면 하위 리소스에 상속되는 ID 및 액세스 관리 (IAM)와 같은 액세스 제어 정책을 설정할 수 있습니다.
액세스 경계를 구성하기 위한 권장사항에 대한 자세한 내용은 리소스 간 액세스 경계 설계를 참고하세요.
리소스 구조 세부정보
다음 항목은 GDC 리소스 계층 구조에서 인식되는 리소스 유형입니다.
GDC 리소스는 계층적으로 구성됩니다. 리소스 계층 구조의 대부분의 리소스에는 상위 요소가 하나만 있습니다. 이 예외는 가장 높은 리소스에만 적용됩니다. 최하위 수준에 있는 서비스 리소스가 모든 GDC 서비스를 구성하는 기본 구성요소입니다.
조직은 GDC 리소스 계층 구조의 최상위 요소이며, 조직에 속하는 모든 리소스는 조직 리소스 아래에 그룹화됩니다. 이는 조직에 속하는 모든 리소스에 대한 중앙 집중식 가시성 및 제어를 제공합니다.
프로젝트와 클러스터는 모두 조직 범위입니다. 서비스 리소스를 구성하기 위해 서로 연결할 수 있습니다. 하지만 프로젝트와 클러스터는 서로 독립적으로 작동합니다. 이러한 유연성 덕분에 서비스와 워크로드를 구성하는 다양한 옵션을 사용할 수 있습니다. 예를 들어 단일 프로젝트 전용 클러스터를 사용할 수 있습니다. 마찬가지로 클러스터는 여러 프로젝트에 걸쳐 있을 수 있습니다.
서비스 리소스는 프로젝트 또는 클러스터에 속해야 하는 항목이며 프로젝트 또는 클러스터 간에 공유할 수 없습니다. 서비스 리소스의 예로는 가상 머신 (VM), 데이터베이스, 스토리지 버킷, 백업이 있습니다. 이러한 하위 수준 리소스의 대부분은 프로젝트 리소스를 상위 항목으로 포함합니다.
다음 다이어그램은 GDC 리소스 계층 구조의 예시를 나타냅니다.
최적의 워크로드 관리를 위해 리소스 계층 구조를 구성하는 권장사항에 대한 자세한 내용은 사용자 워크로드 분리 설계를 참고하세요.
조직
조직 리소스는 회사와 같은 관리 단위 또는 비즈니스 기능을 나타내며 GDC 리소스 계층 구조에서 최상위 리소스입니다. 조직은 사용자가 애플리케이션 워크로드를 배포할 수 있도록 함께 관리할 인프라 리소스를 둘러싸는 보안 경계를 정의합니다. 조직은 전역이며 유니버스의 모든 영역에 걸쳐 있습니다. 조직 내에서 VM 및 스토리지 볼륨과 같은 서비스 리소스는 프로젝트별로 논리적으로 그룹화됩니다.
모든 프로젝트, 클러스터, 서비스 리소스는 생성자가 아닌 조직에 속합니다. 즉, 조직의 리소스 유형은 이를 생성한 사용자가 조직을 떠나도 삭제되지 않습니다. 대신 모든 리소스 유형은 GDC에서 조직의 수명 주기를 따릅니다.
조직 리소스에 적용된 IAM 액세스 제어 정책은 조직 내 모든 리소스의 계층 구조 전체에 적용됩니다. 조직 전체 정책 및 권한 부여에 대한 자세한 내용은 조직 정책 및 IAM 섹션을 참고하세요.
프로젝트
프로젝트는 모든 서비스가 통합해야 하는 테넌시 단위입니다. 프로젝트는 서비스 리소스의 논리적 그룹화를 제공합니다. 프로젝트는 전역이며 유니버스의 모든 영역에 걸쳐 있습니다.
프로젝트를 사용하면 조직 내에서 서비스 리소스를 세분화하고 리소스 관리를 위한 수명 주기 및 정책 경계를 제공할 수 있습니다. 프로젝트 내부의 서비스 리소스는 프로젝트 자체보다 오래 지속되거나 프로젝트 간에 이동할 수 없으므로 리소스 수명 동안 제어를 사용할 수 있습니다. 따라서 프로젝트 네임스페이스 내에 모든 유형의 리소스를 배포해야 합니다.
프로젝트는 조직의 여러 클러스터에 걸쳐 있는 적절한 Kubernetes 네임스페이스로 간주됩니다. 네임스페이스 동일성은 지정된 이름의 모든 네임스페이스를 동일한 조직 내의 모든 클러스터에 대해 동일한 네임스페이스로 간주합니다. 단일 네임스페이스의 소유자가 클러스터 집합 전체에서 일관됩니다. 서비스 제공업체는 네임스페이스에 컨트롤 플레인 및 데이터 영역 구성요소를 만들어 프로젝트 범위 서비스를 만듭니다.
프로젝트의 네임스페이스는 다음을 호스팅합니다.
- 프로젝트 범위 서비스 API
- 역할 및 역할 바인딩과 같은 프로젝트 수준 정책 구성
조직의 일부 클러스터에만 프로젝트를 연결할 수 있습니다. 프로젝트 네임스페이스 내에서 이러한 클러스터에 컨테이너화된 워크로드를 배포할 수 있습니다. 네임스페이스 동일성 개념은 이러한 클러스터의 프로젝트 네임스페이스에 적용됩니다. 역할 기반 액세스 (RBAC) 정책과 같은 네임스페이스 범위 정책은 이러한 모든 네임스페이스에 적용됩니다.
프로젝트에 대한 자세한 내용은 프로젝트 개요를 참고하세요.
Kubernetes 클러스터
Kubernetes 클러스터는 GDC의 GKE의 일부로 컨테이너화된 워크로드를 실행하는 노드 집합입니다. 애플리케이션의 컴퓨팅 요구사항을 지원하도록 Kubernetes 클러스터를 프로비저닝할 수 있습니다. 클러스터는 조직 범위이며 하나 이상의 프로젝트에 연결되어야 합니다.
클러스터는 조직 내 프로젝트에서 사용할 수 있도록 인프라 리소스를 격리된 풀로 세분화합니다. 또한 클러스터는 서로 다른 장애 도메인과 격리 보장을 제공하기 위해 논리적으로 분리됩니다. 조직별 정책 시행을 통해 성능과 리소스 보장을 유지하면서 팀과 사용자 간에 클러스터를 공유할 수 있습니다. 또한 조직 정책을 사용하면 운영 복잡성을 도입하지 않고도 VM 워크로드를 컨테이너 워크로드와 함께 실행할 수 있습니다.
클러스터는 컨테이너화된 워크로드를 배포해야 하는 인스턴스에 유용합니다. 하지만 VM 기반 워크로드를 배포하는 옵션을 사용하면 GDC에서 Kubernetes 클러스터가 없어도 됩니다.
클러스터는 영역별 리소스이며 여러 영역에 걸쳐 있을 수 없습니다. 멀티 영역 배포에서 클러스터를 운영하려면 각 영역에 클러스터를 수동으로 배포해야 합니다.
Kubernetes 클러스터에 대한 자세한 내용은 Kubernetes 클러스터 관리 섹션을 참고하세요.
서비스 리소스
서비스 리소스에는 다음과 같은 여러 항목이 포함됩니다.
- VM
- 데이터베이스
- 저장소 버킷
- 컨테이너화된 워크로드
- 백업
서비스 리소스는 프로젝트에 속해야 하며, 컨테이너화된 워크로드의 경우 선택적으로 클러스터에 속할 수 있습니다. 서비스 리소스는 프로젝트 간에 공유할 수 없습니다. 즉, 프로젝트 내부의 서비스 리소스는 프로젝트 자체보다 오래 지속될 수 없으므로 리소스의 수명 동안 제어가 가능합니다.
서비스 리소스는 유형에 따라 전역 또는 영역별로 배포할 수 있습니다. 멀티 영역 배포 옵션에 관한 자세한 내용은 특정 서비스의 문서를 참고하세요. 서비스 리소스는 기본적으로 사용 설정되어 있으며 조직 정책을 사용하여 사용 중지할 수 있습니다.