Anthos On-Prem API 클라이언트를 사용하여 사용자 클러스터 만들기

이 페이지에서는 Google Cloud 콘솔, Google Cloud CLI(gcloud CLI) 또는 Terraform을 사용하여 사용자 클러스터를 만드는 방법을 설명합니다.

Anthos On-Prem API란?

Anthos On-Prem API는 Terraform 및 표준 Google Cloud 애플리케이션을 사용하여 온프레미스 클러스터의 수명 주기를 관리할 수 있게 해주는 Google Cloud 호스팅 API입니다. Anthos On-Prem API는 Google Cloud 인프라에서 실행됩니다. Terraform, 콘솔 및 gcloud CLI는 API의 클라이언트이며 API를 사용하여 데이터 센터에 클러스터를 만듭니다.

클러스터의 수명 주기를 관리하려면 Anthos On-Prem API가 클러스터를 만들 때 지정한 Google Cloud 리전을 사용하여 클러스터 상태에 대한 메타데이터를 Google Cloud에 저장해야 합니다. 이 메타데이터를 사용하면 API에서 클러스터 수명 주기를 관리할 수 있으며 워크로드별 데이터는 포함되지 않습니다.

Anthos On-Prem API 클라이언트를 사용하여 클러스터를 만든 경우 Google Cloud 프로젝트를 지정합니다. 클러스터가 생성되면 지정된 프로젝트의 Fleet에 자동으로 등록됩니다. 이 프로젝트를 Fleet 호스트 프로젝트라고 합니다. 클러스터를 만든 후에는 Fleet 호스트 프로젝트를 변경할 수 없습니다.

원하는 경우 사용자 클러스터 만들기에 설명된 대로 사용자 클러스터 구성 파일을 만들고 bmctl을 사용하여 사용자 클러스터를 만들 수 있습니다.

Terraform, 콘솔 또는 gcloud CLI를 사용하여 bmctl로 만든 클러스터의 수명 주기를 관리하려는 경우 Anthos On-Prem API에서 관리할 사용자 클러스터 구성을 참조하세요.

시작하기 전에

이 섹션에서는 Anthos On-Prem API 클라이언트를 사용하여 사용자 클러스터를 만들기 위한 요구사항을 설명합니다.

IAM 권한 부여

프로젝트 소유자가 아닌 경우 roles/gkeonprem.admin을 부여받아야 합니다.

콘솔에서 GKE Enterprise 및 Google Kubernetes Engine 페이지에 액세스하려면 다음 역할도 있어야 합니다.

클러스터가 생성된 후 프로젝트 소유자가 아니고 Connect 게이트웨이를 사용하여 명령줄로 사용자 클러스터에 연결하려는 경우 다음 역할이 필요합니다.

  • roles/gkehub.gatewayAdmin: 이 역할을 통해 Connect Gateway API에 액세스할 수 있습니다. 클러스터에 대한 읽기 전용 액세스만 필요하면 roles/gkehub.gatewayReader로 충분합니다.

  • roles/gkehub.viewer: 이 역할을 통해 클러스터 사용자 인증 정보를 검색할 수 있습니다.

역할 부여에 대한 상세 설명은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

필수 Google API

Fleet 호스트 프로젝트에서 모든 필수 Google API가 사용 설정되었는지 확인합니다.

gcloud CLI를 사용하여 클러스터를 만들려면 Anthos On-Prem API를 사용 설정해야 합니다. 콘솔을 사용하여 클러스터를 만드는 경우 Anthos On-Prem API가 자동으로 사용 설정됩니다.

gcloud services enable --project FLEET_HOST_PROJECT_ID \
    gkeonprem.googleapis.com

관리자 클러스터 기본 요건

사용자 클러스터를 만들려면 작동하는 관리자 클러스터가 필요합니다. 관리자 클러스터는 다음과 같아야 합니다.

  • 사용자 클러스터가 생성된 후 해당 클러스터의 Kubernetes API 서버에 액세스합니다.

  • 사용자 클러스터가 생성된 후 해당 클러스터의 모든 노드에 대한 네트워크 연결이 있습니다.

  • Fleet에 등록되어 있어야 합니다. Fleet 호스트 프로젝트라고 하는 관리자 클러스터의 필드인 gkeConnect.projectID에 구성된 프로젝트 ID는 사용자 클러스터를 만들려는 프로젝트와 동일해야 합니다.

클러스터 노드 머신 기본 요건

클러스터 노드 머신 기본 요건을 검토하여 사용자 클러스터를 실행할 머신이 기본 요건을 충족하는지 확인하세요.

명령줄 액세스 권한

클러스터가 생성된 후 Connect 게이트웨이를 사용하여 관리자 워크스테이션 이외의 컴퓨터에서 사용자 클러스터에 kubectl을 실행하려면 사용할 컴퓨터에 다음 명령줄 도구를 설치합니다.

  • gcloud CLI의 최신 버전
  • Kubernetes 클러스터에 명령어를 실행하기 위한 kubectl. kubectl을 설치해야 하는 경우 이 안내를 따르세요.

사용자 클러스터 만들기

Terraform, Google Cloud 콘솔 또는 Google Cloud CLI(gcloud CLI)를 사용하여 Anthos On-Prem API에서 관리되는 클러스터를 만들 수 있습니다. 베어메탈용 GKE를 처음 설치하는 경우 가장 쉽게 사용할 수 있는 도구는 콘솔입니다.

클러스터를 만들기 위해 제공해야 하는 정보에 익숙해지면 특히 2개 이상의 클러스터를 만드는 경우 Terraform 또는 gcloud CLI를 사용하는 것이 더 편리할 수 있습니다. Terraform은 코드 도구의 업계 표준 인프라입니다. 조직에서 이미 Terraform을 사용하는 경우 클러스터를 만들고 클러스터 수명 주기를 관리하는 데 사용할 수 있습니다.

gcloud CLI를 사용하면 인수와 함께 명령어를 텍스트 파일에 저장하고 필요에 따라 추가로 클러스터를 만들 수 있습니다. Cloud Build와 같은 CI/CD 도구를 사용할 경우에는 gcloud 명령어를 사용하여 클러스터 및 노드 풀을 만들고 --impersonate-service-account 플래그를 지정하여 만들기를 자동화할 수 있습니다.

콘솔

콘솔에 있는 대부분의 설정은 클러스터 구성 파일의 필드에 해당합니다.

  1. Google Cloud 콘솔에서 GKE Enterprise 클러스터 페이지로 이동합니다.

    GKE Enterprise 클러스터 페이지로 이동

  2. 클러스터를 만들 Google Cloud 프로젝트를 선택합니다. 선택한 프로젝트는 Fleet 호스트 프로젝트로도 사용됩니다. 이 프로젝트는 관리자 클러스터가 등록된 프로젝트와 같아야 합니다. 사용자 클러스터가 생성되면 선택한 프로젝트의 Fleet에 자동으로 등록됩니다.

  3. 클러스터 만들기를 클릭합니다.

  4. 대화상자에서 온프레미스를 클릭합니다.

  5. 베어메탈 옆의 구성을 클릭합니다.

  6. 기본 요건과 샘플 아키텍처를 검토합니다. 준비되었으면 다음을 클릭하여 클러스터 구성을 시작합니다.

다음 섹션에서는 사용자 클러스터를 구성하는 방법을 안내합니다.

클러스터 기본사항

클러스터에 대한 기본 정보를 입력합니다.

  1. 사용자 클러스터의 이름을 입력합니다.

  2. 관리자 클러스터의 목록에서 관리자 클러스터를 선택합니다.

  3. Google Cloud API 위치 필드의 목록에서 Google Cloud 리전을 선택합니다. 이 설정은 Anthos On-Prem API가 실행되는 리전 및 다음 항목이 저장되는 리전을 지정합니다.

    • Anthos On-Prem API가 클러스터 수명 주기를 관리하는 데 필요한 사용자 클러스터 메타데이터
    • 시스템 구성요소의 Cloud Logging 및 Cloud Monitoring 데이터
    • Cloud 감사 로그에서 만든 관리자 감사 로그

    클러스터 이름, 프로젝트, 위치에 따라 Google Cloud의 클러스터가 고유하게 식별됩니다.

  4. 사용자 클러스터에 베어메탈용 GKE 버전을 선택합니다. 사용자 클러스터는 관리자 클러스터와 동일한 마이너 버전이거나 관리자 클러스터보다 한 단계 낮은 마이너 버전이어야 합니다.

  5. 클러스터 생성자는 클러스터에 대한 클러스터 관리자 권한을 부여받습니다. 필요한 경우 관리자 필드에 클러스터를 관리할 다른 사용자의 이메일 주소를 입력하세요.

    클러스터가 생성되면 Anthos On-Prem API는 클러스터에 Kubernetes 역할 기반 액세스 제어(RBAC) 정책을 적용하여 사용자 및 다른 관리자에게 모든 네임스페이스의 클러스터 내 모든 리소스에 대한 전체 액세스 권한을 제공하는 Kubernetes clusterrole/cluster-admin 역할을 부여합니다.

  6. 노드 구성 섹션에서 다음을 지정합니다.

    • 노드당 최대 포드 수: 단일 노드에서 실행할 수 있는 최대 포드 수를 입력합니다. 허용되는 값은 32 ~ 250입니다. Kubernetes는 각 포드가 고유 IP 주소를 가질 수 있도록 각 노드에 클래스 없는 도메인 간 라우팅(CIDR) 블록을 할당합니다. CIDR 블록의 크기는 노드당 최대 포드 수에 해당합니다. 노드당 최대 포드 수를 설정하는 방법에 대한 자세한 내용은 포드 네트워킹을 참조하세요.

    • 컨테이너 런타임: containerd는 클러스터에 사용할 수 있는 유일한 컨테이너 런타임입니다.

  7. 다음을 클릭하여 네트워킹 섹션으로 이동합니다.

네트워킹

이 섹션에서는 클러스터의 노드, 포드, 서비스의 IP 주소를 지정합니다. MetalLB를 사용한 번들 부하 분산을 사용하는 경우에도 구성합니다.

  1. 제어 영역 노드 섹션에서 각 제어 영역 노드의 IPv4 주소를 입력합니다. 제어 영역 노드는 시스템 워크로드를 실행합니다. 일반적으로 머신 1개(최소 배포를 사용하는 경우) 또는 머신 3개(고가용성 배포를 사용하는 경우)입니다. 고가용성을 위해 대다수의 쿼럼을 가지도록 노드를 홀수로 지정하세요. 이 필드는 클러스터를 업데이트하거나 업그레이드할 때마다 변경할 수 있습니다.

    필요에 따라 + IP 주소 추가를 클릭하여 IP 주소를 더 입력합니다.

  2. 부하 분산기 섹션의 모드 목록에서 부하 분산기를 선택하여 클러스터를 설정합니다. 자세한 내용은 부하 분산기 개요를 참조하세요.

    MetalLB와 함께 번들로 제공

    번들 MetalLB 부하 분산기로 부하 분산을 구성합니다. 이 옵션을 사용하는 베어메탈용 GKE는 워커 노드의 전용 풀 또는 제어 영역과 동일한 노드에서 실행되는 계층 4 부하 분산기를 배포합니다.

    1. 부하 분산기 노드 풀 섹션에서 다음 중 하나를 선택합니다.

      • 제어 영역 노드 사용: 제어 영역과 동일한 노드에서 부하 분산기를 실행하려면 이 옵션을 선택합니다.

      • 부하 분산기 노드 풀 만들기: 전용 워커 노드 풀에서 부하 분산기를 실행해야 하는 경우 이 고급 옵션을 선택합니다. 부하 분산기 노드 풀의 모든 노드는 부하 분산기 주소 풀 섹션에서 구성하는 부하 분산기 가상 IP(VIP)와 동일한 Layer 2 서브넷에 있어야 합니다.

        1. 부하 분산기 노드 풀 IP 1 필드에 부하 분산기 노드 풀의 노드에 대한 IPv4 주소를 입력합니다.

        2. 필요에 따라 + IP 주소 추가를 클릭하여 추가 IP 주소를 입력합니다.

    2. 부하 분산기 주소 풀 섹션에서 LoadBalancer 유형의 서비스에서 선택하고 할당할 MetalLB 컨트롤러의 주소 풀을 하나 이상 추가합니다. 가상 IP 섹션에서 지정하는 인그레스 VIP가 이러한 풀 중 하나에 있어야 합니다.

      1. 주소 풀의 이름을 입력합니다.

      2. CIDR 표기법(예: 192.0.2.0/26) 또는 범위 표기법(예: 192.0.2.64~192.0.2.72)으로 IP 주소 범위를 입력합니다. 풀에 단일 IP 주소를 지정하려면 /32를 CIDR 표기법으로 사용합니다(예: 192.0.2.1/32)

      3. 인그레스 VIP가 주소 범위에 없으면 + IP 주소 범위 추가를 선택하고 인그레스 VIP가 포함된 다른 주소 범위를 입력합니다.

        각 풀의 IP 주소는 겹칠 수 없으며 클러스터 노드와 동일한 서브넷에 있어야 합니다.

      4. IP 주소 할당에서 다음 중 하나를 선택합니다.

        • 자동: MetalLB 컨트롤러가 주소 풀의 IP 주소를 LoadBalancer 유형의 서비스에 자동으로 할당하도록 하려면 이 옵션을 선택합니다.
        • 수동: 풀의 주소를 사용하여 LoadBalancer 유형의 서비스 주소를 수동으로 지정하려면 이 옵션을 선택합니다.

      5. MetalLB 컨트롤러가 .0 또는 .255로 끝나는 풀의 주소를 사용하지 않도록 하려면 버그가 있는 IP 주소 방지를 클릭합니다. 이렇게 하면 버그가 있는 소비자 기기가 특수한 IP 주소로 전송된 트래픽을 실수로 차단하는 문제를 방지할 수 있습니다.

      6. 완료하면 완료를 클릭합니다.

      7. 필요한 경우 주소 풀 추가를 클릭합니다.

    수동 부하 분산기

    수동 부하 분산을 사용하면 제어 영역 및 데이터 영역 트래픽에 대한 자체 부하 분산 솔루션을 구성할 수 있습니다. 클러스터를 만들기 전에 외부 부하 분산기에서 제어 영역 VIP를 구성해야 합니다. 외부 제어 영역 부하 분산기를 데이터 영역 트래픽에 사용할 수도 있고, 데이터 영역에 대해 별도의 부하 분산기를 설정할 수도 있습니다. 자세한 내용은 수동 부하 분산 구성을 참조하세요.

  3. 가상 IP 섹션에서 다음을 입력합니다.

    • 제어 영역 VIP: 사용자 클러스터의 Kubernetes API 서버로 전송되는 트래픽에 사용할 대상 IP 주소입니다. 제어 영역 VIP는 부하 분산기 노드와 동일한 서브넷에 있어야 하며 부하 분산기 주소 풀에 사용되는 주소 범위에 포함되지 않아야 합니다.

    • 포트: Kubernetes API 서버로 전송되는 트래픽에 사용되는 대상 포트입니다. 기본값은 443입니다.

    • 인그레스 VIP: 인그레스 프록시의 부하 분산기에서 구성할 IP 주소입니다. 부하 분산기 주소 풀 중 하나의 주소를 입력하세요.

  4. 서비스 및 포드 CIDR 섹션에서 Kubernetes 서비스 및 포드 IP 주소 범위를 CIDR 표기법으로 지정합니다. 이러한 범위는 서로 겹치거나 클러스터 내에서 연결하려는 클러스터 외부의 주소와 겹치지 않아야 합니다. RFC 1918로 정의된 비공개 IP 주소 범위를 사용하는 것이 좋습니다. 콘솔에서는 다음과 같은 기본 주소 범위가 제공되지만 변경할 수 있습니다.

    • 서비스 CIDR: 10.96.0.0/20 기본값을 원하지 않으면 /24에서 /12 사이의 CIDR 범위를 입력합니다. 여기서 /12는 대부분의 IP 주소를 제공합니다.

    • 포드 CIDR: 192.168.0.0/16 기본값을 원하지 않으면 /18과 /8 사이의 CIDR 범위를 입력합니다. 여기서 /8은 대부분의 IP 주소를 제공합니다.

  5. 고급 속성 속성 섹션에서 선택 사항으로 다음을 지정합니다.

    • 프록시 URL: 프록시 서버의 HTTP 주소입니다. 포트 번호가 스키마의 기본 포트와 동일하더라도 포함합니다(예: http://my-proxy.example.local:80).

    • URL: IP 주소, IP 주소 범위, 호스트 이름 그리고 프록시 서버를 거치지 않아야 하는 도메인 이름의 쉼표로 구분된 목록입니다. 베어메탈용 GKE가 이러한 주소, 호스트, 도메인 중 하나에 요청을 보내면 요청이 직접 전송됩니다.

  6. 다음을 클릭합니다.

스토리지

베어메탈용 GKE는 블록 및 파일 스토리지 인터페이스를 제공합니다. 기본 옵션이 있지만 구성을 맞춤설정할 수 있습니다. 자세한 내용은 로컬 스토리지 구성을 참조하세요.

  1. 선택 사항으로 다음을 구성할 수 있습니다.

    • 로컬 볼륨 프로비저닝 도구 노드 마운트: 마운트된 디스크로 지원되는 로컬 PersistentVolumes(PV)의 구성을 지정합니다. 이러한 디스크를 포맷하고 마운트해야 하며, 이는 클러스터 생성 전이나 후에 수행할 수 있습니다.

    • 로컬 볼륨 프로비저닝 도구 공유: 공유 파일 시스템의 하위 디렉터리에서 지원되는 로컬 PersistentVolumes의 구성을 지정합니다. 이러한 하위 디렉터리는 클러스터 생성 중에 자동으로 생성됩니다.

  2. 다음을 클릭합니다.

기능

클러스터 모니터링, 문제해결, 운영을 지원하기 위해 다음 항목이 자동으로 사용 설정되며 중지할 수 없습니다.

노드 풀 만들기

클러스터에 워커 노드에 대해 노드 풀이 하나 이상 있어야 합니다. 노드 풀은 이 클러스터에서 만든 워커 노드 그룹의 템플릿입니다.

콘솔에서 노드 풀을 하나 이상 구성하고(또는 기본값 수락) 클러스터를 만듭니다. 클러스터가 생성된 후 노드 풀을 추가할 수 있습니다. gcloud CLI를 사용하여 클러스터를 먼저 만든 후 하나 이상의 노드 풀을 새로 만든 클러스터에 추가합니다.

  1. 왼쪽 탐색 메뉴에서 기본 풀을 클릭합니다.

  2. 노드 풀 기본값 섹션에서 노드 풀 이름을 입력하거나 이름으로 'default-pool'을 사용합니다.

  3. 워커 노드 섹션에서 클러스터를 실행할 머신의 IP 주소를 입력합니다.

  4. 노드 풀 메타데이터(선택사항) 섹션에서 Kubernetes 라벨 및 taint를 추가하려면 다음 안내를 따르세요.

    1. + Kubernetes 라벨 추가를 클릭합니다. 라벨의 키 및 값을 입력합니다. 필요한 경우 반복합니다.
    2. + taint 추가를 클릭합니다. taint의 키, 값, 효과를 입력합니다. 필요한 경우 반복합니다.

  5. 확인 및 완료를 클릭하여 사용자 클러스터를 만듭니다. 사용자 클러스터를 만드는 데 15분 이상 걸립니다. 콘솔은 설정을 확인하고 데이터 센터에 클러스터를 만들 때 상태 메시지를 표시합니다.

    구성에 문제가 있으면 콘솔에 구성 문제를 해결하고 클러스터를 다시 만들 수 있도록 명확한 오류 메시지가 표시됩니다.

gcloud CLI

다음 명령어를 사용하여 사용자 클러스터를 만듭니다.

gcloud container bare-metal clusters create

클러스터를 만든 후 다음 명령어를 사용하여 적어도 하나 이상의 노드 풀을 만들어야 합니다.

gcloud container bare-metal node-pools create

클러스터 및 노드 풀을 만들기 위한 대부분의 플래그는 사용자 클러스터 구성 파일의 필드에 해당합니다. 시작하는 데 도움을 얻기 위해 예시 섹션의 전체 명령어를 시도해볼 수 있습니다. 플래그에 대한 자세한 내용은 예시에 이어지는 섹션을 참조하거나 gcloud CLI 참조를 확인하세요.

시작하기 전에

사용자 클러스터를 만들 때 선택하는 베어메탈용 GKE 버전은 관리자 클러스터에서 지원하는 버전이어야 합니다. 또한 출시 후 7~10일까지는 Anthos On-Prem API에서 최신 부 버전 또는 패치 버전을 사용할 수 없습니다. gcloud 명령어를 실행하여 사용자 클러스터에 설치할 수 있는 지원 버전 목록을 가져올 수 있습니다.

  1. 구성요소를 업데이트합니다.

    gcloud components update

  2. 사용자 클러스터에 설치할 수 있는 버전 목록을 가져옵니다.

    gcloud container bare-metal clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=global \
  --location=REGION

    다음을 바꿉니다.

    • ADMIN_CLUSTER_NAME: 관리자 클러스터 이름입니다.

    • FLEET_HOST_PROJECT_ID: 관리자 클러스터가 등록된 프로젝트의 ID입니다.

    • REGION: Anthos On-Prem API에 클러스터를 등록할 때 지정한 Google Cloud 리전입니다.

지원되는 최신 버전을 사용하여 최신 수정사항과 개선사항을 적용하는 것이 좋습니다.

예시

이 섹션에서는 MetalLB 부하 분산기를 사용하여 클러스터를 만드는 명령어의 예시와 수동 부하 분산기를 사용하는 예시를 제공합니다. 지정하는 정보는 사용할 부하 분산기 유형에 따라 다릅니다. 자세한 내용은 부하 분산기 개요를 참조하세요.

예시에서는 노드 풀 없이 클러스터를 만듭니다. 클러스터가 실행된 후 워크로드를 배포하기 전 노드 풀을 추가해야 합니다.

MetalLB

필요에 따라 화면을 스크롤해서 --admin-cluster-membership 플래그의 ADMIN_CLUSTER_NAME 자리표시자를 채워야 합니다.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --metal-lb-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

다음을 바꿉니다.

  • USER_CLUSTER_NAME: 사용자 클러스터의 이름입니다. 클러스터를 만든 후에는 이름을 변경할 수 없습니다. 이름은 다음 조건을 충족해야 합니다.
    • 40자(영문 기준) 이하여야 합니다.
    • 소문자 영숫자 문자 또는 하이픈(-)만 포함해야 합니다.
    • 알파벳 문자로 시작해야 합니다.
    • 영숫자 문자로 끝나야 합니다.
  • FLEET_HOST_PROJECT_ID: 클러스터를 만들려는 프로젝트의 ID입니다. 지정된 프로젝트는 Fleet 호스트 프로젝트로도 사용됩니다. 이 프로젝트는 관리자 클러스터가 등록된 프로젝트와 같아야 합니다. 사용자 클러스터가 생성되면 선택한 프로젝트의 Fleet에 자동으로 등록됩니다. 클러스터를 만든 후에는 Fleet 호스트 프로젝트를 변경할 수 없습니다.
  • ADMIN_CLUSTER_NAME: 사용자 클러스터를 관리하는 관리자 클러스터의 이름입니다. 관리자 클러스터 이름은 Google Cloud에서 클러스터를 고유하게 식별하는 완전히 지정된 클러스터 이름의 마지막 세그먼트입니다. projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
  • REGION: Anthos On-Prem API가 실행되는 Google Cloud 리전입니다. us-west1 또는 다른 지원되는 리전을 지정합니다. 클러스터를 만든 후에는 리전을 변경할 수 없습니다. 이 설정은 다음이 저장되는 리전을 지정합니다.
    • Anthos On-Prem API가 클러스터 수명 주기를 관리하는 데 필요한 사용자 클러스터 메타데이터
    • 시스템 구성요소의 Cloud Logging 및 Cloud Monitoring 데이터
    • Cloud 감사 로그에서 만든 관리자 감사 로그

    클러스터 이름, 프로젝트, 위치에 따라 Google Cloud의 클러스터가 고유하게 식별됩니다.

  • VERSION: 사용자 클러스터의 베어메탈 GKE 버전입니다.
  • YOUR_EMAIL_ADDRESS 및 ANOTHER_EMAIL_ADDRESS: --admin-users 플래그를 포함하지 않으면 클러스터 생성자로서 기본적으로 클러스터 관리자 권한이 부여됩니다. 그러나 다른 사용자를 관리자로 지정하기 위해 --admin-users를 포함할 경우 기본값이 재정의되고 자신의 이메일 주소와 다른 관리자의 이메일 주소를 모두 포함해야 합니다. 예를 들어 두 명의 관리자를 추가하려면 다음 안내를 따르세요. 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    클러스터가 생성되면 Anthos On-Prem API는 클러스터에 Kubernetes 역할 기반 액세스 제어(RBAC) 정책을 적용하여 사용자 및 다른 관리자에게 모든 네임스페이스의 클러스터 내 모든 리소스에 대한 전체 액세스 권한을 제공하는 Kubernetes clusterrole/cluster-admin 역할을 부여합니다.

MetalLB 주소 풀

  • --metal-lb-address-pools: MetalLB 부하 분산기에서 사용할 주소 풀의 구성을 지정합니다. 플래그 값의 형식은 다음과 같습니다.
'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

값에 pool, avoid-buggy-ip, manual-assign, addresses 키워드로 시작하는 세그먼트가 있습니다. 각 세그먼트는 쉼표로 구분합니다.

  • pool: 풀에 대해 선택한 이름입니다.

  • avoid-buggy-ips: 이 값을 True로 설정하면 MetalLB 컨트롤러가 .0 또는 .255로 끝나는 IP 주소를 서비스에 할당하지 않습니다. 이렇게 하면 버그가 있는 소비자 기기가 특수한 IP 주소로 전송된 트래픽을 실수로 차단하는 문제를 방지할 수 있습니다. 지정되지 않은 경우 기본값은 False입니다.

  • manual-assign: MetalLB 컨트롤러가 이 풀의 IP 주소를 서비스에 자동으로 할당하지 않도록 하려면 이를 True로 설정합니다. 그러면 개발자는 LoadBalancer 유형의 서비스를 만들고 풀에서 주소 중 하나를 수동으로 지정할 수 있습니다. 지정하지 않으면 manual-assign이 False로 설정됩니다.

  • addresses 목록에서 각 주소는 CIDR 범위이거나 하이픈으로 연결된 범위 형식이어야 합니다. 인그레스 VIP와 같이 풀에 단일 IP 주소를 지정하려면 /32를 CIDR 표기법으로 사용합니다(예: 192.0.2.1/32).

다음 구문 규칙에 유의하세요.

  • 전체 값은 작은따옴표로 묶어야 합니다.
  • 공백은 허용되지 않습니다.
  • 각 IP 주소 범위를 세미콜론으로 구분합니다.

다음 예시와 같이 플래그 인스턴스를 두 개 이상 지정할 수 있습니다.

--metal-lb-address-pools='pool=pool1,avoid-buggy-ips=False,manual-assign=True,addresses=192.0.2.0/26;192.0.2.64-192.0.2.72'
--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.133.0/24;10.251.134.80/32'

MetalLB 노드

  • 선택사항: --metal-lb-load-balancer-node-configs 기본적으로 부하 분산기는 제어 영역과 동일한 노드에서 실행됩니다. 워커 노드의 전용 풀에서 부하 분산기를 실행해야 하는 경우 각 노드에 이 플래그를 지정합니다. 부하 분산기 노드 풀의 모든 노드는 부하 분산기 가상 IP(VIP)와 동일한 레이어 2 서브넷에 있어야 합니다.

    플래그 값의 형식은 다음과 같습니다.

    'node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_VALUE_1.2;...' \

    값에 node-ip 및 labels 키워드로 시작하는 세그먼트가 있습니다. 각 세그먼트는 쉼표로 구분합니다.

    • node-ip: 부하 분산기 노드 풀에 있는 노드의 IP 주소입니다. 플래그당 node-ip 하나만 지정할 수 있습니다. 노드를 두 개 이상 지정해야 하는 경우 각 노드에 플래그를 다시 포함합니다.

    • labels: 노드에 연결된 하나 이상의 키-값 쌍입니다.

    다음 구문 규칙에 유의하세요.

    • 전체 값은 작은따옴표로 묶어야 합니다.
    • 공백은 허용되지 않습니다.
    • labels 세그먼트의 각 키-값 쌍을 세미콜론으로 구분합니다.

    --metal-lb-load-balancer-node-configs를 지정하면 선택적으로 다음 플래그를 포함할 수 있습니다.

    • --metal-lb-load-balancer-node-labels: 이 플래그를 사용하여 부하 분산기 노드 풀의 모든 노드에 라벨을 추가합니다. 키-값 쌍 목록을 쉼표로 구분합니다.

      --metal-lb-load-balancer-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

    • --metal-lb-load-balancer-node-taints: 이 플래그를 사용하여 부하 분산기 노드 풀의 모든 노드에 taint를 추가합니다. 각 taint는 효과와 연결된 키-값 쌍이며 PreferNoSchedule, NoSchedule 또는 NoExecute 중 하나여야 합니다.

      --metal-lb-load-balancer-node-taints=KEY_1=VALUE_1:EFFECT_1,KEY_2=VALUE_2:EFFECT_2

    다음 예시에서는 부하 분산기 노드 풀에 3개의 노드를 추가합니다. 모든 노드에는 lb-pool-key=lb-pool-value 라벨이 지정되고 taint dedicated=experimental:PreferNoSchedule이 있습니다.

    --metal-lb-load-balancer-node-configs='node-ip=192.0.2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
--metal-lb-load-balancer-node-labels=lb-pool-key=lb-pool-value \
--metal-lb-load-balancer-node-taints=dedicated=experimental:PreferNoSchedule \

제어 영역 노드

  • --control-plane-node-configs: 제어 영역 노드의 IPv4 주소입니다. 제어 영역 노드는 시스템 워크로드를 실행합니다. 각 제어 영역 노드에 이 플래그를 지정합니다. 일반적으로 최소 배포를 사용하는 경우에는 단일 머신이 있고 고가용성(HA) 배포를 사용하는 경우에는 머신이 3개 있습니다. 고가용성을 위해 대다수의 쿼럼을 가지도록 노드를 홀수로 지정하세요. 이러한 주소는 클러스터를 업데이트하거나 업그레이드할 때마다 변경할 수 있습니다.

    플래그 값의 형식은 다음과 같습니다.

      'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \

    값에 node-ip 및 labels 키워드로 시작하는 세그먼트가 있습니다. 각 세그먼트는 쉼표로 구분합니다.

  • node-ip: 제어 영역 노드의 IP 주소입니다. 플래그당 node-ip 하나만 지정할 수 있습니다. 노드를 두 개 이상 지정해야 하는 경우 각 노드에 플래그를 다시 포함합니다.
  • labels: 노드에 연결된 하나 이상의 키-값 쌍입니다.

    다음 구문 규칙에 유의하세요.

    • 전체 값은 작은따옴표로 묶어야 합니다.
    • 공백은 허용되지 않습니다.
    • labels 세그먼트의 각 키-값 쌍을 세미콜론으로 구분합니다.

    선택적으로 다음 플래그를 포함합니다.

  • --control-plane-node-labels: 모든 제어 영역 노드에 라벨을 추가하려면 이 플래그를 사용합니다. 키-값 쌍 목록을 쉼표로 구분합니다. 
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints: 이 플래그를 사용하여 taint를 모든 제어 영역 노드에 추가합니다. 각 taint는 효과와 연결된 키-값 쌍이며 PreferNoSchedule, NoSchedule 또는 NoExecute 중 하나여야 합니다.

    다음 예시에서는 제어 영역 노드에 노드 3개를 추가합니다. 모든 노드에는 cp-node-pool-key=cp-node-pool-value 라벨이 지정되고 taint dedicated=experimental:PreferNoSchedule이 있습니다.

      --control-plane-node-configs='node-ip=192.0.2.1' \
  --control-plane-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
  --control-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

가상 IP

  • CONTROL_PLANE_VIP: 사용자 클러스터의 Kubernetes API 서버에 대해 부하 분산기에서 구성하도록 선택한 IP 주소입니다.

    예: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: 부하 분산기에서 Kubernetes API 서버를 제공하는 포트입니다.

    예: -control-plane-load-balancer-port=443

  • INGRESS_VIP: 인그레스 프록시의 부하 분산기에서 구성하도록 선택한 IP 주소입니다.

    예를 들면 --ingress-vip=10.251.134.80입니다.

    인그레스 VIP의 IP 주소는 MetalLB 주소 풀 중 하나여야 합니다.

서비스 및 포드 CIDR

  • SERVICE_CIDR_BLOCK: 클러스터의 서비스에 사용할 CIDR 형식의 IP 주소 범위입니다. CIDR 범위는 /24에서 /12 사이여야 합니다. 여기서 /12는 대부분의 IP 주소를 제공합니다.

    예: --island-mode-service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: 클러스터의 포드에 사용할 CIDR 형식의 IP 주소 범위입니다. CIDR 범위는 /18에서 /8 사이여야 합니다. 여기서 /8은 대부분의 IP 주소를 제공합니다.

    예: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

스토리지

  1. --lvp-share-path: 하위 디렉터리를 만들 수 있는 호스트 머신 경로입니다. 각 하위 디렉터리에 대해 로컬 PersistentVolume(PV)이 생성됩니다.
  2. --lvp-share-storage-class: 영구 볼륨을 만드는 데 사용할 StorageClass입니다. StorageClass는 클러스터 생성 중에 생성됩니다.
  3. --lvp-node-mounts-config-path: 마운트된 디스크를 검색할 수 있는 호스트 머신 경로입니다. 각 마운트마다 로컬 PersistentVolume(PV)이 생성됩니다.
  4. --lvp-node-mounts-config-storage: 클러스터 생성 중에 PV가 만들어지는 스토리지 클래스입니다.

스토리지에 대한 자세한 내용은 로컬 스토리지 구성을 참조하세요.

수동

수동 부하 분산을 사용하면 제어 영역 및 데이터 영역 트래픽에 대한 자체 부하 분산 솔루션을 구성할 수 있습니다. 클러스터를 만들기 전에 외부 부하 분산기에서 제어 영역 VIP를 구성해야 합니다. 외부 제어 영역 부하 분산기를 데이터 영역 트래픽에 사용할 수도 있고, 데이터 영역에 대해 별도의 부하 분산기를 설정할 수도 있습니다. 자세한 내용은 수동 부하 분산 구성을 참조하세요.

필요에 따라 화면을 스크롤해서 --admin-cluster-membership 플래그의 ADMIN_CLUSTER_NAME 자리표시자를 채워야 합니다.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --enable-manual-lb \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

다음을 바꿉니다.

  • USER_CLUSTER_NAME: 사용자 클러스터의 이름입니다. 클러스터를 만든 후에는 이름을 변경할 수 없습니다. 이름은 다음 조건을 충족해야 합니다.
    • 40자(영문 기준) 이하여야 합니다.
    • 소문자 영숫자 문자 또는 하이픈(-)만 포함해야 합니다.
    • 알파벳 문자로 시작해야 합니다.
    • 영숫자 문자로 끝나야 합니다.
  • FLEET_HOST_PROJECT_ID: 클러스터를 만들려는 프로젝트의 ID입니다. 지정된 프로젝트는 Fleet 호스트 프로젝트로도 사용됩니다. 이 프로젝트는 관리자 클러스터가 등록된 프로젝트와 같아야 합니다. 사용자 클러스터가 생성되면 선택한 프로젝트의 Fleet에 자동으로 등록됩니다. 클러스터를 만든 후에는 Fleet 호스트 프로젝트를 변경할 수 없습니다.
  • ADMIN_CLUSTER_NAME: 사용자 클러스터를 관리하는 관리자 클러스터의 이름입니다. 관리자 클러스터 이름은 Google Cloud에서 클러스터를 고유하게 식별하는 완전히 지정된 클러스터 이름의 마지막 세그먼트입니다. projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
  • REGION: Anthos On-Prem API가 실행되는 Google Cloud 리전입니다. us-west1 또는 다른 지원되는 리전을 지정합니다. 클러스터를 만든 후에는 리전을 변경할 수 없습니다. 이 설정은 다음이 저장되는 리전을 지정합니다.
    • Anthos On-Prem API가 클러스터 수명 주기를 관리하는 데 필요한 사용자 클러스터 메타데이터
    • 시스템 구성요소의 Cloud Logging 및 Cloud Monitoring 데이터
    • Cloud 감사 로그에서 만든 관리자 감사 로그

    클러스터 이름, 프로젝트, 위치에 따라 Google Cloud의 클러스터가 고유하게 식별됩니다.

  • VERSION: 사용자 클러스터의 베어메탈 GKE 버전입니다.
  • YOUR_EMAIL_ADDRESS 및 ANOTHER_EMAIL_ADDRESS: --admin-users 플래그를 포함하지 않으면 클러스터 생성자로서 기본적으로 클러스터 관리자 권한이 부여됩니다. 그러나 다른 사용자를 관리자로 지정하기 위해 --admin-users를 포함할 경우 기본값이 재정의되고 자신의 이메일 주소와 다른 관리자의 이메일 주소를 모두 포함해야 합니다. 예를 들어 두 명의 관리자를 추가하려면 다음 안내를 따르세요. 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    클러스터가 생성되면 Anthos On-Prem API는 클러스터에 Kubernetes 역할 기반 액세스 제어(RBAC) 정책을 적용하여 사용자 및 다른 관리자에게 모든 네임스페이스의 클러스터 내 모든 리소스에 대한 전체 액세스 권한을 제공하는 Kubernetes clusterrole/cluster-admin 역할을 부여합니다.

제어 영역 노드

  • --control-plane-node-configs: 제어 영역 노드의 IPv4 주소입니다. 제어 영역 노드는 시스템 워크로드를 실행합니다. 각 제어 영역 노드에 이 플래그를 지정합니다. 일반적으로 최소 배포를 사용하는 경우에는 단일 머신이 있고 고가용성(HA) 배포를 사용하는 경우에는 머신이 3개 있습니다. 고가용성을 위해 대다수의 쿼럼을 가지도록 노드를 홀수로 지정하세요. 이러한 주소는 클러스터를 업데이트하거나 업그레이드할 때마다 변경할 수 있습니다.

    플래그 값의 형식은 다음과 같습니다.

      'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \

    값에 node-ip 및 labels 키워드로 시작하는 세그먼트가 있습니다. 각 세그먼트는 쉼표로 구분합니다.

  • node-ip: 제어 영역 노드의 IP 주소입니다. 플래그당 node-ip 하나만 지정할 수 있습니다. 노드를 두 개 이상 지정해야 하는 경우 각 노드에 플래그를 다시 포함합니다.
  • labels: 노드에 연결된 하나 이상의 키-값 쌍입니다.

    다음 구문 규칙에 유의하세요.

    • 전체 값은 작은따옴표로 묶어야 합니다.
    • 공백은 허용되지 않습니다.
    • labels 세그먼트의 각 키-값 쌍을 세미콜론으로 구분합니다.

    선택적으로 다음 플래그를 포함합니다.

  • --control-plane-node-labels: 모든 제어 영역 노드에 라벨을 추가하려면 이 플래그를 사용합니다. 키-값 쌍 목록을 쉼표로 구분합니다. 
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints: 이 플래그를 사용하여 taint를 모든 제어 영역 노드에 추가합니다. 각 taint는 효과와 연결된 키-값 쌍이며 PreferNoSchedule, NoSchedule 또는 NoExecute 중 하나여야 합니다.

    다음 예시에서는 제어 영역 노드에 노드 3개를 추가합니다. 모든 노드에는 cp-node-pool-key=cp-node-pool-value 라벨이 지정되고 taint dedicated=experimental:PreferNoSchedule이 있습니다.

      --control-plane-node-configs='node-ip=192.0.2.1' \
  --control-plane-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
  --control-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

가상 IP

  • CONTROL_PLANE_VIP: 사용자 클러스터의 Kubernetes API 서버에 대해 부하 분산기에서 구성하도록 선택한 IP 주소입니다.

    예: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: 부하 분산기에서 Kubernetes API 서버를 제공하는 포트입니다.

    예: -control-plane-load-balancer-port=443

  • INGRESS_VIP: 인그레스 프록시의 부하 분산기에서 구성하도록 선택한 IP 주소입니다.

    예를 들면 --ingress-vip=10.251.134.80입니다.

    인그레스 VIP의 IP 주소는 MetalLB 주소 풀 중 하나여야 합니다.

서비스 및 포드 CIDR

  • SERVICE_CIDR_BLOCK: 클러스터의 서비스에 사용할 CIDR 형식의 IP 주소 범위입니다. CIDR 범위는 /24에서 /12 사이여야 합니다. 여기서 /12는 대부분의 IP 주소를 제공합니다.

    예: --island-mode-service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: 클러스터의 포드에 사용할 CIDR 형식의 IP 주소 범위입니다. CIDR 범위는 /18에서 /8 사이여야 합니다. 여기서 /8은 대부분의 IP 주소를 제공합니다.

    예: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

스토리지

  1. --lvp-share-path: 하위 디렉터리를 만들 수 있는 호스트 머신 경로입니다. 각 하위 디렉터리에 대해 로컬 PersistentVolume(PV)이 생성됩니다.
  2. --lvp-share-storage-class: 영구 볼륨을 만드는 데 사용할 StorageClass입니다. StorageClass는 클러스터 생성 중에 생성됩니다.
  3. --lvp-node-mounts-config-path: 마운트된 디스크를 검색할 수 있는 호스트 머신 경로입니다. 각 마운트마다 로컬 PersistentVolume(PV)이 생성됩니다.
  4. --lvp-node-mounts-config-storage: 클러스터 생성 중에 PV가 만들어지는 스토리지 클래스입니다.

스토리지에 대한 자세한 내용은 로컬 스토리지 구성을 참조하세요.

gcloud 명령어를 실행하여 클러스터를 만들기 전에 --validate-only를 포함하여 gcloud 명령어에 플래그를 지정한 구성을 검사해야 할 수 있습니다. 클러스터를 만들 준비가 되었으면 이 플래그를 삭제하고 명령어를 실행합니다.

사용자 클러스터를 만드는 데 15분 이상 걸립니다. Anthos 클러스터 페이지의 Google Cloud 콘솔에서 클러스터를 볼 수 있습니다.

플래그 및 해당 설명의 전체 목록은 gcloud CLI 참조를 확인하세요.

노드 풀 만들기

클러스터를 만든 후에는 워크로드를 배포하기 전 노드 풀을 하나 이상 만들어야 합니다. 노드 풀은 이 클러스터에서 만든 워커 노드 그룹의 템플릿입니다. gcloud CLI를 사용하여 클러스터를 먼저 만든 후 하나 이상의 노드 풀을 새로 만든 클러스터에 추가합니다.

gcloud container bare-metal node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --node-configs='node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...'

다음을 바꿉니다.

  • NODE_POOL_NAME: 노드 풀에 대해 선택한 이름입니다. 이름은 다음 조건을 충족해야 합니다.

    • 40자(영문 기준) 이하여야 합니다.
    • 소문자 영숫자 문자 또는 하이픈(-)만 포함해야 합니다.
    • 알파벳 문자로 시작해야 합니다.
    • 영숫자 문자로 끝나야 합니다.

  • USER_CLUSTER_NAME: 새로 생성된 사용자 클러스터의 이름입니다.

  • FLEET_HOST_PROJECT_ID: 클러스터가 등록된 프로젝트의 ID입니다.

  • REGION: 클러스터를 만들 때 지정한 Google Cloud 리전입니다.

  • --node-configs: 워커 노드 머신의 IPv4 주소입니다. 각 노드에 이 플래그를 지정합니다. 플래그 값의 형식은 다음과 같습니다.

    'node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...' \

    값에 node-ip 및 labels 키워드로 시작하는 세그먼트가 있습니다. 각 세그먼트는 쉼표로 구분합니다.

    • node-ip: 워커 노드의 IP 주소입니다. 플래그당 node-ip 하나만 지정할 수 있습니다. 노드 풀의 각 노드에 이 플래그를 다시 추가합니다.

    • labels: 노드에 연결된 하나 이상의 키-값 쌍입니다.

    다음 구문 규칙에 유의하세요.

    • 전체 값은 작은따옴표로 묶어야 합니다.
    • 공백은 허용되지 않습니다.
    • labels 세그먼트의 각 키-값 쌍을 세미콜론으로 구분합니다.

    선택적으로 다음을 지정할 수 있습니다.

    • --node-labels=KEY=VALUE,...: 풀에서 각 노드에 적용된 쉼표로 구분된 Kubernetes 라벨(키-값 쌍) 목록입니다.

    • --node-taints=KEY=VALUE:EFFECT,... 풀의 각 노드에 적용되는 쉼표로 구분된 Kubernetes taint 목록입니다. Taint는 특정 효과와 연결된 키-값 쌍입니다. Taint는 포드 예약에 대한 톨러레이션(toleration)과 함께 사용됩니다. EFFECT에 NoSchedule, PreferNoSchedule, NoExecute 중 하나를 지정합니다.

다음 예시에서는 user-cluster-에 default-pool이라는 노드 풀을 만들고 노드 풀 2개를 추가합니다. 두 노드 모두 node-pool-key=node-pool-value 라벨이 지정되고 taint dedicated=experimental:PreferNoSchedule이 있습니다.

gcloud container bare-metal node-pools create default-pool \
  --cluster=user-cluster-1  \
  --project=example-project-12345 \
  --location=us-west1 \
  --node-configs='node-ip=10.200.0.10' \
  --node-configs='node-ip=10.200.0.11,labels=key2.1=value2.1' \
  --node-labels=node-pool-key=node-pool-value \
  --node-taints=dedicated=experimental:PreferNoSchedule

자세한 내용은 gcloud CLI 참조를 확인하세요.

Terraform

시작하기 전에

사용자 클러스터를 만들 때 선택하는 베어메탈용 GKE 버전은 관리자 클러스터에서 지원하는 버전이어야 합니다. 또한 출시 후 7~10일까지는 Anthos On-Prem API에서 최신 부 버전 또는 패치 버전을 사용할 수 없습니다. gcloud 명령어를 실행하여 사용자 클러스터에 설치할 수 있는 지원 버전 목록을 가져올 수 있습니다.

  1. 구성요소를 업데이트합니다.

    gcloud components update

  2. 사용자 클러스터에 설치할 수 있는 버전 목록을 가져옵니다.

    gcloud container bare-metal clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=global \
  --location=REGION

    다음을 바꿉니다.

    • ADMIN_CLUSTER_NAME: 관리자 클러스터 이름입니다.

    • FLEET_HOST_PROJECT_ID: 관리자 클러스터가 등록된 프로젝트의 ID입니다.

    • REGION: Anthos On-Prem API에 클러스터를 등록할 때 지정한 Google Cloud 리전입니다.

지원되는 최신 버전을 사용하여 최신 수정사항과 개선사항을 적용하는 것이 좋습니다.

예시

다음 기본 구성 샘플을 사용하여 번들 MetalLB 분산기로 사용자 클러스터를 만들 수 있습니다. 자세한 내용은 google_gkeonprem_bare_metal_cluster 참조 문서를 확인하세요.

  1. anthos-samples 저장소를 클론하고 Terraform 샘플이 있는 디렉터리로 변경합니다.

    git clone https://github.com/GoogleCloudPlatform/anthos-samples
cd anthos-samples/anthos-onprem-terraform/abm_user_cluster_metallb

    이 샘플은 main.tf에 전달할 변수 파일 예시를 제공합니다.

  2. terraform.tfvars.sample 파일의 사본을 만듭니다.

    cp terraform.tfvars.sample terraform.tfvars
    anthos-onprem-terraform/abm_user_cluster_metallb/terraform.tfvars.sample 
    
project_id          = "PROJECT_ID"
region              = "ON_PREM_API_REGION"
admin_cluster_name  = "ADMIN_CLUSTER_NAME"
bare_metal_version  = "VERSION"
admin_user_emails   = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name        = "abm-user-cluster-metallb"
control_plane_ips   = ["10.200.0.4"]
worker_node_ips     = ["10.200.0.5", "10.200.0.6"]
control_plane_vip   = "10.200.0.50"
ingress_vip         = "10.200.0.51"
lb_address_pools    = [
    { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
]

  3. terraform.tfvars의 매개변수 값을 수정하고 파일을 저장합니다.

    아래 목록에서 변수를 설명합니다.

    • project_id: 클러스터를 만들려는 프로젝트의 ID입니다. 지정된 프로젝트는 Fleet 호스트 프로젝트로도 사용됩니다. 이 프로젝트는 관리자 클러스터가 등록된 프로젝트와 같아야 합니다. 사용자 클러스터가 생성되면 선택한 프로젝트의 Fleet에 자동으로 등록됩니다. 클러스터를 만든 후에는 Fleet 호스트 프로젝트를 변경할 수 없습니다.

    • region: Anthos On-Prem API가 실행되는 Google Cloud 리전입니다. us-west1 또는 다른 지원되는 리전을 지정합니다.

    • admin_cluster_name: 사용자 클러스터를 관리하는 관리자 클러스터의 이름입니다.

    • bare_metal_version: 사용자 클러스터의 베어메탈 GKE 버전입니다. 관리자 클러스터와 동일한 버전 또는 관리자 클러스터보다 부 버전이 두 단계 낮은 버전을 지정합니다.

    • cluster_name: 선택한 사용자 클러스터의 이름입니다. 클러스터를 만든 후에는 이름을 변경할 수 없습니다. 이름은 다음 조건을 충족해야 합니다.

      • 40자(영문 기준) 이하여야 합니다.
      • 소문자 영숫자 문자 또는 하이픈(-)만 포함해야 합니다.
      • 알파벳 문자로 시작해야 합니다.
      • 영숫자 문자로 끝나야 합니다.

    • control_plane_ips: 제어 영역 노드에 대한 하나 이상의 IPv4 주소 목록입니다. 제어 영역 노드는 시스템 워크로드를 실행합니다. 일반적으로 최소 배포를 사용하는 경우에는 단일 머신이 있고 고가용성(HA) 배포를 사용하는 경우에는 머신이 3개 있습니다. 고가용성을 위해 대다수의 쿼럼을 가지도록 노드를 홀수로 지정하세요. 이러한 주소는 클러스터를 업데이트하거나 업그레이드할 때마다 변경할 수 있습니다.

    • worker_node_ips: 워커 노드 머신에서 하나 이상의 IPv4 주소 목록입니다.

    • control_plane_vip: 사용자 클러스터의 Kubernetes API 서버에 대해 부하 분산기에서 구성하도록 선택한 가상 IP 주소(VIP)입니다.

    • ingress_vip: 인그레스 프록시의 부하 분산기에서 구성하도록 선택한 IP 주소입니다.

    • lb_address_pools: MetalLB 부하 분산기에서 사용할 주소 풀을 정의하는 맵 목록입니다. 인그레스 VIP는 이러한 풀 중 하나에 있어야 합니다.

    • admin_user_emails: 클러스터에 대한 관리자 권한을 부여할 사용자의 이메일 주소 목록입니다. 클러스터를 관리하려면 이메일 주소를 추가해야 합니다.

    클러스터가 생성되면 Anthos On-Prem API는 클러스터에 Kubernetes 역할 기반 액세스 제어(RBAC) 정책을 적용하여 관리자에게 모든 네임스페이스의 클러스터 내 모든 리소스에 대한 전체 액세스 권한을 제공하는 Kubernetes clusterrole/cluster-admin 역할을 부여합니다. 이렇게 하면 사용자가 Google ID를 사용하여 콘솔에 로그인할 수 있습니다.

  4. 변경사항을 terraform.tfvars에 저장합니다.

  5. Terraform 계획을 초기화하고 만듭니다.

    terraform init

    Terraform은 Google Cloud 제공업체와 같은 필요한 라이브러리를 설치합니다.

  6. 구성을 검토하고 필요한 경우 변경합니다.

    terraform plan

  7. Terraform 계획을 적용하여 사용자 클러스터를 만듭니다.

    terraform apply

    사용자 클러스터를 만드는 데 15분 이상 걸립니다. Anthos 클러스터 페이지의 Google Cloud 콘솔에서 클러스터를 볼 수 있습니다.

사용자 클러스터에 연결

콘솔에서 사용자 클러스터를 만들 때 클러스터는 Google Cloud ID를 사용하여 클러스터에 로그인할 수 있도록 Kubernetes 역할 기반 액세스 제어(RBAC) 정책으로 구성됩니다. gcloud CLI로 사용자 클러스터를 만들 때는 --admin-users 플래그를 포함하지 않는 경우에 기본적으로 이러한 RBAC 정책이 부여됩니다. 다른 사용자를 관리자로 지정하기 위해 --admin-users를 포함할 경우 기본값이 재정의되고 자신의 이메일 주소와 다른 관리자의 이메일 주소를 모두 포함해야 합니다. 필요한 IAM 및 RBAC 정책에 대한 자세한 내용은 Google ID 인증 설정을 참조하세요.

모든 클러스터에는 표준 엔드포인트가 있습니다. 이 엔드포인트는 kubectl 및 기타 서비스가 TCP 포트 443을 통해 클러스터 제어 영역과 통신하는 데 사용하는 Kubernetes API 서버를 노출합니다. 공개 인터넷에서 이 엔드포인트에 액세스할 수 없습니다. VPC를 통해 클러스터의 비공개 엔드포인트에 액세스할 수 있으면 비공개 엔드포인트에 직접 연결하고 kubeconfig 파일을 직접 생성할 수 있습니다. 아니면 Connect 게이트웨이를 사용할 수 있습니다.

명령줄에서 사용자 클러스터에 액세스하려면 kubeconfig 파일이 필요합니다. kubeconfig 파일을 가져오는 방법에는 두 가지가 있습니다.

  • Connect 게이트웨이를 사용하여 Google Cloud CLI가 설치된 컴퓨터에서 클러스터에 액세스합니다. 이 경우 kubectl은 Connect 게이트웨이의 kubeconfig를 사용합니다. 그러면 트래픽이 사용자 대신 비공개 엔드포인트로 안전하게 전달됩니다.

  • 비공개 엔드포인트에 직접 액세스하려면 관리자 워크스테이션에서 kubeconfig 파일을 만들고 관리자 워크스테이션에서 클러스터를 관리합니다.

Google Cloud 콘솔에서 사용자 클러스터 상태가 정상으로 표시될 때까지 기다려야 합니다.

Connect 게이트웨이

  1. Fleet 호스트 프로젝트에서 사용할 gcloud CLI를 초기화하거나 다음 명령어를 실행하여 Google 계정으로 로그인하고 Fleet 호스트 프로젝트를 기본값으로 설정하고 구성요소를 업데이트합니다.

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

  2. Connect 게이트웨이와 상호작용하는 데 사용되는 클러스터 사용자 인증 정보를 가져옵니다. 다음 명령어에서 MEMBERSHIP_NAME을 클러스터 이름으로 바꿉니다. 베어메탈 GKE에서 멤버십 이름은 클러스터 이름과 동일합니다.

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

    이 명령어는 게이트웨이를 통해 클러스터에 연결할 수 있는 특수한 Connect 게이트웨이별 kubeconfig를 반환합니다.

필요한 사용자 인증 정보가 있으면 일반적인 Kubernetes 클러스터에서처럼 kubectl을 사용하여 명령어를 실행할 수 있으며 kubeconfig 파일 이름을 지정할 필요가 없습니다. 예를 들면 다음과 같습니다.

kubectl get namespaces

관리자 워크스테이션

bmctl get credentials 명령어를 사용하여 새로 만든 사용자 클러스터의 kubeconfig 파일을 검색합니다.

bmctl get credentials --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

다음을 바꿉니다.

  • CLUSTER_NAME: 대상 사용자 클러스터의 이름입니다.

  • ADMIN_KUBECONFIG_PATH: 관리자 클러스터 kubeconfig 파일의 경로입니다.

사용자 클러스터의 사용자 인증 정보가 포함된 kubeconfig가 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig 파일에 기록됩니다. 파일 이름의 TIMESTAMP는 파일이 생성된 날짜 및 시간을 나타냅니다.

이 파일에는 클러스터에 대한 인증 사용자 인증 정보가 포함되기 때문에 액세스가 제한된 보안 위치에 이를 저장해야 합니다.

다음 단계