이 문서에서는 Google Distributed Cloud 업그레이드를 위한 권장사항과 고려사항을 설명합니다. 클러스터 업그레이드를 준비하는 방법과 업그레이드 전에 수행해야 하는 권장사항에 대해 알아봅니다. 이러한 권장사항은 클러스터 업그레이드와 연관된 위험을 줄이는 데 도움이 됩니다.
테스트, 개발, 프로덕션과 같은 여러 환경이 있는 경우 테스트와 같이 가장 중요하지 않은 환경에서 시작하여 업그레이드 기능을 확인하는 것이 좋습니다. 업그레이드가 성공했는지 확인한 후 다음 환경으로 이동합니다. 프로덕션 환경을 업그레이드할 때까지 이 프로세스를 반복합니다. 이 방법을 사용하면 중요한 시점에서 다음 지점으로 이동하여 업그레이드 및 워크로드가 모두 올바르게 실행되는지 확인할 수 있습니다.
업그레이드 체크리스트
이 문서의 모든 권장사항을 따르는 것이 좋습니다. 다음 체크리스트를 사용하여 진행 상황을 추적하세요. 목록의 각 항목은 이 문서의 추가 정보가 포함된 섹션으로 연결됩니다.
이 확인을 완료하면 업그레이드 프로세스를 시작할 수 있습니다. 모든 클러스터가 성공적으로 업그레이드될 때까지 진행 상황을 모니터링합니다.
업그레이드 계획
업그레이드가 중단될 수 있습니다. 업그레이드를 시작하기 전에 환경과 애플리케이션이 준비 및 준비되었는지 신중하게 계획합니다.
소요 시간 예측 및 유지보수 기간 계획
클러스터를 업그레이드하는 데 걸리는 시간은 노드 수와 여기에서 실행되는 워크로드 밀도에 따라 다릅니다. 클러스터 업그레이드를 성공적으로 완료하려면 충분한 시간이 포함된 유지보수 기간을 사용하세요.
업그레이드의 대략적인 예상 시간을 계산하려면 단일 동시 노드 업그레이드에 10 minutes * the number of
nodes를 사용합니다.
예를 들어 클러스터 하나에 노드가 50개 있는 경우 총 업그레이드 시간은 약 500분입니다(10 minutes * 50 nodes = 500 minutes).
다른 GKE Enterprise 구성요소의 호환성 확인
클러스터가 Cloud Service Mesh, 구성 동기화, 정책 컨트롤러, 구성 컨트롤러와 같은 GKE Enterprise 구성요소를 실행하는 경우 GKE Enterprise 버전 및 업그레이드 지원을 확인하고 업그레이드 전후에 Google Distributed Cloud에서 지원되는 버전을 확인하세요.
호환성 검사는 Cloud Service Mesh, 구성 동기화, 정책 컨트롤러 또는 구성 컨트롤러가 배포된 관리자 또는 사용자 클러스터를 기반으로 합니다.
클러스터 리소스 사용률 확인
노드가 드레이닝될 때 포드를 제거할 수 있고 업그레이드 중인 클러스터에 업그레이드를 관리하기에 충분한 리소스가 있는지 확인하려면 클러스터의 현재 리소스 사용량을 확인합니다. 클러스터의 리소스 사용량을 확인하려면 Google Cloud Observability의 커스텀 대시보드를 사용합니다.
kubectl top nodes과 같은 명령어를 사용하여 현재 클러스터 리소스 사용량을 가져올 수 있지만 대시보드는 시간 경과에 따른 리소스 소비에 대한 자세한 뷰를 제공할 수 있습니다. 이 리소스 사용량 데이터는 실행 중인 워크로드 및 사용 사례에 따라 주말 또는 저녁과 같이 업그레이드로 인한 운영 중단이 가장 적은 시기를 나타내는 데 도움이 될 수 있습니다.
일반적으로 관리자 클러스터 업그레이드 시에는 애플리케이션 다운타임이 발생하지 않기 때문에 관리자 클러스터 업그레이드 시간은 사용자 클러스터보다 덜 중요할 수 있습니다. 하지만 관리자 클러스터 업그레이드를 시작하기 전에 사용 가능한 리소스를 확인하는 것이 여전히 중요합니다. 또한 관리자 클러스터를 업그레이드하면 위험이 발생할 수 있으므로 클러스터에 대한 관리 액세스가 덜 중요한 활성 사용량이 낮은 기간에 권장될 수 있습니다.
관리자 클러스터 컨트롤 플레인 리소스
모든 업그레이드 컨트롤러 및 작업은 관리자 클러스터 컨트롤 플레인 노드에서 실행됩니다. 이러한 컨트롤 플레인 노드의 리소스 소비에서 사용 가능한 컴퓨팅 리소스를 확인합니다. 업그레이드 프로세스에는 일반적으로 각 수명 주기 컨트롤러 집합에 1,000밀리코어의 CPU(1,000mCPU)와 2~3GiB RAM이 필요합니다. CPU 단위 'mCPU'는 '코어의 1/1,000'을 의미하므로 1,000밀리코어는 각 수명 주기 컨트롤러 집합에 대한 각 노드의 코어 하나에 해당합니다. 업그레이드 중에 필요한 추가 컴퓨팅 리소스를 줄이려면 사용자 클러스터를 동일한 버전으로 유지해 보세요.
다음 배포 예시에서는 두 사용자 클러스터가 관리자 클러스터와 버전이 다릅니다.
| 관리자 클러스터 | 사용자 클러스터 1 | 사용자 클러스터 2 |
|---|---|---|
| 1.13.3 | 1.13.0 | 1.13.2 |
수명 주기 컨트롤러 집합은 사용 중인 각 버전의 관리자 컨트롤러에 배포됩니다. 이 예시에는 1.13.3, 1.13.0, 1.13.2라는 세 가지 수명 주기 컨트롤러 집합이 있습니다. 각 수명 주기 컨트롤러 집합은 총 1,000mCPU와 3GiB RAM을 사용합니다. 이 수명 주기 컨트롤러의 현재 총 리소스 소비량은 3,000mCPU와 9GiB RAM입니다.
사용자 클러스터 2가 1.13.3으로 업그레이드된 경우 이제 1.13.3 및 1.13.0의 두 가지 수명 주기 컨트롤러 집합이 있습니다.
| 관리자 클러스터 | 사용자 클러스터 1 | 사용자 클러스터 2 |
|---|---|---|
| 1.13.3 | 1.13.0 | 1.13.3 |
이제 수명 주기 컨트롤러는 총 2,000mCPU와 6GiB의 RAM을 사용합니다.
사용자 클러스터 1이 1.13.3으로 업그레이드되면 이제 Fleet이 모두 동일한 버전(1.13.3)에서 실행됩니다.
| 관리자 클러스터 | 사용자 클러스터 1 | 사용자 클러스터 2 |
|---|---|---|
| 1.13.3 | 1.13.3 | 1.13.3 |
이제 수명 주기 컨트롤러 세트가 하나만 있으며 총 1,000mCPU와 3GiB RAM을 사용합니다.
다음 예시에서는 모든 사용자 클러스터가 동일한 버전입니다. 관리자 클러스터가 업그레이드되면 두 개의 수명 주기 컨트롤러 집합만 사용되므로 컴퓨팅 리소스 소비가 줄어듭니다.
| 관리자 클러스터 | 사용자 클러스터 1 | 사용자 클러스터 2 |
|---|---|---|
| 1.14.0 | 1.13.3 | 1.13.3 |
이 예시에서 수명 주기 컨트롤러는 모든 사용자 클러스터가 관리자 클러스터와 동일한 버전으로 업그레이드될 때까지 총 2,000mCPU와 6GiB RAM을 사용합니다.
업그레이드 중에 컨트롤 플레인 노드에 추가 컴퓨팅 리소스가 없으면 Pending 상태의 anthos-cluster-operator ,capi-controller-manager ,cap-controller-manager, cap-kubeadm-bootstraper 포드가 표시될 수 있습니다. 이 문제를 해결하려면 일부 사용자 클러스터를 동일한 버전으로 업그레이드하여 버전을 통합하고 사용 중인 수명 주기 컨트롤러의 수를 줄이세요. 업그레이드가 이미 중단된 경우 kubectl edit deployment를 사용하여 대기 중인 배포를 수정하여 관리자 클러스터 컨트롤 플레인에 맞도록 CPU 및 RAM 요청을 낮출 수 있습니다.
다음 표에는 다양한 업그레이드 시나리오의 컴퓨팅 리소스 요구사항이 자세히 나와 있습니다.
| 클러스터 | 필요한 관리자 클러스터 리소스 |
|---|---|
| 사용자 클러스터 업그레이드 | 동일한 버전의 다른 클러스터로 업그레이드: 해당 사항 없음 다른 관리자 또는 사용자 클러스터의 다른 버전으로 업그레이드: 1,000mCPU 및 3GiB RAM 하이브리드 클러스터의 사용자 클러스터는 리소스 요구사항이 동일합니다. |
| 관리자 클러스터 업그레이드(사용자 클러스터 포함) | 1,000mCPU 및 3GiB RAM |
| 하이브리드 클러스터 업그레이드(사용자 클러스터 제외) | 1,000mCPU 및 3GiB RAM 일시 급증. 사용 후 리소스가 반환됩니다. |
| 독립형 | 200mCPU 및 1GiB RAM 일시 급증. 사용 후 리소스가 반환됩니다. |
클러스터 백업
업그레이드를 시작하기 전에 bmctl backup cluster 명령어를 사용하여 클러스터를 백업하세요.
백업 파일에는 민감한 정보가 포함되어 있으므로 백업 파일을 안전하게 보관하세요.
클러스터가 구성되어 올바르게 작동하는지 확인
업그레이드 전에 클러스터 상태를 확인하려면 클러스터에서 bmctl check cluster를 실행합니다. 이 명령어는 올바르게 구성되지 않았거나 중단된 상태의 포드가 있는 노드 식별과 같은 고급 검사를 실행합니다.
클러스터를 업그레이드하는 bmctl upgrade cluster 명령어를 실행하면 일부 프리플라이트 검사가 실행됩니다. 확인이 실패하면 업그레이드 프로세스가 중지됩니다. 발생 가능한 손상으로부터 클러스터를 보호하기 위해 프리플라이트 검사에 의존하기보다는 bmctl check cluster 명령어를 사용하여 이러한 문제를 사전에 식별하고 수정하는 것이 가장 좋습니다.
사용자 워크로드 배포 검토
사용자 워크로드의 경우 드레이닝과 API 호환성이라는 두 가지 영역을 고려해야 합니다.
워크로드 드레이닝
노드의 사용자 워크로드는 업그레이드 중에 드레이닝됩니다. 워크로드에 단일 복제본이 있거나 모든 복제본이 동일한 노드에 있는 경우 워크로드 드레이닝으로 인해 클러스터에서 실행 중인 서비스가 중단될 수 있습니다. 여러 복제본으로 워크로드를 실행합니다. 복제본 수가 동시 노드 수보다 커야 합니다.
업그레이드 중단이 방지되도록 최대 1.29로 업그레이드하는 드레이닝 프로세스는 포드 중단 예산(PDB)을 따르지 않습니다. 워크로드가 성능 저하 상태로 실행될 수 있으며 최소 제공 복제본은 total
replica number - concurrent upgrade number입니다.
API 호환성
API 호환성을 위해 부 버전 업그레이드를 수행할 때 최신 Kubernetes 부 버전과의 워크로드 API 호환성을 확인합니다. 필요한 경우 워크로드를 호환되는 버전으로 업그레이드합니다. 가능한 경우 GKE Enterprise 엔지니어링팀이 삭제된 Kubernetes API와 같은 호환되지 않는 API를 사용하여 워크로드를 식별하는 방법을 안내합니다.
Cloud Service Mesh, 구성 동기화, 정책 컨트롤러, 구성 컨트롤러, 기타 GKE Enterprise 구성요소를 사용하는 경우 설치된 버전이 새 버전의 Google Distributed Cloud와 호환되는지 확인하세요. GKE Enterprise 구성요소 버전 호환성 정보는 GKE Enterprise 버전 및 업그레이드 지원을 참조하세요.
웹훅 사용 감사
클러스터에 웹훅이 있는지, 특히 정책 컨트롤러와 같은 감사용 포드 리소스가 있는지 확인합니다. 클러스터 업그레이드 중 드레이닝 프로세스로 인해 정책 컨트롤러 웹훅 서비스가 중단될 수 있으며 이로 인해 업그레이드가 중단되거나 시간이 오래 걸릴 수 있습니다. 이러한 웹훅을 일시적으로 중지하거나 가용성이 높은(HA) 배포를 사용하는 것이 좋습니다.
미리보기 기능 사용 검토
미리보기 기능은 변경될 수 있으며 테스트 및 평가 목적으로만 제공됩니다. 프로덕션 클러스터에서 미리보기 기능을 사용하지 마세요. 미리보기 기능을 사용하는 클러스터가 업그레이드되지 않을 수도 있습니다. 경우에 따라 미리보기 기능을 사용하는 클러스터의 업그레이드가 명시적으로 차단됩니다.
업그레이드와 관련된 브레이킹 체인지에 대한 자세한 내용은 출시 노트를 참조하세요.
SELinux 상태 확인
컨테이너 보안을 위해 SELinux를 사용 설정하려면 모든 호스트 머신에서 SELinux가 Enforced 모드로 사용 설정되었는지 확인해야 합니다. Google Distributed Cloud 출시 버전 1.9.0 이상부터는 클러스터 만들기 또는 클러스터 업그레이드 전후에 SELinux를 사용 설정 또는 사용 중지할 수 있습니다. SELinux는 기본적으로 Red Hat Enterprise Linux(RHEL)에서 사용 설정됩니다. SELinux가 호스트 머신에 사용 중지되었거나 확실하지 않으면 SELinux를 사용하여 컨테이너 보안에서 이를 사용 중지하는 방법에 대한 안내를 참조하세요.
Google Distributed Cloud는 RHEL 시스템에서만 SELinux를 지원합니다.
포드 밀도 구성 변경 금지
Google Distributed Cloud는 nodeConfig.PodDensity.MaxPodsPerNode로 노드당 최대 250개의 포드 구성을 지원합니다. 포드 생성은 클러스터 생성 중에만 구성할 수 있습니다. 기존 클러스터의 포드 밀도 설정은 업데이트할 수 없습니다. 업그레이드 중에 포드 밀도 구성을 변경하려고 하지 마세요.
컨트롤 플레인과 부하 분산기 노드가 유지보수 모드가 아닌지 확인
업그레이드를 시작하기 전에 컨트롤 플레인과 부하 분산기 노드가 유지보수되고 있지 않은지 확인합니다. 노드가 유지보수 모드에 있는 경우, 컨트롤 플레인과 부하 분산기 노드 풀을 충분히 확보하기 위해 업그레이드가 일시 중지됩니다.