버전 1.5 이 버전은 Anthos 버전 지원 정책에 설명된 대로 지원되며 VMware용 Anthos 클러스터(GKE On-Prem)에 영향을 미치는 보안 취약점, 노출, 문제에 대한 최신 패치와 업데이트를 제공합니다. 자세한 내용은 출시 노트를 참조하세요. 이 버전은 최신 버전이 아닙니다.

DHCP를 사용하여 설치

이 페이지에서는 클러스터 노드에 IP 주소를 할당하기 위해 기존 동적 호스트 구성 프로토콜(DHCP) 서버를 사용하여 VMware vSphere 6.5 또는 6.7 업데이트 3 환경에 GKE On-Prem을 설치하는 방법을 설명합니다. 또한 고정 IP를 사용하여 설치할 수도 있습니다.

개요

이 페이지에서는 3개 노드가 포함된 관리자 클러스터사용자 클러스터를 만드는 방법을 보여줍니다. 각 노드는 vSphere 클러스터의 가상 머신(VM)에서 실행되며, 각 노드에는 해당 환경의 DHCP 서버에 할당된 IP 주소가 포함됩니다.

클러스터를 만든 후에는 추가 사용자 클러스터 만들기사용자 클러스터에서 노드 추가 또는 삭제를 수행할 수 있습니다.

시작하기 전에

  1. vSphere 요구사항의 설명대로 온프레미스 환경을 설정합니다.

  2. vSphere에서 관리 워크스테이션을 만듭니다.

  3. 관리 워크스테이션에 SSH를 통해 연결합니다.

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
  4. 프록시를 사용하는 경우 관리 워크스테이션의 인터넷 요청에 대해 config.yaml에 설정된 것과 동일한 프록시가 모든 gkectl 명령어에 자동으로 사용됩니다. 이 권장 환경에서는 관리 워크스테이션 및 모든 클러스터에 동일한 프록시가 사용됩니다. 이 사용 사례에서는 프록시 환경 변수를 설정할 필요가 없습니다.

    수동 프록시 옵션: 관리 워크스테이션이 동일한 프록시에 있지 않으면 인터넷에 액세스할 수 있도록 환경을 수동으로 구성해야 합니다. gkectl 명령어를 포함하여 모든 HTTPS 요청을 프록시하도록 HTTPS_PROXY 환경을 설정할 수 있지만 프록시에서 제외하려는 모든 요청에 대해서도 NO_PROXY 환경 변수를 구성해야 합니다.

    또한 gcloudgsutil 명령어를 개별적으로 실행해야 하면 항상 특정 프록시를 사용하도록 Cloud SDK를 구성하면 됩니다. 자세한 내용은 프록시/방화벽 뒤에서 사용할 수 있도록 Cloud SDK 구성을 참조하세요.

    다음 옵션을 사용하여 gkectl 명령어에 프록시를 수동으로 설정합니다.

    • 모든 gkectl 명령어:

      HTTPS_PROXYNO_PROXY 환경 변수를 사용하여 모든 gkectl 명령어의 프록시 방법을 수동으로 설정할 수 있습니다.

      • gkectl 명령어에 다른 프록시를 설정합니다. 예를 들면 다음과 같습니다.
        HTTPS_PROXY="http://my.other.proxy"
        NO_PROXY="10.0.1.0/24,private-registry.example,10.0.2.1"
      • gkectl 명령어를 프록시에서 제외합니다. 예를 들면 HTTPS_PROXY=""입니다.
      export HTTP_PROXY="http://[PROXY_ADDRESS]"
      export HTTPS_PROXY="http://[PROXY_ADDRESS]"
      export NO_PROXY="[NO_PROXY_ADDRESSES]"

      각 항목의 의미는 다음과 같습니다.

      • [PROXY_ADDRESS]는 비워둘 수 있으며(""), 프록시 IP 주소 또는 프록시의 호스트 이름입니다.
      • [NO_PROXY_ADDRESSES]는 프록시에서 제외할 URL, IP 주소 또는 호스트 이름을 쉼표로 구분한 목록일 수 있지만 공백이나 탭은 포함할 수 없습니다.

    • 단일 gkectl 명령어:

      또한 해당 호출에만 지정된 프록시를 사용하도록 개별 gkectl 명령어에 환경 변수를 프리픽스로 지정할 수 있습니다.

      예시:

      구성 파일(config.yaml)에 지정된 것과 다른 프록시를 통해 gkectl 명령어를 프록시하려면 HTTPS_PROXY 환경 변수를 사용합니다.

      • http://my.other.proxy 프록시를 사용하려면 다음 안내를 따르세요.
        • HTTPS_PROXY="http://my.other.proxy" gkectl create cluster --config config.yaml
        • HTTPS_PROXY="http://my.other.proxy" gkectl prepare --config config.yaml
      • 프록시를 제외하려면 빈 값을 사용합니다.
        • HTTPS_PROXY="" gkectl create cluster --config config.yaml
        • HTTPS_PROXY="" gkectl check-config --config config.yaml
  5. Google Cloud 사용자 계정 사용자 인증 정보를 사용하여 Google Cloud에 로그인합니다. 사용자 계정에는 최소한 IAM 뷰어 이상의 역할이 있어야 합니다.

    gcloud auth login
  6. 프록시를 사용하는 경우 gcloudgsutil 명령어에 해당 프록시가 사용되도록 Cloud SDK를 구성해야 합니다. 자세한 내용은 프록시/방화벽 뒤에서 사용할 수 있도록 Cloud SDK 구성을 참조하세요.

  7. 기본 프로젝트를 설정합니다. 기본 Google Cloud를 설정하면 모든 Cloud SDK 명령어가 해당 프로젝트에 대해 실행되므로 각 명령어에 프로젝트를 지정할 필요가 없습니다.

    gcloud config set project [PROJECT_ID]
    

    여기서 [PROJECT_ID]프로젝트 ID로 바꿉니다. (프로젝트 ID는 Cloud Console에서 또는 gcloud config get-value project를 실행하여 찾을 수 있습니다.)

클러스터 노드에 DHCP 예약 사용

Kubernetes에서는 노드 IP 주소가 변경되지 않는다는 것이 중요합니다. 노드 IP 주소가 변경되거나 사용할 수 없게 되면 클러스터가 손상될 수 있습니다. 이를 방지하기 위해서는 DHCP 예약을 사용해서 관리자 및 사용자 클러스터에 영구 주소 노드를 할당하는 방법을 고려해볼 수 있습니다. DHCP 예약을 사용하면 다시 시작하거나 임대를 갱신한 후 각 노드에 동일한 IP 주소가 할당됩니다.

관리자 및 사용자 클러스터에 필요한 IP 주소

DHCP 서버는 관리자 및 사용자 클러스터 노드에 충분한 IP 주소를 제공할 수 있어야 합니다.

관리자 클러스터에 필요한 IP 주소

관리자 클러스터에는 다음 노드의 주소가 필요합니다.

  • 관리자 클러스터 제어 영역용 노드 한 개
  • 관리자 클러스터의 부가기능용 노드 두 개
  • 관리자 클러스터의 업그레이드 중 수시로 사용되는 임시 노드
  • 연결된 사용자 클러스터별로 노드 한 개 또는 세 개

고가용성(HA) 사용자 클러스터의 경우 관리자 클러스터에는 사용자 클러스터의 제어 영역 구성요소를 실행하는 노드 세 개가 포함됩니다. HA가 아닌 사용자 클러스터의 경우 관리자 클러스터에는 사용자 클러스터의 제어 영역 구성요소를 실행하는 노드 한 개가 포함됩니다.

여기서 N은 만들려는 비HA 사용자 클러스터 수이고 H는 만들려는 HA 사용자 클러스터 수라고 가정합니다. 그러면 DHCP 서버가 관리자 클러스터 노드에 대해 최소한 다음 개수 이상의 IP 주소를 제공할 수 있어야 합니다.

4 + N + 3 x H

예를 들어 관리자 클러스터와 HA 사용자 클러스터 하나를 만든다고 가정합니다. 그러면 DHCP 서버가 관리자 클러스터에 IP 주소 7개를 제공해야 합니다.

사용자 클러스터에 필요한 IP 주소

사용자 클러스터에는 각 노드에 대한 IP 주소와 사용자 클러스터 업그레이드 중 임시 노드에 사용할 추가 IP 주소 1개가 필요합니다.

예를 들어 5개 노드가 포함된 사용자 클러스터를 만든다고 가정합니다. 그러면 DHCP 서버가 사용자 클러스터에 대해 IP 주소 6개를 제공해야 합니다.

설치를 위해 컨테이너 이미지 레지스트리 선택

설치하려면 GKE On-Prem이 컨테이너식 클러스터 구성요소를 가져올 위치를 알아야 합니다. 다음과 같은 두 가지 옵션이 있습니다.

Container Registry

기본적으로 GKE On-Prem은 Container Registry에서 호스팅되는 Google 소유의 기존 컨테이너 이미지 레지스트리를 사용합니다. gcr.io의 트래픽을 허용하도록 프록시 설정 이외의 추가 설정이 필요하지 않습니다.

비공개 Docker 레지스트리

설치에 비공개 Docker 레지스트리를 사용할 수 있습니다. GKE On-Prem은 클러스터 구성요소를 Docker 레지스트리에 푸시합니다. 비공개 Docker 레지스트리를 지정하려면 privateregistryconfig 필드를 설정합니다.

설치를 위해 비공개 Docker 레지스트리 구성(선택사항)

이 섹션에서는 GKE On-Prem 설치에 사용되는 기존 Docker 레지스트리를 구성하는 방법을 설명합니다. Docker 레지스트리를 만드는 방법은 외부에서 액세스할 수 있는 레지스트리 실행을 참조하세요. 레지스트리를 구성한 후 GKE On-Prem 구성 파일의 privateregistryconfig 필드를 채웁니다.

설치에 비공개 Docker 레지스트리를 사용하려면 관리 워크스테이션 VM이 사용자 인증서를 서명한 CA를 신뢰해야 합니다. GKE On-Prem은 안전하지 않은 Docker 레지스트리를 지원하지 않습니다. Docker 레지스트리를 시작할 때 인증서와 키를 제공해야 합니다. 인증서는 공개 인증 기관(CA)에서 서명하거나 자체 서명할 수 있습니다.

이 신뢰를 확립하려면 관리 워크스테이션 VM에서 다음 단계를 수행합니다.

  1. 인증서를 저장할 폴더를 만듭니다.

    sudo mkdir -p /etc/docker/certs.d/[REGISTRY_SERVER]
    

    여기서 [REGISTRY_SERVER]는 Docker 레지스트리를 실행하는 VM의 IP 주소 또는 호스트 이름입니다.

  2. 인증서 파일을 /etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt에 복사합니다. 원래 파일 이름이 다르더라도 파일 이름을 ca.crt로 지정해야 합니다.

  3. Docker 서비스를 다시 시작합니다.

    sudo service docker restart
  4. Docker에 로그인할 수 있는지 확인합니다.

    docker login -u [USERNAME] -p [PASSWORD] [REGISTRY_SERVER]

    여기서 [USERNAME][PASSWORD]는 Docker 레지스트리에 로그인하는 데 사용되는 사용자 인증 정보입니다.

이제 설치 중에 gkectl prepare를 실행하면 설치에 필요한 이미지가 Docker 레지스트리로 푸시됩니다.

레지스트리 구성 문제 해결

  • GET https://[REGISTRY_SERVER]/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers): Docker 레지스트리를 실행하는 VM의 IP 주소가 올바른지 확인합니다.

  • login attempt to https://[REGISTRY_SERVER]/v2/ failed with status: 401 Unauthorized: 사용자 이름과 비밀번호가 올바른지 확인합니다.

  • GET https://[REGISTRY_SERVER]/v1/users/: x509: certificate signed by unknown authority: 관리 워크스테이션 VM이 인증서를 신뢰하지 않습니다.

관리 워크스테이션에서 서비스 계정 비공개 키 만들기

서비스 계정에 아직 JSON 키를 만들지 않았으면 지금 만듭니다.

구성요소 액세스 서비스 계정

gcloud iam service-accounts keys create component-access-key.json \
--iam-account [COMPONENT_ACCESS_SERVICE_ACCOUNT_EMAIL]

여기서 [COMPOONENT_ACCESS_SERVICE_ACCOUNT_EMAIL]은 구성요소 액세스 서비스 계정의 이메일 주소입니다.

연결-등록 서비스 계정

gcloud iam service-accounts keys create connect-register-key.json \
--iam-account [REGISTER_SERVICE_ACCOUNT_EMAIL]

여기서 [CONECT_REGISTER_SERVICE_ACCOUNT_EMAIL]은 연결-등록 서비스 계정의 이메일 주소입니다.

연결-에이전트 서비스 계정

gcloud iam service-accounts keys create connect-agent-key.json \
--iam-account [CONNECT_AGENT_SERVICE_ACCOUNT_EMAIL]

여기서 [CONNECT_AGENT_SERVICE_ACCOUNT_EMAIL]은 연결-에이전트 서비스 계정의 이메일 주소입니다.

로깅-모니터링 서비스 계정

gcloud iam service-accounts keys create logging-monitoring-key.json \
--iam-account [LOGGING_MONITORING_SERVICE_ACCOUNT_EMAIL]

여기서 [LOGGING_MONITORINGH_SERVICE_ACCOUNT_EMAIL]은 로깅-모니터링 서비스 계정의 이메일 주소입니다.

구성 파일 생성

설치를 시작하려면 gkectl create-config를 실행하여 구성 파일을 생성합니다. 환경 사양과 원하는 클러스터 사양에 맞게 파일을 수정합니다.

파일을 생성하려면 다음 명령어를 실행합니다. 여기서 --config [PATH]는 선택사항이며 구성 파일의 경로와 이름이 사용됩니다. --config를 생략하면 현재 작업 디렉터리에 config.yaml이 생성됩니다.

gkectl create-config [--config [PATH]]

구성 파일 수정

이제 구성 파일이 생성되었으므로 환경에 적합하면서 클러스터 요구사항을 충족하도록 이를 수정해야 합니다. 다음 섹션에서는 각 필드, 예상되는 필드 값, 정보를 찾을 수 있는 위치를 설명합니다. 일부 필드는 기본적으로 주석 처리되어 있습니다. 이러한 필드 중 설치와 관련된 필드가 있으면 주석 처리를 없애고 값을 제공하세요.

이 섹션의 안내에서는 관리자 클러스터와 사용자 클러스터를 하나씩 만드는 단일 명령어 사용 방법을 설명합니다. 버전 1.2부터는 관리자 클러스터와 사용자 클러스터를 개별적으로 만들 수 있습니다.

bundlepath

GKE On-Prem 번들 파일에는 GKE On-Prem의 특정 출시 버전에 있는 모든 구성요소가 포함되어 있습니다. 관리자 워크스테이션을 만들 때는 /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz에서 전체 번들과 함께 제공됩니다. 이 번들 버전은 관리 워크스테이션을 만들기 위해 가져온 OVA 버전과 일치합니다.

bundlepath의 값을 관리자 워크스테이션 번들 파일의 경로로 설정합니다. 즉 bundlepath를 다음과 같이 설정합니다.

/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz

여기서 [VERSION]은 설치 중인 GKE On-Prem의 버전입니다. 최신 버전은 1.5.2-gke.3입니다.

다른 위치에 번들 파일을 두거나 이름을 다르게 지정해도 됩니다. 구성 파일에서 bundlepath의 값이 무엇이든 번들 파일의 경로인지만 확인하면 됩니다.

vCenter 사양

vCenter Server 사양 vcenter에는 GKE On-Prem이 사용자 환경에 설치해야 하는 vCenter 서버 인스턴스에 대한 정보가 포함됩니다.

vcenter.credentials.address

vcenter.credentials.address 필드에는 vCenter Server의 IP 주소 또는 호스트 이름이 포함됩니다.

vsphere.credentials.address field를 입력하기 전에 사용 중인 vCenter Server의 인증서를 다운로드하고 검사합니다. 다음 명령어를 입력하여 인증서를 다운로드하고 vcenter.pem이라는 파일로 저장합니다.

true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

인증서 파일을 열어서 제목 일반 이름 및 제목 대체 이름을 확인합니다.

openssl x509 -in vcenter.pem -text -noout

결과에 Subject 일반 이름(CN)이 표시됩니다. 이 이름은 IP 주소이거나 호스트 이름일 수 있습니다. 예를 들면 다음과 같습니다.

Subject: ... CN = 203.0.113.100
Subject: ... CN = my-host.my-domain.example

결과의 Subject Alternative Name 아래에는 DNS 이름이 1개 이상 포함될 수도 있습니다.

X509v3 Subject Alternative Name:
    DNS:vcenter.my-domain.example

Subject 일반 이름을 선택하거나 Subject Alternative Name 아래에서 구성 파일의 vcenter.credentials.address 값으로 사용할 DNS 이름 중 하나를 선택합니다. 예를 들면 다음과 같습니다.

vcenter:
  credentials:
    address: "203.0.113.1"
    ...
vcenter:
  credentials:
    address: "my-host.my-domain.example"
    ...

인증서에 표시되는 값을 선택해야 합니다. 예를 들어 IP 주소가 인증서에 표시되지 않으면 이를 vcenter.credentials.address에 사용할 수 없습니다.

vcenter.credentials

GKE On-Prem은 vCenter Server의 사용자 이름과 비밀번호를 알아야 합니다. 이 정보를 제공하려면 vcenter.credentials 아래에서 usernamepassword 값을 설정하세요. 예를 들면 다음과 같습니다.

vcenter:
  credentials:
    ...
    username: "my-name"
    password: "my-password"

vcenter.datacenter, .datastore, .cluster, .network

GKE On-Prem에는 vSphere 환경 구조에 대한 정보가 필요합니다. 이 정보를 제공하려면 vcenter 아래에서 값을 설정하세요. 예를 들면 다음과 같습니다.

vcenter:
  ...
  datacenter: "MY-DATACENTER"
  datastore: "MY-DATASTORE"
  cluster: "MY-VSPHERE-CLUSTER"
  network: "MY-VIRTUAL-NETWORK"

vcenter.resourcepool

vSphere 리소스 풀은 vSphere 클러스터에서 vSphere VM을 논리적으로 묶은 그룹입니다. 기본값이 아닌 리소스 풀을 사용하는 경우 vcenter.resourcepool에 리소스 풀 이름을 제공합니다. 예를 들면 다음과 같습니다.

vcenter:
  ...
  resourcepool: "my-pool"

GKE On-Prem이 해당 노드를 vSphere 클러스터의 기본 리소스 풀에 배포하도록 하려면 vcenter.resourcepool에 빈 문자열을 제공합니다. 예를 들면 다음과 같습니다.

vcenter:
  ...
  resourcepool: ""

vcenter.datadisk

GKE On-Prem은 관리자 클러스터의 Kubernetes 객체 데이터를 저장할 가상 머신 디스크(VMDK)를 만듭니다. 설치 프로그램에서 자동으로 VMDK를 만들지만 vcenter.datadisk 필드에 VMDK 이름을 제공해야 합니다. 예를 들면 다음과 같습니다.

vcenter:
  ...
  datadisk: "my-disk.vmdk"
vSAN Datastore: VMDK에 폴더 만들기

vSAN Datastore를 사용하는 경우 VMDK를 폴더에 두어야 합니다. 폴더는 수동으로 미리 만들어야 합니다. 이렇게 하려면 govc를 사용하여 폴더를 만들면 됩니다.

govc datastore.mkdir -namespace=true my-gke-on-prem-folder

그런 다음 vcenter.datadisk를 폴더가 포함된 VMDK 경로로 설정합니다. 예를 들면 다음과 같습니다.

vcenter:
...
datadisk: "my-gke-on-prem-folder/my-disk.vmdk"

버전 1.1.1 이하에서는 알려진 문제로 인해 파일 경로 대신 폴더의 범용 고유 식별자(UUID) 경로를 vcenter.datadisk에 제공해야 합니다. 위 govc 명령어의 결과에서 이를 복사합니다.

그런 다음 vcenter.datadisk 필드에 폴더의 UUID를 제공합니다. UUID 앞에 슬래시를 사용하지 마세요. 예를 들면 다음과 같습니다.

vcenter:
...
datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"

이 문제는 버전 1.1.2 이상에서 해결되었습니다.

vcenter.cacertpath

GKE On-Prem과 같은 클라이언트가 vCenter Server로 요청을 전송할 때 서버는 인증서 또는 인증서 번들을 제공하여 클라이언트에 해당 ID를 입증해야 합니다. 인증서 또는 번들을 확인하려면 GKE On-Prem의 신뢰 체인에 루트 인증서가 있어야 합니다.

vcenter.cacertpath를 루트 인증서의 경로로 설정합니다. 예를 들면 다음과 같습니다.

vcenter:
  ...
  cacertpath: "/my-cert-folder/the-root.crt"

VMware 설치에는 vCenter Server에 인증서를 발급하는 인증 기관(CA)이 포함됩니다. 신뢰 체인의 루트 인증서는 VMware에서 생성된 자체 서명 인증서입니다.

기본값인 VMWare CA를 사용하지 않을 경우 다른 인증 기관을 사용하도록 VMware를 구성할 수 있습니다.

vCenter Server에 기본 VMware CA에서 발급된 인증서가 사용될 경우에는 루트 인증서를 가져올 수 있는 몇 가지 방법이 있습니다.

  • curl -k "https://[SERVER_ADDRESS]/certs/download.zip" > download.zip

    여기서 [SERVER_ADDRESS]는 vCenter Server의 주소입니다.

  • 브라우저에서 vCenter Server의 주소를 입력합니다. 오른쪽 회색 상자에서 신뢰할 수 있는 루트 CA 인증서 다운로드를 클릭합니다.

  • 다음 명령어를 입력하여 사용 중인 인증서를 가져옵니다.

    true | openssl s_client -connect [SERVER_ADDRESS]:443 -showcerts

    결과에서 https://[SERVER_ADDRESS]/afd/vecs/ca와 비슷한 URL을 찾습니다. 브라우저에 이 URL을 입력합니다. 루트 인증서를 다운로드합니다.

다운로드한 파일 이름은 downloads.zip입니다.

파일의 압축을 풉니다.

unzip downloads.zip

처음에 unzip 명령어가 작동하지 않으면 명령어를 다시 입력합니다.

certs/lin에서 인증서 파일을 찾습니다.

프록시 사양

네트워크가 프록시 서버 뒤에 있는 경우 프록시에서 제외해야 하는 주소와 HTTPS 프록시를 proxy 필드에 입력합니다. 예를 들면 다음과 같습니다.

proxy:
  url: "https://username:password@domain"
  noproxy: "10.0.1.0/24,private-registry.example,10.0.2.1"

관리자 클러스터 사양

관리자 클러스터 사양 admincluster에는 GKE On-Prem이 관리자 클러스터를 만들기 위해 필요한 정보가 포함됩니다.

admincluster.vcenter.network

admincluster.vcenter.network에서는 관리자 클러스터 노드에 대한 vCenter 네트워크를 지정할 수 있습니다. 이는 vcenter에서 제공한 전역 설정보다 우선 적용됩니다. 예를 들면 다음과 같습니다.

admincluster:
  vcenter:
    network: MY-ADMIN-CLUSTER-NETWORK

admincluster.ipblockfilepath

이 필드는 고정 IP를 사용할 경우에 사용됩니다. IP 주소 할당을 위해 DHCP 서버를 사용 중이므로 admincluster.ipblockfilepath 필드는 주석 처리된 상태로 둡니다.

admincluster.bigip.credentials(통합 부하 분산 모드)

통합 부하 분산 모드를 사용하는 경우 GKE On-Prem은 F5 BIG-IP 부하 분산기의 IP 주소 또는 호스트 이름, 사용자 이름, 비밀번호를 알아야 합니다. 이 정보를 제공하려면 admincluster.bigip 아래에서 값을 설정하세요. 예를 들면 다음과 같습니다.

admincluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.2"
      username: "my-admin-f5-name"
      password: "rJDlm^%7aOzw"

admincluster.bigip.credentials(통합 부하 분산 모드)

통합 부하 분산 모드를 사용하는 경우 관리자 클러스터의 BIG-IP 파티션을 만들어야 합니다. admincluster.bigip.partition을 파티션 이름으로 설정합니다. 예를 들면 다음과 같습니다.

admincluster:
  ...
  bigip:
    partition: "my-admin-f5-partition"

admincluster.vips

admincluster.vips.controlplanevip 값을 부하 분산기에서 관리자 클러스터의 Kubernetes API 서버에 구성한 IP 주소로 설정합니다. ingressvip 값을 부하 분산기에서 관리자 클러스터의 인그레스 컨트롤러에 구성한 IP 주소로 설정합니다. 예를 들면 다음과 같습니다.

admincluster:
  ...
  vips:
    controlplanevip: 203.0.113.3
    ingressvip: 203.0.113.4

admincluster.serviceiprange, admincluster.podiprange

관리자 클러스터에는 서비스에 사용할 IP 주소 범위와 Pod에 사용할 IP 주소 범위가 있어야 합니다. 이러한 범위는 admincluster.serviceiprangeadmincluster.podiprange 필드로 지정됩니다. 이러한 필드는 gkectl create-config를 실행할 때 채워집니다. 필요에 따라 채워진 값을 원하는 값으로 변경할 수 있습니다.

서비스 및 pod 범위는 겹치지 않아야 합니다. 또한 서비스 및 pod 범위는 클러스터의 노드에 사용되는 IP 주소와 겹치지 않아야 합니다.

예를 들면 다음과 같습니다.

admincluster:
  ...
  serviceiprange: 10.96.232.0/24
  podiprange: 192.168.0.0/16

사용자 클러스터 사양

사용자 클러스터 사양 usercluster에는 GKE On-Prem이 초기 사용자 클러스터를 만드는 데 필요한 정보가 포함되어 있습니다.

VMware DRS 안티어피니티 규칙 중지(선택사항)

GKE On-Prem은 사용자 클러스터 노드의 VMware Distributed Resource Scheduler(DRS) 안티어피니티 규칙을 자동으로 만들어서 데이터 센터에 있는 물리적 호스트 최소 세 개 이상에 분산되도록 합니다.

이 기능을 사용하려면 vSphere 환경이 다음 조건을 충족해야 합니다.

  • VMware DRS가 사용 설정되어 있습니다. VMware DRS에는 vSphere Enterprise Plus 라이선스 버전이 필요합니다. DRS를 사용 설정하는 방법은 클러스터에서 VMware DRS 사용 설정을 참조하세요.
  • vcenter 필드에 제공된 vSphere 사용자 계정에는 Host.Inventory.EditCluster 권한이 포함됩니다.
  • 사용 가능한 물리적 호스트가 3개 이상입니다.

vSphere 스탠더드 라이선스가 있으면 VMware DRS를 사용 설정할 수 없습니다.

DRS가 사용 설정되지 않았거나 vSphere VM을 예약할 수 있는 호스트가 최소 세 개 이상 없으면 구성 파일에 usercluster.antiaffinitygroups.enabled: false를 추가합니다. 예를 들면 다음과 같습니다.

usercluster:
  ...
  antiaffinitygroups:
    enabled: false

자세한 내용은 1.1.0-gke.6 버전의 출시 노트를 참조하세요.

실행 중인 노드 수가 3개를 초과하는 클러스터
vSphere vMotion에서 노드를 다른 호스트로 이동하는 경우 노드의 워크로드를 다시 시작해야 호스트 간에 다시 분산됩니다.

usercluster.vcenter.network

usercluster.vcenter.network에서는 사용자 클러스터 노드에 사용되는 vCenter 네트워크를 지정할 수 있습니다. 이는 vcenter에서 제공한 전역 설정보다 우선 적용됩니다. 예를 들면 다음과 같습니다.

usercluster:
  vcenter:
    network: MY-USER-CLUSTER-NETWORK

usercluster.ipblockfilepath

이 필드는 고정 IP를 사용할 경우에 사용됩니다. IP 주소 할당을 위해 DHCP 서버를 사용 중이므로 usercluster.ipblockfilepath 필드는 주석 처리된 상태로 둡니다.

usercluster.bigip.credentials(통합 부하 분산 모드)

통합 부하 분산 모드를 사용하는 경우 GKE On-Prem은 사용자 클러스터에 사용할 F5 BIG-IP 부하 분산기의 IP 주소 또는 호스트 이름, 사용자 이름, 비밀번호를 알아야 합니다. 이 정보를 제공하려면 usercluster.bigip 아래에서 값을 설정하세요. 예를 들면 다음과 같습니다.

usercluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.5"
      username: "my-user-f5-name"
      password: "8%jfQATKO$#z"
  ...

usercluster.bigip.partition(통합 부하 분산 모드)

사용자 클러스터에 대한 BIG-IP 파티션을 만들어야 합니다. usercluster.bigip.partition을 파티션 이름으로 설정합니다. 예를 들면 다음과 같습니다.

usercluster:
  ...
  bigip:
    partition: "my-user-f5-partition"
  ...

usercluster.vips

usercluster.vips.controlplanevip 값을 부하 분산기에서 사용자 클러스터의 Kubernetes API 서버에 구성한 IP 주소로 설정합니다. ingressvip 값을 부하 분산기에서 사용자 클러스터의 인그레스 컨트롤러에 구성한 IP 주소로 설정합니다. 예를 들면 다음과 같습니다.

usercluster:
  ...
  vips:
    controlplanevip: 203.0.113.6
    ingressvip: 203.0.113.7

usercluster.serviceiprange, usercluster.podiprange

사용자 클러스터에는 서비스에 사용할 IP 주소 범위와 pod에 사용할 IP 주소 범위가 있어야 합니다. 이러한 범위는 usercluster.serviceiprangeusercluster.podiprange 필드로 지정됩니다. 이러한 필드는 gkectl create-config를 실행할 때 채워집니다. 필요에 따라 채워진 값을 원하는 값으로 변경할 수 있습니다.

서비스 및 pod 범위는 겹치지 않아야 합니다. 또한 서비스 및 pod 범위는 클러스터의 노드에 사용되는 IP 주소와 겹치지 않아야 합니다.

예를 들면 다음과 같습니다.

usercluster:
  ...
  serviceiprange: 10.96.233.0/24
  podiprange: 172.16.0.0/12

usercluster.clustername

usercluster.clustername의 값을 원하는 이름으로 설정합니다. 40자(영문 기준)를 초과하지 않는 이름을 선택하세요. 예를 들면 다음과 같습니다.

usercluster:
  ...
  clustername: "my-user-cluster-1"

usercluster.masternode.replicas

usercluster.masternode.replicas 필드는 사용자 클러스터에 포함할 제어 영역 노드 수를 지정합니다. 사용자 클러스터의 제어 영역 노드는 Kubernetes 제어 영역 구성요소인 사용자 제어 영역을 실행합니다. 이 값은 1 또는 3이어야 합니다.

  • 사용자 제어 영역 하나를 실행하려면 이 필드를 1로 설정합니다.
  • 각 항목이 사용자 제어 영역을 실행하는 제어 영역 노드 세 개로 구성된 고가용성(HA) 사용자 제어 영역을 사용하려면 이 필드를 3으로 설정합니다.

usercluster.masternode.cpususercluster.masternode.memorymb

usercluster.masternode.cpususercluster.masternode.memorymb 필드에는 사용자 클러스터의 각 제어 영역 노드에 할당되는 CPU 수 및 메모리 양(MB)이 지정됩니다. 예를 들면 다음과 같습니다.

usercluster:
  ...
  masternode:
    cpus: 4
    memorymb: 8192

usercluster.workernode.replicas

usercluster.workernode.replicas 필드에는 사용자 클러스터에 포함할 워커 노드 수가 지정됩니다. 워커 노드는 클러스터 워크로드를 실행합니다.

usercluster.workernode.cpususercluster.workernode.memorymb

usercluster.masternode.cpususercluster.masternode.memorymb 필드에는 사용자 클러스터의 각 워커 노드에 할당된 CPU 수와 메모리 양이 지정됩니다. 예를 들면 다음과 같습니다.

usercluster:
  ...
  workernode:
    cpus: 4
    memorymb: 8192
    replicas: 3

usercluster.oidc

사용자 클러스터의 클라이언트가 OIDC 인증을 사용하도록 하려면 usercluster.oidc 아래에서 필드에 대해 값을 설정합니다. OIDC 구성은 선택사항입니다.

OIDC 구성 방법을 알아보려면 OIDC로 인증을 참조하세요.

1.0.2-gke.3 버전 설치 정보

버전 1.0.2-gke.3에는 다음 OIDC 필드(usercluster.oidc)가 도입되었습니다. 이러한 필드를 통해 Cloud Console에서 클러스터에 로그인할 수 있습니다.

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

버전 1.0.2-gke.3에서 OIDC를 사용하려면 Cloud Console에서 클러스터에 로그인하지 않더라도 clientsecret 필드가 필요합니다. 이 경우 clientsecret에 자리표시자 값을 제공할 수 있습니다.

oidc:
clientsecret: "secret"

usercluster.sni

전송 계층 보안(TLS)의 확장 기능인 서버 이름 표시(SNI)를 통해 서버는 클라이언트에 표시된 호스트 이름에 따라 단일 IP 주소 및 TCP 포트에 여러 인증서를 제공할 수 있습니다.

CA가 이미 사용자 클러스터 외부의 클라이언트에 신뢰할 수 있는 CA로 배포되었고 이 체인을 사용해서 신뢰할 수 있는 클러스터를 식별하려면, 부하 분산기 IP 주소의 외부 클라이언트에 제공된 추가 인증서를 사용해서 Kubernetes API 서버를 구성할 수 있습니다.

사용자 클러스터에서 SNI를 사용하려면 고유 CA 및 공개 키 인프라(PKI)가 있어야 합니다. 각 사용자 클러스터에 대해 사용 중인 개별 인증서를 프로비저닝하고 GKE On-Prem은 사용 중인 각 인증서를 해당 사용자 클러스터에 추가합니다.

사용자 클러스터의 Kubernetes API 서버에 대해 SNI를 구성하려면 usercluster.sni.certpath의 값(외부 인증서 경로) 및 usercluster.sni.keypath의 값(외부 인증서의 비공개 키 파일 경로)을 제공합니다. 예를 들면 다음과 같습니다.

usercluster:
  ...
  sni:
    certpath: "/my-cert-folder/example.com.crt"
    keypath: "/my-cert-folder/example.com.key"

lbmode

통합 부하 분산을 DHCP에 사용할 수 있습니다. 통합 부하 분산 모드는 관리자 클러스터 및 초기 사용자 클러스터에 적용됩니다. 이후에 만드는 모든 추가적인 사용자 클러스터에도 적용됩니다. 통합 부하 분산 모드에서는 F5 BIG-IP를 부하 분산기로 사용할 수 있습니다.

lbmode 값을 Integrated로 설정합니다. 예를 들면 다음과 같습니다.

lbmode: Integrated

gkeconnect

gkeconnect 사양에는 GKE On-Prem이 Google Cloud Console에서 온프렘 클러스터 관리를 설정하는 데 필요한 정보가 포함되어 있습니다.

gkeconnect.projectid를 온프렘 클러스터를 관리하려는 Google Cloud 프로젝트의 프로젝트 ID로 설정합니다.

gkeconnect.registerserviceaccountkeypath 값을 등록 서비스 계정의 JSON 키 파일 경로로 설정합니다. gkeconnect.agentserviceaccountkeypath의 값을 연결 서비스 계정에 대한 JSON 키 파일의 경로로 설정합니다.

예:

gkeconnect:
  projectid: "my-project"
  registerserviceaccountkeypath: "/my-key-folder/register-key.json"
  agentserviceaccountkeypath: "/my-key-folder/connect-key.json"

stackdriver

stackdriver 사양에는 GKE On-Prem이 온프렘 클러스터에서 생성된 로그 항목을 저장하기 위해 필요한 정보가 포함되어 있습니다.

stackdriver.projectid를 온프렘 클러스터와 관련된 Stackdriver 로그를 보려는 Google Cloud 프로젝트의 프로젝트 ID로 설정합니다.

stackdriver.clusterlocation을 Stackdriver 로그를 저장하려는 Google Cloud 리전으로 설정합니다. 온프레미스 데이터 센터와 가까운 리전을 선택하는 것이 좋습니다.

클러스터의 네트워크가 VPC로 제어되는 경우 stackdriver.enablevpctrue로 설정합니다. 이렇게 하면 모든 원격 분석이 Google의 제한된 IP 주소를 통해 이동합니다.

stackdriver.serviceaccountkeypathStackdriver Logging 서비스 계정의 JSON 키 파일 경로로 설정합니다. 예를 들면 다음과 같습니다.

stackdriver:
  projectid: "my-project"
  clusterlocation: "us-west1"
  enablevpc: false
  serviceaccountkeypath: "/my-key-folder/stackdriver-key.json"

privateregistryconfig

비공개 Docker 레지스트리가 있는 경우 privateregistryconfig 필드에는 GKE On-Prem에서 비공개 레지스트리에 이미지를 푸시하는 데 사용하는 정보가 포함됩니다. 비공개 레지스트리를 지정하지 않으면 gkectl이 설치 중에 Container Registry 저장소 gcr.io/gke-on-prem-release에서 GKE On-Prem의 컨테이너 이미지를 가져옵니다.

privatedockerregistry.credentials에서 address를 비공개 Docker 레지스트리를 실행하는 머신의 IP 주소로 설정합니다. usernamepassword를 비공개 Docker 레지스트리의 사용자 이름과 비밀번호로 설정합니다. address에 설정한 값이 자동으로 proxy.noproxy에 추가됩니다.

Docker가 비공개 레지스트리에서 이미지를 가져올 때 레지스트리는 인증서를 제공하여 해당 ID를 입증해야 합니다. 레지스트리 인증서는 인증 기관(CA)에서 서명됩니다. Docker는 CA 인증서를 사용하여 레지스트리 인증서를 검사합니다.

privateregistryconfig.cacertpath를 CA 인증서 경로로 설정합니다. 예를 들면 다음과 같습니다.

privateregistryconfig
  ...
  cacertpath: /my-cert-folder/registry-ca.crt

gcrkeypath

gcrkeypath의 값을 구성요소 액세스 서비스 계정의 JSON 키 파일 경로로 설정합니다.

예를 들면 다음과 같습니다.

gcrkeypath: "/my-key-folder/component-access-key.json"

cloudauditlogging

Kubernetes 감사 로그를 Google Cloud 프로젝트로 보내려면 cloudauditlogging 사양을 채웁니다. 예를 들면 다음과 같습니다.

cloudauditlogging:
  projectid: "my-project"
  # A Google Cloud region where you would like to store audit logs for this cluster.
  clusterlocation: "us-west1"
  # The absolute or relative path to the key file for a Google Cloud service account used to
  # send audit logs from the cluster
  serviceaccountkeypath: "/my-key-folder/audit-logging-key.json"

감사 로깅 사용에 대해 자세히 알아보기

구성 파일 유효성 검사

관리 워크스테이션에서 이 단계를 완료합니다.

구성 파일을 수정한 후에는 gkectl check-config를 실행하여 파일이 올바르고 설치에 사용될 수 있는지 확인합니다.

gkectl check-config --config config.yaml

명령어가 FAILURE 메시지를 반환하면 문제를 해결하고 파일 유효성을 다시 검사합니다.

시간이 오래 걸리는 검사를 건너뛰려면 --fast 플래그를 전달합니다. 개별 검사를 건너뛰려면 --skip-validation-xxx 플래그를 사용합니다. check-config 명령어에 대해 자세히 알아보려면 실행 전 검사 실행을 참조하세요.

gkectl prepare 실행

설치하기 전 관리 워크스테이션에서 gkectl prepare를 실행하여 vSphere 환경을 초기화해야 합니다. gkectl prepare는 다음 태스크를 수행합니다.

  • 노드 OS 이미지를 vSphere로 가져오고 템플릿으로 표시합니다.

  • 선택적으로 컨테이너 이미지의 빌드 증명을 검사하여 이미지가 빌드되었고, Google에서 서명되었으며, 배포에 사용할 준비가 되었는지 확인합니다.

GKE On-Prem 구성 파일로 gkectl prepare를 실행합니다. 여기서 --validate-attestations는 선택사항입니다.

gkectl prepare --config [CONFIG_FILE] --validate-attestations

--validate-attestations의 긍정 출력은 Image [IMAGE_NAME] validated입니다.

GKE On-Prem 설치

지금까지 환경과 클러스터 모양을 지정하는 구성 파일을 만들고 파일의 유효성을 검사했습니다. 그리고 GKE On-Prem 소프트웨어로 환경을 초기화하도록 gkectl prepare를 실행했습니다. 이제 GKE On-Prem을 새로 설치할 수 있습니다.

GKE On-Prem을 설치하려면 관리자 클러스터와 사용자 클러스터를 만듭니다. 다음 단계에서는 동일한 프로세스 중에 관리자 클러스터와 사용자 클러스터를 모두 만듭니다. 각 클러스터를 개별적으로 만들려면 관리자 클러스터 및 사용자 클러스터를 개별적으로 만들기를 참조하세요.

관리자 클러스터와 사용자 클러스터를 만들려면 다음 안내를 따르세요.

  1. gkectl create cluster 명령어를 실행하여 관리자 클러스터와 사용자 클러스터를 만듭니다.

    gkectl create cluster --config [CONFIG_FILE]

    여기서 [CONFIG_FILE]은 앞서 만든 구성 파일입니다.

    gkectl create cluster 명령어는 현재 디렉터리에 [CLUSTER_NAME]-kubeconfig라는 kubeconfig 파일을 만듭니다. 여기서 [CLUSTER_NAME]cluster에 설정한 이름입니다. 예: MY-VSPHERE-CLUSTER-kubeconfig

    GKE On-Prem 문서에서는 다음과 같은 자리표시자를 사용하여 이러한 kubeconfig 파일을 나타냅니다.

    • 관리자 클러스터: [ADMIN_CLUSTER_KUBECONFIG]
    • 사용자 클러스터: [USER_CLUSTER_KUBECONFIG]
  2. 클러스터가 생성되었고 실행 중인지 확인합니다.

    1. 관리자 클러스터를 확인하려면 다음 명령어를 실행합니다.

      kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

      출력에 관리자 클러스터 노드가 표시됩니다.

    2. 사용자 클러스터를 확인하려면 다음 명령어를 실행합니다.

      kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]

      출력에 사용자 클러스터 노드가 표시됩니다. 예를 들면 다음과 같습니다.

      NAME                        STATUS   ROLES    AGE   VERSION
      xxxxxx-1234-ipam-15008527   Ready    <none>   12m   v1.14.7-gke.24
      xxxxxx-1234-ipam-1500852a   Ready    <none>   12m   v1.14.7-gke.24
      xxxxxx-1234-ipam-15008536   Ready    <none>   12m   v1.14.7-gke.24
      

구성 파일을 다시 사용하여 추가 사용자 클러스터를 만드는 방법을 알아보세요.

설치 재개

관리자 클러스터를 만든 후 설치가 중단된 경우 다음 단계에 따라 설치를 재개할 수 있습니다.

  1. 구성 파일에서 admincluster 사양을 삭제합니다.
  2. --kubeconfig--skip-validation-all 플래그를 모두 사용해 gkectl create cluster를 실행하여 관리자 클러스터의 kubeconfig 파일을 전달하고 실행 전 검사를 건너뜁니다.

    gkectl create cluster  \
    --config [CONFIG_FILE] \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --skip-validation-all
    

    여기서 [ADMIN_CLUSTER_NAME]은 설치를 시작할 때 작업 디렉터리에 생성된 관리자 클러스터의 kubeconfig입니다.

Google에 클러스터 연결

  • gkeconnect 사양을 입력하면 사용자 클러스터가 Cloud Console에 자동으로 등록됩니다. Cloud Console의 Kubernetes 클러스터 메뉴에서 등록된 GKE On-Prem 클러스터를 볼 수 있습니다. 여기에서 클러스터에 로그인하여 해당 워크로드를 볼 수 있습니다.

  • 클러스터를 만들고 1시간 내에 Cloud Console에 클러스터가 표시되지 않으면 연결 문제 해결을 참조하세요.

인그레스 사용 설정

사용자 클러스터가 실행되면 게이트웨이 객체를 만들어 인그레스를 사용 설정해야 합니다. 게이트웨이 매니페스트의 첫 번째 부분은 항상 다음과 같습니다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system

니즈에 따라 매니페스트의 나머지 부분을 조정할 수 있습니다. 예를 들어 이 매니페스트에는 클라이언트가 HTTP/2 프로토콜과 모든 호스트 이름을 사용하여 포트 80으로 요청을 전송할 수 있도록 지정되어 있습니다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system
  servers:
  - port:
      number: 80
      protocol: HTTP2
      name: http
    hosts:
    - "*"

HTTPS 요청을 수락하려면 인그레스 컨트롤러에서 클라이언트에 제공할 수 있는 하나 이상의 인증서를 제공해야 합니다.

인증서를 제공하려면 다음 안내를 따르세요.

  1. 인증서와 키가 포함된 보안 비밀을 만듭니다.
  2. 게이트웨이 객체를 만들거나 보안 비밀을 참조하는 기존 게이트웨이 객체를 수정합니다. 게이트웨이 객체 이름은 istio-autogenerated-k8s-ingress여야 합니다.

예를 들어 인증서 파일 ingress-wildcard.crt와 키 파일 ingress-wildcard.key가 이미 생성되었다고 가정합니다.

ingressgateway-wildcard-certs라는 보안 비밀을 만듭니다.

kubectl create secret tls \
    --namespace gke-system \
    ingressgateway-wildcard-certs \
    --cert ./ingress-wildcard.crt \
    --key ./ingress-wildcard.key

다음은 보안 비밀을 참조하는 게이트웨이의 매니페스트입니다. 클라이언트는 HTTPS 프로토콜 및 *.example.com과 일치하는 모든 호스트 이름을 사용하여 포트 443으로 호출을 수행할 수 있습니다. 인증서의 호스트 이름은 매니페스트에 있는 호스트 이름과 일치해야 합니다(이 예시에서는 *.example.com).

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system
  servers:
  - port:
      number: 80
      protocol: HTTP2
      name: http
    hosts:
    - "*"
  - hosts:
    - "*.example.com"
    port:
      name: https-demo-wildcard
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: ingressgateway-wildcard-certs

게이트웨이 매니페스트를 수정하여 서로 다른 호스트에 TLS 인증서를 여러 개 만들 수 있습니다.

매니페스트를 my-gateway.yaml이라는 파일에 저장하고 게이트웨이를 만듭니다.

kubectl apply -f my-gateway.yaml

이제 표준 방식으로 Kubernetes 인그레스 객체를 사용할 수 있습니다.

관리자 클러스터 및 사용자 클러스터를 개별적으로 만들기

GKE On-Prem 버전 1.2부터 관리자 클러스터와 사용자 클러스터를 개별적으로 만들 수 있습니다. 즉, 관리자 클러스터 생성부터 시작할 수 있습니다. 그런 다음 필요에 따라 사용자 클러스터를 하나 이상 만들 수 있습니다.

버전 1.2 이전:

  • 첫 번째 사용자 클러스터에는 항상 관리자 클러스터의 Datastore가 사용되었습니다. 이후에 생성된 사용자 클러스터는 관리자 클러스터의 Datastore와 별개인 다른 Datastore를 사용할 수 있습니다.

  • 사용자 클러스터에 별개의 Datastore를 지정한 경우 사용자 클러스터 워커 노드와 워커 노드에 대한 PersistentVolume(PV)에 별개의 Datastore가 사용되었습니다. 하지만 사용자 제어 영역 VM과 관련 PV에는 관리자 클러스터의 Datastore가 사용되었습니다.

버전 1.2 기준:

  • 첫 번째 사용자 클러스터를 포함하여 모든 사용자 클러스터가 관리자 클러스터의 Datastore와 별개인 다른 Datastore를 사용할 수 있습니다.

  • 사용자 클러스터에 별개의 Datastore를 지정하면 사용자 클러스터 워커 노드, 사용자 클러스터 워커 노드의 PV, 사용자 제어 영역 VM, 사용자 제어 영역 VM의 PV 모두에 별개의 Datastore가 사용됩니다.

관리자 클러스터만 만들려면 클러스터 구성 파일에서 전체 usercluster 섹션을 삭제합니다. 그런 다음 gkectl create 명령어를 입력합니다.

gkectl create --config [ADMIN_CONFIG_FILE]

여기서 [ADMIN_CONFIG_FILE]usercluster 섹션이 삭제된 구성 파일의 경로입니다.

그런 다음 전체 admincluster 섹션이 삭제된 구성 파일을 만듭니다. 이 파일에서는 관리자 클러스터의 Datastore와 다른 vSphere Datastore를 지정할 수 있습니다. Datastore를 지정하려면 vcenter.credentials.datastore 값을 입력합니다. 예를 들면 다음과 같습니다.

vcenter:
  credentials:
    ...
  ...
  datastore: "my-user-cluster-datastore"

사용자 클러스터를 만들려면 다음 명령어를 입력합니다.

gkectl create --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]

각 항목의 의미는 다음과 같습니다.

  • [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일입니다.
  • [USER_CLUSTER_CONFIG]는 사용자 클러스터의 구성 파일입니다.

제한사항

제한사항 설명
클러스터와 노드의 최대 및 최소 한도

할당량 및 한도를 참조하세요. 이러한 한도는 환경 성능에 따라 달라질 수 있습니다.

사용자 클러스터 이름의 고유성

동일한 Google Cloud 프로젝트에 등록된 모든 사용자 클러스터에는 고유한 이름이 있어야 합니다.

vCenter 또는 vSphere 데이터 센터 두 개 이상에 배포할 수 없음

현재 관리자 클러스터와 연관된 사용자 클러스터 집합을 단일 vCenter 또는 vSphere 데이터 센터에만 배포할 수 있습니다. 동일한 관리자 및 사용자 클러스터를 둘 이상의 vCenter 또는 vSphere 데이터 센터에 배포할 수 없습니다.

생성 후 클러스터 구성을 선언적으로 변경할 수 없음 추가 클러스터 만들기기존 클러스터 크기 조절은 가능하지만 구성 파일을 통해 기존 클러스터를 변경할 수 없습니다.

문제해결

자세한 내용은 문제 해결을 참조하세요.

gkectl을 사용하여 클러스터 문제 진단

gkectl diagnose 명령어를 사용하여 클러스터 문제를 식별하고 클러스터 정보를 Google과 공유하세요. 클러스터 문제 진단을 참조하세요.

기본 로깅 동작

gkectlgkeadm의 경우 기본 로깅 설정만 사용해도 됩니다.

  • 기본적으로 로그 항목은 다음과 같이 저장됩니다.

    • gkectl의 기본 로그 파일은 /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log이며 파일은 gkectl을 실행하는 로컬 디렉터리의 logs/gkectl-$(date).log 파일과 심볼릭 링크됩니다.
    • gkeadm의 경우 기본 로그 파일은 gkeadm을 실행하는 로컬 디렉터리의 logs/gkeadm-$(date).log입니다.
  • 모든 로그 항목은 터미널에서 출력되지 않더라도 로그 파일에 저장됩니다(--alsologtostderrfalse인 경우).
  • -v5 세부정보 수준(기본값)에는 지원팀에 필요한 모든 로그 항목이 포함됩니다.
  • 로그 파일에는 실행된 명령어와 실패 메시지도 포함되어 있습니다.

도움이 필요한 경우 로그 파일을 지원팀에 보내는 것이 좋습니다.

로그 파일에 기본값이 아닌 위치 지정

gkectl 로그 파일에 기본값이 아닌 위치를 지정하려면 --log_file 플래그를 사용합니다. 지정한 로그 파일은 로컬 디렉터리와 심볼릭 링크되지 않습니다.

gkeadm 로그 파일에 기본값이 아닌 위치를 지정하려면 --log_file 플래그를 사용합니다.

관리자 클러스터에서 Cluster API 로그 찾기

관리자 제어 영역이 시작된 후에 VM을 시작하지 못하는 경우 다음 안내에 따라 관리자 클러스터에서 Cluster API 컨트롤러의 로그를 검사하여 디버깅할 수 있습니다.

  1. kube-system 네임스페이스에서 Cluster API 컨트롤러 pod의 이름을 찾습니다. 여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일 경로입니다.

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. pod의 로그를 엽니다. 여기서 [POD_NAME]은 pod 이름입니다. 원하는 경우 grep 또는 비슷한 도구를 사용하여 오류를 검색합니다.

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

관리자 클러스터 제어 영역 노드의 kubeconfig를 사용하여 F5 BIG-IP 문제 디버깅

설치 후 GKE On-Prem은 이름이 internal-cluster-kubeconfig-debug인 관리자 워크스테이션의 홈 디렉터리에 kubeconfig 파일을 생성합니다. 이 kubeconfig 파일은 관리자 클러스터의 kubeconfig와 동일하지만 관리 제어 영역이 실행되는 관리자 클러스터의 제어 영역 노드를 직접 가리킨다는 것만 다릅니다. internal-cluster-kubeconfig-debug 파일을 사용하여 F5 BIG-IP 문제를 디버깅할 수 있습니다.

gkectl check-config 검사 실패: F5 BIG-IP 파티션을 찾을 수 없음

증상

F5 BIG-IP 파티션이 존재하더라도 이를 찾을 수 없어서 검사가 실패합니다.

가능한 원인

F5 BIG-IP API 관련 문제로 인해 검사가 실패할 수 있습니다.

해결 방법

gkectl check-config를 다시 실행해 보세요.

gkectl prepare --validate-attestations 실패: 빌드 증명을 검사할 수 없음

증상

선택사항인 --validate-attestations 플래그로 gkectl prepare를 실행하면 다음 오류가 반환됩니다.

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
가능한 원인

해당 이미지에 대한 증명이 존재하지 않을 수 있습니다.

해결 방법

관리 워크스테이션 만들기 안내를 따라 관리 워크스테이션 OVA를 다시 다운로드하고 배포하세요. 문제가 계속되면 Google에 도움을 요청하세요.

부트스트랩 클러스터 로그를 사용하여 디버깅

설치 중 GKE On-Prem은 임시 부트스트랩 클러스터를 만듭니다. 설치가 성공한 후에는 GKE On-Prem이 부트스트랩 클러스터를 삭제하고 관리자 및 사용자 클러스터를 남겨둡니다. 일반적으로 이 클러스터와 상호작용할 이유가 없습니다.

설치 중 문제가 발생하고 --cleanup-external-cluster=falsegkectl create cluster에 전달한 경우 부트스트랩 클러스터의 로그를 사용하여 디버깅하는 것이 유용할 수 있습니다. Pod를 찾은 후 해당 로그를 가져올 수 있습니다.

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

다음 단계