GKE On-Prem 설치

이 페이지에서는 vSphere에서 GKE On-Prem를 설치하는 방법을 설명합니다. 이 페이지의 안내에서는 1개의 관리자 클러스터와 1개의 사용자 클러스터를 만드는 방법을 보여줍니다. 관리자 클러스터 및 초기 사용자 클러스터를 만든 후에는 추가 사용자 클러스터를 만들 수 있습니다.

시작하기 전에

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

  2. 시작하기의 절차를 완료합니다.

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

  4. 비공개 Docker 레지스트리를 사용하려는 경우 비공개 Docker 레지스트리를 만듭니다.

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

  6. 고정 IP를 사용하려는 경우 고정 IP를 구성합니다.

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

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

  8. Google Cloud에 액세스하도록 gcloud를 승인합니다.

    gcloud auth login

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

    gcloud auth configure-docker

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

    gcloud config set project [PROJECT_ID]

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

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

시작하기에서는 서비스 계정을 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-file \
--iam-account [ACCESS_SERVICE_ACCOUNT_EMAIL]

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

등록 서비스 계정

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

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

연결 서비스 계정

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

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

Cloud Monitoring 서비스 계정

gcloud iam service-accounts keys create stackdriver-key \
--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 번들은 YAML 파일의 모음입니다. 공통적으로 YAML 파일은 GKE On-Prem의 특정 출시 버전에 있는 모든 구성 요소를 설명합니다.

관리자 워크스테이션을 만들면 /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz에 번들이 함께 제공됩니다.

bundlepath 값을 번들 파일의 경로로 설정합니다. 즉 bundlepath를 다음과 같이 설정합니다.

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

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

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

gkeplatformversion

gkeplatformversion 필드에는 설치 중인 GKE On-Prem 출시 버전의 Kubernetes 버전이 포함됩니다. 형식은 다음과 같습니다.

[KUBERNETES_VERSION]-[GKE_PATCH]

Kubernetes 버전의 예시는 1.12.7-gke.19입니다.

gkectl create-config를 실행하면 이 필드가 채워집니다.

bundlepath 및 gkeplatformversion의 버전 관리 체계는 서로 다르지만, 제공된 번들 버전에는 해당하는 GKE 플랫폼 버전이 있습니다. 예를 들어 번들 버전이 1.0.10인 경우 GKE 플랫폼 버전은 1.12.7-gke.19여야 합니다.

번들 버전과 GKE 플랫폼 버전 간의 대응에 대해 알아보려면 번들 파일을 추출하고 YAML 파일을 확인하세요. 특히 gke-onprem-vsphere-[VERSION]-images.yaml을 연 다음 osImages 필드를 보면, OS 이미지 파일 이름에서 GKE 플랫폼 버전을 확인할 수 있습니다. 예를 들어 다음 OS 이미지에서 GKE 플랫폼 버전이 1.12.7-gke.19임을 알 수 있습니다.

osImages:
  admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"

vcenter

이 필드를 사용하여 vCenter Server의 전역 설정을 선언합니다. GKE On-Prem은 vCenter Server 인스턴스의 IP 주소, 사용자 이름, 비밀번호를 알아야 합니다. 이 정보를 제공하려면 vcenter 아래에서 값을 설정하세요. 예를 들면 다음과 같습니다.

vcenter:
  credentials:
    address: "203.0.113.1"
    username: "my-name"
    password: "my-password"

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

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

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

vcenter:
  ...
  datadisk: "my-disk.vmdk"

GKE On-Prem을 통해 VMDK를 디렉터리에 넣으려면 미리 디렉터리를 직접 수동으로 만들어야 합니다. 예를 들어 govc를 사용하여 디렉터리를 만들 수 있습니다.

govc datastore.mkdir my-gke-on-prem-directory

그런 다음 디렉터리를 vcenter.datadisk 필드에 포함시킬 수 있습니다.

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

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

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

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

CA의 인증서 다운로드에 대한 자세한 내용은 vCenter Server 루트 인증서를 다운로드 및 설치하는 방법을 참조하세요.

vCenter Server가 자체 서명된 인증서를 사용하는 경우 관리자 워크스테이션에서 openssl로 vCenter에 연결하여 인증서를 추출할 수 있습니다.

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

gcrkeypath

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

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

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-directory/register-key.json"
  agentserviceaccountkeypath: "/my-key-directory/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 리전으로 설정합니다. 온프렘 데이터 센터와 가까운 리전을 선택하는 것이 좋습니다.

stackdriver.serviceaccountkeypath를 Stackdriver Logging 서비스 계정의 JSON 키 파일 경로로 설정합니다.

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

stackdriver:
  projectid: "my-project"
  clusterlocation: "us-west1"
  proxyconfigsecretname: ""
  enablevpc: false
  serviceaccountkeypath: "/my-key-directory/logging-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-directory/registry-ca.crt

admincluster

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

vCenter 네트워크 - 관리자 클러스터

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

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

DHCP 또는 고정 IP 주소 - 관리자 클러스터

IP 주소를 관리자 클러스터 노드에 할당하는 데 동적 호스트 구성 프로토콜(DHCP)을 사용할지 여부를 결정합니다. 대안은 클러스터 노드에 고정 IP 주소를 사용하는 것입니다. 수동 부하 분산 모드의 사용을 선택한 경우 클러스터 노드에 고정 IP 주소를 사용해야 합니다.

DHCP의 사용을 선택한 경우 admincluster.ipblockfilepath 필드를 주석 처리된 상태로 둡니다.

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

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

통합 부하 분산 - 관리자 클러스터

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

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

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

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

수동 부하 분산 - 관리자 클러스터

수동 부하 분산 모드를 사용하는 경우 클러스터 노드에 고정 IP 주소를 사용해야 합니다. admincluster.ipblockfilepath 값을 설정했는지 확인합니다. 예를 들면 다음과 같습니다.

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

관리자 클러스터의 인그레스 컨트롤러는 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

vips - 관리자 클러스터

관리자 클러스터에 통합 부하 분산을 사용하는지 수동 부하 분산을 사용하는지에 관계없이 admincluster.vips 필드를 입력해야 합니다.

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

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

serviceiprange 및 podiprange - 관리자 클러스터

관리자 클러스터에는 서비스에 사용할 IP 주소 범위와 포드에 사용할 IP 주소 범위가 있어야 합니다. 이러한 범위는 admincluster.serviceiprange 및 admincluster.podiprange 필드로 지정됩니다. 이러한 필드는 gkectl create-config를 실행할 때 채워집니다. 필요에 따라 채워진 값을 원하는 값으로 변경할 수 있습니다. 서비스 및 포드 IP 범위 선택에 대한 자세한 내용은 IP 주소 할당 최적화를 참조하세요.

서비스 및 포드 범위는 겹치지 않아야 합니다. 또한 관리자 클러스터에 대해 선택한 서비스 및 포드 범위는 사용자 클러스터에 대해 선택한 서비스 및 포드 범위와 겹치면 안됩니다.

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

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

usercluster

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

vCenter 네트워크 - 관리자 클러스터

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

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

DHCP 또는 고정 IP 주소 - 사용자 클러스터

DHCP를 사용하여 사용자 클러스터 노드에 IP 주소를 할당할지를 결정합니다. 대안은 클러스터 노드에 고정 IP 주소를 사용하는 것입니다. 수동 부하 분산 모드를 선택한 경우 클러스터 노드에 고정 IP 주소를 사용해야 합니다.

DHCP의 사용을 선택한 경우 usercluster.ipblockfilepath 필드를 주석 처리된 상태로 둡니다.

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

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

통합 부하 분산 - 사용자 클러스터

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

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

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

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

수동 부하 분산 - 사용자 클러스터

수동 부하 분산 모드를 사용하는 경우 클러스터 노드에 고정 IP 주소를 사용해야 합니다. usercluster.ipblockfilepath 값을 설정했는지 확인합니다. 예를 들면 다음과 같습니다.

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

사용자 클러스터의 인그레스 컨트롤러는 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

vips - 사용자 클러스터

사용자 클러스터에 통합 부하 분산을 사용하는지 수동 부하 분산을 사용하는지에 관계없이 usercluster.vips 필드를 입력해야 합니다.

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

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

serviceiprange 및 podiprange - 사용자 클러스터

사용자 클러스터에는 서비스에 사용할 IP 주소 범위와 포드에 사용할 IP 주소 범위가 있어야 합니다. 이러한 범위는 usercluster.serviceiprange 및 usercluster.podiprange 필드로 지정됩니다. 이러한 필드는 gkectl create-config를 실행할 때 채워집니다. 필요에 따라 채워진 값을 원하는 값으로 변경할 수 있습니다. 서비스 및 포드 IP 범위 선택에 대한 자세한 내용은 IP 주소 할당 최적화를 참조하세요.

서비스 및 포드 범위는 겹치지 않아야 합니다. 또한 사용자 클러스터에 대해 선택한 서비스 및 포드 범위는 관리자 클러스터에 대해 선택한 서비스 및 포드 범위와 겹치면 안됩니다.

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

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

clustername

usercluster.clustername의 값을 원하는 이름으로 설정합니다. 예를 들면 다음과 같습니다.

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

masternode

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

  • 사용자 제어 영역 하나를 실행하려면 이 필드를 1로 설정합니다.
  • 고가용성 사용자 제어 영역을 사용하려면 이 필드를 3으로 설정합니다. 세 개의 사용자 제어 영역이 생성됩니다.

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

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

oidc

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

버전 1.0.2-gke.3에는 다음 필수 필드가 추가되었습니다. 이러한 필드는 Google Cloud Console에서 클러스터에 로그인하도록 허용합니다.

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

Google Cloud Console에서 클러스터에 로그인하지 않고 OIDC를 사용하려는 경우 이러한 필드에 자리표시자 값을 전달할 수 있습니다.

oidc:
  kubectlredirecturl: "redirect.invalid"
  clientsecret: "secret"
  usehttpproxy: "false"

자세한 내용은 OIDC로 인증을 참조하세요.

sni

사용자 클러스터의 Kubernetes API 서버에 추가 제공 인증서를 제공하려면 usercluster.sni.certpath 및 usercluster.sni.keypath 값을 제공합니다. 예를 들면 다음과 같습니다.

usercluster:
  ...
  sni:
    certpath: "/my-cert-directory/my-second-cert.crt"
    keypath: "/my-cert-directory/my-second-cert.key"

workernode

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

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

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

구성 파일 검사

구성 파일을 수정한 후에는 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]은 생성 및 수정된 구성 파일입니다.

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

Google에 클러스터 연결

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

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

인그레스 사용 설정

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

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 인그레스 객체를 사용할 수 있습니다.

문제해결

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

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]

다음 단계