이 페이지에서는 Google Kubernetes Engine(GKE) 클러스터에서 자동 업그레이드와 같은 클러스터 유지보수가 가능한 경우와 불가능한 경우를 제어하는 정책인 유지보수 기간 및 유지보수 제외에 대해 설명합니다. 예를 들어 소매업에서 주중 저녁에만 유지보수를 수행하도록 제한할 수 있으며 주요 판매 이벤트 중에는 자동 유지보수를 수행하지 않을 수 있습니다.
GKE 유지보수 정책 정보
유지보수 기간 및 유지보수 제외가 포함된 GKE 유지보수 정책을 사용하면 클러스터 업그레이드와 노드 구성 또는 클러스터의 네트워크 토폴로지에 대한 기타 변경사항을 포함하여 클러스터에서 특정 자동 유지보수가 수행되는 시기를 제어할 수 있습니다.
유지보수 기간은 GKE 자동 유지보수가 허용되는 반복되는 기간입니다.
유지보수 제외는 GKE 자동 유지보수가 금지되는 반복되지 않는 기간입니다.
열려 있는 유지보수 기간이 있고 활성 유지보수 제외가 없으면 GKE는 클러스터의 유지보수 정책을 준수하는 자동 변경을 수행합니다. 클러스터마다 하나의 반복 유지보수 기간과 여러 개의 유지보수 제외를 구성할 수 있습니다.
다른 유형의 유지보수는 제어 영역 복구 작업 및 Compute Engine과 같이 GKE가 의존하는 서비스의 유지보수를 비롯한 GKE 유지보수 정책에 종속되지 않습니다. 자세한 내용은 유지보수 정책을 준수하지 않는 자동 유지보수를 참조하세요.
GKE 유지보수 정책을 준수하는 변경사항과 그렇지 않은 변경사항
GKE 유지보수 정책(유지보수 기간 및 유지보수 제외)을 구성하기 전에 다음 섹션을 검토하여 GKE 및 관련 서비스가 어떻게 정책을 준수하며 또한 준수하지 않는지 확인하세요.
GKE 유지보수 정책을 준수하는 자동 유지보수
GKE 유지보수 정책을 사용하면 클러스터가 일시적으로 중단되는 다음 유형의 이벤트 시점을 제어할 수 있습니다.
- 제어 영역 업그레이드 및 노드 업그레이드를 포함한 자동 클러스터 업그레이드. 이러한 변경사항과 이로 인해 어떻게 환경에 일시적인 중단이 발생할 수 있는지 자세히 알아보려면 Autopilot 클러스터 업그레이드 및 Standard 클러스터 업그레이드를 참고하세요.
- 노드가 다시 생성되거나 클러스터의 내부 네트워크 토폴로지가 크게 변경되는 사용자가 시작한 구성 변경. 자세한 내용은 GKE 유지보수 정책을 준수하는 수동 변경사항을 참조하세요.
다른 유형의 자동 유지보수는 유지보수 정책에 따라 다릅니다. 자세한 내용은 유지보수 정책을 준수하지 않는 자동 유지보수를 참조하세요.
GKE 유지보수 정책을 준수하지 않는 자동 유지보수
GKE 유지보수 기간 및 유지보수 제외는 모든 유형의 자동 유지보수를 차단하지 않습니다. GKE 클러스터의 유지보수 정책을 구성하기 전에 유지보수 기간 및 유지보수 제외를 준수하지 않는 변경사항 유형을 이해해야 합니다.
기타 Google Cloud 유지보수
GKE 유지보수 기간 및 유지보수 제외는 기본 Google Cloud 서비스(주로 Compute Engine) 또는 애플리케이션을 클러스터에 설치하는 서비스(예: Cloud Deploy)의 자동 유지보수를 차단하지 않습니다.
예를 들어 GKE 노드는 클러스터에 대해 GKE가 관리하는 Compute Engine VM입니다. 때로는 Compute Engine VM에서 유지보수 이벤트 또는 호스트 오류가 포함될 수 있는 호스트 이벤트가 발생합니다. 이러한 이벤트 중에 VM이 작동하는 방식은 VM의 호스트 유지보수 정책에 따라 결정되며 이는 기본적으로 대부분의 VM에서 라이브 마이그레이션을 의미합니다. 일반적으로 노드의 다운타임이 거의 또는 전혀 없으며, 대부분의 워크로드에서는 기본 정책만으로도 충분하다는 뜻입니다. 일부 VM 머신 계열의 경우 호스트 유지보수 이벤트를 모니터링 및 계획하고 호스트 유지보수 이벤트를 트리거하여 GKE 유지보수 정책에 따라 시기를 조정할 수 있습니다.
GPU 및 TPU를 포함한 일부 VM은 라이브 마이그레이션을 수행할 수 없습니다. 이러한 가속기를 사용하는 경우 GPU 또는 TPU의 노드 유지보수로 인한 중단을 처리하는 방법을 알아보세요.
호스트 이벤트, 호스트 유지보수 정책에 대한 정보를 검토하고 특히 라이브 마이그레이션을 수행할 수 없는 노드에서 실행 중인 경우 워크로드가 중단에 대비할 수 있는지 확인하는 것이 좋습니다.
자동화된 수리 및 크기 조정
GKE는 제어 영역에서 자동 복구를 수행합니다. 여기에는 제어 영역을 적절한 크기로 확장하거나 제어 영역을 다시 시작하여 문제를 해결하는 등의 프로세스가 포함됩니다. 대부분의 수리는 유지보수 기간 및 유지보수 제외를 무시하는데 그 이유는 수리를 하지 않으면 클러스터가 작동하지 않는 문제가 발생할 수 있기 때문입니다.
제어 영역 복구는 사용 중지할 수 없습니다. 하지만 Autopilot 클러스터 및 Standard 리전 클러스터를 포함한 대부분의 클러스터 유형에는 제어 영역의 복제본이 여러 개 있어 유지보수 이벤트 중에도 Kubernetes API 서버의 고가용성을 유지할 수 있습니다. 단일 제어 영역만 있는 Standard 영역 클러스터는 제어 영역 구성 변경 및 클러스터 유지보수 중에 수정할 수 없습니다. 여기에는 워크로드 배포가 포함됩니다.
노드에는 Standard 클러스터에서 사용 중지할 수 있는 자동 복구 기능도 있습니다.
중요한 보안 취약점 패치 적용
유지보수 기간 및 제외로 인해 보안 패치 적용이 지연될 수 있습니다. GKE는 중요한 보안 취약점과 관련해 유지보수 정책을 재정의할 권리를 보유합니다.
GKE 유지보수 정책을 준수하는 수동 변경사항
다음을 포함한 노드 또는 네트워킹 구성의 일부 변경사항의 경우 새 구성을 적용하려면 노드를 다시 만들어야 합니다.
- 제어 영역의 IP 주소 순환
- 제어 영역의 사용자 인증 정보 순환
- IP 주소 할당 최적화
- 보안 노드 구성
- 네트워크 정책 구성
- 노드 내 가시성 구성
- NodeLocal DNSCache 구성
- GKE Sandbox 구성
이러한 변경사항은 GKE 유지보수 정책을 준수합니다. 즉, GKE가 열린 유지보수 기간을 기다리고 노드 유지보수를 막는 활성 유지보수 제외가 없을 때까지 기다립니다. 노드에 변경사항을 수동으로 적용하려면 Google Cloud CLI를 사용하여 gcloud container clusters
upgrade
명령어를 호출하고 노드 풀이 이미 실행 중인 동일한 GKE 버전으로 --cluster-version
플래그를 전달합니다.
유지보수 기간
유지보수 기간을 통해 제어 영역과 노드의 자동 업그레이드 수행 시기를 제어하여 워크로드의 일시적 중단 가능성을 완화할 수 있습니다. 유지보수 기간은 다음과 같은 상황에서 유용합니다.
- 사용량이 적은 시간대: 트래픽이 줄어드는 사용량이 적은 시간대에 자동 업그레이드를 예약하여 다운타임 발생 가능성을 최소화할 수 있습니다.
- 업무 시간 중: 누군가 업그레이드를 모니터링하고 예상치 못한 문제를 관리할 수 있도록 업무 시간 중 업그레이드가 실시되도록 할 수 있습니다.
- 다중 클러스터 업그레이드: 지정된 간격으로 한 번에 하나씩 여러 지역에 있는 여러 클러스터에 업그레이드를 출시할 수 있습니다.
자동 업그레이드 외에도 Google은 경우에 따라 다른 유지보수 태스크를 수행해야 할 수 있으며 가능한 경우 클러스터 유지보수 기간을 적용합니다.
태스크가 유지보수 기간을 초과하여 실행되면 GKE는 태스크를 일시중지하고 다음 유지보수 기간 중에 해당 태스크를 재개하려 합니다.
GKE는 유지보수 기간 외에도 계획되지 않은 긴급 업그레이드를 롤아웃할 수 있는 권리를 보유합니다. 또한 지원 중단되었거나 오래된 소프트웨어의 필수 업그레이드는 유지보수 기간이 아닐 때에도 자동으로 진행될 수 있습니다.
새 클러스터 또는 기존 클러스터에 유지보수 기간을 설정하는 방법은 유지보수 기간 구성을 참조하세요.
유지보수 기간 표준 시간대
유지보수 기간을 구성 및 확인할 때 사용 중인 도구에 따라 시간이 다르게 표시됩니다.
유지보수 기간을 구성할 경우
시간은 항상 UTC로 저장됩니다. 하지만 유지보수 기간을 구성할 때는 UTC 또는 현지 시간대를 사용합니다.
보다 일반적인 --maintenance-window
플래그를 사용하여 유지보수 기간을 구성할 경우에는 표준 시간대를 지정할 수 없습니다. gcloud CLI 또는 API를 사용할 때는 UTC가 사용되며 Google Cloud 콘솔에는 현지 표준 시간대로 시간이 표시됩니다.
--maintenance-window-start
와 같이 더욱 세분화된 플래그를 사용하면 값의 일부로 표준 시간대를 지정할 수 있습니다. 표준 시간대를 생략하면 현지 표준 시간대가 사용됩니다.
유지보수 기간을 확인할 경우
클러스터 정보를 확인할 경우 정보 확인 방법에 따라 유지보수 기간의 타임스탬프가 UTC 또는 현지 표준 시간대로 표시될 수 있습니다.
- Google Cloud 콘솔을 사용하여 클러스터의 정보를 확인할 경우 시간은 항상 현지 표준 시간대로 표시됩니다.
- gcloud CLI를 사용하여 클러스터에 대한 정보를 보는 경우 시간은 항상 UTC로 표시됩니다.
두 경우 모두 RRULE
은 항상 UTC입니다. 즉, 예를 들어 요일을 지정하면 해당 요일은 UTC로 표시됩니다.
유지보수 제외
유지보수 제외를 사용하면 특정 기간 동안 자동 유지보수를 수행하지 않아도 됩니다. 예를 들어 많은 소매업체에는 연말 연시에 인프라 변경을 금지하는 비즈니스 가이드라인이 있습니다. 또 다른 예시로, 회사에서 지원 중단될 API를 사용하는 경우 유지보수 제외를 사용하여 마이너 업그레이드를 일시중지하고 애플리케이션을 마이그레이션할 시간을 확보할 수 있습니다.
영향이 큰 알려진 이벤트의 경우 이벤트 1주일 후에 시작되고 이벤트 기간 동안 지속되는 유지보수 제외와 내부 변경 제한사항을 일치시키는 것이 좋습니다.
제외에는 반복 기능이 없지만 대신 주기적 제외 인스턴스를 각각 개별적으로 만듭니다.
제외 및 유지보수 기간이 겹치는 경우 제외가 우선합니다.
새 클러스터 또는 기존 클러스터에 유지보수 제외를 설정하는 방법은 유지보수 제외 구성을 참조하세요.
제외할 유지보수 범위
클러스터의 자동 유지보수를 방지하기 위해 시점을 지정할 수 있을 뿐만 아니라 발생할 수 있는 자동 업데이트의 범위를 제한할 수 있습니다. 유지보수 제외 범위는 다음과 같은 상황에서 유용합니다.
- 업그레이드 없음 - 유지보수 방지: 특정 기간 동안 클러스터 변경을 일시적으로 방지하려고 합니다. 이는 기본 범위입니다.
- 마이너 업그레이드 없음 - 현재 Kubernetes 마이너 버전 유지: API 변경을 방지하거나 다음 마이너 버전을 검증하기 위해 클러스터의 마이너 버전을 임시로 유지하려고 합니다.
- 마이너 또는 노드 업그레이드 없음 - 노드 풀 중단 방지: 노드 업그레이드로 인한 워크로드 제거 및 재예약을 일시적으로 방지하려고 합니다.
다음 표에는 이러한 각 범위가 클러스터 컨트롤 플레인이나 노드의 마이너 또는 패치 업그레이드를 제한하는 방식이 나와 있습니다.
GKE에서 클러스터를 업그레이드하면 컨트롤 플레인과 노드의 VM이 다시 시작됩니다. 컨트롤 플레인의 경우 Autopilot 및 리전 표준 클러스터에서 Kubernetes API 서버 가용성을 유지합니다. 컨트롤 플레인 노드가 하나인 영역 클러스터에서 VM을 다시 시작하면 컨트롤 플레인을 일시적으로 사용할 수 없게 됩니다. 노드의 경우 VM이 다시 시작되면 포드 재예약이 트리거되어 기존 워크로드가 일시적으로 중단될 수 있습니다. 포드 중단 예산(PDB)을 사용하여 워크로드 중단 허용 범위를 설정할 수 있습니다.
범위 | 제어 영역 | 노드 | ||
---|---|---|---|---|
마이너 업그레이드 | 패치 업그레이드 | 마이너 업그레이드 | 패치 업그레이드 | |
업그레이드 없음(기본값) | 아니요 | 아니요 | 아니요 | 아니요 |
마이너 업그레이드 없음 | 아니요 | 예 | 아니요 | 예 |
마이너 또는 노드 업그레이드 없음 | 아니요 | 예 | 아니요 | 아니요 |
마이너 버전과 패치 버전의 정의는 버전 관리 스키마를 참조하세요.
여러 제외
한 클러스터에 여러 개의 제외를 설정할 수 있습니다. 이러한 제외는 범위가 다를 수 있으며 기간이 겹칠 수 있습니다. 연말 시즌 사용 사례는 '업그레이드 없음' 및 '마이너 업그레이드 없음' 범위가 모두 사용되는 중복 제외의 예시입니다.
제외가 겹칠 때 활성 제외(즉, 현재 시간이 제외 기간 내)가 업그레이드를 차단하면 업그레이드가 연기됩니다.
연말 시즌 사용 사례를 사용하면 클러스터에 다음과 같은 제외가 지정됩니다.
- 마이너 업그레이드 없음: 9월 30일~1월 15일
- 업그레이드 없음: 11월 19일~12월 4일
- 업그레이드 없음: 12월 15일~1월 5일
이러한 중복 제외로 인해 다음 업그레이드가 클러스터에서 차단됩니다.
- 11월 25일, 노드 풀에 대한 패치 업그레이드('업그레이드 없음' 제외로 거부됨)
- 12월 20일, 제어 영역에 대한 마이너 업그레이드('마이너 업그레이드 없음' 및 '업그레이드 없음' 제외로 거부됨)
- 12월 25일, 제어 영역에 대한 패치 업그레이드('업그레이드 없음' 제외로 거부됨)
- 1월 1일, 노드 풀에 대한 마이너 업그레이드('마이너 업그레이드 없음' 및 '업그레이드 없음' 제외로 인해 거부됨)
다음 유지보수가 클러스터에서 허용됩니다.
- 11월 10일에 제어 영역으로의 업그레이드 패치('마이너 업그레이드 없음' 제외로 허용됨)
- 12월 10일, GKE 유지보수로 인한 VM 중단('마이너 업그레이드 없음' 제외로 허용됨)
제외 만료
제외가 만료되면(즉, 현재 시간이 제외에 지정된 종료 시간 이후) 제외가 더 이상 GKE 업데이트를 차단하지 않습니다. 여전히 유효하지만 만료되지 않은 다른 제외는 계속 GKE 업데이트를 방지합니다.
클러스터 업그레이드를 방지하는 제외가 없으면 클러스터가 클러스터의 출시 채널에 있는 현재 기본 버전(또는 출시 채널이 없는 클러스터의 정적 기본값)으로 점진적으로 업그레이드됩니다.
제외 만료 후 클러스터가 현재 기본 버전보다 여러 마이너 버전으로 뒤처지는 경우 GKE는 클러스터가 출시 채널의 기본 버전에 도달할 때까지 매달 1회의 마이너 업그레이드(클러스터 제어 영역 및 노드 업그레이드)를 예약합니다. 클러스터를 더 빨리 기본 버전으로 되돌리려면 수동 업그레이드를 실행하면 됩니다.
유지보수 제외 구성에 대한 제한사항
유지보수 제외에는 다음과 같은 제한사항이 있습니다.
- 출시 채널에 등록된 클러스터만 유지보수 제외에서 자동 업그레이드 범위를 제한할 수 있습니다. 출시 채널에 등록되지 않은 클러스터의 경우 기본 '업그레이드 없음' 범위로만 유지보수 제외를 만들 수 있습니다.
- 모든 업그레이드를 제외하는 유지보수 제외를 최대 3개 추가할 수 있습니다(즉, '업그레이드 없음' 범위). 이러한 제외는 32일의 순환 기간 동안 최소 48시간의 유지보수를 허용하도록 구성해야 합니다.
- 각 클러스터에 대해 최대 20개의 유지보수 제외 항목을 지정할 수 있습니다.
- 제외 항목에 범위를 지정하지 않는 경우 범위는 기본적으로 '업그레이드 없음'으로 설정됩니다.
- 범위에 따라 유지보수 제외의 기간을 다르게 설정할 수 있습니다. 자세한 내용은 유지보수 제외 구성 섹션의 유지보수 제외 기간 행을 참조하세요.
- 클러스터의 출시 채널 등록에 해당하는 마이너 버전의 지원 종료 날짜를 포함하거나 초과하도록 유지보수 제외를 구성할 수 없습니다. 다음 예를 참조하세요.
- 클러스터가 GKE 출시 일정에 표준 지원 종료 날짜가 2025년 6월 5일로 명시된 안정화 버전 채널에서 마이너 버전을 실행 중입니다. 유지보수 제외 종료 시간을
2025-06-05T00:00:00Z
이전으로 설정해야 합니다. - GKE 출시 일정에 따라 연장된 지원 종료 날짜가 2026년 4월 5일로 명시된 연장 채널에서 클러스터가 마이너 버전을 실행합니다. 유지보수 제외 종료 시간을
2026-04-0500:00:00Z
이전으로 설정해야 합니다. 클러스터 출시 채널을 다른 채널로 변경하려는 경우 유지보수 제외 종료 시간이 스탠더드 지원 종료 시간을 초과하면 유지보수 제외 종류 시간을 변경해야 합니다. 자세한 내용은 확장 채널에서 클러스터 변경을 참조하세요.
- 클러스터가 GKE 출시 일정에 표준 지원 종료 날짜가 2025년 6월 5일로 명시된 안정화 버전 채널에서 마이너 버전을 실행 중입니다. 유지보수 제외 종료 시간을
사용 예시
다음은 발생할 수 있는 업데이트 범위를 제한하는 사용 사례입니다.
예시: 연말 시즌을 준비하는 소매업체
이 예시에서 소매업체는 판매량이 가장 많은 기간(블랙 프라이데이부터 사이버 먼데이까지 4일간 및 12월부터 새해의 시작) 동안 중단을 원하지 않습니다. 쇼핑 시즌에 대비하여 클러스터 관리자가 다음 제외를 설정합니다.
- 마이너 업그레이드 없음: 9월 30일~1월 15일 사이에 제어 영역 및 노드에서 패치 업데이트만 허용합니다.
- 업그레이드 없음: 11월 19일~12월 4일 사이에 모든 업그레이드를 중지합니다.
- 업그레이드 없음: 12월 15일~1월 5일 사이에 모든 업그레이드를 중지합니다.
유지보수 제외가 만료될 때 다른 제외 기간이 적용되지 않는 경우 새 GKE 마이너 버전이 9월 30일에서 1월 6일 사이에 제공되었다면 클러스터가 새 GKE 마이너 버전으로 업그레이드됩니다.
예시: Kubernetes에서 삭제되는 베타 API를 사용하는 회사
이 예시에서 회사에서는 버전 1.22에서 삭제될 CustomResourceDefinition
apiextensions.k8s.io/v1beta1
API를 사용합니다.
회사에서 1.22 이전 버전을 실행 중인 경우 클러스터 관리자는 다음 제외를 설정합니다.
- 마이너 업그레이드 없음: 고객 애플리케이션을
apiextensions.k8s.io/v1beta1
에서apiextensions.k8s.io/v1
로 마이그레이션하는 3개월 동안 마이너 업그레이드를 중지합니다.
예시: 회사의 기존 데이터베이스가 노드 풀 업그레이드에 대한 복원력이 없음
이 예시에서 회사는 노드 풀 업그레이드 중에 발생하는 포드 제거 및 재예약에 잘 응답하지 않는 데이터베이스를 실행합니다. 클러스터 관리자가 다음과 같은 제외를 설정합니다.
- 마이너 또는 노드 업그레이드 없음: 3개월 동안 노드 업그레이드가 없습니다. 회사에서 데이터베이스의 다운타임을 수락할 준비가 되면 수동 노드 업그레이드를 트리거합니다.
다음 단계
- 클러스터 또는 노드 업그레이드 자세히 알아보기
- 노드 업그레이드 전략 자세히 알아보기
- 클러스터 알림 수신 방법 알아보기