이 가이드는 단일 사용자 클러스터로 Google Distributed Cloud의 소규모 개념 증명 설치를 안내하는 가이드의 1부에 해당합니다.
이 문서에서는 이 설치를 위해 vSphere 및 Google Cloud 환경을 최소한으로 설정하고 IP 주소를 계획하는 방법을 보여주고, 후속 기본 클러스터 만들기는 관리자 워크스테이션, 관리자 클러스터, 사용자 클러스터를 만드는 방법을 보여줍니다.
이 가이드를 사용하여 설정한 인프라는 실제 프로덕션 요구사항 및 사용 사례에 적합하지 않을 수 있습니다. 프로덕션 설치에 대한 자세한 내용은 설치 개요 및 가이드를 참조하세요.
시작하기 전에
이 설정에서 설치할 각 구성요소의 역할을 포함하여 Google Distributed Cloud의 작동 방식에 대한 개요를 제공하는 Google Distributed Cloud 개요를 읽어보세요.
vSphere 지원 버전을 참조하세요.
vSphere 라이선스 요구사항을 참조하세요. 이 최소 설치는 vSphere Standard 라이선스로 충분합니다.
실행 중인 vCenter Server 인스턴스가 필요합니다.
충분한 권한이 있는 vCenter 사용자 계정이 필요합니다. 이 계정에 대한 사용자 이름 및 비밀번호를 기록해 둡니다.
프로젝트, IAM 권한, 서비스 계정을 비롯한 몇 가지 기본 Google Cloud 개념에 익숙해야 합니다. 그렇지 않은 경우 자세한 내용은 다음 가이드를 참조하세요.
절차 개요
이 설정과 관련된 기본 단계는 다음과 같습니다.
- 환경을 설정합니다. 리소스 요구사항을 충족할 수 있는지 확인합니다. 이 설치에 대한 요구사항을 충족하는 ESXi 호스트 및 vSphere 데이터 스토어에 대한 구성 예시를 제공합니다.
- vSphere 객체를 설정합니다. Google Distributed Cloud 구성요소는 vSphere 객체 계층 구조 내에서 실행됩니다.
- IP 주소를 계획합니다. Google Distributed Cloud에서는 배포에 대한 관리자 및 사용자 액세스를 위한 가상 IP 주소(VIP) 외에 모든 노드의 IP 주소를 제공해야 합니다. 이 설정에서는 클러스터 노드에 고정 IP 주소를 사용합니다. 하지만 네트워크 관리자에게 문의하여 사용자의 네트워크에 적합한 주소를 선택하는 것이 좋습니다.
- 방화벽 및 프록시 규칙 구성
- Google Cloud 리소스를 설정합니다. 여기에는 Google Distributed Cloud를 설정 및 관리할 때 사용할 Google Cloud 프로젝트와 Google Distributed Cloud 구성요소 소프트웨어에 액세스하고 다운로드하는 데 필요한 서비스 계정이 포함됩니다.
1. 환경 설정하기
이 최소 설치에는 ESXi를 실행하는 단일 물리적 호스트를 사용하면 됩니다.
호스트에 다음 최소 CPU, RAM, 스토리지 용량이 있어야 합니다.
- 하이퍼스레딩이 사용 설정된 2.7Ghz 물리적 CPU 8개
- 80GiB(기비바이트) RAM
- 470GiB 스토리지
ESXi 버전 7.0u2 이상이 설치되어 있어야 합니다.
vCenter Server 버전 7.0u2 이상을 사용 중이어야 합니다.
호스트 및 Datastore 예시
다음은 요구사항을 충족하는 ESXi 호스트 및 vSphere Datastore의 예시입니다.
ESXi 호스트 구성:
- 제조업체: Dell Inc.
- 물리적 CPU: 2.7GHz CPU 8개
- 프로세서 유형: Intel(R) Xeon(R) Platinum 8168 CPU @ 2.70GHz
- 프로세서 소켓: 2
- ESXi 버전: 7.0u2 이상
- vCenter Server 버전: 7.0u2 이상
- 하이퍼스레딩: 사용 설정됨
Datastore 구성:
- 유형: VMFS 6.82
- 드라이브 유형: SSD
- 공급업체: DELL
- 드라이브 유형: 논리
- RAID 수준: RAID1
2. vSphere 객체 설정
vSphere 환경에서 다음 객체를 설정하세요.
기본 클러스터 만들기에서 관리자 워크스테이션을 설정할 때 필요하므로 vSphere 데이터 센터, 클러스터, 데이터 스토어, 네트워크 이름을 기록해 둡니다.
vSAN 데이터 스토어를 설정한 경우 govc를 사용하여 datastore 디렉터리에 VMware용 GKE의 가상 머신 디스크(VMDK)에 사용할 폴더를 만듭니다.
govc datastore.mkdir -namespace=true data-disks
3. IP 주소 계획
Google Distributed Cloud 개요에서 확인한 것처럼 Google Distributed Cloud 설치에는 다음을 포함한 여러 IP 주소가 필요합니다.
- 모든 노드의 IP 주소
- Kubernetes API 서버와 같은 제어 영역 구성요소 및 사용자 클러스터에서 실행되는 애플리케이션에 액세스하기 위한 가상 IP 주소(VIP)
- 포드와 서비스 간의 통신을 위한 CIDR 범위
따라서 Google Distributed Cloud를 설정할 때 주소 충돌을 일으키지 않도록 IP 주소를 계획하는 것이 중요합니다. 간단한 설치더라도 구성에 적절한 값을 찾으려면 네트워크 관리자가 필요할 수 있습니다. 이 섹션의 나머지 부분에서는 가상 네트워크에서 이 설치에 적합한 값의 예시를 보여줍니다. 실제 사용할 값은 예시 값과 다릅니다.
이 최소 설치의 클러스터에는 번들 MetalLB 부하 분산기가 사용됩니다. 이 부하 분산기는 클러스터 노드에서 실행되므로 부하 분산에 추가 VM이 필요하지 않습니다.
Google Distributed Cloud를 사용하면 클러스터 노드에 고정 IP 주소를 제공하거나 DHCP 서버를 사용할 수 있습니다. 이 간단한 설치에서는 고정 IP 주소를 사용합니다.
VLAN 예시
이 소규모 설치의 경우 관리자 워크스테이션, 관리자 클러스터 노드, 사용자 클러스터 노드를 vSphere 네트워크의 동일한 VLAN에 배치하는 것이 좋습니다. 예를 들어 172.16.20.0/24 범위의 모든 IP 주소가 특정 VLAN에 라우팅된다고 가정해보세요. 또한 네트워크 관리자에 의해 VM 및 가상 IP 주소(VIP)에 172.16.20.49 - 172.16.20.69를 사용할 수 있다고 가정해보세요.
다음 다이어그램은 관리자 워크스테이션, 관리자 클러스터, 사용자 클러스터가 있는 VLAN을 보여줍니다. VIP는 클러스터의 특정 노드와 연결된 것으로 표시되지 않습니다. 이는 MetalLB 부하 분산기가 개별 서비스의 VIP를 공지하는 노드를 선택할 수 있기 때문입니다. 예를 들어 사용자 클러스터에서는 하나의 워커 노드가 172.16.20.64를 공지하고 다른 워커 노드가 172.16.20.65를 공지할 수 있습니다.
IP 주소 예시: 관리자 워크스테이션
이 예시에서는 관리자 워크스테이션에서 네트워크 관리자가 지정한 범위(172.16.20.49)의 첫 번째 주소를 사용합니다.
IP 주소 예시: 클러스터 노드
다음 표에서는 클러스터 노드에 IP 주소를 사용할 수 있는 방법에 대한 예시를 보여줍니다. 이 표에서는 admin-vm-6 및 user-vm-5라는 두 추가 노드의 주소를 보여줍니다. 추가 노드는 클러스터 업그레이드, 업데이트, 자동 복구 중에 필요합니다. 자세한 내용은 노드 IP 주소 관리를 참조하세요.
| VM 호스트 이름 | 설명 | IP 주소 |
|---|---|---|
| admin-vm-1 | 관리자 클러스터의 제어 영역 노드 | 172.16.20.50 |
| admin-vm-2 | 관리자 클러스터의 제어 영역 노드 | 172.16.20.51 |
| admin-vm-3 | 관리자 클러스터의 제어 영역 노드 | 172.16.20.52 |
| user-vm-1 | 사용자 클러스터의 제어 영역 노드 | 172.16.20.53 |
| user-vm-2 | 사용자 클러스터 워커 노드 | 172.16.20.54 |
| user-vm-3 | 사용자 클러스터 워커 노드 | 172.16.20.55 |
| user-vm-4 | 사용자 클러스터 워커 노드 | 172.16.20.56 |
| user-vm-5 | 172.16.20.57 |
IP 주소 예시: 관리자 클러스터의 VIP
다음 표에서는 관리자 클러스터의 제어 영역 VIP를 지정하는 방법의 예시를 보여줍니다.
| VIP | 설명 | IP 주소 |
|---|---|---|
| 관리자 클러스터의 Kubernetes API 서버의 VIP | 관리자 클러스터의 부하 분산기에 구성됨 | 172.16.20.58 |
IP 주소 예시: 사용자 클러스터의 VIP
다음 테이블에서는 사용자 클러스터에 VIP를 지정하는 방법의 예시를 보여줍니다.
사용자 클러스터의 Kubernetes API 서버에 대한 VIP와 인그레스 VIP는 모두 워커 노드 및 제어 영역 노드와 동일한 VLAN에 있습니다.
| VIP | 설명 | IP 주소 |
|---|---|---|
| 사용자 클러스터의 Kubernetes API 서버의 VIP | 관리자 클러스터의 부하 분산기에 구성됨 | 172.16.20.59 |
| 인그레스 VIP | 사용자 클러스터의 부하 분산기에 구성됨 | 172.16.20.60 |
| 서비스 VIP | LoadBalancer 유형의 서비스에 대한 10개 주소입니다.필요에 따라 사용자 클러스터의 부하 분산기에 구성됩니다. 이 범위에는 인그레스 VIP가 포함됩니다. MetalLB 부하 분산기의 요구사항입니다. |
172.16.20.60 - 172.16.20.69 |
포드 및 서비스용 IP 주소
클러스터 노드의 IP 주소 및 배포에 액세스하기 위한 IP 주소 외에도 각 클러스터 내에서 클러스터 내 트래픽에 사용할 수 있는 주소 범위를 지정해야 합니다.
이렇게 하려면 포드 IP 주소에 사용할 CIDR 범위와 Kubernetes 서비스의 ClusterIP 주소에 사용할 다른 CIDR 범위를 지정합니다. 이 가이드의 다음 부분에서 볼 수 있듯이 클러스터 구성의 일부로 지정됩니다.
IP 계획의 일부로 포드 및 서비스에 사용할 CIDR 범위를 결정합니다. 특별한 이유가 없는 한 다음 기본 범위를 사용하세요.
| 목적 | 기본 CIDR 범위 |
|---|---|
| 관리자 클러스터 포드 | 192.168.0.0/16 |
| 사용자 클러스터 포드 | 192.168.0.0/16 |
| 관리자 클러스터 서비스 | 10.96.232.0/24 |
| 사용자 클러스터 서비스 | 10.96.0.0/20 |
기본값은 다음 사항을 나타냅니다.
포드 CIDR 범위는 여러 클러스터에서 동일할 수 있습니다.
클러스터의 서비스 CIDR 범위가 다른 클러스터의 서비스 CIDR 범위와 겹치지 않습니다.
일반적으로 서비스보다 더 많은 포드가 필요하므로 특정 클러스터의 경우 서비스 CIDR 범위보다 큰 포드 CIDR 범위가 필요할 수 있습니다. 예를 들어 사용자 클러스터의 기본 포드 범위에는 2^(32-16) = 2^16개의 주소가 있지만, 사용자 클러스터의 기본 서비스 범위에는 주소가 2^(32-20) = 2^12개만 있습니다.
겹침 방지
경우에 따라 네트워크에서 연결할 수 있는 IP 주소와 겹치지 않도록 기본이 아닌 CIDR 범위를 사용해야 할 수 있습니다. 서비스 범위와 포드 범위는 클러스터 내부에서 연결하려는 클러스터 외부의 주소와 겹치지 않아야 합니다.
예를 들어 서비스 범위가 10.96.232.0/24이고 포드 범위가 192.168.0.0/16이라고 가정해 보겠습니다. 포드에서 이러한 범위 중 하나의 주소로 전송되는 트래픽은 클러스터 내 트래픽으로 처리되며 클러스터 외부의 대상에 도달하지 않습니다.
특히 서비스 범위와 포드 범위는 다음과 겹치지 않아야 합니다.
모든 클러스터에 있는 노드의 IP 주소
부하 분산기 머신에서 사용하는 IP 주소
제어 영역 노드 및 부하 분산기에서 사용하는 VIP
vCenter 서버, DNS 서버, NTP 서버의 IP 주소
포드 및 서비스 범위에 RFC 1918로 정의된 내부 IP 주소 범위를 사용하는 것이 좋습니다.
다음은 RFC 1918 주소를 사용을 권장하는 이유입니다. 포드 또는 서비스 범위에 외부 IP 주소가 포함되어 있다고 가정해보세요. 포드에서 이러한 외부 주소 중 하나로 전송되는 모든 트래픽은 클러스터 내 트래픽으로 취급되며 외부 대상에 도달하지 않습니다.
DNS 서버 및 기본 게이트웨이
관리자 및 사용자 클러스터를 만들기 전에 다음의 IP 주소도 알아야 합니다.
관리자 워크스테이션 및 클러스터 노드에 사용할 수 있는 DNS 서버
클러스터 노드에서 사용할 수 있는 NTP 서버
관리자 워크스테이션 및 클러스터 노드가 있는 서브넷에 대한 기본 게이트웨이의 IP 주소입니다. 예를 들어 관리자 워크스테이션, 관리자 클러스터 노드, 사용자 클러스터 노드가 모두 172.16.20.0/24 서브넷에 있다고 가정해보세요. 서브넷의 기본 게이트웨이 주소는 172.16.20.1일 수 있습니다.
4. 방화벽 및 프록시 구성
프록시 및 방화벽 규칙에 따라 필요한 Google Distributed Cloud 트래픽을 허용하도록 방화벽과 프록시를 구성합니다. 이 작업을 수행하려면 이전 섹션에서 식별한 클러스터 노드 IP 주소가 필요합니다. 사용자 및 관리자 클러스터의 IP 주소가 특정 노드에 할당되지 않으므로 모든 관련 방화벽 규칙이 각 클러스터의 모든 IP 주소에 적용되는지 확인해야 합니다.
5. Google Cloud 리소스 설정
Google Cloud 프로젝트는 Google Distributed Cloud를 설치하고 관리하는 데 사용되는 서비스를 포함하여 모든 Google Cloud 서비스를 만들고, 사용 설정하고, 사용하기 위한 기반을 형성합니다. Google Cloud 프로젝트에 익숙하지 않으면 프로젝트 만들기 및 관리에서 자세한 내용을 확인하세요.
기존 Google Cloud 프로젝트를 선택하거나 새 프로젝트를 만듭니다.
나중에 필요하므로 Google Cloud 프로젝트 ID를 기록해 둡니다.
Google Cloud CLI 설정
Google Cloud CLI는 프로젝트에 사용할 수 있는 명령줄 도구입니다. Google Cloud SDK 설치의 안내에 따라 최신 버전을 사용하세요.
필수 권한
프로젝트 소유자인 경우(예: 프로젝트를 직접 만든 경우) 이 간단한 설치의 나머지 부분을 수행하는 데 필요한 모든 권한이 이미 있습니다. 프로젝트 소유자가 아닌 경우 사용자 또는 프로젝트 관리자가 Google 계정에 필요한 권한을 가지고 있는지 확인해야 합니다.
다음 IAM 역할을 사용하여 서비스 계정을 만들고, 여기에 IAM 역할을 할당하고, API를 사용 설정하고, gkeadm 도구가 이 설정의 두 번째 부분에서 서비스 계정을 만들고 관리할 수 있도록 할 수 있습니다.
resourcemanager.projectIamAdminserviceusage.serviceUsageAdminiam.serviceAccountCreatoriam.serviceAccountKeyAdmin
IAM 역할을 직접 부여하는 데 필요한 권한에 대한 자세한 내용은 리소스에 대한 액세스 권한 부여, 변경, 취소를 참조하세요. 이러한 권한이 없으면 조직의 다른 사람이 대신 역할을 부여해야 합니다.
역할을 부여하려면 다음 안내를 따르세요.
Linux 및 macOS
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/resourcemanager.projectIamAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/serviceusage.serviceUsageAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/iam.serviceAccountCreator"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:ACCOUNT" \
--role="roles/iam.serviceAccountKeyAdmin"
Windows
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/resourcemanager.projectIamAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/serviceusage.serviceUsageAdmin"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/iam.serviceAccountCreator"
gcloud projects add-iam-policy-binding PROJECT_ID ^
--member="user:ACCOUNT" ^
--role="roles/iam.serviceAccountKeyAdmin"
다음을 바꿉니다.
PROJECT_ID: Google Cloud 프로젝트의 IDACCOUNT: Google 계정의 식별 이메일 주소
서비스 계정 설정
Google Cloud 프로젝트에는 Google Distributed Cloud에서 사용할 서비스 계정 4개가 있어야 합니다. 이 연습에서는 이러한 서비스 계정 중 두 개가 자동으로 생성됩니다. 하지만 다른 두 서비스 계정은 수동으로 만들어야 합니다.
- 연결-등록 서비스 계정(자동 생성됨)
- 로깅-모니터링 서비스 계정(자동 생성됨)
- 감사 로깅 서비스 계정(수동으로 생성)
- 구성요소 액세스 서비스 계정(수동으로 생성)
감사 로깅 서비스 계정
Google Cloud 프로젝트에서 Google Distributed Cloud가 클러스터의 Kubernetes 감사 로그를 Cloud 감사 로그로 전송하는 데 사용할 수 있는 서비스 계정을 만듭니다. 이 계정을 감사 로깅 서비스 계정이라고 합니다.
gcloud iam service-accounts create audit-logging-sa \ --display-name "Audit Logging Service Account" \ --project PROJECT_IDPROJECT_ID를 Google Cloud 프로젝트의 ID로 바꿉니다.새로 만든 감사 로깅 서비스 계정의 이메일 주소를 가져옵니다.
gcloud iam service-accounts list \ --project PROJECT_ID감사 로깅 서비스 계정의 JSON 키를 만들려면 다음을 실행합니다.
gcloud iam service-accounts keys create audit-logging-key.json \ --iam-account SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGINGSERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING을 감사 로깅 서비스 계정의 이메일 주소로 바꿉니다.감사 로깅 서비스 계정에 역할을 부여할 필요가 없습니다.
구성요소 액세스 서비스 계정
Google Cloud 프로젝트에서 사용자 대신 Google Distributed Cloud가 Container Registry에서 클러스터 구성요소 코드를 다운로드하는 데 사용할 수 있는 서비스 계정을 만듭니다. 이를 구성요소 액세스 서비스 계정이라고 부릅니다.
gcloud iam service-accounts create component-access-sa \ --display-name "Component Access Service Account" \ --project PROJECT_IDPROJECT_ID를 Google Cloud 프로젝트의 ID로 바꿉니다.새로 만든 구성요소 액세스 서비스 계정의 이메일 주소를 가져옵니다.
gcloud iam service-accounts list \ --project PROJECT_ID구성요소 액세스 서비스 계정의 JSON 키를 만듭니다.
gcloud iam service-accounts keys create component-access-key.json \ --iam-account SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS
SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS를 구성요소 액세스 서비스 계정의 이메일 주소로 바꿉니다.구성요소 액세스 서비스 계정에 다음 IAM 역할을 추가합니다.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \ --role "roles/serviceusage.serviceUsageViewer" gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \ --role "roles/iam.roleViewer" gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \ --role "roles/iam.serviceAccountViewer"
Google API 사용 설정
Google Cloud 프로젝트에서 다음 Google API를 사용 설정합니다. 이렇게 하면 프로젝트의 Google Distributed Cloud에 필요한 모든 Google Cloud 서비스를 사용할 수 있습니다.
gcloud services enable --project PROJECT_ID \ anthos.googleapis.com \ anthosgke.googleapis.com \ anthosaudit.googleapis.com \ cloudresourcemanager.googleapis.com \ connectgateway.googleapis.com \ container.googleapis.com \ gkeconnect.googleapis.com \ gkehub.googleapis.com \ gkeonprem.googleapis.com \ kubernetesmetadata.googleapis.com \ serviceusage.googleapis.com \ stackdriver.googleapis.com \ opsconfigmonitoring.googleapis.com \ monitoring.googleapis.com \ logging.googleapis.com \ iam.googleapis.com \ storage.googleapis.com프로젝트에서 GKE On-Prem API(
gkeonprem.googleapis.com)를 처음 사용 설정한 경우 API를 초기화해야 합니다. gcloud CLI 명령어를 호출하여 사용자 클러스터를 만드는 데 사용할 수 있는 버전을 표시하면 됩니다.gcloud container vmware clusters query-version-config \ --project=PROJECT_ID \ --location="us-central1"다음 단계