고정 IP를 사용하여 설치

이 페이지에서는 고정 IP를 사용하여 VM 기반의 VMware vSphere 6.5 환경에 GKE On-Prem을 설치하는 방법을 설명합니다. DHCP 서버를 사용하여 설치할 수도 있습니다.

개요

이 페이지의 안내에서는 3개의 노드를 사용하여 관리자 클러스터와 1개의 사용자 클러스터를 만드는 방법을 보여줍니다.

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

시작하기 전에

  1. 시스템 요구사항에 설명된 대로 온프렘 환경을 설정합니다.

  2. 설치 준비의 절차를 따릅니다.

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

  4. 수동 부하 분산을 사용하려는 경우 수동 부하 분산을 사용 설정하는 방법을 알아봅니다.

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

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]

  6. 프록시를 사용하는 경우 gcloud 및 gsutil 명령어를 실행할 수 있도록 프록시에 Google Cloud CLI를 구성해야 합니다. 자세한 내용은 gcloud CLI를 프록시/방화벽 뒤에서 사용할 수 있도록 구성을 참조하세요.

  7. 계정 사용자 인증 정보를 사용하여 Google Cloud에 로그인합니다.

    gcloud auth login

  8. gcloud를 Docker 사용자 인증 정보 도우미로 등록합니다. (이 명령어에 대해 자세히 알아보기)

    gcloud auth configure-docker

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

    gcloud config set project [PROJECT_ID]

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

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

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

Container Registry

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

비공개 Docker 레지스트리

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

설치하려면 먼저 레지스트리를 구성해야 합니다. 설치 중에는 레지스트리에 대한 정보를 GKE On-Prem 구성 파일에 채워야 합니다.

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

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

설치에 비공개 Docker 레지스트리를 사용하려면 인증서에 서명한 CA를 관리 워크스테이션 VM이 신뢰해야 합니다. 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이 인증서를 신뢰하지 않습니다.

고정 IP 구성

설치 중에 GKE On-Prem 구성 파일을 생성합니다. 생성하는 구성 파일에는 다음의 두 ipblockfilepath 필드가 포함됩니다.

  • admincluster.ipblockfilepath
  • usercluster.ipblockfilepath.

ipblockfilepath는 아래에 설명된 것처럼 호스트 구성(또는 hostconfig) 파일이 포함된 YAML 파일의 경로를 수락합니다.

고정 IP를 사용하려면 관리자 워크스테이션에 두 개의 YAML 파일을 만들어야 합니다. hostconfig를 포함한 파일은 관리자 클러스터에서 사용되며 다른 하나는 사용자 클러스터에서 사용됩니다.

관리자 클러스터 IP 구성에는 최소 N + 4 개의 IP/호스트 이름 쌍이 필요합니다. 여기서 N은 만들려는 사용자 클러스터의 수입니다.

고가용성 사용자 클러스터를 만들도록 선택할 수 있습니다. HA 사용자 클러스터는 세 가지 사용자 제어 영역을 사용합니다. 사용자 제어 영역을 실행하는 각 VM에는 고유한 고정 IP가 필요합니다. 사용자 제어 영역이 관리자 클러스터에서 관리되므로 이러한 값은 관리자 클러스터의 hostconfig 파일에서 제공되어야 합니다.

예시

다음은 호스트가 3개인 hostconfig 파일의 예시입니다. 환경에 따라 파일이 다르게 표시될 수 있습니다. 예를 들어 ips 배열을 더 많은 ip/hostname 쌍으로 펼칠 수 있습니다.

hostconfig:
  dns: 172.16.255.1
  tod: 192.138.210.214
  otherdns:
  - 8.8.8.8
  - 8.8.4.4
  othertod:
  - ntp.ubuntu.com
blocks:
  - netmask: 255.255.252.0
    gateway: 110.116.232.1
    ips:
    - ip: 10.116.232.23
      hostname: host1.enterprise.net  # will be trimmed to host1
    - ip: 10.116.232.65
      hostname: host2.enterprise.net  # will be trimmed to host2
    - ip: 10.116.232.66
      hostname: host3.enterprise.net  # will be trimmed to host3

YAML 파일에는 hostconfig 및 blocks라는 2개의 섹션이 있습니다.

hostconfig

hostconfig에는 모든 클러스터 노드에 정적으로 적용되는 네트워킹 매개변수가 포함됩니다. hostconfig는 다음의 값을 구성합니다.

  • dns: 노드에 사용할 DNS 서버의 IP 주소입니다.
  • tod: 노드에 사용할 시간 서버의 IP 주소입니다.
  • otherdns: 노드에 사용할 대체 DNS 서버입니다.
  • othertod: 노드에 사용할 대체 시간 서버입니다.

blocks

blocks는 고정 IP 주소 블록의 배열을 포함합니다. 현재 GKE On-Prem에서는 IP 할당을 위한 첫 번째 블록만 고려합니다. 각 블록은 네트워크 및 네트워크 내의 IP 주소를 나타냅니다.

netmask, gateway

netmask 및 gateway는 노드에 사용할 네트워크 마스크 및 기본 게이트웨이를 나타냅니다.

blocks:
  - netmask: 255.255.252.0
    gateway: 110.116.232.1

ips

ips 배열은 할당한 IP를 나열합니다. 배열의 각 객체에는 IPv4 주소 및 호스트 이름이 포함됩니다.

blocks:
...
  ips:
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
...

GKE On-Prem은 이 블록 내에 있는 무료 IP 주소와 할당된 IP 주소를 추적하고 사용 가능한 IP 주소 하나를 클러스터의 각 노드에 할당합니다. 배열의 IP 주소 수가 클러스터의 노드 수보다 엄밀하게 많고 각 IP 주소가 사용자 환경의 네트워크에 고유하는지 확인합니다.

hostname은 도메인이 없는 로컬 호스트 이름으로 간주합니다. 정규화된 도메인 이름(FQDN)을 지정하면 도메인 이름이 잘립니다. 예를 들어 host1.enterprise.net은 host1이 됩니다. hostname 값은 소문자여야 합니다.

hostconfig 파일 만들기

다음은 3개의 노드가 있는 사용자 클러스터에 대한 hostconfig 파일의 예시입니다.

  1. 다음의 템플릿을 YAML 파일에 복사합니다.

    hostconfig:
  dns:
  tod:
blocks:
  - netmask:
    gateway:
    ips:
    - ip:
      hostname:
    - ip:
      hostname:
    - ip:
      hostname:

  2. admin-cluster-hostconfig.yaml 및 user-cluster-hostconfig.yaml와 같이, 다른 이름으로 파일을 저장합니다.

  3. 설치 중에 구성 파일의 admincluster.ipblockfilepath 및 usercluster.ipblockfilepath 필드를 적절한 파일로 수정합니다.

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

설치 준비에서 서비스 계정을 4개 만들었습니다. 이제 이러한 서비스 계정마다 JSON 비공개 키를 만들어야 합니다. 이러한 키는 설치 중에 사용됩니다.

서비스 계정의 이메일 주소 나열

먼저 Google Cloud 프로젝트의 서비스 계정을 나열합니다.

gcloud iam service-accounts list

이름이 my-gcp-project인 Google Cloud 프로젝트에서 이 명령어의 출력은 다음과 같이 표시됩니다.

gcloud iam service-accounts list
NAME                                    EMAIL
                                        access-service-account@my-gcp-project.iam.gserviceaccount.com
                                        register-service-account@my-gcp-project.iam.gserviceaccount.com
                                        connect-service-account@my-gcp-project.iam.gserviceaccount.com
                                        stackdriver-service-account@my-gcp-project.iam.gserviceaccount.com

각 계정의 이메일 주소를 기록합니다. 다음 각 섹션에 관련 계정의 이메일 계정을 제공합니다.

액세스 서비스 계정

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

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

등록 서비스 계정

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

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

연결 서비스 계정

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

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

Cloud Monitoring 서비스 계정

gcloud iam service-accounts keys create stackdriver-key.json \
--iam-account [STACKDRIVER_SERVICE_ACCOUNT_EMAIL]

여기서 [STACKDRIVER_SERVICE_ACCOUNT_EMAIL]은 Cloud Monitoring 서비스 계정의 이메일 주소입니다.

Google Cloud CLI용 액세스 서비스 계정 활성화

gcloud CLI용 액세스 서비스 계정을 활성화하면 모든 gcloud 명령어와 gsutil 명령어가 이 서비스 계정으로 실행됩니다. 액세스 서비스 계정이 GKE On-Prem 바이너리에 액세스할 수 있도록 허용 목록에 포함되므로 gcloud CLI용 계정을 활성화하면 Cloud Storage에서 GKE On-Prem의 바이너리를 다운로드할 수 있는 권한이 주어집니다.

액세스 서비스 계정을 활성화하려면 다음 명령어를 실행합니다. 현재 작업 디렉터리에 계정의 키 파일이 없는 경우 계정의 키 파일 경로를 제공해야 합니다.

gcloud auth activate-service-account --key-file=access-key.json

구성 파일 생성

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

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

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

구성 파일 수정

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

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.1.2-gke.0입니다.

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

vCenter 사양

vcenter 사양에는 vCenter Server 인스턴스에 대한 정보가 포함되어 있습니다. GKE On-Prem은 vCenter Server와 통신하기 위해 이 정보가 필요합니다.

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 아래에서 username 및 password 값을 설정하세요. 예를 들면 다음과 같습니다.

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 my-gke-on-prem-folder

현재 알려진 문제로 인해 해당 파일 경로 대신 폴더의 범용 고유 식별자(UUID) 경로를 vcenter.datadisk에 제공해야 합니다. 폴더의 UUID를 찾으려면 vCenter 클라이언트를 열고 Datastore를 선택한 후 폴더를 선택합니다. 폴더의 UUID를 복사합니다. 또한 다음 명령어를 실행할 수도 있습니다. 여기서 [ADMIN_CONTROL_PLANE_VM]은 관리 제어 영역을 실행하는 vSphere VM입니다.

govc vm.info -json ./vm/[ADMIN_CONTROL_PLANE_VM] | jq '.VirtualMachines[0].Config.Hardware.Device[] | select(.Backing | has("FileName")) | .Backing.FileName'

그런 다음 vcenter.datadisk 필드에 폴더의 UUID를 제공합니다. 예를 들면 다음과 같습니다.

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

vcenter.cacertpath

GKE On-Prem과 같은 클라이언트가 vCenter Server로 요청을 전송할 때 서버는 인증서를 제공하여 클라이언트에 해당 ID를 입증해야 합니다. 인증서는 인증 기관(CA)에 의해 서명됩니다. 클라이언트는 CA의 인증서를 사용하여 서버의 인증서를 확인합니다.

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

vcenter:
  ...
  cacertpath: "/my-cert-folder/altostrat.crt"

vCenter Server가 자체 서명된 인증서를 사용하는지 또는 공개 CA에 의해 서명된 인증서를 사용하는지에 관계없이 관리 워크스테이션에서 다음 명령어를 실행하여 CA의 인증서를 가져올 수 있습니다.

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

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

프록시 사양

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

proxy:
  url: "https://password:username@domain"
  noproxy: "100.151.222.0/24,corp.domain,100.151.2.1"
  • proxy.url은 HTTPS 프록시의 URL입니다.
  • proxy.noproxy에는 프록시를 사용하지 않아야 하는 CIDR, 도메인, IP 주소가 포함되어 있습니다. 비공개 Docker 레지스트리를 사용하는 경우 일반적으로 vSphere 서브넷과 비공개 레지스트리 주소가 포함됩니다.

관리자 클러스터 사양

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

admincluster.vcenter.network

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

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

admincluster.ipblockfilepath

고정 IP 주소를 사용 중이므로 고정 IP 구성의 설명대로 호스트 구성 파일이 있어야 합니다. 호스트 구성 파일의 경로를 admincluster.ipblockfilepath 필드에 입력합니다. 예를 들면 다음과 같습니다.

admincluster:
  ipblockfilepath: "/my-config-folder/my-admin-hostconfig.yaml"

admincluster.manuallbspec(수동 부하 분산 모드)

관리자 클러스터의 인그레스 컨트롤러는 NodePort 유형 서비스로 구현됩니다. 서비스에는 HTTP용 ServicePort 하나와 HTTPS용 다른 ServicePort가 있습니다. 수동 부하 분산 모드를 사용하는 경우 이러한 ServicePort에 nodePort 값을 선택해야 합니다. ingresshttpnodeport 및 ingresshttpsnodeport의 nodePort 값을 지정합니다. 예를 들면 다음과 같습니다.

admincluster:
  ...
  manuallbspec:
    ingresshttpnodeport: 32527
    ingresshttpsnodeport: 30139

관리자 클러스터의 Kubernetes API 서버는 NodePort 유형 서비스로 구현됩니다. 수동 부하 분산을 사용하는 경우 서비스에 nodePort 값을 선택해야 합니다. controlplanenodeport에 nodePort 값을 지정합니다. 예를 들면 다음과 같습니다.

admincluster:
  ...
  manuallbspec:
    ...
    controlplanenodeport: 30968

관리자 클러스터의 부가기능 서버는 NodePort 유형 서비스로 구현됩니다. 수동 부하 분산을 사용하는 경우 서비스에 nodePort 값을 선택해야 합니다. controlplanenodeport에 nodePort 값을 지정합니다. 예를 들면 다음과 같습니다.

admincluster:
  manuallbspec:
    ...
    addonsnodeport: 30562

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

통합 부하 분산 모드를 사용하지 않는 경우 admincluster.bigip를 주석 처리된 상태로 둡니다.

통합 부하 분산 모드를 사용하는 경우 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.partition(통합 부하 분산 모드)

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

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

admincluster.vips

관리자 클러스터에 통합 부하 분산을 사용하는지 수동 부하 분산을 사용하는지에 관계없이 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 주소 범위와 포드에 사용할 IP 주소 범위가 있어야 합니다. 이러한 범위는 admincluster.serviceiprange 및 admincluster.podiprange 필드로 지정됩니다. 이러한 필드는 gkectl create-config를 실행할 때 채워집니다. 필요에 따라 채워진 값을 원하는 값으로 변경할 수 있습니다.

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

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

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

사용자 클러스터 사양

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

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

버전 1.1.0-gke.6부터 GKE On-Prem은 사용자 클러스터 노드에 대해 VMware Distributed Resource Scheduler(DRS) 안티어피니티 규칙을 자동으로 만들어 데이터 센터에 있는 최소 3개 이상의 물리적 호스트에 분산되도록 합니다. 버전 1.1.0-gke.6부터 이 기능은 새 클러스터와 기존 클러스터에서 자동으로 사용 설정됩니다.

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

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

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

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

usercluster.vcenter.network

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

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

usercluster.ipblockfilepath

고정 IP 주소를 사용 중이므로 고정 IP 구성의 설명대로 호스트 구성 파일이 있어야 합니다. 호스트 구성 파일의 경로를 usercluster.ipblockfilepath 필드에 입력합니다. 예를 들면 다음과 같습니다.

usercluster:
  ipblockfilepath: "/my-config-folder/my-user-hostconfig.yaml"

usercluster.manuallbspec(수동 부하 분산 모드)

사용자 클러스터의 인그레스 컨트롤러는 NodePort 유형 서비스로 구현됩니다. 서비스에는 HTTP용 ServicePort 하나와 HTTPS용 다른 ServicePort가 있습니다. 수동 부하 분산 모드를 사용하는 경우 이러한 ServicePort에 nodePort 값을 선택해야 합니다. ingresshttpnodeport 및 ingresshttpsnodeport의 nodePort 값을 지정합니다. 예를 들면 다음과 같습니다.

usercluster:
  manuallbspec:
    ingresshttpnodeport: 30243
    ingresshttpsnodeport: 30879

사용자 클러스터의 Kubernetes API 서버는 NodePort 유형 서비스로 구현됩니다. 수동 부하 분산을 사용하는 경우 서비스에 nodePort 값을 선택해야 합니다. controlplanenodeport에서 nodePort 값을 지정합니다. 예를 들면 다음과 같습니다.

usercluster:
  ...
  manuallbspec:
    ...
    controlplanenodeport: 30562

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 필드를 입력해야 합니다.

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 주소 범위와 포드에 사용할 IP 주소 범위가 있어야 합니다. 이러한 범위는 usercluster.serviceiprange 및 usercluster.podiprange 필드로 지정됩니다. 이러한 필드는 gkectl create-config를 실행할 때 채워집니다. 필요에 따라 채워진 값을 원하는 값으로 변경할 수 있습니다.

서비스 및 포드 범위는 겹치지 않아야 합니다. 또한 서비스 및 포드 범위는 클러스터의 노드에 사용되는 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.cpus, usercluster.masternode.memorymb

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

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

usercluster.workernode.replicas

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

usercluster.workernode.cpus, usercluster.workernode.memorymb

usercluster.masternode.cpus 및 usercluster.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

통합 부하 분산이나 수동 부하 분산을 사용할 수 있습니다. 선택한 부하 분산 모드는 관리자 클러스터와 초기 사용자 클러스터에 적용되며, 이후에 만드는 모든 추가적인 사용자 클러스터에도 적용됩니다.

lbmode 값을 Integrated 또는 Manual로 설정하여 부하 분산 선택을 지정합니다. 예를 들면 다음과 같습니다.

lbmode: Integrated

gkeconnect

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

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

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

커넥트 에이전트가 프록시를 사용하여 Google Cloud와 통신하도록 하려면 gkeconnect.proxy 값을 프록시의 URL로 설정합니다. http(s)://[PROXY_ADDRESS] 형식을 사용합니다.

예:

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

stackdriver

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

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

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

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

stackdriver.serviceaccountkeypath를 Stackdriver 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 주소로 설정합니다. username 및 password를 비공개 Docker 레지스트리의 사용자 이름과 비밀번호로 설정합니다.

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

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

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

gcrkeypath

gcrkeypath의 값을 액세스 서비스 계정의 JSON 키 파일 경로로 설정합니다. 예를 들면 다음과 같습니다.

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

cloudauditlogging

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

cloudauditlogging:
  projectid: "my-project"
  # A GCP 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 GCP 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 [PATH_TO_CONFIG]

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

유효성 검사 건너뛰기

다음 gkectl 명령어는 구성 파일에 대해 자동으로 유효성 검사를 실행합니다.

  • gkectl prepare
  • gkectl create cluster
  • gkectl upgrade

명령어 유효성 검사를 건너뛰려면 --skip-validation-all을 전달합니다. 예를 들어 gkectl prepare 명령어의 모든 유효성 검사를 건너뛰려면 다음을 실행합니다.

gkectl prepare --config [PATH_TO_CONFIG] --skip-validation-all

특정 유효성 검사를 건너뛰기 위해 사용 가능한 모든 플래그를 보려면 다음을 실행합니다.

gkectl check-config --help

gkectl prepare 실행

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

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

  • 비공개 Docker 레지스트리를 사용하는 경우 레지스트리에 GKE On-Prem 이미지를 푸시합니다.

  • 선택적으로 컨테이너 이미지의 빌드 증명을 검사하여 이미지가 빌드되었고, 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을 설치하려면 다음 명령어를 실행합니다.

gkectl create cluster --config [CONFIG_FILE]

여기서 [CONFIG_FILE]은 생성 및 수정된 구성 파일입니다.

구성 파일을 다시 사용하여 추가 사용자 클러스터를 만들 수 있습니다.

설치 재개

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

  • 구성 파일에서 admincluster 사양을 삭제합니다.
  • gkectl create cluster를 다시 실행하여 관리자 클러스터의 kubeconfig 파일을 전달합니다.
gkectl create cluster --config [CONFIG_FILE] \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

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

알려진 문제

현재 HA 사용자 클러스터를 만드는 경우 설치를 재개할 수 없습니다. 이 문제는 차후 버전에서 해결될 예정입니다.

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 제한사항

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

할당량 및 한도를 참조하세요. 이러한 한도는 환경 성능에 따라 달라질 수 있습니다.
사용자 클러스터 이름의 고유성

동일한 Google Cloud 프로젝트에 등록된 모든 사용자 클러스터에는 고유한 이름이 있어야 합니다.
vCenter 또는 vSphere 데이터 센터 두 개 이상에 배포할 수 없음

현재 관리자 클러스터와 연관된 사용자 클러스터 집합을 단일 vCenter 또는 vSphere 데이터 센터에만 배포할 수 있습니다. 동일한 관리자 및 사용자 클러스터를 둘 이상의 vCenter 또는 vSphere 데이터 센터에 배포할 수 없습니다.
생성 후 클러스터 구성을 선언적으로 변경할 수 없음 추가 클러스터 만들기 및 기존 클러스터 크기 조절은 가능하지만 구성 파일을 통해 기존 클러스터를 변경할 수 없습니다.

문제 해결

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

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

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

기본 로깅 동작

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

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

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

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

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

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

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

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

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

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

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

  2. 포드의 로그를 엽니다. 여기서 [POD_NAME]은 포드 이름입니다. 원하는 경우 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=false를 gkectl create cluster에 전달한 경우 부트스트랩 클러스터의 로그를 사용하여 디버깅하는 것이 유용할 수 있습니다. 포드를 찾은 후 해당 로그를 가져올 수 있습니다.

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]

다음 단계