이 가이드에서는 베어메탈용 GDCV를 배포하는 데 사용되는 참조 아키텍처를 설명합니다. 이 가이드는 가용성이 높고 지리적으로 중복된 구성으로 GKE Enterprise on a bare metal 플랫폼을 배포하려는 플랫폼 관리자를 대상으로 합니다. 이 가이드를 잘 이해하기 위해서는 GKE Enterprise 기술 개요에 설명된 기본 GKE Enterprise 개념에 익숙해야 합니다. 또한 Kubernetes 기본 알아보기 및 GKE 문서에 기술된 대로 Kubernetes 개념과 Google Kubernetes Engine(GKE)에 대한 기본적인 이해가 필요합니다.
이 가이드에는 설명된 아키텍처를 배포하기 위해 사용할 수 있는 스크립트가 포함된 GitHub 소스 저장소가 있습니다. 이 가이드에서는 또한 해당 구성요소를 만드는 데 사용되는 스크립트 및 모듈이 포함된 아키텍처 구성요소를 설명합니다. 이러한 파일을 템플릿으로 사용하여 조직의 권장사항과 정책을 사용하는 모듈을 만드는 것이 좋습니다.
베어메탈용 GDCV 아키텍처 모델
GKE Enterprise 아키텍처 기초 가이드에서 플랫폼 아키텍처는 레이어로 설명됩니다. 각 레이어의 리소스는 특정 기능 집합을 제공합니다. 이러한 리소스는 하나 이상의 캐릭터에 의해 소유되고 관리됩니다. 다음 다이어그램에 표시된 것처럼 베어메탈용 GKE Enterprise 플랫폼 아키텍처는 다음 레이어 및 리소스로 구성됩니다.
- 인프라: 이 레이어에는 온프레미스 구조로 처리되는 스토리지, 컴퓨팅, 네트워킹이 포함됩니다.
- 데이터 관리: 이 가이드의 목적을 위해 데이터 관리 레이어에는 배포 중인 Kubernetes 클러스터 외부에서 관리되는 SQL 데이터베이스가 필요합니다.
- 컨테이너 관리 레이어: 이 레이어는 GKE 클러스터를 사용합니다.
- 서비스 관리 레이어: 이 레이어는 Anthos Service Mesh를 사용합니다.
- 정책 관리 레이어: 이 레이어는 구성 동기화 및 정책 컨트롤러를 사용합니다.
- 애플리케이션 관리 레이어: 이 레이어는 Cloud Build 및 Cloud Source Repositories를 사용합니다.
- 관측 가능성 레이어: 이 레이어는 Google Cloud Observability 및 Anthos Service Mesh 대시보드를 사용합니다.
이러한 각 레이어는 개발, 스테이징, 프로덕션과 같은 서로 다른 수명 주기 환경에서 스택 간에 반복됩니다.
다음 섹션에서는 베어메탈용 GDCV와 관련된 추가 정보만 다룹니다. GKE Enterprise 아키텍처 기초 가이드의 해당 섹션을 기반으로 합니다. 이 문서를 읽으면서 기초 가이드를 검토하는 것이 좋습니다.
네트워킹
네트워크 요구사항에 대한 자세한 내용은 네트워크 요구사항을 참조하세요.
베어메탈 부하 분산기용 GDCV에는 번들과 수동이라는 두 가지 옵션이 있습니다.
번들 모드에서 L4 부하 분산 소프트웨어는 클러스터 생성 중에 배포됩니다. 부하 분산기 프로세스는 워커 노드의 전용 풀 또는 제어 영역과 동일한 노드에서 실행될 수 있습니다. 이 부하 분산기에는 가상 IP 주소(VIP)를 공지하기 위한 두 가지 옵션이 있습니다.
- 주소 결정 프로토콜(ARP): 부하 분산기를 실행하는 노드 간에 레이어 2 연결이 필요합니다.
- 경계 경로 프로토콜(BGP): 피어링을 사용하여 클러스터 네트워크(자율 시스템)를 외부 네트워크와 같은 다른 자율 시스템과 상호 연결합니다.
수동 모드에서는 제어 영역과 데이터 영역 트래픽에 대한 자체 부하 분산 솔루션을 구성합니다. 외부 부하 분산기에는 여러 하드웨어 및 소프트웨어 옵션을 사용할 수 있습니다. 베어메탈 클러스터를 만들기 전에 제어 영역에 외부 부하 분산기를 설정해야 합니다. 외부 제어 영역 부하 분산기를 데이터 영역 트래픽에 사용할 수도 있고, 데이터 영역에 대해 별도의 부하 분산기를 설정할 수도 있습니다. 가용성을 확인하기 위해 부하 분산기에서 구성 가능한 준비 검사를 기반으로 노드 풀에 트래픽을 배포할 수 있어야 합니다.
베어메탈용 GDCV의 부하 분산기에 대한 자세한 내용은 부하 분산기 개요를 참조하세요.
클러스터 아키텍처
베어메탈용 GDCV는 가용성, 격리, 리소스 사용 공간이 각기 다른 여러 가지 배포 모델을 지원합니다. 이러한 배포 모델은 배포 모델 선택에 설명되어 있습니다.
ID 관리
베어메탈용 GDCV는 GKE ID 서비스를 사용하여 ID 공급업체와 통합됩니다. OpenID Connect(OIDC) 및 경량 디렉터리 액세스 프로토콜(LDAP)을 지원합니다. 애플리케이션 및 서비스의 경우 많은 ID 솔루션에서 Anthos Service Mesh를 사용할 수 있습니다.
ID 관리에 대한 자세한 내용은 베어메탈용 GDCV에서 OIDC를 사용한 ID 관리 및 OIDC로 인증 또는 LDAP로 Anthos Identity Service 설정을 참조하세요.
보안 및 정책 관리
베어메탈 보안 및 정책 관리를 위해서는 GDCV에서 구성 동기화 및 정책 컨트롤러를 사용하는 것이 좋습니다. 정책 컨트롤러를 사용하면 정책을 만들고 클러스터에서 시행할 수 있습니다. 구성 동기화는 변경사항을 평가하고 이를 모든 클러스터에 적용하여 적절한 상태를 얻습니다.
서비스
부하 분산을 위해 베어메탈의 번들 모드에 GDCV를 사용하는 경우 LoadBalancer 유형 서비스를 만들 수 있습니다. 이러한 서비스를 만들 때 베어메탈용 GDCV는 구성된 부하 분산기 IP 주소 풀에서 서비스로 IP 주소를 할당합니다. LoadBalancer 서비스 유형은 종방향 트래픽에 대해 클러스터 외부에서 Kubernetes 서비스를 노출하기 위해 사용됩니다.
베어메탈용 GDCV를 사용할 때는 기본적으로 IngressGateway도 클러스터에 생성됩니다. 수동 모드에서는 베어메탈용 GDCV의 LoadBalancer 유형 서비스를 만들 수 없습니다. 대신 IngressGateway를 사용하는 Ingress 객체를 만들거나 NodePort 유형 서비스를 만들고 Kubernetes 서비스를 백엔드로 사용하도록 외부 부하 분산기를 수동으로 구성할 수 있습니다.
횡방향 트래픽이라고도 부르는 Service Management에 대해서는 Anthos Service Mesh를 사용하는 것이 좋습니다. Anthos Service Mesh는 Istio 개방형 API를 기반으로 하며, 균일한 관측 가능성, 인증, 암호화, 세밀하게 조정된 트래픽 제어, 기타 기능과 함수를 제공합니다. Service Management에 대한 자세한 내용은 Anthos Service Mesh를 참조하세요.
지속성 및 상태 관리
베어메탈용 GDCV는 임시 스토리지, 볼륨 스토리지, PersistentVolume 스토리지를 위해 대부분 기존 인프라에 의존합니다. 임시 데이터는 Kubernetes Pod가 예약된 노드에서 로컬 디스크 리소스를 사용합니다. 영구 데이터의 경우 GKE Enterprise는 많은 스토리지 공급업체에서 지원하는 개방형 표준 API인 컨테이너 스토리지 인터페이스(CSI)와 호환됩니다. 프로덕션 스토리지의 경우 GKE Enterprise Ready 스토리지 파트너의 CSI 드라이버를 설치하는 것이 좋습니다. GKE Enterprise Ready 스토리지 파트너의 전체 목록은 GKE Enterprise Ready 스토리지 파트너를 참조하세요.
스토리지에 대한 자세한 내용은 스토리지 구성을 참조하세요.
데이터베이스
베어메탈용 GDCV는 GKE Enterprise 플랫폼의 표준 기능 외에 추가 데이터베이스 관련 기능을 제공하지 않습니다. 대부분의 데이터베이스는 외부 데이터 관리 시스템에서 실행됩니다. GKE Enterprise 플랫폼의 워크로드는 액세스 가능한 외부 데이터베이스에 연결하도록 구성될 수도 있습니다.
관측 가능성
Google Cloud Observability는 GKE 클러스터의 수집 및 모니터링 정책과 비슷한 방식으로 베어메탈용 GDCV 클러스터의 로그 및 모니터링 측정항목을 수집합니다. 기본적으로 클러스터 로그 및 시스템 구성요소 측정항목이 Cloud Monitoring으로 전송됩니다.
Google Cloud Observability에서 애플리케이션 로그 및 측정항목을 수집하도록 하려면 클러스터 구성 YAML 파일에서 clusterOperations.enableApplication 옵션을 사용 설정합니다.
관측 가능성에 대한 상세 내용은 로깅 및 모니터링 구성을 참조하세요.
사용 사례: Cymbal Bank 배포
이 가이드에서는 Cymbal Bank/Bank of Anthos 애플리케이션을 사용하여 베어메탈용 GDCV를 위한 계획, 플랫폼 배포, 애플리케이션 배포 프로세스를 시뮬레이션합니다.
이 문서의 나머지 부분은 세 가지 섹션으로 구성됩니다. 계획 섹션에서는 아키텍처 모델 섹션에 설명된 옵션을 기준으로 수행되는 결정 항목에 대해 설명합니다. 플랫폼 배포 섹션에서는 GKE Enterprise 플랫폼을 배포하기 위해 소스 저장소에서 제공되는 스크립트 및 모듈에 대해 설명합니다. 마지막으로 애플리케이션 배포 섹션에서는 Cymbal Bank 애플리케이션이 플랫폼에 배포됩니다.
이 베어메탈용 GDCV 가이드는 자체 관리 호스트 또는 Compute Engine instances 인스턴스에 배포하기 위한 목적으로 사용될 수 있습니다. Google Cloud 리소스를 사용하면 물리적인 하드웨어 액세스 없이 누구나 이 가이드를 완료할 수 있습니다. Compute Engine 인스턴스 사용은 데모 목적으로만 제한됩니다. 프로덕션 워크로드에 이 인스턴스를 사용하지 마세요. 물리적 하드웨어 액세스가 제공되고 동일한 IP 주소 범위가 사용되는 경우 제공된 소스 저장소를 있는 그대로 사용할 수 있습니다. 환경이 계획 섹션에 설명된 것과 다르면 차이점에 맞게 스크립트 및 모듈을 수정할 수 있습니다. 연관된 소스 저장소에는 물리적 하드웨어 및 Compute Engine 인스턴스 시나리오 모두에 대한 안내가 포함되어 있습니다.
계획
다음 섹션에서는 베어메탈용 GDCV에서 Bank of GKE Enterprise 애플리케이션 배포를 위해 플랫폼을 계획하고 설계하는 동안 아키텍처와 관련된 결정 항목에 대해 자세히 설명합니다. 이 섹션에서는 프로덕션 환경에 대해 집중해서 설명합니다. 개발 및 스테이징과 같은 하위 환경을 빌드하기 위해서는 비슷한 단계를 사용하면 됩니다.
Google Cloud 프로젝트
Google Cloud에서 베어메탈용 GDCV용 프로젝트를 만들 때는 Fleet 호스트 프로젝트가 필요합니다. 각 환경 또는 비즈니스 기능마다 추가 프로젝트를 사용하는 것이 좋습니다. 이 프로젝트 구성을 사용하면 리소스와 상호작용하는 사용자를 기준으로 리소스를 구성할 수 있습니다.
다음 하위 섹션에서는 이와 연결된 권장되는 프로젝트 유형 및 캐릭터에 대해 설명합니다.
허브 프로젝트
허브 프로젝트 hub-prod는 네트워크 관리자인 사용자를 대상으로 합니다. 이 프로젝트에서는 사용자가 선택한 형태의 하이브리드 연결을 사용해 온프레미스 데이터 센터를 Google Cloud에 연결합니다. 하이브리드 연결 옵션에 대한 자세한 내용은 Google Cloud 연결을 참조하세요.
Fleet 호스트 프로젝트
Fleet 호스트 프로젝트 fleet-prod는 플랫폼 관리자인 사용자를 대상으로 합니다. 이 프로젝트의 위치는 베어메탈용 GDCV 클러스터가 등록된 곳입니다. 또한 이 프로젝트는 플랫폼 관련 Google Cloud 리소스가 있는 곳에 위치합니다. 이러한 리소스에는 Google Cloud Observability, Cloud Source Repositories 등이 포함됩니다. 지정된 Google Cloud 프로젝트는 연관된 단일 Fleet만 포함할 수 있습니다(또는 Fleet 없음). 이 제한사항은 Google Cloud 프로젝트를 사용하여 함께 적용되지 않거나 함께 소비되지 않는 리소스 간에 더욱 강력한 격리 조치를 적용합니다.
애플리케이션 또는 팀 프로젝트
애플리케이션 또는 팀 프로젝트 app-banking-prod는 개발자인 사용자를 대상으로 합니다. 이 프로젝트에는 애플리케이션 관련 또는 팀 관련 Google Cloud 리소스가 존재합니다. 이 프로젝트에는 GKE 클러스터를 제외한 모든 것이 포함됩니다. 팀 또는 애플리케이션 수에 따라 이 프로젝트 유형의 인스턴스가 여러 개 존재할 수 있습니다. 여러 팀에 대해 개별 프로젝트를 만들면 각 팀에 대해 IAM, 청구, 할당량을 개별적으로 관리할 수 있습니다.
네트워킹
각 베어메탈용 GDCV 클러스터에는 다음 IP 주소 서브넷이 필요합니다.
- 노드 IP 주소
- Kubernetes Pod IP 주소
- Kubernetes 서비스/클러스터 IP 주소
- 부하 분산기 IP 주소(번들 모드)
각 클러스터에서 Kubernetes 포드 및 서비스 서브넷에 동일한 라우팅할 수 없는 IP 주소 범위를 사용하려면 섬(island) 모드 네트워크 모델을 선택합니다. 이 구성에서 Pod는 클러스터 내에서 서로 직접 통신할 수 있지만 Pod IP 주소를 사용하여 클러스터 외부에서 직접 연결될 수 없습니다. 이 구성은 외부 네트워크에 연결되지 않은 네트워크 내에 섬(island)을 만듭니다. 클러스터는 섬(island) 내에서 클러스터 노드 간에 전체 노드 간 메시를 만들어 Pod가 클러스터 내에서 다른 Pod와 직접 연결될 수 있게 해줍니다.
IP 주소 할당
| 클러스터 | 노드 | pod | 서비스 | 부하 분산기 |
|---|---|---|---|---|
| metal-admin-dc1-000-prod | 10.185.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 해당 사항 없음 |
| metal-user-dc1a-000-prod | 10.185.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.1.3~10.185.1.10 |
| metal-user-dc1b-000-prod | 10.185.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.2.3~10.185.2.10 |
| metal-admin-dc2-000-prod | 10.195.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 해당 사항 없음 |
| metal-user-dc2a-000-prod | 10.195.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.1.3~10.195.1.10 |
| metal-user-dc2b-000-prod | 10.195.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.2.3~10.195.2.10 |
섬(island) 모드에서는 Kubernetes Pod 및 서비스에 선택된 IP 주소가 사용 중이 아니거나 노드 네트워크에서 라우팅할 수 없는지 확인하는 것이 중요합니다.
네트워크 요구사항
구성이 필요하지 않은 베어메탈용 GDCV에 대해 통합 부하 분산기를 제공하려면 각 클러스터에서 번들 부하 분산기 모드를 사용합니다. 워크로드가 LoadBalancer 서비스를 실행할 때는 부하 분산기 풀에서 IP 주소가 할당됩니다.
번들 부하 분산기의 요구사항 및 구성에 대한 자세한 내용은 부하 분산기 개요 및 번들 부하 분산 구성을 참조하세요.
클러스터 아키텍처
프로덕션 환경에서는 베어메탈용 GDCV를 위한 최고의 중복성과 내결함성을 달성하기 위해 각 지리적 위치에 관리자 클러스터 1개와 사용자 클러스터 2개가 있는 관리자 및 사용자 클러스터 배포 모델을 사용하는 것이 좋습니다.
각 프로덕션 환경마다 최소 4개의 사용자 클러스터를 사용하는 것이 좋습니다. 각각 2개의 내결함성 클러스터가 포함된 지리적으로 중복된 2개 위치를 사용하세요. 각 내결함성 클러스터에는 중복된 하드웨어 및 중복된 네트워크 연결이 포함됩니다. 클러스터 수를 줄이면 아키텍처의 중복성 또는 내결함성이 줄어듭니다.
고가용성 보장을 위해 각 클러스터의 제어 영역에는 3개 노드가 사용됩니다. 사용자 클러스터당 최소 3개의 워커 노드를 사용하므로, 노드가 오프라인으로 전환될 때 영향을 줄이기 위해 이러한 노드 간에 워크로드를 분산할 수 있습니다. 워커 노드 수 및 크기는 대부분 클러스터에서 실행되는 워크로드 유형 및 수에 따라 달라집니다. 각 노드의 권장 크기는 베어메탈용 GDCV용 하드웨어 구성을 참조하세요.
다음 표에서는 이 사용 사례에서 CPU 코어, 메모리, 로컬 디스크 스토리지에 대한 권장 노드 크기를 설명합니다.
| 노드 유형 | CPUs/vCPUs | 메모리 | 스토리지 |
|---|---|---|---|
| 제어 영역 | 코어 8개 | 32GiB | 256GiB |
| 작업자 | 코어 8개 | 64GiB | 512GiB |
머신 기본 요건과 크기 조정에 대한 자세한 내용은 클러스터 노드 머신 기본 요건을 참조하세요.
ID 관리
ID 관리를 위해서는 GKE Identity Service를 통한 OIDC 통합이 권장됩니다. 소스 저장소에 제공된 예시에서는 요구사항을 간소화하기 위해 로컬 인증이 사용됩니다. OIDC를 사용할 수 있으면 이를 사용하도록 예시를 수정하면 됩니다. 자세한 내용은 베어메탈용 GDCV에서 OIDC로 ID 관리를 참조하세요.
보안 및 정책 관리
Cymbal Bank 사용 사례에서는 정책 관리에 구성 동기화 및 정책 컨트롤러가 사용됩니다. Cloud Source Repositories는 구성 동기화에 사용되는 구성 데이터를 저장하기 위해 생성됩니다. 구성 동기화 및 정책 컨트롤러를 설치하고 관리하는 데 사용되는 ConfigManagement 연산자에는 구성 소스 저장소에 대한 읽기 전용 액세스 권한이 필요합니다. 액세스 권한을 부여하려면 허용되는 인증 형식을 사용합니다. 이 예에서는 Google 서비스 계정이 사용됩니다.
서비스
이 사용 사례의 Service Management를 위해서는 Anthos Service Mesh를 사용하여 분산된 서비스가 빌드되는 기초를 제공합니다. 기본적으로 표준 Kubernetes Ingress 객체를 처리하는 클러스터에 IngressGateway도 생성됩니다.
지속성 및 상태 관리
영구 스토리지는 기존 인프라에 크게 의존하기 때문에 이 사용 사례에는 이것이 필요하지 않습니다. 하지만 다른 사례에서는 GKE Enterprise Ready 스토리지 파트너의 스토리지 옵션을 사용하는 것이 좋습니다. CSI 스토리지 옵션을 사용할 수 있으면 공급업체의 안내에 따라 이를 클러스터에 설치할 수 있습니다. 개념 증명과 고급 사용 사례에 대해서는 로컬 볼륨을 사용할 수 있습니다. 하지만 대부분의 사용 사례에서는 프로덕션 환경에서 로컬 볼륨을 사용하지 않는 것이 좋습니다.
데이터베이스
베어메탈용 GDCV의 많은 스테이트풀(Stateful) 애플리케이션은 영구 저장소로 데이터베이스를 사용합니다. 스테이트풀(Stateful) 데이터베이스 애플리케이션은 클라이언트에 비즈니스 논리를 제공하기 위해 데이터베이스에 대한 액세스 권한이 필요합니다. 베어메탈용 GDCV에서 사용하는 Datastore 유형에는 제한이 없습니다. 따라서 개발자 또는 연관된 데이터 관리 팀이 데이터 스토리지를 결정해야 합니다. 애플리케이션마다 필요한 Datastore가 다를 수 있기 때문에 이러한 Datastore도 제한 없이 사용될 수 있습니다. 데이터베이스는 클러스터 내부, 온프레미스 또는 클라우드에서도 관리될 수 있습니다.
Cymbal Bank 애플리케이션은 2개의 PostgreSQL 데이터베이스에 액세스하는 스테이트풀(Stateful) 애플리케이션입니다. 데이터베이스 액세스는 환경 변수를 통해 구성됩니다. PostgreSQL 데이터베이스는 데이터베이스가 클러스터 외부에서 관리되더라도 워크로드를 실행하는 노드에서 액세스할 수 있어야 합니다. 이 예시에서 애플리케이션은 기존 외부 PostgreSQL 데이터베이스에 액세스합니다. 애플리케이션이 플랫폼에서 실행되지만 데이터베이스는 외부에서 관리됩니다. 따라서 데이터베이스는 GKE Enterprise 플랫폼의 일부가 아닙니다. PostgreSQL 데이터베이스가 제공된 경우 이를 사용합니다. 그렇지 않으면 Cymbal Bank 애플리케이션용 Cloud SQL 데이터베이스를 만들고 사용합니다.
관측 가능성
Cymbal Bank 사용 사례의 각 클러스터는 Google Cloud Observability에서 시스템 구성요소와 애플리케이션 모두의 로그 및 측정항목을 수집하도록 구성됩니다. Google Cloud 콘솔 설치 프로그램에서 만든 여러 Cloud Monitoring 대시보드를 Monitoring 대시보드 페이지에서 볼 수 있습니다. 관측 가능성에 대한 자세한 내용은 로깅 및 모니터링 구성과 베어메탈용 GDCV에서 Logging 및 Monitoring 작동 방식을 참조하세요.
플랫폼 배포
자세한 내용은 GitHub 소스 저장소의 문서에서 플랫폼 배포 섹션을 참조하세요.
애플리케이션 배포
자세한 내용은 GitHub 소스 저장소의 문서에서 애플리케이션 배포 섹션을 참조하세요.
다음 단계
- Anthos Service Mesh, 구성 동기화, 정책 컨트롤러에 대해 자세히 알아보기
- 다른 GKE Enterprise 참조 아키텍처 살펴보기
- GKE Enterprise 샘플 배포로 Google Cloud에서 GKE Enterprise 사용해 보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기