클러스터 업그레이드 권장사항

이 페이지에서는 Google Kubernetes Engine(GKE) 클러스터를 최신 상태로 원활하게 유지하고, 요구사항에 맞는 업그레이드 전략을 수립하고, 환경의 가용성 및 안정성을 향상시키기 위한 권장사항을 제공합니다. 이 정보를 참조하여 워크로드 중단을 최소화하면서 클러스터를 업데이트하여 안정성과 보안을 확보할 수 있습니다.

또는 Fleet으로 구성된 프로덕션 환경에서 자동 클러스터 업그레이드를 관리하려면 출시 시퀀싱으로 클러스터 업그레이드 정보를 참조하세요.

여러 환경 설정

소프트웨어 업데이트를 제공하는 워크플로의 일환으로 여러 환경을 사용하는 것이 좋습니다. 여러 환경을 사용하면 소프트웨어 및 인프라 업데이트를 프로덕션 환경과 별도로 테스트하여 위험과 원치 않는 다운타임을 최소화할 수 있습니다. 최소한 프로덕션 환경과 사전 프로덕션 또는 테스트 환경이 있어야 합니다.

다음 권장 환경을 참조하세요.

환경 설명
프로덕션 미션 크리티컬 비즈니스 애플리케이션의 최종 사용자에게 실시간 트래픽을 제공하는 데 사용됩니다.
스테이징 변경사항이 프로덕션에 배포되기 전에 이전 환경에서 배포된 모든 새 변경사항이 의도한 대로 작동하는지 확인하는 데 사용됩니다.
테스트 프로덕션에서 사용할 GKE 출시 버전에 대한 성능 벤치마크, 테스트, QA 워크로드에 사용됩니다. 이 환경에서는 프로덕션에서 업그레이드를 진행하기 전에 제어 영역과 노드의 업그레이드를 테스트할 수 있습니다.
개발 프로덕션에서 실행되는 동일한 버전을 사용하는 개발 단계에 사용됩니다. 이 환경에서는 프로덕션에 배포할 수정사항과 단계적 변경을 적용합니다.
Canary 최신 Kubernetes 출시 버전, GKE 기능, API를 테스트하기 위한 보조 개발 환경으로 사용되어 이 버전이 승격되고 기본 버전이 되었을 때 TTM(time to market)을 단축하는 데 도움이 되도록 합니다.

출시 채널에 클러스터 등록

Kubernetes는 보안 업데이트를 제공하고 알려진 문제를 해결하며 새로운 기능을 소개하기 위해 자주 업데이트를 출시합니다. GKE 출시 채널을 사용하면 클러스터에 배포된 버전의 안정성과 기능의 조합 간에 균형을 맞출 수 있습니다. 새 클러스터를 출시 채널에 등록하면 Google에서 클러스터와 노드 풀의 버전과 업그레이드 주기를 자동으로 관리합니다.

클러스터를 최신 GKE 및 Kubernetes 업데이트에 맞게 최신 상태로 유지하기 위한 몇 가지 권장 환경 및 클러스터를 등록해야 하는 각 출시 채널입니다.

환경 출시 채널 설명
프로덕션 안정화 버전 또는 일반 안정성과 버전 성숙도를 위해 프로덕션 워크로드에 안정화 버전이나 일반 채널을 사용합니다.
스테이징 프로덕션과 동일 테스트가 프로덕션이 업그레이드될 버전으로 수행된 것을 나타내려면 프로덕션과 동일한 출시 채널을 사용합니다.
테스트
개발
Canary 신속 새로운 GKE 기능 또는 API를 테스트하여 최신 Kubernetes 출시 버전을 테스트하고 빠르게 진행하려면 신속 채널을 사용합니다. 신속 채널의 버전이 프로덕션에 사용하는 채널로 승격될 때 TTM(time to market)이 개선될 수 있습니다.
해당 사항 없음 확장 스탠더드 지원 날짜가 경과된 후에도 보안 패치를 계속 제공받으면서 클러스터를 부 버전으로 더 오래 유지하려면 확장 채널을 사용합니다. 자세한 내용은 장기적 지원이 필요한 경우 확장 채널 사용을 참조하세요.

클러스터 제어 영역은 클러스터가 출시 채널에 등록되었는지 여부에 관계없이 항상 정기적으로 업그레이드됩니다.

지속적 업그레이드 전략 만들기

클러스터를 출시 채널에 등록하면 해당 클러스터는 채널의 품질 및 안정성 기준을 충족하는 버전으로 정기적으로 업그레이드됩니다. 다음 업데이트에는 보안 및 버그 수정이 포함되며 각 채널에 대한 면밀한 검토가 적용됩니다.

  • 패치는 모든 채널에서 제어 영역과 노드로 점진적으로 내보내지는데 이 때 공개 버전 채널에서 시작하기 전에 신속 채널과 일반 채널에 흡수 시간을 축적합니다.
  • Kubernetes OSS 정책을 준수하도록 먼저 컨트롤 플레인이 업그레이드된 후 노드가 업그레이드 됩니다. (예: kubelet은 kube-apiserver보다 최신 버전이 아니어야 합니다.).
  • GKE는 중요도에 따라 채널에 패치를 자동으로 배포합니다.
  • 공개 버전 채널은 중요한 패치만 수신합니다.

새 GKE 버전에 대한 업데이트 받기

새 버전에 대한 정보는 기본 GKE 출시 노트 페이지와 RSS 피드에 게시됩니다. 각 출시 채널에는 해당 채널에 권장되는 GKE 버전에 대한 정보가 담긴 간소화된 전용 출시 노트 페이지(예: 공개 버전 채널의 출시 노트)가 있습니다.

업그레이드 시작 전에 GKE 업그레이드에 대한 업데이트를 사전에 받으려면 Pub/Sub를 사용하고 업그레이드 알림을 구독합니다.

새 버전이 사용 가능한 상태가 되면 버전이 기본 버전이 되기 전에 업그레이드를 계획해야 합니다. 이 방식을 사용하면 GKE는 미리 업그레이드된 클러스터의 자동 업그레이드를 건너뛰므로 예측 가능성을 높이고 더욱 효과적으로 제어할 수 있습니다.

새 패치 및 부 버전 테스트 및 확인

모든 출시 버전은 출시된 채널에 관계없이 내부 테스트를 통과합니다. 그러나 업스트림 Kubernetes 및 GKE의 빈번한 업데이트와 패치로 프로덕션 환경, 특히 Kubernetes 부 버전 업그레이드에 출시 버전이 배포되기 전에 새 버전을 테스트 및 스테이징 환경에서 테스트하는 것이 좋습니다.

각 출시 채널은 기본 버전과 사용 가능 버전 두 가지를 제공합니다.

  • 새 패치 출시는 기본 버전이 되기 1주일 전에 제공됩니다.
  • 새로운 Kubernetes 부 버전은 기본 버전이 되기 4주 전에 제공됩니다.

GKE는 클러스터를 기본 버전으로 점진적으로 자동 업그레이드합니다. 업그레이드 프로세스를 보다 세밀하게 제어해야 하는 경우 사용 가능한 버전으로 미리 업그레이드하는 것을 권장합니다. GKE 자동 업그레이드는 수동으로 업그레이드된 클러스터를 건너뜁니다.

업그레이드를 자동화하고 간소화하기 위해 권장되는 방법은 다음과 같습니다.

  • 사용 가능한 버전을 사용하는 사전 프로덕션 환경
  • 테스트 및 인증을 위해 사용 가능한 새 버전에 대해 팀에 알리기 위한 업그레이드 알림 클러스터에 설정
  • 채널의 기본 버전을 사용하여 출시 채널을 구독한 프로덕션 환경
  • 프로덕션 클러스터에 사용 가능한 새 버전 점진적 출시 예를 들어 프로덕션 클러스터가 여러 개 있는 경우 점진적 업그레이드 계획은 이러한 클러스터의 일부를 사용 가능한 버전으로 업그레이드하면서 시작합니다. 이 때 나머지는 기본 버전으로 둡니다. 그런 다음 업그레이드가 100%로 완료될 때까지 조금씩 추가로 업그레이드됩니다.

다음 표에는 출시 이벤트 및 권장 조치가 요약되어 있습니다.

이벤트 권장 조치
새 버전 X가 채널에서 사용할 수 있는 버전이 됩니다. 테스트 클러스터를 수동으로 업그레이드하고 새 버전을 검증 및 테스트합니다.
버전 X가 기본 버전이 됩니다. GKE는 기본 버전으로 자동 업그레이드를 시작합니다. 프로덕션을 미리 업그레이드하는 것이 좋습니다.
GKE는 클러스터 자동 업그레이드를 시작합니다. 클러스터의 자동 업그레이드를 허용하거나 유지보수 제외 기간을 사용하여 업그레이드를 연기합니다.

패치 출시의 업그레이드 전략

패치 출시의 권장 업그레이드 전략은 다음과 같습니다.

  • 모든 클러스터가 공개 버전 채널을 구독합니다.
  • 새로운 버전을 스테이징 클러스터에 먼저 출시합니다.
  • 프로덕션 클러스터를 새로운 기본 버전으로 자동 업그레이드합니다.
  • GKE에 사용 가능한 새 버전을 정기적으로 모니터링합니다.
시간 이벤트 어떻게 해야 하나요?
T - 1주 새 패치 버전이 사용할 수 있는 버전이 됩니다. 스테이징 환경을 업그레이드합니다.
T 패치 버전이 기본값이 됩니다. 예측 가능성을 높이려면 프로덕션 제어 영역을 미리 업그레이드하는 것이 좋습니다.
T GKE는 제어 영역을 기본 버전으로 업그레이드하기 시작합니다. 예측 가능성을 높이려면 프로덕션 노드 풀을 미리 업그레이드하는 것이 좋습니다.
T + 1주 GKE는 클러스터 노드 풀을 기본 버전으로 업그레이드하기 시작합니다. GKE 클러스터를 자동 업그레이드하고 수동으로 업그레이드된 클러스터를 건너뜁니다.

새로운 부 버전의 업그레이드 전략

다음은 새로운 부 버전에 권장되는 업그레이드 전략입니다.

시간 이벤트 어떻게 해야 하나요?
T - 3주 새로운 부 버전이 사용 가능 버전이 됩니다. 테스트 제어 영역을 업그레이드합니다.
T - 2주
  1. 제어 영역 업그레이드가 성공적으로 완료되면 프로덕션 제어 영역을 미리 업그레이드하는 것이 좋습니다.
  2. 테스트 노드 풀을 업그레이드합니다.
T - 1주 업그레이드가 성공적으로 완료되면 프로덕션 노드 풀을 미리 업그레이드하는 것이 좋습니다.
T 부 버전이 기본 버전이 됩니다.
T GKE는 클러스터 제어 영역을 기본 버전으로 업그레이드하기 시작합니다. 프로덕션 출시 전에 테스트 또는 오류 완화가 더 필요한 경우 제외 기간을 만듭니다.
T + 1주 GKE는 클러스터 노드 풀을 기본 버전으로 업그레이드하기 시작합니다. GKE 클러스터를 자동 업그레이드하고 수동으로 업그레이드된 클러스터를 건너뜁니다.

업그레이드 중 기존 워크로드 중단 감소

클러스터의 안정성과 비즈니스 연속성을 보장하려면 보안 패치 및 버그 수정으로 클러스터를 최신 상태로 유지하는 것이 중요합니다. 정기적인 업데이트는 취약점 및 장애로부터 워크로드를 보호합니다.

유지보수 기간 및 유지보수 제외 예약

업그레이드 예측 가능성을 높이고 바쁘지 않은 영업시간에 맞춰 업그레이드를 조정하기 위해 유지보수 기간을 만들어 제어 영역과 노드의 자동 업그레이드를 제어할 수 있습니다. GKE는 유지보수 기간을 준수합니다. 즉, 업그레이드 프로세스가 정의된 유지보수 기간을 초과하여 실행되면 GKE는 작업을 일시중지하고 다음 유지보수 기간 중에 작업을 재개하려 합니다.

GKE는 여러 리전에서 클러스터 제어 영역과 노드의 자동 업그레이드는 물론 새 버전을 공개하는 데 며칠에 걸친 출시 일정을 따릅니다. 일반적으로 출시는 4일 이상 진행되며 여기에는 문제를 관찰하고 모니터링하는 시간이 포함됩니다. 멀티 클러스터 환경에서는 클러스터마다 별도의 유지보수 기간을 사용하여 클러스터에서 출시를 순차적으로 수행할 수 있습니다. 예를 들어 클러스터마다 유지보수 기간을 다르게 설정하여 서로 다른 리전의 클러스터를 유지보수하는 시기를 제어할 수 있습니다.

특히 수요가 많은 비즈니스 기간 동안 중단을 줄이는 또 다른 도구는 유지보수 제외입니다. 이 기간 동안 자동 유지보수를 수행하지 않으려면 유지보수 제외를 사용합니다. 새 클러스터 또는 기존 클러스터에서 유지보수 제외를 설정할 수 있습니다. 또한 제외를 업그레이드 전략과 함께 사용할 수 있습니다. 예를 들어 업그레이드로 인해 테스트 또는 스테이징 환경이 실패할 경우 프로덕션 클러스터로의 업그레이드를 연기할 수 있습니다.

중단에 대한 허용 범위 설정

Kubernetes의 복제본 개념에 익숙할 것입니다. 복제본은 성능과 응답성을 높이기 위해 워크로드의 중복성을 보장합니다. 설정되면 복제본은 특정 시점에 실행되는 Pod 복제본 수를 제어합니다. 하지만 유지보수 중에 Kubernetes는 기본 노드 VM을 삭제하여 복제본 수를 줄일 수 있습니다. 유지보수 중에도 워크로드에 애플리케이션에 대한 충분한 수의 복제본이 있는지 확인하려면 Pod 중단 예산(PDB)을 사용합니다.

Pod 중단 예산에서는 Pod를 종료하면 현재 복제본 수가 원하는 값 아래로 내려가더라도 종료 가능한 Pod 수(또는 백분율)를 정의할 수 있습니다. 이 프로세스는 마이그레이션된 Pod가 완전히 작동할 때까지 기다릴 필요가 없으므로 노드 드레이닝 속도를 높일 수 있습니다. 대신 드레이닝은 PDB 구성에 따라 노드에서 Pod를 제거하므로 배포를 통해 다른 가용 노드에 누락된 Pod를 배포할 수 있습니다. PDB가 설정되면 GKE는 Pod의 수가 구성된 한도 이하인 경우 애플리케이션의 Pod를 종료하지 않습니다. GKE는 최대 60분 동안 PDB를 따릅니다.

노드 풀 업그레이드 제어

GKE에서는 노드 업그레이드 전략을 사용하여 노드 풀의 노드가 업그레이드되는 방법을 결정할 수 있습니다. 기본적으로 노드 풀에는 일시 급증 업그레이드가 사용됩니다. 일시 급증 업그레이드의 경우 GKE 노드 풀의 업그레이드 프로세스 중에 노드 풀에서 모든 VM을 다시 만듭니다. 순차적 업데이트 방식으로 새 버전(업그레이드된 이미지)을 사용하여 새 VM이 생성됩니다. 따라서 이전 노드에서 실행 중인 모든 pod를 종료하고 pod를 새 노드로 이동해야 합니다. 워크로드는 충분한 중복성(복제본)을 갖추어 실행할 수 있고 Kubernetes를 활용하여 필요에 따라 pod를 이동 및 다시 시작할 수 있습니다. 그러나 일시적으로 줄어든 복제본 수로 인해 중단이 발생할 수 있으며 Kubernetes가 원하는 상태를 다시 충족할 수 있을 때까지 워크로드 성능이 저하될 수 있습니다. 즉, 최소 복제본 수를 충족해야 합니다. 일시 급증 업그레이드를 사용하여 이러한 중단을 방지할 수 있습니다.

일시 급증 업그레이드가 사용 설정된 업그레이드 중에 GKE는 먼저 업그레이드에 필요한 리소스(머신)를 보호하고 업그레이드된 새 노드를 만든 후 이전 노드를 드레이닝하고 마지막으로 종료합니다. 이렇게 하면 예상 용량이 업그레이드 과정 내내 그대로 유지됩니다.

업그레이드 프로세스가 더 오래 걸리는 큰 클러스터의 경우 한 번에 여러 노드를 동시에 업그레이드하여 업그레이드 완료 시간을 단축할 수 있습니다. maxSurge=20, maxUnavailable=0으로 일시 급증 업그레이드를 사용하여 기존 용량을 사용하지 않고 한 번에 20개 노드를 업그레이드하도록 GKE에 지시합니다.

장기적 지원이 필요한 경우 확장 채널 사용

클러스터를 부 버전으로 더 오래 유지하려면 확장 채널에 클러스터 등록에 대한 권장사항을 따르세요. 이 채널을 사용하면 GKE에서 약 24개월 동안 부 버전을 지원합니다. 자세한 내용은 확장 채널로 장기 지원 받기를 참조하세요.

채널의 이점을 최대한 활용하려면 다음 권장사항을 준수하는 것이 좋습니다. 이러한 권장사항 중 일부를 따르려면 클러스터 수동 업그레이드 및 클러스터 출시 채널 변경을 포함한 직접 조치가 필요합니다. 다음과 같은 지원되는 시나리오와 확장 채널을 사용하지 않는 경우를 검토하세요.

부 버전으로 장시간 일시적으로 유지

예를 들어 다음 부 버전에서 삭제되는 지원 중단된 API 사용을 완화하기 위해 14개월의 스탠더드 지원 기간보다 오래 동안 클러스터를 부 버전으로 임시로 유지해야 하는 경우 다음 프로세스를 수행합니다. 다음 부 버전으로 업그레이드를 준비하는 동안 임시로 클러스터를 다른 출시 채널에서 확장 채널로 이동하여 보안 패치를 계속 받을 수 있습니다. 다음 부 버전으로 업그레이드할 준비가 되면 클러스터를 수동으로 업그레이드한 후 클러스터를 다시 원래 출시 채널로 이동합니다.

부 버전 업그레이드 연간 1~2회

클러스터를 새 부 버전으로 업그레이드할 준비가 되었을 때 일부 새 기능을 계속 수신하는 동안에 클러스터 중단을 최소화하려면 다음을 수행합니다.

  • 클러스터를 확장 채널에 등록합니다.
  • 1년에 1~2회 연속 부 버전 업그레이드를 2번 수행합니다. 예를 들어 1.30에서 1.31, 1.32로 순차적으로 업그레이드합니다.

이 프로세스를 통해 클러스터가 사용 가능한 부 버전으로 유지되고 새로운 부 버전의 기능이 수신되지만 클러스터가 준비되었다고 판단되면 부 버전 업그레이드만 수신됩니다.

확장 채널을 사용하지 않으려는 경우

확장 채널을 의도된 목적으로 사용하려면 직접 조치가 필요합니다. 다음 시나리오에서는 클러스터의 부 버전을 적극적으로 관리하지 않고 확장 채널을 사용할 경우의 결과를 보여줍니다.

아무 작업도 수행하지 않고 동일한 주기로 부 버전 업그레이드 수신

클러스터를 부 버전으로 영구 유지하려면 클러스터를 확장 채널에 등록하고 추가 조치를 취하지 않습니다. 결국 모든 부 버전은 지원되지 않고 GKE가 지원되지 않는 부 버전에서 클러스터를 자동으로 업그레이드합니다. 따라서 GKE는 평균적으로 약 4개월마다 이 클러스터를 지원되지 않는 부 버전 하나에서 곧 지원되지 않는 부 버전으로 업그레이드합니다. 즉, 클러스터가 다른 출시 채널처럼 부 버전 업그레이드를 자주 받지만 나중에 새 기능을 수신합니다.

체크리스트 요약

다음 표에는 GKE 클러스터를 원활하게 최신 상태로 유지하기 위한 업그레이드 전략에 권장되는 작업이 요약되어 있습니다.

권장사항 작업
여러 환경 설정
출시 채널에 클러스터 등록
지속적 업그레이드 전략 만들기
기존 워크로드의 중단 감소

다음 단계