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

이 문서에서는 Google Distributed Cloud를 업그레이드하기 위한 권장사항과 고려사항을 설명합니다. 클러스터 업그레이드를 준비하는 방법과 업그레이드 전에 수행해야 하는 권장사항에 대해 알아봅니다. 이러한 권장사항은 클러스터 업그레이드와 연관된 위험을 줄이는 데 도움이 됩니다.

테스트, 개발, 프로덕션과 같은 여러 환경이 있는 경우 테스트와 같이 가장 중요하지 않은 환경에서 시작하여 업그레이드 기능을 확인하는 것이 좋습니다. 업그레이드가 성공했는지 확인한 후 다음 환경으로 이동합니다. 프로덕션 환경을 업그레이드할 때까지 이 프로세스를 반복합니다. 이 방법을 사용하면 중요한 시점에서 다음 지점으로 이동하여 업그레이드 및 워크로드가 모두 올바르게 실행되는지 확인할 수 있습니다.

업그레이드 체크리스트

업그레이드 프로세스를 가능한 한 매끄럽게 진행하기 위해 클러스터 업그레이드를 시작하기 전에 다음 검사를 검토하고 완료합니다.

업그레이드 계획

업그레이드가 중단될 수 있습니다. 업그레이드를 시작하기 전에 환경과 애플리케이션이 준비 및 준비되었는지 신중하게 계획합니다.

소요 시간 예측 및 유지보수 기간 계획

기본적으로 모든 노드 풀은 동시에 업그레이드되지만 각 노드 풀 내에서 노드는 순차적으로 업그레이드됩니다. 따라서 업그레이드의 총 시간은 가장 큰 노드 풀에 있는 노드 수에 따라 다릅니다. 업그레이드의 대략적인 예상 시간을 계산하려면 가장 큰 노드 풀에 있는 노드 수에 15분을 곱한 값을 사용합니다. 예를 들어 가장 큰 풀에 노드가 10개 있는 경우 총 업그레이드 시간은 약 150분입니다.

버전 1.28 이상에서는 개별 노드 풀의 maxSurge 값을 설정하여 업그레이드 속도를 높일 수 있습니다.

사용자 및 관리자 클러스터 백업

업그레이드를 시작하기 전에 사용자 및 관리자 클러스터를 백업합니다.

사용자 클러스터 백업은 사용자 클러스터 etcd 저장소의 스냅샷입니다. etcd 저장소에는 클러스터 상태를 관리하는 데 필요한 모든 Kubernetes 객체와 커스텀 객체가 포함되어 있습니다. 스냅샷에는 클러스터의 구성요소와 워크로드를 다시 만드는 데 필요한 데이터가 포함되어 있습니다. 자세한 내용은 사용자 클러스터 백업을 참조하세요.

Google Distributed Cloud 버전 1.8 이상에서는 관리자 클러스터 구성 파일에서 clusterBackup.datastore를 사용하여 자동 백업을 설정할 수 있습니다. 기존 클러스터에서 이 기능을 사용 설정하려면 관리자 클러스터 구성 파일을 수정하고 clusterBackup.datastore 필드를 추가한 후 gkectl update admin을 실행합니다.

clusterBackup.datastore가 사용 설정되었으면 구성된 vSphere Datastore에서 관리자 클러스터가 자동으로 etcd에 백업됩니다. 이 백업 프로세스는 관리자 클러스터가 변경될 때마다 반복됩니다. 클러스터 업그레이드를 시작할 때 클러스터를 업그레이드하기 전 백업 태스크가 실행됩니다.

문제가 있는 경우 백업에서 관리자 클러스터를 복원하려면 gkectl로 관리자 클러스터 백업 및 복원을 참조하세요.

PodDisruptionBudgets 사용 검토

Kubernetes에서 PodDisruptionBudgets(PDB)는 원치 않는 애플리케이션 다운타임 또는 중단을 방지할 수 있습니다. PDB는 다른 포드가 실패하는 동안 항상 여러 포드를 계속 실행하도록 스케줄러에 지시합니다. 이 동작은 애플리케이션 가용성을 제공하는 유용한 방법입니다.

  1. 클러스터에 구성된 PDB를 확인하려면 kubectl get pdb 명령어를 사용합니다.

    kubectl get pdb -A --kubeconfig KUBECONFIG

    KUBECONFIG를 kubeconfig 파일의 이름으로 바꿉니다.

    다음 출력 예시는 istio-ingress, istiod, kube-dns라는 PDB를 보여줍니다.

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

앞의 표에서 각 PDB는 하나 이상의 포드를 항상 사용할 수 있도록 지정합니다. 이 가용성은 노드가 드레이닝되는 업그레이드 기간 동안 중요합니다.

처리할 수 없는 PDB를 확인합니다. 예를 들어 배포에 복제본이 1개만 있으면 최소 가용성을 1로 설정할 수 있습니다. 이 예시에서는 리소스 컨트롤러로 PDB를 충족할 수 없기 때문에 드레이닝 작업이 중단됩니다.

PDB가 업그레이드 절차와 충돌하지 않는지 확인하려면 업그레이드를 시작하기 전 지정된 클러스터에서 모든 PDB를 확인합니다. 클러스터 업그레이드 중 PDB를 일시적으로 변경하거나 사용 중지하려면 개발 팀 및 애플리케이션 소유자와 협력이 필요할 수 있습니다.

Google Distributed Cloud는 업그레이드 프로세스 중 프리플라이트 검사를 실행하여 PDB에 대해 경고합니다. 그러나 원활한 업그레이드 환경을 위해 PDB도 수동으로 확인해야 합니다. PDB에 대한 자세한 내용은 애플리케이션에 중단 예산 지정을 참조하세요.

사용 가능한 IP 주소 검토

다음 IP 주소 고려사항은 클러스터 업그레이드 중에 적용됩니다.

  • 클러스터 업그레이드 프로세스로 새 노드를 만들고 이전 노드를 삭제하기 전 리소스를 드레이닝합니다. 관리자 또는 사용자 클러스터의 IP 주소는 항상 N+1로 설정하는 것이 좋습니다. 여기서 N은 클러스터의 노드 수입니다.
  • 고정 IP 주소를 사용할 때 필요한 IP 주소는 IP 블록 파일에 나열되어 있어야 합니다.
  • DHCP를 사용하는 경우 업그레이드 중에 새 VM이 원하는 서브넷에서 추가 IP 임대를 받을 수 있는지 확인합니다.
    • IP 주소를 추가해야 할 경우 IP 블록 파일을 업데이트한 후 gkectl update 명령어를 실행합니다. 자세한 내용은 IP 주소 계획을 참조하세요.
  • 고정 IP 주소를 사용하여 사용자 클러스터 업그레이드 프로세스의 속도를 높이려면 각 노드 풀에 사용 가능한 추가 IP 주소가 있을 수 있도록 IP 블록 파일에 충분한 IP 주소를 나열합니다. 이 접근 방식을 사용하면 노드 풀 단위로 수행 시 VM 추가 및 삭제 절차를 더 빠르게 처리할 수 있습니다.
    • 이 접근 방식은 사용자 클러스터 업그레이드를 가속화하는 데 좋은 옵션이지만 계속하기 전 vSphere 환경의 리소스 및 성능 가용성을 고려하세요.
  • 전체 사용자 클러스터에 대해 하나의 예비 IP만 있는 경우 이 제한으로 인해 여러 노드 풀이 사용되더라도 한 번에 하나의 VM에 대해 업그레이드 프로세스 속도가 저하됩니다.

클러스터 사용률 확인

노드가 드레이닝될 때 포드를 제거할 수 있고 업그레이드 중인 클러스터에 업그레이드를 관리하기에 충분한 리소스가 있는지 확인합니다. 클러스터의 현재 리소스 사용량을 확인하려면 Google Cloud Observability에서 커스텀 대시보드를 사용하거나 kubectl top nodes와 같은 명령어를 사용하여 클러스터에서 직접 사용할 수 있습니다.

클러스터에 대해 실행하는 명령어는 현재 클러스터 리소스 사용량에 대한 스냅샷을 보여줍니다. 대시보드는 시간 경과에 따라 소비되는 리소스를 더 자세히 보여줄 수 있습니다. 이 리소스 사용량 데이터는 실행 중인 워크로드 및 사용 사례에 따라 주말 또는 저녁과 같이 업그레이드로 인한 운영 중단이 가장 적은 시기를 나타내는 데 도움이 될 수 있습니다.

일반적으로 관리자 클러스터 업그레이드 시에는 애플리케이션 다운타임이 발생하지 않기 때문에 관리자 클러스터 업그레이드 시간은 사용자 클러스터보다 덜 중요할 수 있습니다. 하지만 관리자 클러스터 업그레이드를 시작하기 전에 vSphere에서 무료 리소스를 확인하는 것이 여전히 중요합니다. 또한 관리자 클러스터를 업그레이드하면 위험이 발생할 수 있으므로 클러스터에 대한 관리 액세스가 덜 중요한 활성 사용량이 낮은 기간에 권장될 수 있습니다.

자세한 내용은 클러스터 업그레이드 중 영향을 받는 서비스를 참조하세요.

vSphere 사용률 확인

기본 vSphere 인프라에서 리소스가 충분한지 확인합니다. 이 리소스 사용량을 확인하려면 vCenter에서 클러스터를 선택하고 요약 탭을 검토합니다.

요약 탭에는 전체 클러스터의 전체 메모리, CPU, 스토리지 소비가 표시됩니다. Google Distributed Cloud 업그레이드에는 추가 리소스가 필요하므로 클러스터가 이러한 추가 리소스 요청을 처리할 수 있는지도 확인해야 합니다.

일반적으로 vSphere 클러스터는 다음 추가 리소스를 지원할 수 있어야 합니다.

  • 관리자 클러스터 업그레이드당 VM 1개 추가
  • 사용자 클러스터 업그레이드별 노드 풀당 VM 1개 추가

예를 들어 사용자 클러스터에 3개의 노드 풀이 있고 각 노드 풀에는 8개의 vCPU와 32GB 이상의 RAM을 사용하는 노드가 있다고 가정해 보겠습니다. 업그레이드는 기본적으로 3개의 노드 풀에 대해 동시에 수행되므로, 업그레이드 절차는 3개의 추가 일시 급증 노드에 대해 다음과 같은 추가 리소스를 사용합니다.

  • vCPU 24개
  • RAM 256GB
  • VM 디스크 공간 + vSwap 256GB

업그레이드 프로세스는 vSphere 클론 작업을 사용하여 VM을 만듭니다. 템플릿에서 여러 VM을 클론하면 I/O 작업이 증가하는 방식으로 기본 스토리지 시스템에 부하가 발생할 수 있습니다. 업그레이드 중에 기본 스토리지 하위 시스템이 충분한 성능을 제공할 수 없으면 업그레이드 속도가 크게 느려질 수 있습니다.

vSphere가 동시 리소스 사용을 위해 설계되고 리소스를 제공할 메커니즘이 있는 경우 오버커밋된 경우에도 VM 메모리를 오버커밋하지 않는 것이 좋습니다. 페이지를 Datastore로 교체하는 과정에서 vSphere가 '누락된 RAM'이 제공되므로 메모리 오버커밋은 전체 클러스터에 영향을 미치는 심각한 성능 영향을 초래할 수 있습니다. 이 동작으로 인해 클러스터 업그레이드 중에 문제가 발생할 수 있으며, vSphere 클러스터에서 실행 중인 다른 VM의 성능에 영향을 미칠 수 있습니다.

사용 가능한 리소스가 이미 부족한 경우 추가 요구사항을 충족하고 잠재적인 성능 저하를 방지하기 위해 불필요한 VM 전원을 꺼야 합니다.

클러스터 상태 및 구성 확인

업그레이드하기 전 모든 클러스터에서 다음 도구를 실행합니다.

  • gkectl diagnose 명령어: gkectl diagnose는 모든 클러스터가 정상 상태인지 확인합니다. 이 명령어는 올바르게 구성되지 않았거나 중단된 상태의 포드가 있는 노드 식별과 같은 고급 검사를 실행합니다. gkectl diagnose 명령어에 Cluster unhealthy 경고가 표시되면 업그레이드를 시도하기 전에 문제를 해결해야 합니다. 자세한 내용은 클러스터 문제 진단을 참조하세요.

  • 업그레이드 전 도구: 클러스터 상태와 구성을 추가로 확인합니다. 업그레이드 전 도구는 클러스터 업그레이드 중에 발생할 수 있는 잠재적인 문제를 확인합니다.

또한 사용자 클러스터를 1.29 이상으로 업그레이드할 때는 --dry-run 플래그와 함께 gkectl upgrade cluster 명령어를 실행하는 것이 좋습니다. --dry-run 플래그는 프리플라이트 검사를 실행하지만 업그레이드 프로세스를 시작하지 않습니다. 이전 버전의 Google Distributed Cloud는 프리플라이트 검사를 실행하지만 업그레이드와 별도로 실행할 수는 없습니다. --dry-run 플래그를 추가하면 업그레이드 전 사용자 클러스터에서 프리플라이트 검사가 발견한 모든 문제를 찾고 해결할 수 있습니다.

배포를 사용하여 애플리케이션 중단 최소화

업데이트 중에 노드를 드레이닝해야 하므로 클러스터를 업그레이드하면 애플리케이션이 중단될 수 있습니다. 노드를 드레이닝하면 실행 중인 모든 포드를 클러스터의 나머지 노드에서 종료하고 다시 시작해야 합니다.

가능한 경우 애플리케이션에서 배포를 사용해야 합니다. 이 방식을 사용하면 애플리케이션이 중단을 처리하도록 디자인됩니다. 모든 영향을 복제본이 여러 개 있는 배포로 최소화해야 합니다. 애플리케이션이 배포를 사용하지 않는 경우에도 클러스터를 업그레이드할 수 있습니다.

또한 설정된 수의 복제본이 항상 실행되도록 하는 배포 규칙도 있습니다. 이러한 규칙을 PodDisruptionBudgets(PDB)라고 부릅니다. PDB를 사용하면 클러스터 노드의 업그레이드 또는 유지보수와 같은 이유로 포드를 다시 예약해야 하는 경우 워크로드 중단을 제한할 수 있으며 업그레이드 전에 확인하는 것이 중요합니다.

고가용성 부하 분산 장치 쌍 사용

클러스터에서 Seesaw를 부하 분산 장치로 사용하는 경우 클러스터를 업그레이드할 때 부하 분산 장치가 자동으로 업그레이드됩니다. 이 업그레이드는 서비스 중단을 일으킬 수 있습니다. 업그레이드 및 최종 부하 분산기 장애의 영향을 줄이려면 고가용성 쌍(HA 쌍)을 사용하면 됩니다. 이 구성에서 시스템은 다른 동종 앱으로 장애 조치를 수행할 수 있도록 2개의 부하 분산 장치 VM을 만들고 구성합니다.

서비스 가용성(즉, Kubernetes API 서버)을 늘리려면 항상 관리자 클러스터 앞에 HA 쌍을 사용하는 것이 좋습니다. Seesaw 및 해당 HA 구성에 대한 자세한 내용은 Seesaw를 사용한 번들 부하 분산을 참조하세요.

HA 쌍으로 업그레이드 중 서비스 중단을 방지하기 위해 클러스터가 새 부하 분산 장치 VM을 만들기 전에 장애 조치를 시작합니다. 사용자 클러스터가 단일 부하 분산기 인스턴스만 사용하는 경우 부하 분산기의 업그레이드가 완료될 때까지 서비스가 중단됩니다.

사용자 클러스터 자체가 가용성이 높도록 구성된 경우 HA 부하 분산 장치 쌍을 사용하는 것이 좋습니다. 이 일련의 권장사항에서는 HA 사용자 클러스터에 HA 부하 분산 장치 쌍이 사용된다고 가정합니다.

MetalLB를 번들 부하 분산기로 사용하는 경우 사전 업그레이드 설정이 필요하지 않습니다. 부하 분산 장치는 클러스터 업그레이드 프로세스 중에 업그레이드됩니다.

각 사용자 클러스터를 업그레이드하는 방법 결정

버전 1.14 이상에서는 사용자 클러스터를 전체적으로 업그레이드하거나(즉, 제어 영역과 클러스터의 모든 노드 풀 업그레이드 가능) 사용자 클러스터의 제어 영역을 업그레이드하고 노드 풀을 현재 버전으로 둘 수 있습니다. 제어 영역을 개별적으로 업그레이드해야 하는 이유는 사용자 클러스터 업그레이드를 참조하세요.

멀티 클러스터 환경에서 업그레이드된 사용자 클러스터를 추적하고 버전 번호를 기록합니다. 제어 영역과 노드 풀을 개별적으로 업그레이드하려면 각 클러스터에서 제어 영역과 각 노드 풀의 버전을 기록합니다.

사용자 및 관리자 클러스터 버전 확인

gkectl

  • 사용자 클러스터 버전을 확인하려면 다음 명령어를 실행합니다.

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    ADMIN_CLUSTER_KUBECONFIG를 관리자 클러스터의 kubeconfig 파일 경로로 바꿉니다.

  • 관리자 클러스터 버전을 확인하려면 다음 명령어를 실행합니다.

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

gcloud CLI

GKE On-Prem API에 등록된 클러스터의 경우 gcloud CLI를 사용하여 사용자 클러스터, 사용자 클러스터의 노드 풀, 관리자 클러스터의 버전을 가져올 수 있습니다.

  1. 최신 버전의 gcloud CLI가 있는지 확인합니다. 필요한 경우 gcloud CLI 구성요소를 업데이트합니다.

    gcloud components update

  2. 다음 명령어를 실행하여 버전을 확인합니다.

  • 사용자 클러스터 버전을 확인하려면 다음 명령어를 실행합니다.

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    PROJECT_ID를 Fleet 호스트 프로젝트의 프로젝트 ID로 바꿉니다.

    --location=-을 설정하면 모든 리전의 모든 클러스터가 나열됩니다. 목록의 범위를 좁혀야 하는 경우 클러스터를 등록할 때 지정한 리전으로 --location을 설정합니다.

    이 명령어 출력에 클러스터 버전이 포함됩니다.

  • 관리자 클러스터 버전을 확인하려면 다음 명령어를 실행합니다.

    gcloud container vmware admin-clusters list \
    --project=PROJECT_ID \
    --location=-

클러스터 노드 버전 확인

kubectl을 사용하여 클러스터 노드 버전을 가져올 수 있지만 kubectl은 Kubernetes 버전을 반환합니다. Kubernetes 버전에 해당하는 Google Distributed Cloud 버전을 가져오려면 버전 기록을 참조하세요.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

USER_CLUSTER_KUBECONFIG를 사용자 클러스터의 kubeconfig 파일 경로로 바꿉니다.

CA 인증서를 순환해야 하는지 확인

업그레이드하는 동안에는 리프 인증서가 순환되지만 CA 인증서는 순환되지 않습니다. CA 인증서를 5년마다 최소 1회 이상 수동으로 순환해야 합니다. 자세한 내용은 사용자 클러스터 인증 기관 순환 및 관리자 클러스터 CA 인증서 순환을 참조하세요.

클러스터 유형 간 차이점

클러스터에는 두 가지 유형이 있습니다.

  • 사용자 클러스터
  • 관리자 클러스터

사용자 클러스터를 만드는 방법에 따라 워커 노드와 제어 영역 노드(제어 영역 V2) 모두 또는 워커 노드(kubeception)만 포함될 수 있습니다. kubeception을 사용하면 사용자 클러스터의 제어 영역이 관리자 클러스터에 있는 노드 하나 이상에서 실행됩니다. 두 경우 모두 버전 1.14 이상에서는 워크로드를 실행하는 노드 풀과 별도로 사용자 클러스터의 제어 영역을 업그레이드할 수 있습니다.

사용자 클러스터와 관리자 클러스터 업그레이드의 영향 차이

Google Distributed Cloud 업그레이드 절차에는 노드에서 모든 포드를 삭제하는 노드 드레이닝 프로세스가 포함됩니다. 이 프로세스는 드레이닝된 워커 노드마다 새 VM을 만들고 클러스터에 추가합니다. 그런 다음 드레이닝된 워커 노드는 VMware 인벤토리에서 삭제됩니다. 이 프로세스 중에 이러한 노드에서 실행되는 모든 워크로드가 중지되고 클러스터의 다른 사용 가능한 노드에서 다시 시작됩니다.

워크로드의 선택된 아키텍처에 따라 이 절차는 애플리케이션의 가용성에 영향을 미칠 수 있습니다. 클러스터의 리소스 기능에 대한 과도한 부담을 방지하기 위해 Google Distributed Cloud는 한 번에 하나씩 노드를 업그레이드합니다.

사용자 클러스터 중단

다음 표에서는 인플레이스(In-Place) 사용자 클러스터 업그레이드의 영향에 대해 설명합니다.

기능 관리자 클러스터 비HA 사용자 클러스터 HA 사용자 클러스터
Kubernetes API 액세스 영향을 받지 않음 영향을 받지 않음 영향을 받지 않음
사용자 워크로드 영향을 받지 않음 영향을 받지 않음 영향을 받지 않음
PodDisruptionBudgets* 영향을 받지 않음 영향을 받지 않음 영향을 받지 않음
제어 영역 노드 영향을 받지 않음 영향을 받음 영향을 받지 않음
포드 자동 확장 처리(VMware) 영향을 받지 않음 영향을 받지 않음 영향을 받지 않음
자동 복구 영향을 받지 않음 영향을 받지 않음 영향을 받지 않음
노드 자동 확장(VMware) 영향을 받지 않음 영향을 받지 않음 영향을 받지 않음
수평형 포드 자동 확장 영향을 받음 영향을 받음 영향을 받지 않음
  • * : PDB가 업그레이드 실패 또는 중지를 일으킬 수 있습니다.
  • 영향을 받음: 업그레이드가 완료될 때까지 업그레이드 중에 서비스가 중단될 수 있습니다.
  • 영향을 받지 않음: 매우 짧은 기간 동안 서비스 중단이 발생할 수 있지만 거의 알아챌 수 없습니다.

사용자 클러스터 제어 영역 노드는 관리자 클러스터(kubeception) 또는 사용자 클러스터 자체(Controlplane V2)에서 실행되는지 여부에 관계없이 사용자 워크로드를 실행하지 않습니다. 업그레이드 중에 이러한 제어 영역 노드가 드레이닝된 후 그에 따라 업데이트됩니다.

고가용성(HA) 제어 영역이 있는 환경에서 사용자 클러스터의 제어 영역을 업그레이드해도 사용자 워크로드는 중단되지 않습니다. HA 환경에서 관리자 클러스터를 업그레이드해도 사용자 워크로드는 중단되지 않습니다. Controlplane V2를 사용하는 사용자 클러스터의 경우 제어 영역만 업그레이드해도 사용자 워크로드는 중단되지 않습니다.

HA가 아닌 제어 영역 환경에서 업그레이드하는 동안에는 제어 영역에서 포드 확장, 복구 또는 배포 작업을 제어할 수 없습니다. 업그레이드 중에 제어 영역이 잠시 중단되면 확장, 배포 또는 복구 상태이면 사용자 워크로드가 영향을 받을 수 있습니다. 즉, HA가 아닌 환경에서 업그레이드하는 동안에 출시가 실패합니다.

업그레이드 중 가용성을 향상시키고 프로덕션 사용자 클러스터의 중단을 줄이려면 세 개의 제어 영역 노드(고가용성 모드)를 사용하는 것이 좋습니다.

관리자 클러스터 중단

다음 표에서는 인플레이스(In-Place) 관리자 클러스터 업그레이드의 영향에 대해 설명합니다.

기능 관리자 클러스터 비HA 사용자 클러스터 HA 사용자 클러스터
Kubernetes API 액세스 영향을 받음 영향을 받음 영향을 받지 않음
사용자 워크로드 영향을 받지 않음 영향을 받지 않음 영향을 받지 않음
제어 영역 노드 영향을 받음 영향을 받음 영향을 받지 않음
포드 자동 확장 처리 영향을 받음 영향을 받음 영향을 받지 않음
자동 복구 영향을 받음 영향을 받음 영향을 받지 않음
노드 자동 확장 영향을 받음 영향을 받음 영향을 받지 않음
수평형 포드 자동 확장 영향을 받음 영향을 받음 영향을 받지 않음
  • 영향을 받음: 업그레이드가 완료될 때까지 업그레이드 중에 서비스가 중단될 수 있습니다.
  • 영향을 받지 않음: 매우 짧은 기간 동안 서비스 중단이 발생할 수 있지만 거의 알아챌 수 없습니다.

다음 단계