조직 리소스는 동일한 리소스 풀과 공통 정책을 공유하는 관리 단위 또는 비즈니스 기능을 나타냅니다. Google Distributed Cloud (GDC) 에어 갭은 하드웨어 수준 멀티 테넌시 기능을 사용하여 조직 간에 물리적 격리를 제공합니다. 각 조직에는 다른 조직과 공유되지 않는 서비스용 자체 제어 영역 구성요소도 있습니다. 프로젝트, 클러스터, 서비스와 같은 모든 리소스는 생성자가 아닌 조직에 속합니다. 따라서 리소스를 만든 사용자가 조직을 탈퇴해도 리소스는 삭제되지 않습니다. 대신 모든 리소스 유형은 조직의 수명 주기를 따릅니다. 자세한 내용은 GDC 리소스 계층 구조를 참고하세요.
외부 네트워크 연결
조직이 유용하려면 외부 네트워크에 연결되어 있어야 합니다. 이를 통해 플랫폼 관리자 (PA)와 애플리케이션 운영자 (AO)는 조직과 리소스를 관리하고 최종 사용자는 조직 내에 배포된 서비스를 사용할 수 있습니다. GDC에서는 모든 외부 연결이 상호 연결에 의해 제공됩니다.
조직이 생성되면 네트워크에 자동으로 연결되지 않습니다. 운영자는 기존 Interconnect에 조직을 연결하거나 전용 Interconnect를 새로 프로비저닝하기 위해 추가 구성 단계를 수행해야 합니다. 여기에는 일반적으로 다음이 포함됩니다.
AttachmentGroup에 조직을 추가합니다.- 새 실제 또는 논리 연결을 위한
Interconnect리소스 만들기 - 조직의 네트워크 경로를 외부 네트워크에 공지하기 위해
RoutePolicy리소스를 정의합니다.
조직은 전용 상호 연결이 있는 조직이 중복되는 외부 IP 주소를 사용할 수 있는 기능을 비롯한 향상된 네트워킹 기능을 제공하여 IP 관리를 간소화합니다.
자세한 개념 및 구성 절차는 Interconnect 개요를 참고하세요.
Interconnect 연결 모델
GDC 상호 연결은 다양한 보안 및 IP 관리 요구사항에 부합하는 두 가지 기본 구성을 지원합니다.
공유 외부 네트워크 연결
이 모델을 사용하면 여러 조직이 공통 외부 네트워크를 통해 GDC 영역에 연결할 수 있습니다. 이 구성에서 인프라 운영자 (IO)는 일반적으로 물리적 연결과 BGP 피어링을 관리합니다. 핵심 요구사항은 각 조직에서 사용하는 외부 IP 주소가 공유 네트워크에서 고유해야 한다는 것입니다. 이 모델은 공통 신뢰 도메인이 있는 환경에서 관리하기가 더 간단합니다.
전용 외부 네트워크 연결
이 모델은 별도의 외부 네트워크에 연결하여 더 높은 수준의 격리가 필요한 조직을 위한 것입니다. 전용 연결을 사용하면 PA가 BGP 피어링을 관리하여 더 많은 제어 기능을 제공할 수 있습니다.
이 모델의 중요한 이점은 조직에서 중복되는 외부 IP 주소를 사용할 수 있다는 것입니다. 이 기능을 사용하면 GDC 유니버스에 있는 모든 테넌트에서 IP 범위를 중복 해제할 필요가 없어 IP 주소 관리가 간소화됩니다.
자세한 개념 및 구성 절차는 Interconnect 개요를 참고하세요.
조직 아키텍처
GDC는 조직에 다음 두 가지 아키텍처를 제공합니다.
- GDC 에어 갭 조직 v1 아키텍처 (v1 조직)
- GDC 에어 갭 조직 v2 아키텍처 (v2 조직)
표면적으로는 두 아키텍처 모두 조직에서 유사한 방식으로 프로비저닝, 사용, 운영됩니다. 하지만 각 조직 유형 내에서 기본 클러스터, 네트워킹, 스토리지 아키텍처는 서로 다릅니다.
GDC 에어 갭 적용 조직 v1 아키텍처
v1 조직은 다음 두 클러스터로 구성됩니다.
- 조직 관리자 클러스터: 조직의 관리 서비스 및 Marketplace 서비스의 컨트롤 플레인 구성요소를 실행합니다. 또한 일부 핵심 인프라 서비스를 호스팅합니다.
- 시스템 클러스터: 가상 머신 (VM) 워크로드와 조직의 일부 관리 서비스 데이터 영역 워크로드를 실행합니다. 워커 노드 수는 클러스터 사용률에 따라 달라집니다.
PA와 AO는 워크로드를 배포하고 시스템을 관리하기 위해 이러한 클러스터 유형에 액세스해야 하는 경우가 있습니다.
가상 클러스터의 스토리지는 클러스터 내의 공급업체별 CSI 드라이버에서 처리합니다.
GDC 에어 갭 조직 v2 아키텍처
v2 조직은 조직의 컨트롤 플레인 및 데이터 영역 구성요소를 실행하는 조직 인프라 클러스터라는 클러스터로 구성됩니다. 이 클러스터는 모든 비 컨테이너 워크로드와 서비스가 배포되는 관리 API 서버도 호스팅합니다. 관리 API 서버는 PA와 AO가 워크로드를 배포할 수 있지만 조직 인프라 클러스터와 직접 상호작용할 수는 없는 레이어를 제공합니다.
가상 클러스터의 스토리지는 조직 인프라 클러스터 CSI 드라이버가 작업을 처리할 수 있도록 지원하는 프록시 CSI 드라이버에 의해 처리됩니다.
IP 주소 관리, 인그레스 및 이그레스 리라우팅, VRF 구조를 비롯한 네트워킹 구성요소는 시스템의 보안 및 사용성을 위해 v1 조직 아키텍처에 비해 개선사항을 제공합니다.
v2 조직의 새로운 기능
v2 조직 아키텍처는 v1 조직 아키텍처와 비교하여 여러 구성요소에 변경사항을 도입합니다.
API 및 클러스터 아키텍처
v2 조직 아키텍처는 이전 아키텍처에서 제공된 두 클러스터 대신 조직에 단일 클러스터만 제공합니다. 클러스터가 감소하면 하드웨어 리소스를 더 탄력적으로 사용할 수 있습니다.
v1 조직에서는 사용할 수 없었던 컨트롤 플레인과 데이터 영역의 네트워크 분리도 있습니다. 이제 관리 API 서버 또는 제어 영역이 데이터 영역이 노출되는 고객 네트워크와 다른 고객 네트워크에 노출될 수 있습니다. 이 분리를 통해 클라우드 리소스 프로비저닝과 리소스 소비 간에 선택적인 추가 격리 레이어를 제공할 수 있습니다. 관리자와 개발자는 외부 네트워크에 모두 연결되어 있어야 합니다.
스토리지
새 v2 조직 아키텍처는 이전 아키텍처에 있던 NetApp Trident CSI 드라이버 대신 KubeVirt CSI 드라이버를 배포하여 사용자 클러스터에서 NetApp 스토리지 사용자 인증 정보를 삭제합니다. 이 CSI 드라이버 업데이트는 직접 스토리지 어레이 권한을 더욱 줄입니다.
네트워킹
v2 조직에서는 다음과 같은 네트워킹 개선사항을 사용할 수 있습니다.
노드 간 암호화
v2 조직 아키텍처는 조직의 베어 메탈 노드 간에 암호화를 제공하므로 고객 네트워크 트래픽이 물리적 노드를 떠날 때 모두 암호화되어 네트워크 스위치가 암호화되지 않은 트래픽을 볼 수 없습니다.
네트워크 트래픽 처리를 위한 전용 클러스터
경계 클러스터는 조직의 모든 인그레스 및 이그레스 (북/남) 트래픽을 처리하는 확장 가능한 가상 클러스터입니다. 이 클러스터를 사용하면 향후 GDC 유니버스를 확장성이 뛰어난 가상 침입 감지 및 방지 시스템 (IDPS) 옵션으로 이동할 수도 있습니다.
간소화된 VM 네트워킹
v2 조직 아키텍처는 이전 아키텍처의 VM당 인터페이스 2개를 단일 인터페이스로 통합합니다. VM이 기본 가상 프라이빗 클라우드 (VPC) 네트워킹 모델로 이동됩니다. 즉, VM이 레이어 3 (L3) 수준에서 네트워크에 연결됩니다.
고객은 자체 서브넷을 정의할 수도 있으며, 이는 v1 조직에서는 지원되지 않습니다.
효율적인 IP 주소 사용 및 관리
v2 조직 아키텍처에서는 조직의 외부 IP 주소가 중복될 수 있습니다. 중복되는 외부 IP 주소를 사용하면 조직에서 고객 네트워크에 직접 연결할 수 있으므로 GDC 유니버스에 있는 모든 조직에서 정렬된 단일 대규모 외부 IP 주소 공간이 필요하지 않습니다.
IP 주소는 단일 영역 범위 상위 서브넷에 고정되지 않고 조직별로도 제공됩니다. 이 기능을 사용하면 운영자가 IP 주소를 지정할 필요 없이 관리자가 자체 IP 주소를 지정할 수 있습니다. 이 기능은 상위 슈퍼넷을 공유하지 않아 강력한 네트워크 격리를 원하는 조직에 더 나은 탄력성과 격리를 제공합니다.
v1 조직의 경우 이그레스 NAT IP 주소는 프로젝트별, 사용자 클러스터별, 조직별로 하나씩 필요했습니다. v2 조직의 경우 이 요구사항이 조직당 프로젝트당 하나로 크게 개선되었습니다. 이번 변경으로 고객이 제공한 IP 주소의 사용 효율성이 향상됩니다.
v1 조직과 v2 조직 간의 기능 차이
v2 조직은 v1 조직과 동일한 모든 기능을 제공합니다. v2 조직에서 사용할 수 없는 기능은 다음과 같습니다.
- Vertex AI
- 데이터베이스 서비스 CLI
다중 영역 조직은 어떤 아키텍처를 사용하나요?
다중 영역 GDC 유니버스에서 기존 조직을 새 영역으로 확장하는 경우 새 영역의 조직은 기존 영역과 동일한 아키텍처를 사용해야 합니다. 따라서 영역별로 다른 조직 아키텍처를 사용하는 것은 지원되지 않습니다.
v2 조직을 프로비저닝하는 방법
조직을 프로비저닝할 때 인증 절차를 거치지 않는 고객의 경우 기본적으로 v2 조직이 생성됩니다.
하지만 v2 조직은 상당한 아키텍처 변경사항을 제공합니다. 인증 대상 고객 배포의 경우 v2 조직 아키텍처가 인증을 완료할 때까지 v1 조직 아키텍처가 기본값으로 유지됩니다.
조직 아키텍처 기본값은 영역을 배포할 때 구성된 기능 플래그로 제어됩니다.
조직 아키텍처 강제 적용 방법
드물지만 프로비저닝 프로세스 중에 Organization 리소스에 spec.compatibilityOptions.architectureOverridePolicy 필드를 추가하여 기본 프로비저닝 동작을 재정의하고 특정 조직 아키텍처를 강제 적용할 수 있습니다. 자세한 내용은 고객 조직 만들기 페이지를 참고하세요.
특정 동작을 강제해야 하는 강력한 이유가 없는 한 기본 조직 아키텍처를 재정의하지 않는 것이 좋습니다.
예를 들어 v2 조직에서 작업을 차단하는 심각한 문제가 발생하면 v1 조직을 강제할 수 있습니다. 마찬가지로 인증이 필요하고 인증 절차를 시작하기 위해 단일 v2 조직이 필요한 경우 v2 조직을 강제할 수 있습니다. 이러한 재정의 플래그는 잘못된 아키텍처로 향후 조직 프로비저닝을 방지하기 위해 더 이상 엄격하게 필요하지 않은 경우 삭제해야 합니다.
기존 v1 조직은 어떻게 되나요?
GDC 에어갭 1.14.2 이전에 생성된 기존 조직은 GDC 영역이 버전 1.14.2 이상으로 업그레이드되더라도 동일한 아키텍처를 유지합니다. v1 조직을 v2 조직으로 변환하는 인플레이스 업그레이드는 사용할 수 없지만 v1 조직의 기존 기능은 향후 v1 조직 아키텍처가 지원 중단될 때까지 계속 지원됩니다.
향후 새로운 기능은 v2 조직에만 추가될 수 있습니다. 따라서 최대한 빨리 v1 조직에서 새 v2 조직 아키텍처로 워크로드를 이동하는 것이 좋습니다. 단일 GDC 에어갭 유니버스에는 조직 아키텍처가 동시에 포함될 수 있으므로 전환이 더 쉬워집니다.