이 문서에서는 조직, 프로젝트, Kubernetes 클러스터를 사용하여 Google Distributed Cloud (GDC) 오프라인 환경에서 워크로드의 계층 구조와 분리를 설계하기 위한 권장사항을 소개합니다. 이 가이드에서는 효율적인 리소스 사용, 워크로드 격리, 운영 용이성의 균형을 맞춥니다.
고객 간의 물리적 및 논리적 격리를 위한 조직 설계
Organization 리소스는 단일 고객이 소유한 모든 리소스의 루트입니다. 조직 내 워크로드 간의 세분화된 액세스 제어는 역할 바인딩 및 네트워크 정책을 통해 정의할 수 있습니다. 자세한 내용은 ID 및 액세스 관리를 참고하세요.
GDC 영역 내의 각 조직은 컴퓨팅 인프라에 대한 물리적 격리와 네트워킹, 스토리지, 기타 서비스에 대한 논리적 격리를 제공합니다. 한 조직의 사용자는 명시적으로 액세스 권한을 부여하지 않는 한 다른 조직의 리소스에 액세스할 수 없습니다. 한 조직에서 다른 조직으로의 네트워크 연결은 기본적으로 허용되지 않습니다. 단, 한 조직에서 데이터 아웃바운드 전송을 허용하고 다른 조직으로 데이터 인바운드 전송을 허용하도록 명시적으로 구성된 경우는 예외입니다.
조직을 공유할 수 있는 워크로드의 범위 정의
회사 컨텍스트에서 조직의 범위는 회사가 신뢰 경계를 정의하는 방식에 따라 다를 수 있습니다. 일부 회사에서는 회사 내 여러 법인에 대해 조직 리소스를 여러 개 만드는 것을 선호할 수 있습니다. 예를 들어 각 회사 부서에 워크로드의 완전한 물리적 및 관리적 분리가 필요한 경우 각 부서는 독립적인 조직을 갖는 GDC의 독립적인 고객일 수 있습니다.
일반적으로 다음 신호에 따라 여러 워크로드를 단일 조직으로 그룹화하는 것이 좋습니다.
- 워크로드는 종속 항목을 공유할 수 있습니다. 예를 들어 공유 데이터 소스, 워크로드 간 연결 또는 공유 모니터링 도구가 여기에 해당할 수 있습니다.
- 워크로드는 관리 신뢰할 수 있는 루트를 공유할 수 있습니다. 동일한 관리자가 조직의 모든 워크로드에 대한 독점 액세스 권한을 신뢰할 수 있습니다.
- 충분한 논리적 분리가 이루어진다면 워크로드가 동일한 조직의 다른 워크로드와 기본 물리적 인프라를 공유할 수 있습니다.
- 동일한 예산 보유자가 워크로드 예산에 대한 책임을 집계하여 갖습니다. 조직의 집계 비용 보기 또는 워크로드별 세부 분석에 대한 자세한 내용은 결제 페이지를 참고하세요.
- 워크로드 가용성 요구사항은 다중 영역 거리의 고가용성 요구사항을 따라야 합니다.
워크로드 간 논리적 격리를 위한 프로젝트 설계
조직 내에서는 리소스 간의 논리적 분리를 위해 여러 프로젝트를 프로비저닝하는 것이 좋습니다. 동일한 조직의 프로젝트는 기본 물리적 인프라를 공유할 수 있지만, 프로젝트는 Identity and Access Management (IAM) 정책 및 네트워크 정책을 기반으로 논리적 경계를 사용하여 워크로드를 분리하는 데 사용됩니다.
프로젝트 경계를 설계할 때는 역할 바인딩, 네트워크 정책, 관측 가능성 요구사항과 같이 리소스에서 공유할 수 있는 가장 큰 기능 집합을 고려하세요. 이 기능을 공유할 수 있는 리소스를 프로젝트로 그룹화하고 이 기능을 공유할 수 없는 리소스를 다른 프로젝트로 이동합니다.
Kubernetes 용어로 프로젝트는 조직의 모든 클러스터에서 예약된 Kubernetes 네임스페이스입니다. 네임스페이스가 여러 클러스터에서 예약되더라도 포드가 모든 클러스터에서 자동으로 예약되는 것은 아닙니다. 특정 클러스터에 예약된 포드는 해당 클러스터에 예약된 상태로 유지됩니다.
다음 다이어그램은 여러 클러스터에 걸쳐 있는 프로젝트에 역할 바인딩이 적용되는 방식을 보여줍니다.
역할 바인딩은 프로젝트 수준에서 설정되어 누가 어떤 리소스 유형에 대해 어떤 작업을 할 수 있는지 정의합니다. VM 또는 포드와 같은 워크로드가 프로젝트에 배포되며 이러한 워크로드에 대한 액세스는 역할 바인딩에 따라 관리됩니다. 역할 바인딩은 VM 기반 워크로드와 컨테이너 기반 워크로드에 일관되게 적용되며, 어떤 클러스터에 배포되는지는 중요하지 않습니다.
다음 다이어그램은 네트워크 정책이 프로젝트 간 액세스를 관리하는 방법을 보여줍니다.
Backend Project, Frontend Project, Database Project 간의 프로젝트 간 통신이 사용 중지됩니다. 하지만 각 프로젝트 내의 리소스는 서로 통신할 수 있습니다.
네트워크 정책은 리소스 간 네트워크 액세스를 선택적으로 허용하기 위해 프로젝트 수준에서 설정됩니다. 기본적으로 단일 프로젝트 내의 모든 리소스는 내부 네트워크에서 서로 통신할 수 있으며 한 프로젝트의 리소스는 다른 프로젝트의 리소스와 통신할 수 없습니다. 네트워크 정책의 이 동작은 리소스가 동일한 클러스터에 배포되는지 여부에 관계없이 적용됩니다.
ProjectNetworkPolicy 커스텀 리소스를 정의하여 프로젝트 간 통신을 사용 설정할 수도 있습니다. 이 정책은 다른 프로젝트의 인그레스 트래픽을 허용하기 위해 각 프로젝트에 대해 정의됩니다. 다음 다이어그램은 Frontend Project 및 Database Project에서 데이터를 전송할 수 있도록 Backend Project에 정의된 ProjectNetworkPolicy 커스텀 리소스를 보여줍니다.
또한 모니터링 스택은 조직 전체의 측정항목을 수집하지만 리소스 계층 구조의 다양한 수준에서 필터링하고 쿼리할 수 있습니다. 클러스터 또는 네임스페이스와 같은 항목으로 측정항목을 쿼리할 수 있습니다.
배포 환경별로 프로젝트 만들기
각 워크로드에 대해 프로덕션, 개발, 기타 필요한 배포 환경을 위한 별도의 프로젝트를 만드는 것이 좋습니다. 프로덕션 및 개발 배포 환경을 분리하면 개발에 사용되는 프로젝트에서 이루어진 변경사항이 프로덕션 환경에 영향을 미치지 않도록 역할 바인딩과 네트워크 정책을 세부적으로 정의할 수 있습니다.
프로젝트 내에서 리소스 수준 역할 바인딩 부여
팀 구조와 요구사항에 따라 개발자가 관리하는 프로젝트 내의 리소스를 수정하도록 허용할 수도 있고, 더 세부적인 액세스 제어가 필요할 수도 있습니다. 프로젝트 내에서 세부적인 역할 바인딩을 부여하여 개별 개발자가 프로젝트의 일부 리소스에만 액세스할 수 있도록 합니다. 예를 들어 팀에는 데이터베이스를 관리해야 하지만 다른 리소스를 수정해서는 안 되는 데이터베이스 관리자가 있을 수 있으며, 팀의 소프트웨어 개발자는 데이터베이스를 수정할 권한이 없어야 합니다.
Kubernetes 작업의 논리적 격리를 위한 클러스터 설계
Kubernetes 클러스터는 역할 바인딩 및 네트워크 정책이 Kubernetes 클러스터가 아닌 프로젝트에 적용되므로 엄격한 테넌트 경계가 아닙니다. Kubernetes 클러스터와 프로젝트는 다대다 관계입니다. 단일 프로젝트에 Kubernetes 클러스터가 여러 개 있거나 여러 프로젝트에 걸쳐 있는 단일 Kubernetes 클러스터가 있을 수 있습니다.