이 페이지에서는 관리자 및 사용자 클러스터를 하나의 GKE On-Prem 패치 버전에서 다음 상위 패치 버전으로 업그레이드하는 방법을 설명합니다. 사용 가능한 버전에 대한 자세한 내용은 버전을 참조하세요.
관련 주제에 대한 추가 정보
개요
GKE On-Prem은 순차적 업그레이드를 지원합니다. 예를 들어 다음과 같은 버전들만 있다고 가정해 보겠습니다.
- 1.0.10
- 1.0.X(X는 .10 이후)
- 1.0.Y(Y는 X 이후)
이 경우 1.0.Y는 최신 버전입니다. 버전 1.0.10 클러스터를 1.0.Y로 업그레이드하려면 다음 단계를 따르세요.
- 클러스터를 1.0.10에서 1.0.X로 업그레이드합니다.
- 그런 다음 클러스터를 1.0.X에서 1.0.Y로 업그레이드합니다.
시작하기 전에
관리 워크스테이션에 SSH를 통해 연결
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
Google Cloud에 액세스하도록
gcloud를 승인합니다.gcloud auth login
액세스 서비스 계정을 활성화합니다.
gcloud auth activate-service-account --project [PROJECT_ID] \ --key-file [ACCESS_KEY_FILE]
각 항목의 의미는 다음과 같습니다.
- [PROJECT_ID]는 프로젝트 ID입니다.
- [ACCESS_KEY_FILE]은 액세스 서비스 계정의 JSON 키 파일 경로입니다(예:
/home/ubuntu/access.json).
버전 1.0.2로 업그레이드하는 중
버전 1.0.2-gke.3에는 다음 필수 OIDC 필드(usercluster.oidc)가 추가되었습니다. 이러한 필드는 Google Cloud 콘솔에서 클러스터에 로그인하도록 허용합니다.
- usercluster.oidc.kubectlredirecturl
- usercluster.oidc.clientsecret
- usercluster.oidc.usehttpproxy
Google Cloud 콘솔에서 클러스터에 로그인하지 않고 OIDC를 사용하려는 경우 이러한 필드에 자리표시자 값을 전달할 수 있습니다.
oidc: kubectlredirecturl: "redirect.invalid" clientsecret: "secret" usehttpproxy: "false"
클러스터 업그레이드 시나리오 확인
클러스터를 업그레이드하기 전에 업그레이드 할 버전과 관련된 시나리오를 결정합니다.
| 시나리오 | 조치 필요 | 참고 |
|---|---|---|
| 버전에 보안 업데이트가 없습니다. |
|
|
| 버전에 보안 업데이트가 있습니다. |
|
새 버전에 보안 업데이트가 있는 경우에만 관리 워크스테이션을 업그레이드하면 됩니다. 관리 워크스테이션을 업그레이드할 때 최신 gkectl 및 번들이 포함됩니다. |
플랫폼 버전 확인
클러스터를 업그레이드하려면 클러스터의 플랫폼 버전을 확인해야 합니다.
문서에서
버전을 참조하세요.
번들에서
다음 명령어를 실행하여 번들을 임시 디렉터리에 추출합니다.
tar -xvzf /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz -C [TEMP_DIR]
추출된 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"
구성 파일 수정
관리 워크스테이션 VM에서 구성 파일을 수정합니다. gkeplatformversion 및 bundlepath 값을 설정합니다. 예:
gkeplatformversion: 1.12.7-gke.19 bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-1.0.10.tgz
gkectl 준비 실행
다음 명령어를 실행합니다.
gkectl prepare --config [CONFIG_FILE]
gkectl prepare 명령어는 다음 태스크를 수행합니다.
필요한 경우 새 노드 OS 이미지를 vSphere 환경에 복사하고 OS 이미지를 템플릿으로 표시합니다.
새 번들에 지정된 업데이트된 Docker 이미지를 비공개 Docker 레지스트리로 푸시합니다(구성한 경우).
클러스터 업그레이드
사용자 클러스터를 업그레이드하려면 관리자 클러스터의 버전이 사용자 클러스터 업그레이드의 대상 버전보다 높아야 합니다. 관리자 클러스터 버전이 높지 않다면 사용자 클러스터를 업그레이드하기 전에 관리자 클러스터를 업그레이드하세요.
관리자 클러스터
다음 명령어를 실행합니다.
gkectl upgrade admin \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --config [CONFIG_FILE]
여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일이고 [CONFIG_FILE]은 업그레이드를 수행하는 데 사용하는 GKE On-Prem 구성 파일입니다.
사용자 클러스터
다음 명령어를 실행합니다.
gkectl upgrade cluster \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --config [CONFIG_FILE] \ --cluster-name [CLUSTER_NAME]
여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일이고 [CLUSTER_NAME]은 업그레이드하는 사용자 클러스터의 이름입니다. [CONFIG_FILE]은 업그레이드를 수행하는 데 사용하는 GKE On-Prem 구성 파일입니다.
업그레이드 중 다운타임 정보
| 리소스 | 설명 |
|---|---|
| 관리자 클러스터 | 관리자 클러스터가 다운되면 다운타임을 유발한 오류의 영향을 받지 않는 한 사용자 클러스터 제어 영역과 워크로드는 사용자 클러스터에서 계속 실행됩니다. |
| 사용자 클러스터 제어 영역 | 일반적으로 사용자 클러스터 제어 영역에는 뚜렷한 다운타임이 없어야 합니다. 하지만 Kubernetes API 서버로의 장기 실행 연결이 끊어져 다시 설정해야 할 수 있습니다. 이 경우 API 호출자는 연결을 설정할 때까지 다시 시도해야 합니다. 최악의 경우에는 업그레이드 중에 다운타임이 최대 1분간 발생할 수 있습니다. |
| 사용자 클러스터 노드 | 업그레이드 시 사용자 클러스터 노드를 변경해야 하는 경우 GKE On-Prem은 노드를 롤링 방식으로 다시 만들고 이 노드에서 실행 중인 pod를 다시 예약합니다. 적절한 podDisruptionBudget과 안티어피니티 규칙을 설정하여 워크로드에 대한 영향을 방지할 수 있습니다. |
알려진 문제
- 현재는 클러스터를 업그레이드하면 PodDisruptionBudget(PDB)을 사용하는 워크로드에 장애 또는 다운타임이 발생할 수 있습니다.
문제해결
자세한 내용은 문제 해결을 참조하세요.
새 노드가 생성되었지만 정상이 아님
- 증상
수동 부하 분산 모드를 사용하는 경우 새 노드가 사용자 클러스터 제어 영역에 등록되지 않습니다.
- 가능한 원인
노드의 부팅 프로세스를 차단하는 노드 내 인그레스 검사가 사용 설정되었을 수 있습니다.
- 해결 방법
검사를 중지하려면 다음을 실행하세요.
kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge
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 컨트롤러의 로그를 검사하여 디버깅할 수 있습니다.
kube-system네임스페이스에서 Cluster API 컨트롤러 포드의 이름을 찾습니다. 여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일 경로입니다.kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
포드의 로그를 엽니다. 여기서 [POD_NAME]은 포드 이름입니다. 원하는 경우
grep또는 비슷한 도구를 사용하여 오류를 검색할 수 있습니다.kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager