이 문서에서는 플랫폼 관리자가 Google Kubernetes Engine (GKE) 클러스터 업그레이드를 관리하기 위한 권장사항을 제공합니다. 기본적으로 GKE는 환경의 성능과 보안을 유지하기 위해 새 기능, 버그 수정, 보안 패치를 제공하도록 클러스터의 컨트롤 플레인 및 노드 버전을 자동으로 업그레이드합니다.
이러한 자동 업그레이드가 운영 요구사항에 부합하고 워크로드 중단을 최소화할 수 있도록 GKE는 최대한의 제어권을 주장할 수 있는 도구를 제공합니다. 이 가이드에서는 이러한 도구를 효과적으로 사용하여 높은 성능과 가용성을 유지하는 방법을 설명합니다. 기본적인 이해를 위해서는 GKE 클러스터 업그레이드 정보를 참고하세요.
컨트롤 플레인 및 노드의 GKE 버전 업데이트만 포함하는 클러스터 업그레이드 외에도 GKE는 주기적으로 클러스터에 추가 업데이트를 실행합니다. 이 문서의 권장사항을 구현하면 이러한 유형의 변경사항에 대비할 수 있습니다. 자세한 내용은 클러스터 수명 주기 변경사항을 관리하여 서비스 중단 최소화를 참고하세요.
모든 GKE 권장사항의 통합 개요는 GKE 권장사항을 참고하세요.체크리스트
다음 표에는 이어지는 섹션에서 자세히 설명하는 작업이 요약되어 있습니다. 클러스터 업그레이드를 위해 환경을 준비할 때 이러한 작업을 실행하는 것이 좋습니다.
| 권장사항 | 작업 |
|---|---|
| 출시 채널을 사용하여 기능 속도와 업그레이드 안정성 간의 균형 선택 | |
| 유지보수 정책으로 업그레이드 시기 선택 | |
| 클러스터 간 업그레이드 출시 제어 | |
| 업그레이드 트리거 방식 제어 | |
| 클러스터 업그레이드 모니터링 | |
| 노드 업그레이드 중 기존 워크로드의 중단 최소화 |
출시 채널을 사용하여 기능 속도와 업그레이드 안정성 간의 균형 선택
출시 채널을 사용하면 기능 개발 속도와 업그레이드 안정성 간에 균형을 선택할 수 있습니다. GKE 클러스터는 기본적으로 일반 출시 채널에 등록됩니다. GKE가 보안 패치를 제공하고, 알려진 문제를 수정하고, 새 기능을 도입하기 위해 클러스터의 컨트롤 플레인과 노드를 업그레이드할 때 출시 채널은 클러스터가 실행하는 GKE 버전을 결정합니다. 예를 들어 새 기능을 더 빨리 사용하고 싶다면 신속 채널을 선택하고, 안정성이 더 입증된 버전을 사용하고 싶다면 안정화 버전 채널을 선택하면 됩니다. 특정 채널 간 선택에 대한 자세한 내용은 사용 가능한 채널을 참고하세요.
클러스터를 수동으로 업그레이드하려는 경우에도 새 버전을 선택하기 전에 채널에서 사용 가능한 버전과 자동 업그레이드 대상을 검토하여 출시 채널을 선택하면 이점이 있습니다.
또한 중요한 보안 패치를 받기 위해 출시 채널에서 패치 버전을 최대한 빨리 받으려면 패치 버전을 더 빨리 받는 방법을 참고하세요.
마이너 버전에 필요한 지원 수준 선택
GKE는 부 버전이 일반 채널에서 제공된 후 이 버전에 대해 최대 24개월의 지원 기간을 제공합니다. 이 지원에는 14개월의 표준 지원 기간과 약 10개월의 확장 지원 기간이 포함됩니다(확장 채널에서 이용 가능). GKE에서 마이너 버전을 지원하는 방법에 대한 자세한 내용은 마이너 버전 지원을 참고하세요.
스탠더드 지원 날짜가 경과된 후에도 보안 패치를 계속 제공받으면서 클러스터를 마이너 버전으로 더 오래 유지해야 하거나 스탠더드 지원 종료 시행을 방지하려면 확장 채널을 사용해도 됩니다. 자세한 내용은 뒷부분의 장기적 지원이 필요한 경우 확장 채널 사용 섹션을 참고하세요.
마이너 버전이 지원 종료에 도달하면 클러스터가 등록된 출시 채널에 따라 GKE가 클러스터의 성능과 보안을 유지하기 위해 클러스터를 자동으로 업그레이드합니다. 자세한 내용은 보안 및 호환성을 위한 자동 클러스터 업그레이드를 참고하세요. 이 문서에 설명된 도구를 사용하여 클러스터의 자동 업그레이드를 방지하거나 지연하는 경우, 클러스터가 실행되는 마이너 버전의 지원이 종료되기 전에 클러스터를 수동으로 업그레이드하는 것이 좋습니다. 그렇지 않으면 GKE가 클러스터를 자동으로 업그레이드합니다.
유지보수 정책으로 업그레이드 시기 선택
업그레이드 가능 여부를 제어하려면 다음을 사용하세요.
- 유지보수 기간: GKE가 클러스터를 업그레이드할 수 있는 반복되는 기간을 선택합니다(예: 비즈니스 사용량이 많지 않은 시간). 업그레이드 프로세스가 유지보수 기간을 초과하여 실행되면 GKE는 작업을 일시중지하고 다음 유지보수 기간 중에 작업을 재개하려 합니다.
- 유지보수 제외: 소매업의 주요 할인 이벤트와 같이 GKE에서 클러스터를 업그레이드할 수 없는 특정 기간을 선택합니다. 또한 새 버전으로 업그레이드되는 다른 클러스터에 문제가 있는 경우와 같이 클러스터의 자동 업그레이드를 일시적으로 연기하기 위해 유지보수 제외를 사용할 수도 있습니다.
- 고급 사용 사례의 경우 GKE에서 업그레이드를 수행하는 대신 특정 유형의 업그레이드를 수동으로 수행해야 할 수 있습니다. 유지보수 제외를 사용하여 이러한 유형의 자동 업그레이드를 사용 중지할 수 있습니다. 예를 들어 '마이너 또는 노드 업그레이드 없음' 범위를 사용하여 모든 마이너 업그레이드와 모든 노드 업그레이드를 사용 중지할 수 있습니다. 이러한 업그레이드는 직접 수동으로 실행해야 합니다. 그렇지 않으면 GKE가 부 버전 지원이 종료될 때 클러스터를 업그레이드합니다.
- 유지관리 빈도: 고급 사용 사례의 경우 클러스터 중단 예산으로 연속된 두 자동 업그레이드 간의 최소 간격을 제어합니다.
유지보수 정책을 구성하면 업그레이드 예측 가능성을 높이고 워크로드에 가장 편리한 시간에 업그레이드가 진행되도록 할 수 있습니다.
클러스터 간 업그레이드 출시 제어
여러 환경을 사용하여 소프트웨어 및 인프라 변경사항을 프로덕션 환경과 별도로 테스트하여 위험과 원치 않는 다운타임을 최소화하는 것이 좋습니다. 최소한 프로덕션 환경과 사전 프로덕션 또는 테스트 환경이 있어야 합니다.
다음 권장 환경을 참조하세요.
| 환경 | 설명 |
|---|---|
| 프로덕션 | 미션 크리티컬 비즈니스 애플리케이션의 최종 사용자에게 실시간 트래픽을 제공합니다. |
| 카나리아 | 모든 클러스터가 업그레이드되기 전에 프로덕션 환경의 일부를 테스트합니다. |
| 스테이징 | 변경사항이 프로덕션에 배포되기 전에 이전 환경에서 배포된 모든 새 변경사항이 의도한 대로 작동하는지 확인합니다. |
| 테스트 | 프로덕션에서 사용할 GKE 버전으로 워크로드의 벤치마킹, 테스트, 품질 보증 (QA)을 실행합니다. |
| 개발 | 프로덕션에서 실행되는 동일한 버전을 사용하여 활성 개발을 진행합니다. 이 환경에서는 프로덕션에 배포할 수정사항과 단계적 변경을 적용합니다. |
GKE는 다음 섹션에 자세히 설명된 대로 출시 시퀀싱과 같은 기능을 제공하여 이러한 다양한 환경에 업그레이드가 배포되는 방식을 제어할 수 있도록 지원합니다.
출시 시퀀싱을 사용하여 여러 환경에 출시
이러한 환경 내에서 그리고 환경 간에 새로운 GKE 버전을 점진적으로 출시하려면 출시 순서를 사용하는 것이 좋습니다. 출시 시퀀싱을 사용하면 모든 클러스터가 배포 단계 전반에 걸쳐 동일한 출시 채널과 마이너 버전을 사용합니다. GKE는 구성한 시퀀스에 따라 새 버전을 점진적으로 출시합니다. GKE에서 환경 전반에 새 버전을 출시하면 클러스터 환경과 워크로드가 새 버전에서 예상대로 실행되는지 확인할 수 있습니다.
새 환경을 구성하는 경우 맞춤 단계가 있는 출시 시퀀싱(미리보기)을 사용하세요. 이 최신 버전의 출시 시퀀싱을 사용하면 새 버전을 여러 단계로 Fleet에 출시할 수 있습니다. 이 방식을 사용하면 예를 들어 GKE가 프로덕션의 나머지 부분을 업그레이드하기 전에 프로덕션에서 카나리아 환경을 업그레이드할 수 있습니다. 또는 맞춤 단계 없이 더 선형적인 모델을 사용하는 정식 버전 기능에 관해서는 롤아웃 순서가 지정된 클러스터 업그레이드 정보를 참고하세요.
GKE 패치 및 부 버전 업그레이드 테스트
GKE는 매주 한 번씩 클러스터를 새 패치로 자동 업그레이드합니다. 하지만 마이너 버전 업그레이드는 연간 약 3회만 이루어집니다. 새 Kubernetes 마이너 버전은 동일한 마이너 버전의 패치에 비해 더 많은 변경사항을 도입합니다. 환경 전반에 걸쳐 마이너 버전 업그레이드를 출시하는 동안 추가 검토를 적용하여 새 마이너 버전이 클러스터 및 워크로드와 예상대로 작동하는지 확인하는 것이 좋습니다.
클러스터를 업그레이드하기 전에 검사 실행
GKE는 자동 클러스터 업그레이드를 실행하기 전에 출시 채널에 따라 달라지는 시간 동안 새 버전을 검증하고 클러스터의 준비 상태를 검토합니다.
클러스터를 업그레이드하기 전에 다음을 수행하는 것이 좋습니다.
- 패치 및 마이너 업그레이드를 포함한 모든 업그레이드의 경우 다음을 충족해야 합니다.
- GKE 출시 노트에서 문제를 확인하고 새 부 버전 및 패치 버전의 변경사항을 확인하세요.
- GKE 알려진 문제에서 클러스터 환경 및 새 버전과 관련된 문제가 있는지 확인합니다.
- 마이너 업그레이드의 경우 다음도 검토하세요.
- API 지원 중단을 확인합니다. 자세한 내용은 새 버전의 GKE 출시 노트, Kubernetes 변경 로그, 기능 및 API 지원 중단을 참고하세요.
- 컨트롤 플레인과 노드 간 버전 차이가 지원되는지 확인합니다. GKE는 컨트롤 플레인보다 최대 2개 부 버전이 낮은 노드 실행을 지원합니다. 자세한 내용은 GKE 버전 편향 정책을 참고하세요.
- 노드 업그레이드의 경우:
- 노드에서 사용하는 노드 업그레이드 전략에 충분한 리소스가 있는지 확인합니다. 자세한 내용은 노드 업그레이드 리소스 확인을 참고하세요.
업그레이드 트리거 방식 제어
GKE는 기본적으로 클러스터를 새 버전으로 정기적으로 자동 업그레이드합니다. 하지만 수동 업그레이드를 사용하여 원하는 시점에 정확하게 클러스터를 업그레이드하고 클러스터가 실행되는 버전을 제어할 수도 있습니다.
다음을 수행하면 됩니다.
- 클러스터를 수동으로 업그레이드합니다.
진행 중인 자동 또는 수동 노드 업그레이드에 대해 다음을 비롯한 작업을 실행합니다.
- 업그레이드를 취소합니다.
- 업그레이드를 재개합니다.
- 업그레이드를 롤백합니다.
- 진행 중인 업그레이드를 완료합니다.
업그레이드 프로세스를 더 세부적으로 제어하려면 유지보수 제외를 구성한 후 필요에 따라 수동 업그레이드를 실행하는 것이 좋습니다. 수동 업그레이드 및 진행 중인 업그레이드에 대해 취할 수 있는 기타 작업에 대한 자세한 내용은 클러스터 또는 노드 풀 수동 업그레이드를 참고하세요.
클러스터 업그레이드 모니터링
GKE 업그레이드가 예상대로 진행되고 클러스터 환경의 성능과 가용성이 유지되도록 하려면 다음 도구를 사용하여 클러스터 업그레이드를 모니터링하세요. 클러스터의 상태를 계속 파악하려면 알림, 통계 및 추천, 로그와 같은 도구를 사용하세요. 특히 지원 종료 알림, 업그레이드 시작 알림, 마이너 버전 업그레이드용 선택형 예약 업그레이드 알림에 주의하는 것이 좋습니다. 이러한 알림을 확인할 수 있도록 알림 정책을 설정하세요.
현재 업그레이드에 대한 자세한 내용은 다음 리소스를 참고하세요.
- 현재 자동 업그레이드 타겟을 비롯한 특정 클러스터의 업그레이드에 관한 자세한 내용은 클러스터 업그레이드 가시성 확보를 참고하세요.
- 일반 자동 업그레이드 대상을 검색하려면 현재 버전 표를 참고하세요. 클러스터의 마이너 버전에 대한 구체적인 매핑은 버전 업데이트 출시 노트를 참고하세요.
- GKE 출시 일정에서 마이너 버전을 업그레이드할 수 있고 지원 종료에 도달하는 최적의 예상 시점을 확인하세요.
- 클러스터 알림을 사용하여 Cloud Logging 또는 Pub/Sub를 통해 클러스터의 업그레이드 이벤트(예: 예약된 클러스터 업그레이드(미리보기))에 대한 정보를 확인합니다.
통계 및 권장사항을 사용하여 다음과 같은 클러스터별 권장사항을 확인합니다.
노드 업그레이드 중 기존 워크로드의 중단 최소화
이전 섹션에 설명된 일반적인 권장사항 외에도 클러스터 환경과 워크로드의 요구사항에 맞게 업그레이드 프로세스를 추가로 맞춤설정하기 위해 고급 구성을 고려하는 것이 좋습니다.
특정 워크로드 프로필에 대한 추가 고려사항
특정 유형의 워크로드와 클러스터 환경에서는 클러스터 업그레이드를 위해 추가 준비가 필요합니다. 워크로드가 다음 카테고리 중 하나 이상에 해당하는 경우 다음 추가 고려사항을 확인하세요.
- 라이브 마이그레이션되지 않는 머신에서 실행되는 워크로드: GKE에서 사용자 대신 만드는 Compute Engine 인스턴스인 GKE 노드에는 기본 인프라에 대한 유지보수가 주기적으로 필요합니다. 대부분의 Compute Engine 인스턴스는 라이브 마이그레이션할 수 있습니다. 즉, 이 유지보수가 발생할 때 실행 중인 워크로드가 중단되지 않습니다. 하지만 특정 머신 유형은 라이브 마이그레이션할 수 없으므로 GKE 노드에서 실행되는 워크로드가 중단될 수 있습니다. 중요한 점은 AI/ML 워크로드용 GPU 및 TPU와 같은 가속기는 라이브 마이그레이션할 수 없다는 것입니다. 자세한 내용은 라이브 마이그레이션되지 않는 GKE 노드의 중단 관리를 참고하세요.
- 용량 제한이 있는 워크로드: 워크로드에서 용량 제한이 있는 머신 유형을 사용하는 경우 클러스터 업그레이드를 실행할 때 추가 고려사항이 필요합니다. 자세한 내용은 노드 업그레이드 리소스 확인을 참고하세요.
- 스테이트풀 워크로드: 워크로드가 스테이트풀이고 정상적으로 종료하고 다시 시작하기 위한 특정 요구사항이 있는 경우 클러스터 업그레이드를 실행할 때 추가 고려사항이 필요합니다. 자세한 내용은 워크로드가 서비스 중단에 대비되어 있는지 확인을 참고하세요.
다음 섹션을 검토하여 사용 가능한 도구를 사용하여 이러한 유형의 워크로드를 업그레이드하는 방법을 알아보세요.
노드 업그레이드 전략 선택
GKE Standard 모드에서 GKE는 노드 풀의 개별 노드가 업그레이드되는 방법을 결정하는 다양한 노드 업그레이드 전략을 제공합니다. Standard 노드 풀의 업그레이드 전략을 선택하면 속도, 워크로드 중단, 위험 완화, 비용 최적화가 적절하게 균형 잡힌 프로세스를 선택할 수 있습니다. 필요에 맞게 전략의 매개변수를 구성할 수도 있습니다. GKE Autopilot 모드에서는 GKE가 노드 업그레이드를 관리하므로 사용된 특정 전략을 선택할 필요가 없습니다. 자세한 내용은 노드 업그레이드 전략 정보를 참고하세요.
중단에 대한 허용 범위 설정
포드 중단 예산(PDB)을 사용하여 업그레이드 중에 GKE가 노드를 다시 만들 때(워크로드의 복제본 수가 일시적으로 감소할 수 있음) 워크로드가 충분한 중복성을 유지하도록 합니다.
PDB가 설정되면 GKE는 포드 수가 구성된 한도 이하인 경우 애플리케이션의 포드를 종료하지 않습니다. GKE 업그레이드는 최대 60분 동안 PDB를 준수합니다. 또한 GKE는 PDB로 인해 노드 드레이닝이 차단되거나 PDB 제한 시간이 도달하여 PDB 위반에도 불구하고 포드가 강제 삭제되는 경우 알림을 보냅니다. 자세한 내용은 노드 풀 업그레이드 중 중단 이벤트를 참고하세요.
정상 종료를 사용하여 애플리케이션 종료
정상 종료를 구성하면 워크로드가 종료를 준비할 충분한 시간을 확보할 수 있습니다. 노드 업그레이드 중에 GKE는 기본 일시 급증 업그레이드를 사용하는 경우 최대 60분, 블루-그린 업그레이드 및 자동 확장 블루-그린 업그레이드(미리보기)를 사용하는 경우 최대 24시간 동안 정상 종료 설정을 준수합니다.
정상 종료 설정 구성에 대한 자세한 내용은 GKE에서 워크로드를 정상적으로 종료하도록 구성을 참고하세요.
장기적 지원이 필요한 경우 확장 채널 사용
클러스터를 부 버전으로 더 오래 유지하려면 확장 채널에 클러스터 등록에 대한 권장사항을 따르세요. 이 채널을 사용하면 GKE에서 약 24개월 동안 부 버전을 지원합니다. 확장 채널을 사용하면 마이너 버전 업그레이드를 제어할 수 있으며, 직접 업그레이드를 시작하지 않는 경우 GKE는 지원 종료 시 자동 업그레이드만 실행합니다. 자세한 내용은 확장 채널로 장기 지원 받기를 참고하세요.
표준 지원 기간보다 오래 마이너 버전을 유지할 필요는 없지만 마이너 버전 업그레이드를 제어하고 싶다면 '마이너 업그레이드 없음' 범위로 유지보수 제외를 대신 사용하세요.
채널의 이점을 최대한 활용하려면 다음 권장사항을 준수하는 것이 좋습니다. 이러한 권장사항 중 일부를 따르려면 클러스터 수동 업그레이드 및 클러스터 출시 채널 변경을 포함한 직접 조치가 필요합니다. 다음과 같은 지원되는 시나리오와 확장 채널을 사용하지 않는 경우를 검토하세요.
부 버전으로 장시간 일시적으로 유지
예를 들어 다음 부 버전에서 삭제되는 지원 중단된 API 사용을 완화하기 위해 14개월의 스탠더드 지원 기간보다 오래 동안 클러스터를 부 버전으로 임시로 유지해야 하는 경우 다음 프로세스를 수행합니다. 다음 부 버전으로 업그레이드를 준비하는 동안 임시로 클러스터를 다른 출시 채널에서 확장 채널로 이동하여 보안 패치를 계속 받을 수 있습니다. 다음 부 버전으로 업그레이드할 준비가 되면 클러스터를 수동으로 업그레이드한 후 클러스터를 다시 원래 출시 채널로 이동합니다.
마이너 버전 업그레이드 연간 1~2회
클러스터를 새 부 버전으로 업그레이드할 준비가 되었을 때 일부 새 기능을 계속 수신하는 동안에 클러스터 중단을 최소화하려면 다음을 수행합니다.
- 클러스터를 확장 채널에 등록합니다.
- 1년에 1~2회 연속 마이너 버전 업그레이드를 2번 수행합니다. 예를 들어 1.33에서 1.34, 1.35로 순차적으로 업그레이드합니다.
이 프로세스를 통해 클러스터가 사용 가능한 부 버전으로 유지되고 새로운 부 버전의 기능이 수신되지만 클러스터가 준비되었다고 판단되면 부 버전 업그레이드만 수신됩니다.
확장 채널을 사용하지 않으려는 경우
확장 채널을 의도된 목적으로 사용하려면 직접 조치가 필요합니다. 다음 시나리오에서는 클러스터의 부 버전을 적극적으로 관리하지 않고 확장 채널을 사용할 경우의 결과를 보여줍니다.
아무 작업도 수행하지 않고 동일한 주기로 부 버전 업그레이드 수신
클러스터를 부 버전으로 영구 유지하려면 클러스터를 확장 채널에 등록하고 추가 조치를 취하지 않습니다. 결국 모든 부 버전은 지원되지 않고 GKE가 지원되지 않는 부 버전에서 클러스터를 자동으로 업그레이드합니다. 따라서 GKE는 평균적으로 약 4개월마다 이 클러스터를 지원되지 않는 마이너 버전 하나에서 곧 지원되지 않는 마이너 버전으로 업그레이드합니다. 이 접근 방식을 사용하면 클러스터가 다른 출시 채널처럼 마이너 버전 업그레이드를 자주 받지만 나중에 새 기능을 수신합니다.
다음 단계
- GKE의 다양한 모드에 대한 자세한 내용은 Autopilot 클러스터와 Standard 클러스터의 기능 비교를 참고하세요.