버전 1.29 이상에서 Google Distributed Cloud는 사용자 클러스터의 컨트롤 플레인이 클러스터의 노드 풀보다 최대 두 개의 부 버전까지 높을 수 있도록 허용합니다. 예를 들어 사용자 클러스터의 컨트롤 플레인이 1.29 버전인 경우 클러스터의 노드 풀은 1.16, 1.28 또는 1.29 버전일 수 있습니다. 또한 Google Distributed Cloud에서는 노드 풀을 업그레이드할 때 하나의 부 버전을 건너뛸 수 있습니다. 이전 예시를 기준으로 하면, 1.16 버전에 있는 노드 풀을 1.29 버전으로 바로 업그레이드하여 1.28 업그레이드를 건너뛸 수 있습니다. 노드 풀을 업그레이드할 때 부 버전을 건너뛰는 작업을 버전 건너뛰기 업그레이드라고 합니다.
이 페이지에서는 버전 건너뛰기 업그레이드의 이점을 설명하고 구성 파일을 변경하고 gkectl upgrade cluster를 실행하여 버전 건너뛰기 업그레이드를 수행하는 단계를 제공합니다.
이 페이지는 기본 기술 인프라의 수명 주기를 관리하는 IT 관리자 및 운영자를 위해 작성되었습니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참조하세요. 이 페이지에서는 아래에 설명된 대로 Google Distributed Cloud 업그레이드를 계획하고 수행하는 과정에 대해 어느 정도 익숙하다고 가정합니다.
제한사항
버전 건너뛰기 업그레이드에는 다음과 같은 제한사항이 있습니다.
버전 건너뛰기 업그레이드는 Ubuntu 및 COS 노드 풀에서 지원되지만 Windows 노드 풀에서는 지원되지 않습니다.
버전 1.31: 이 기능은 고급 클러스터에서 사용할 수 없습니다.
버전 1.32 이상: 이 기능은 고급 클러스터에서 사용할 수 있습니다.
Kubernetes 제약 조건으로 인해 사용자 클러스터의 컨트롤 플레인은 한 번에 하나의 부 버전씩 업그레이드해야 합니다. 하지만 컨트롤 플레인만 업그레이드하는 작업은 워크로드가 실행되는 노드 풀을 업그레이드하는 것보다 훨씬 시간이 적게 걸리고 위험도 낮다는 점에 유의하세요.
버전 건너뛰기 업그레이드의 이점
이 섹션에서는 버전 건너뛰기 업그레이드를 사용할 때의 몇 가지 이점을 설명합니다.
지원되는 버전으로 클러스터를 더 쉽게 유지
Google Distributed Cloud의 새로운 부 버전은 4개월마다 출시되며 각 부 버전은 지원 기간이 1년입니다. 클러스터를 지원 기간 내에 유지하려면 아래와 같이 약 4개월마다 부 버전 업그레이드를 수행해야 합니다.
12월 |
1월 |
2월 |
3월 |
4월 |
5월 |
6월 |
7월 |
8월 |
9월 |
10월 |
11월 |
12월 |
1월 |
2월 |
3월 |
4월 |
5월 |
6월 |
7월 |
8월 |
9월 |
10월 |
11월 |
12월 |
1월 |
2월 |
3월 |
| 1.14 | 업그레이드 | ||||||||||||||||||||||||||
| 1.15 | 업그레이드 | ||||||||||||||||||||||||||
| 1.16 | 업그레이드 | ||||||||||||||||||||||||||
| 1.28 | 업그레이드 | ||||||||||||||||||||||||||
| 1.29 | 업그레이드 |
이러한 요구사항 때문에 부 버전을 검증할 때 긴 검증 기간이 필요하고, 클러스터를 새로운 부 버전으로 업그레이드하는 데 짧은 유지보수 기간만 허용되는 경우 문제가 될 수 있습니다. 버전 건너뛰기 업그레이드를 사용하면 이러한 문제를 해결하는 데 도움이 될 수 있습니다. 이렇게 하면 클러스터를 4개월이 아니라 8개월마다 업그레이드하여 지원 기간을 벗어나지 않도록 할 수 있습니다. 다음 표는 1.15 버전 업그레이드를 건너뛰면 4개월이 아닌 8개월 후에 업그레이드를 수행하게 되는 방식을 보여줍니다.
12월 |
1월 |
2월 |
3월 |
4월 |
5월 |
6월 |
7월 |
8월 |
9월 |
10월 |
11월 |
12월 |
1월 |
2월 |
3월 |
4월 |
5월 |
6월 |
7월 |
8월 |
9월 |
10월 |
11월 |
12월 |
1월 |
2월 |
3월 |
| 1.14 | 업그레이드 | ||||||||||||||||||||||||||
| 1.15 | |||||||||||||||||||||||||||
| 1.16 | 업그레이드 | ||||||||||||||||||||||||||
| 1.28 | |||||||||||||||||||||||||||
| 1.29 |
노드 풀을 업그레이드할 때 부 버전 하나를 건너뛰면, 지원되는 버전을 유지하는 데 필요한 업그레이드 횟수가 줄어듭니다. 또한 건너뛴 부 버전은 컨트롤 플레인이 일시적으로만 사용하므로 별도의 검증이 필요하지 않습니다.
더 짧은 유지보수 기간
버전 건너뛰기 업그레이드를 사용하면 유지보수 기간을 늘릴 필요가 없습니다. 노드 풀을 업그레이드할 때 부 버전을 건너뛰는 작업은, 노드 풀을 다음 부 버전으로 업그레이드하는 것과 시간이 동일합니다. 이는 노드 풀의 각 노드가 한 번씩 드레이닝되고 다시 생성되기 때문입니다. 따라서 버전 건너뛰기 업그레이드는 전체적으로 시간을 절약하고 워크로드 중단을 줄여줍니다.
요약
요약하면, 버전 건너뛰기 업그레이드는 다음과 같은 이점을 제공합니다.
클러스터를 지원되는 버전으로 이동: Google Distributed Cloud는 가장 최근의 부 버전 3개를 지원합니다. 클러스터가 지원되지 않는 버전에 있는 경우 클러스터 버전에 따라 노드 풀을 업그레이드할 때 부 버전을 건너뛰면 더 적은 업그레이드 횟수로 지원되는 버전에 도달할 수 있습니다.
시간 절약: 노드 풀을 업그레이드할 때 부 버전을 건너뛰는 작업은 노드 풀을 다음 부 버전으로 업그레이드하는 것과 시간이 동일합니다. 따라서 버전 건너뛰기 업그레이드는 노드 풀을 두 번 업그레이드하는 데 걸리는 시간의 약 절반만 소요됩니다. 또한 버전 건너뛰기 업그레이드에서는 일반 업그레이드와 달리 검증 기간도 두 번이 아니라 한 번만 필요합니다.
중단 감소: 업그레이드 간격이 길어지고 업그레이드 및 검증에 소요되는 시간이 줄어들기 때문에 워크로드는 더 적은 중단으로 더 오래 실행될 수 있습니다.
업그레이드 중 컨트롤 플레인 및 노드 풀 버전 제어
사용자 클러스터 구성 파일에서 nodePools[i].gkeOnPremVersion 필드를 사용하면 특정 노드 풀이 최상위 gkeOnPremVersion 필드와 다른 버전을 사용할 수 있습니다. nodePools[i].gkeOnPremVersion 필드 값을 변경하면 gkectl upgrade cluster를 실행할 때 노드 풀의 업그레이드 시점을 제어할 수 있습니다.
구성 파일에 nodePools[i].gkeOnPremVersion을 포함하지 않거나 이 필드를 빈 문자열로 설정하면, 노드 풀은 gkeOnPremVersion에 지정한 동일한 대상 버전으로 업그레이드됩니다.
버전 규칙
업그레이드 규칙은 클러스터의 마이너 버전에 따라 달라집니다.
버전 1.30 이하의 경우 사용자 클러스터 마이너 버전이 관리자 클러스터 마이너 버전보다 높거나 같아야 합니다. 패치 버전은 상관없습니다. 예를 들어 사용자 클러스터가 버전 1.30.1인 경우 관리자 클러스터를 1.30.3과 같은 더 높은 패치 버전으로 업그레이드할 수 있습니다.
버전 1.31 이상에서는 패치 버전을 포함한 관리자 클러스터 버전이 사용자 클러스터 버전보다 크거나 같아야 합니다. 예를 들어 관리자 클러스터가 1.31.1 버전인 경우 사용자 클러스터가 업그레이드할 수 있는 최대 버전은 1.31.1입니다.
클러스터를 1.31 버전으로 업그레이드하려면 먼저 모든 클러스터를 1.30 버전으로 맞춰야 합니다. 모든 클러스터가 1.30 버전에 도달하면, 관리자 클러스터를 1.31 버전으로 업그레이드합니다. 그런 다음 사용자 클러스터를 관리자 클러스터와 동일한 1.31 패치 버전으로 업그레이드할 수 있습니다.
버전 건너뛰기 업그레이드 순서
관리자 클러스터와 사용자 클러스터를 업그레이드하는 순서는 업그레이드 대상이 되는 클러스터 버전(대상 버전이라고 함)에 따라 달라집니다.
1.32 이상
대상 버전이 1.32 이상인 경우 이 순서를 사용합니다. 사용자 클러스터의 컨트롤 플레인과 모든 노드 풀이 부 버전 1.N에 있다고 가정하겠습니다. 전체적인 흐름에서 보면, 버전 건너뛰기 업그레이드를 사용해 클러스터를 1.N에서 1.N+2로 업그레이드하는 과정은 다음과 같습니다.
- 관리자 클러스터를
1.N버전에서 중간 버전인1.N+1로 업그레이드합니다. - 관리자 클러스터를 중간 버전인
1.N+1에서 대상 버전인1.N+2로 업그레이드합니다. - 사용자 클러스터의 컨트롤 플레인만 소스 버전인
1.N에서 중간 버전인1.N+1로 업그레이드합니다. 노드 풀은 소스 버전 그대로 유지합니다. 중간 버전이 필요한 이유는 컨트롤 플레인이 한 번에 하나의 마이너 버전씩 업그레이드되어야 하기 때문입니다. - 컨트롤 플레인과 노드 풀을 대상 버전인
1.N+2로 업그레이드합니다.
1.31
사용자 클러스터가 1.29 버전에 있는 경우, 대상 버전이 1.31이므로 이 특별한 순서를 사용합니다. 사용자 클러스터가 1.29 버전일 때, 해당 사용자 클러스터를 관리하는 관리자 클러스터는 1.27, 1.28, 1.29 버전에 있을 수 있습니다.
- 관리자 클러스터가 1.27 버전인 경우, 이를 1.28로 업그레이드합니다.
- 관리자 클러스터가 1.28 버전인 경우, 이를 1.29로 업그레이드합니다.
- 사용자 클러스터의 컨트롤 플레인만 소스 버전인 1.29에서 중간 버전인 1.30으로 업그레이드합니다. 노드 풀은 소스 버전 그대로 유지합니다. 중간 버전인 1.30이 필요한 이유는 컨트롤 플레인이 한 번에 하나의 마이너 버전씩 업그레이드되어야 하기 때문입니다.
- 관리자 클러스터를 1.29 버전에서 중간 버전인 1.30으로 업그레이드합니다.
- 관리자 클러스터를 대상 버전인 1.31로 업그레이드합니다.
- 사용자 클러스터의 컨트롤 플레인과 노드 풀을 대상 버전인 1.31로 업그레이드합니다.
1.30 이하
대상 버전이 1.30 이하인 경우 이 순서를 사용합니다.
사용자 클러스터의 컨트롤 플레인과 모든 노드 풀이 마이너 버전 1.N에 있다고 가정하겠습니다. 전체적인 흐름에서 보면, 버전 건너뛰기 업그레이드를 사용해 클러스터를 1.N에서 1.N+2로 업그레이드하는 과정은 다음과 같습니다.
- 컨트롤 플레인만 소스 버전인
1.N에서 중간 버전인1.N+1로 업그레이드합니다. 노드 풀은 소스 버전 그대로 유지합니다. 중간 버전이 필요한 이유는 컨트롤 플레인이 한 번에 하나의 마이너 버전씩 업그레이드되어야 하기 때문입니다. - 컨트롤 플레인과 노드 풀을 대상 버전인
1.N+2로 업그레이드합니다.
버전 건너뛰기 업그레이드 수행
이 섹션에서는 버전 건너뛰기 업그레이드를 수행하는 단계를 제공합니다.
시작하기 전에
클러스터의 현재 버전(소스 버전)이 1.16 이상인지 확인합니다. 컨트롤 플레인(
gkeOnPremVersion)과 모든 노드 풀(nodePools[i].gkeOnPremVersion)의 버전도 확인합니다.버전 1.29 이상에서는 서버 측 프리플라이트 검사가 기본적으로 사용 설정됩니다. 필요한 변경사항이 있는지 방화벽 규칙을 검토하세요.
1.28 이상 버전으로 업그레이드하려면
kubernetesmetadata.googleapis.com을 사용 설정하고 로깅-모니터링 서비스 계정에kubernetesmetadata.publisherIAM 역할을 부여해야 합니다. 자세한 내용은 Google API 및 IAM 요구사항을 참고하세요.
업그레이드 수행
1.31
사용자 클러스터가 1.29 버전에 있는 경우, 대상 버전이 1.31이므로 이 특별한 순서를 사용합니다. 이 순서는 1.31 버전에서 버전 규칙이 변경되었기 때문에 필요합니다.
사용자 클러스터가 1.29 버전일 때, 해당 사용자 클러스터를 관리하는 관리자 클러스터는 1.27, 1.28, 1.29 버전에 있을 수 있습니다.
관리자 클러스터가 1.27 버전인 경우, 관리자 워크스테이션 업그레이드 절차를 따라 관리자 클러스터를 1.28 버전으로 업그레이드합니다.
관리자 클러스터가 1.28 버전인 경우 관리자 워크스테이션 업그레이드 절차를 따라 관리자 클러스터를 1.29 버전으로 업그레이드합니다.
관리자 워크스테이션의 공간을 확보하려면 다운로드한 번들을 삭제합니다.
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz
관리자 클러스터와 모든 사용자 클러스터가 1.29 버전에 도달하면, 버전 건너뛰기 업그레이드를 시작할 수 있습니다.
다음 자리표시자 변수에서 소스 버전(1.29), 중간 버전(1.30), 대상 버전(1.31)을 정의합니다. 모든 버전은
1.29.700-gke.110과 같은x.y.z-gke.N형식의 전체 버전 번호여야 합니다.버전 현재 사용자 클러스터의 1.29 버전을 가져옵니다. 이것이 소스 버전입니다. SOURCE_VERSION중간 1.30 버전을 선택합니다. INTERMEDIATE_VERSION1.31 대상 버전을 선택합니다. 1.31 부 버전에서 권장 패치를 선택합니다. TARGET_VERSION관리자 워크스테이션을 중간 버전인 1.30(
INTERMEDIATE_VERSION)로 업그레이드합니다. 업그레이드가 성공했다는 메시지가 표시될 때까지 기다립니다.해당 번들을 설치합니다.
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG관리자 워크스테이션을 다시 업그레이드하되, 이번에는 대상 버전인 1.31(
TARGET_VERSION)로 업그레이드합니다. 업그레이드가 성공했다는 메시지가 표시될 때까지 기다립니다.해당 번들을 설치합니다.
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG다음과 같이 사용자 클러스터의 컨트롤 플레인만 중간 버전으로 업그레이드합니다.
사용자 클러스터 구성 파일을 다음과 같이 변경합니다.
gkeOnPremVersion필드를 중간 버전인INTERMEDIATE_VERSION으로 설정합니다.nodePools[i].gkeOnPremVersion에 있는 모든 노드 풀 버전을 소스 버전인SOURCE_VERSION으로 설정합니다.
구성 파일을 업데이트한 후에는 다음과 유사한 형태가 되어야 합니다.
gkeOnPremVersion: INTERMEDIATE_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: SOURCE_VERSION ... - name: pool-2 gkeOnPremVersion: SOURCE_VERSION ...
컨트롤 플레인을 업그레이드합니다.
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILEUSER_CLUSTER_CONFIG를 사용자 클러스터 구성 파일의 경로로 바꿉니다.
관리자 클러스터 구성 파일의
bundlePath필드를 1.30 중간 버전 번들로 설정합니다.bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"
관리자 클러스터를 중간 버전인 1.30으로 업그레이드합니다.
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILE관리자 클러스터 구성 파일의
bundlePath필드를 대상 버전인 1.31 번들로 설정합니다.bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"
Upgrade the admin cluster to the target 1.31 version:
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILE다음과 같이 컨트롤 플레인과 노드 풀을 대상 버전으로 업그레이드합니다.
사용자 클러스터 구성 파일을 다음과 같이 변경합니다.
gkeOnPremVersion필드를 대상 버전TARGET_VERSION으로 설정합니다.모든
nodePools[i].gkeOnPremVersion값을 빈 문자열로 설정합니다.
구성 파일을 업데이트한 후에는 다음과 유사한 형태가 되어야 합니다.
gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: "" ...
컨트롤 플레인과 노드 풀을 업그레이드합니다.
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
1.30 이하
대상 버전이 1.30 이하인 경우 이 순서를 사용합니다.
다음 자리표시자 변수에서 소스 버전(
1.N), 중간 버전(1.N+1), 대상 버전(1.N+2)을 정의합니다. 모든 버전은1.16.11-gke.25와 같은x.y.z-gke.N형식의 전체 버전 번호여야 합니다.버전 현재 클러스터 버전을 가져옵니다. 이것이 소스 버전( 1.N)입니다.SOURCE_VERSION중간 버전( 1.N+1)을 선택합니다.INTERMEDIATE_VERSION대상 버전( 1.N+2)을 선택합니다. 대상 마이너 버전에서 권장 패치를 선택합니다.TARGET_VERSION관리자 워크스테이션을 중간 버전인
INTERMEDIATE_VERSION으로 업그레이드합니다. 업그레이드가 성공했다는 메시지가 표시될 때까지 기다립니다.해당 번들을 설치합니다.
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGADMIN_CLUSTER_KUBECONFIG를 관리자 클러스터kubeconfig파일의 경로로 바꿉니다.관리자 워크스테이션을 다시 업그레이드하되, 이번에는 대상 버전인
TARGET_VERSION으로 업그레이드합니다. 업그레이드가 성공했다는 메시지가 표시될 때까지 기다립니다.해당 번들을 설치합니다.
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG다음과 같이 컨트롤 플레인만 중간 버전으로 업그레이드합니다.
사용자 클러스터 구성 파일을 다음과 같이 변경합니다.
gkeOnPremVersion필드를 중간 버전인INTERMEDIATE_VERSION으로 설정합니다.nodePools[i].gkeOnPremVersion에 있는 모든 노드 풀 버전을 소스 버전인SOURCE_VERSION으로 설정합니다.
구성 파일을 업데이트한 후에는 다음과 유사한 형태가 되어야 합니다.
gkeOnPremVersion: INTERMEDIATE_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: SOURCE_VERSION ... - name: pool-2 gkeOnPremVersion: SOURCE_VERSION ...
컨트롤 플레인을 업그레이드합니다.
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILEUSER_CLUSTER_CONFIG를 사용자 클러스터 구성 파일의 경로로 바꿉니다.
다음과 같이 컨트롤 플레인과 노드 풀을 대상 버전으로 업그레이드합니다.
사용자 클러스터 구성 파일을 다음과 같이 변경합니다.
gkeOnPremVersion필드를 대상 버전TARGET_VERSION으로 설정합니다.모든
nodePools[i].gkeOnPremVersion값을 빈 문자열로 설정합니다.
구성 파일을 업데이트한 후에는 다음과 유사한 형태가 되어야 합니다.
gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: "" ...
컨트롤 플레인과 노드 풀을 업그레이드합니다.
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
업그레이드할 다른 사용자 클러스터가 없다면, 관리자 워크스테이션의 공간을 절약하기 위해 번들을 삭제합니다.
rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz