1장. 설치 및 업그레이드
Kubernetes용 Red Hat Advanced Cluster Management를 설치하면 다중 노드 클러스터 프로덕션 환경이 설정됩니다. Red Hat Advanced Cluster Management for Kubernetes를 표준 또는 고가용성 구성으로 설치할 수 있습니다.
설치하기 전에 각 제품에 필요한 하드웨어 및 시스템 구성을 검토하십시오. 지원되는 Red Hat OpenShift Container Platform 버전을 사용하여 Linux에 온라인을 설치할 수 있습니다.
지원되는 OpenShift Container Platform 버전이 있어야 합니다. 예를 들어 AWS에서 Red Hat OpenShift Service 또는 Red Hat OpenShift Dedicated를 사용할 수 있습니다. Kubernetes Operator용 다중 클러스터 엔진을 설치해야 합니다.
더 이상 사용되지 않음: Red Hat Advanced Cluster Management 2.7 및 이전 버전은 더 이상 지원되지 않습니다. 문서는 사용할 수 있지만 에라타 또는 기타 업데이트는 사용할 수 없습니다.
모범 사례: 최신 버전으로 업그레이드합니다.
FIPS 알림: spec.ingress.sslCiphers 에 자체 암호를 지정하지 않으면 multiclusterhub-operator 에서 기본 암호 목록을 제공합니다. FIPS 컴플라이언스를 업그레이드하고 사용하려면 멀티clusterhub 리소스에서 다음 두 가지 암호를 제거하십시오. ECDHE-ECDSA-CHACHA20-POLY1305 및 ECDHE-RSA-CHACHA20-POLY1305.
이 문서는 특정 구성 요소 또는 기능이 도입되어 최신 버전의 OpenShift Container Platform에서만 테스트되지 않는 한 가장 빨리 지원되는 OpenShift Container Platform 버전을 참조합니다.
전체 지원 정보는 Red Hat Advanced Cluster Management for Kubernetes의 지원 매트릭스 및 라이프 사이클 및 업데이트 정책을 참조하십시오.
설치 절차에 대한 자세한 내용은 다음 문서를 참조하십시오.
1.1. 성능 및 확장
Red Hat Advanced Cluster Management for Kubernetes는 특정 확장성 및 성능 데이터를 확인하기 위해 테스트되었습니다. 테스트된 주요 영역은 클러스터 확장성 및 검색 성능입니다. 환경을 계획할 때 이 정보를 사용할 수 있습니다.
참고: 데이터는 테스트 시 랩 환경의 결과를 기반으로 합니다.
Red Hat Advanced Cluster Management는 베어 메탈 머신에서 3개의 노드 허브 클러스터를 사용하여 테스트합니다. 테스트 시 소프트웨어 구성 요소 제한을 찾을 수 있는 충분한 리소스 용량(CPU, 메모리 및 디스크)이 있습니다. 환경, 네트워크 속도 및 제품 변경 사항에 따라 결과가 다를 수 있습니다.
1.1.1. 최대 관리 클러스터 수
Red Hat Advanced Cluster Management에서 관리할 수 있는 최대 클러스터 수는 다음과 같은 여러 요인에 따라 다릅니다.
- 배포된 정책 및 애플리케이션 수와 같은 요인에 따라 달라지는 클러스터의 리소스 수입니다.
- 확장에 사용되는 Pod 수와 같은 허브 클러스터 구성.
관리형 클러스터는 Red Hat Enterprise Linux 하이퍼바이저에서 호스팅되는 단일 노드 OpenShift 가상 머신입니다. 가상 머신은 테스트된 상태에서 단일 베어 메탈 머신당 클러스터의 고밀도 수를 달성하는 데 사용됩니다. sushy-emulator는 Redfish API를 사용하여 가상 머신에 액세스할 수 있는 베어 메탈 클러스터를 보유하는 데 libvirt와 함께 사용됩니다. 다음 운영자는 테스트 설치, 토폴로지 Aware Lifecycle Manager, Local Storage Operator 및 Red Hat OpenShift GitOps의 일부입니다. 다음 표에서는 랩 환경 확장 정보를 보여줍니다.
| 노드 | 수량 | 운영 체제 | 하드웨어 | CPU 코어 수 | 메모리 | 디스크 |
|---|---|---|---|---|---|---|
| hub 클러스터 컨트롤 플레인 | 3 | OpenShift Container Platform | 베어 메탈 | 112 | 512GiB | 446GB SSD, 2.9 TB NVMe, 2 x 1.8TB SSD |
| 관리형 클러스터 | 3500 | 단일 노드 OpenShift | 가상 머신 | 8 | 18GiB | 120GB |
1.1.2. 검색 확장성
검색 구성 요소의 확장성은 데이터 저장소의 성능에 따라 다릅니다. 쿼리 런타임은 검색 성능을 분석할 때 중요한 변수입니다.
1.1.2.1. 쿼리 런타임 고려 사항
쿼리에서 결과를 실행하고 반환하는 데 걸리는 시간에 영향을 줄 수 있는 몇 가지 사항이 있습니다. 환경을 계획하고 구성할 때 다음 항목을 고려하십시오.
키워드 검색은 효율적이지 않습니다.
RedHat을 검색하고 많은 수의 클러스터를 관리하는 경우 검색 결과를 수신하는 데 시간이 더 걸릴 수 있습니다.- 첫 번째 검색은 사용자 역할 기반 액세스 제어 규칙을 수집하는 데 추가 시간이 걸리기 때문에 이후 검색보다 오래 걸립니다.
요청을 완료하는 데 걸리는 시간은 사용자가 액세스할 수 있는 네임스페이스 및 리소스 수에 비례합니다.
참고: 다른 사용자와 검색 쿼리를 저장하고 공유하는 경우 반환된 결과는 해당 사용자의 액세스 수준에 따라 달라집니다. 역할 액세스에 대한 자세한 내용은 RBAC를 사용하여 OpenShift Container Platform 설명서에서 권한 정의 및 적용을 참조하십시오.
- 가장 심각한 성능은 관리자가 아닌 사용자가 모든 네임스페이스 또는 모든 관리형 클러스터에 액세스할 수 있는 요청에 대해 관찰됩니다.
1.1.3. 관찰 기능 확장성
관찰 기능 서비스를 활성화하고 사용하려면 환경을 계획해야 합니다. 나중에 리소스 사용은 관찰 구성 요소가 설치된 OpenShift Container Platform 프로젝트에 사용됩니다. 사용하려는 값은 모든 관찰 기능 구성 요소의 합계입니다.
참고: 데이터는 테스트 시 랩 환경의 결과를 기반으로 합니다. 환경, 네트워크 속도 및 제품 변경 사항에 따라 결과가 다를 수 있습니다.
1.1.3.1. 샘플 관찰 기능 환경
샘플 환경에서 허브 클러스터 및 관리 클러스터는 Amazon Web Services 클라우드 플랫폼에 있으며 다음과 같은 토폴로지 및 구성이 있습니다.
| 노드 | 플레이버 | vCPU | RAM(GiB) | 디스크 유형 | 디스크 크기(GiB) | 수량 | 리전 |
|---|---|---|---|---|---|---|---|
| 마스터 노드 | m5.4xlarge | 16 | 64 | gp2 | 100 | 3 | sa-east-1 |
| 작업자 노드 | m5.4xlarge | 16 | 64 | gp2 | 100 | 3 | sa-east-1 |
관찰 기능 배포는 고가용성 환경에 맞게 구성됩니다. 고가용성 환경에서 각 Kubernetes 배포에는 두 개의 인스턴스가 있으며 각 StatefulSet에는 세 개의 인스턴스가 있습니다.
샘플 테스트 중에 다양한 관리 클러스터 수가 메트릭을 푸시하도록 시뮬레이션되며 각 테스트는 24시간 동안 지속됩니다. 다음 처리량을 참조하십시오.
1.1.3.2. 쓰기 처리량
| Pods | 간격(분) | 분당 시계열 |
|---|---|---|
| 400 | 1 | 83000 |
1.1.3.3. CPU 사용량 (millicores)
테스트 중에 CPU 사용량이 안정적입니다.
| 크기 | CPU 사용량 |
|---|---|
| 10개의 클러스터 | 400 |
| 20개의 클러스터 | 800 |
1.1.3.4. RSS 및 작업 세트 메모리
RSS 및 작업 세트 메모리에 대한 다음 설명을 확인합니다.
-
메모리 사용량 RSS: 지표
container_memory_rss에서 테스트 중에 안정적으로 유지됩니다. -
메모리 사용량 작업 세트:
container_memory_working_set_bytes메트릭에서 테스트와 함께 증가합니다.
다음 결과는 24 시간 테스트에서 수행됩니다.
| 크기 | 메모리 사용량 RSS | 메모리 사용량 작업 세트 |
|---|---|---|
| 10개의 클러스터 | 9.84 | 4.93 |
| 20개의 클러스터 | 13.10 | 8.76 |
1.1.3.5. thanos-receive 구성 요소의 영구 볼륨
중요: 지표는 보존 시간(24일)에 도달할 때까지 thanos-receive 에 저장됩니다. 다른 구성 요소에는 thanos-receive 구성 요소 만큼의 볼륨이 필요하지 않습니다.
테스트와 함께 디스크 사용량이 증가합니다. 데이터는 1일 후 디스크 사용량을 나타내므로 최종 디스크 사용량에 4를 곱합니다.
다음 디스크 사용량을 참조하십시오.
| 크기 | 디스크 사용량(GiB) |
|---|---|
| 10개의 클러스터 | 2 |
| 20개의 클러스터 | 3 |
1.1.3.6. 네트워크 전송
테스트 중에 네트워크 전송은 안정성을 제공합니다. 크기 및 네트워크 전송 값을 참조하십시오.
| 크기 | 인바운드 네트워크 전송 | 아웃 바운드 네트워크 전송 |
|---|---|---|
| 10개의 클러스터 | 초당 6.55MBS | 초당 5.80MBS |
| 20개의 클러스터 | 13.08 MBS/초 | 초당 10.9MBS |
1.1.3.7. Amazon S3(Simple Storage Service)
Amazon Simple Storage Service(S3)의 총 사용량이 증가합니다. 메트릭 데이터는 기본 보존 시간(five days)에 도달할 때까지 S3에 저장됩니다. 다음 디스크 사용량을 참조하십시오.
| 크기 | 디스크 사용량(GiB) |
|---|---|
| 10개의 클러스터 | 16.2 |
| 20개의 클러스터 | 23.8 |
1.1.4. 백업 및 복원 확장성
대규모 확장 환경에서 수행되는 테스트에는 백업 및 복원을 위한 다음 데이터가 표시됩니다.
| 백업 | duration | 리소스 수 | 백업 메모리 |
|---|---|---|---|
| credentials | 2m5s | 18272 리소스 | 55MiB 백업 크기 |
| 관리형 클러스터 | 3m22s | 58655 리소스 | 38MiB 백업 크기 |
| resources | 1m34s | 1190 리소스 | 1.7MiB 백업 크기 |
| 일반/사용자 | 2m56s | 0 리소스 | 16.5KiB 백업 크기 |
총 백업 시간은 10m 입니다.
| 백업 | duration | 리소스 수 |
|---|---|---|
| redentials | 47m8s | 18272 리소스 |
| resources | 3m10s | 1190 리소스 |
| 일반/사용자 백업 | 0m | 0 리소스 |
총 복원 시간은 50m18s 입니다.
백업 파일 수는 BackupSchedule 이 생성될 때 veleroTtl 매개변수 옵션을 사용하여 정리됩니다. 지정된 TTL(Time to Live)보다 오래된 생성 시간이 있는 백업이 만료되고 Velero에 의해 스토리지 위치에서 자동으로 삭제됩니다.
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: BackupSchedule metadata: name:schedule-acm namespace:open-cluster-management-backup spec: veleroSchedule:0 */1 * * * veleroTtl:120h
1.1.5. 클러스터 크기 조정
각 Red Hat Advanced Cluster Management for Kubernetes 클러스터는 고유하며 다음 지침에 따라 샘플 배포 크기를 제공합니다. 권장 사항은 크기와 목적에 따라 분류됩니다.
Red Hat Advanced Cluster Management는 지원 서비스의 규모 조정 및 배치를 위해 다음과 같은 차원을 적용합니다.
- 가용성 영역은 클러스터 전체에서 잠재적인 오류 도메인을 분리합니다. 일반적인 클러스터는 3개 이상의 가용성 영역에서 작업자 노드 용량이 거의 동일합니다.
- vCPU 예약 및 제한은 컨테이너에 할당할 작업자 노드에 vCPU 용량을 설정합니다. vCPU는 Kubernetes 컴퓨팅 단위와 동일합니다. 자세한 내용은 Kubernetes Meaning of CPU 를 참조하십시오.
- 메모리 예약 및 제한은 컨테이너에 할당할 작업자 노드에 메모리 용량을 설정합니다.
- 영구 데이터는 제품에 의해 관리되며 Kubernetes에서 사용하는 etcd 클러스터에 저장됩니다.
중요: OpenShift Container Platform의 경우 클러스터의 마스터 노드를 세 개의 가용성 영역에 배포합니다.
1.1.5.1. 제품 환경
참고: 다음 요구 사항은 최소 요구사항이 아닙니다.
| 노드 유형 | 가용성 영역 | etcd | 총 예약된 메모리 | 총 예약된 CPU |
|---|---|---|---|---|
| Master | 3 | 3 | OpenShift Container Platform 크기 조정 지침 | OpenShift Container Platform 크기 조정 지침 |
| 작업자 또는 인프라 | 3 | 1 | 12GB | 6 |
Red Hat Advanced Cluster Management 외에도 OpenShift Container Platform 클러스터는 추가 서비스를 실행하여 클러스터 기능을 지원합니다. 자세한 내용은 인프라 노드에 Red Hat Advanced Cluster Management Hub 클러스터 설치를 참조하십시오.
1.1.5.1.1. 추가 서비스의 OpenShift Container Platform
가용성 영역은 클러스터 전체에서 잠재적인 오류 도메인을 분리합니다.
| Service | 노드 수 | 가용성 영역 | 인스턴스 크기 | vCPU | 메모리 | 스토리지 크기 | Resources |
|---|---|---|---|---|---|---|---|
| Amazon Web Services의 OpenShift Container Platform | 3 | 3 | m5.xlarge | 4 | 16GB | 120GB | 자세한 내용은 OpenShift Container Platform 제품 설명서에서 사용자 지정으로 AWS에 클러스터 설치를 참조하십시오. 또한 머신 유형에 대해 자세히 알아보십시오. |
| Google Cloud Platform의 OpenShift Container Platform | 3 | 3 | N1-standard-4 (0.95-6.5GB) | 4 | 15GB | 120GB | 할당량에 대한 자세한 내용은 Google Cloud Platform 제품 설명서를 참조하십시오. 또한 머신 유형에 대해 자세히 알아보십시오. |
| Microsoft Azure의 OpenShift Container Platform | 3 | 3 | Standard_D4_v3 | 4 | 16GB | 120GB | 자세한 내용은 OpenShift Container Platform 설명서에서 Azure 계정 구성 을 참조하십시오. |
| VMware vSphere의 OpenShift Container Platform | 3 | 3 | 4 (소켓당 2개 코어) | 16GB | 120GB | 자세한 내용은 OpenShift Container Platform 설명서에서 vSphere에 다음 설치를 참조하십시오. | |
| IBM Z 시스템의 OpenShift Container Platform | 3 | 3 | 10 | 16GB | 100GB | 자세한 내용은 OpenShift Container Platform 설명서에서 IBM Z 시스템에 클러스터 설치를 참조하십시오. IBM Z 시스템은 각 코어에서 실행할 수 있는 vCPU 수를 확장하는 SMT(동시 멀티스레딩)를 구성할 수 있는 기능을 제공합니다. SMT를 구성한 경우 하나의 물리적 코어(IFL)는 두 개의 논리 코어(스레드)를 제공합니다. 하이퍼바이저는 두 개 이상의 vCPU를 제공할 수 있습니다. SMT(동시 멀티스레딩) 또는 하이퍼 스레딩이 활성화되지 않은 경우 하나의 vCPU는 하나의 물리적 코어와 동일합니다. 활성화하면 다음과 같은 공식을 사용하여 해당 비율을 계산합니다. (코어 당 스레드 수 × 코어 수) × 소켓 수 = vCPU 수 SMT에 대한 자세한 내용은 Simultaneous multithreading 을 참조하십시오. | |
| IBM Power 시스템의 OpenShift Container Platform | 3 | 3 | 16 | 16GB | 120GB | 자세한 내용은 OpenShift Container Platform 설명서에서 Power 시스템에 클러스터 설치를 참조하십시오. IBM Power 시스템은 각 코어에서 실행할 수 있는 vCPU 수를 확장하는 SMT(동시 멀티스레딩)를 구성할 수 있는 기능을 제공합니다. SMT를 구성한 경우 SMT 수준이 16 vCPU 요구 사항을 충족하는 방법을 결정합니다. 가장 일반적인 구성은 다음과 같습니다. SMT-8(IBM Power VM을 실행하는 시스템의 기본 구성)에서 실행되는 두 코어는 필요한 16개의 vCPU를 제공합니다. SMT-4에서 실행되는 4개의 코어는 필요한 16개의 vCPU를 제공합니다. SMT에 대한 자세한 내용은 Simultaneous multithreading 을 참조하십시오. | |
| OpenShift Container Platform 온-프레미스 | 3 | 4 | 16GB | 120GB | 자세한 내용은 OpenShift Container Platform 설명서에서 3 노드 클러스터 구성 을 참조하십시오. OpenShift Container Platform 베어 메탈에서 Red Hat Advanced Cluster Management for Kubernetes Hub 클러스터를 설치하고 지원할 수 있습니다. 허브 클러스터는 소형 베어 메탈 토폴로지에서 실행할 수 있으며, 여기에는 스케줄링 가능한 컨트롤 플레인 노드가 3개, 추가 작업자가 0개 있습니다. |
1.1.5.1.2. 단일 노드 OpenShift Container Platform 클러스터 생성 및 관리
요구 사항을 알아보려면 단일 노드에 설치를 확인합니다. 각 클러스터는 고유하므로 다음 지침은 크기와 목적에 따라 분류되는 샘플 배포 요구 사항만 제공합니다.
가용성 영역은 클러스터 전체에서 잠재적인 오류 도메인을 분리합니다. 일반적인 클러스터에는 3개 이상의 가용성 영역에 동일한 작업자 노드 용량이 있습니다. 고가용성은 지원되지 않습니다.
중요: OpenShift Container Platform의 경우 클러스터의 마스터 노드를 세 개의 가용성 영역에 배포합니다.
3500개의 단일 노드 OpenShift Container Platform 클러스터를 생성하고 관리하는 데 필요한 요구 사항의 예를 참조하십시오. Red Hat Advanced Cluster Management를 사용하여 단일 노드 OpenShift 클러스터 (230 이상)를 생성하고 허브 클러스터를 사용하여 단일 노드 OpenShift 클러스터를 관리하는 데 필요한 최소 요구 사항을 참조하십시오.
| 노드 수 | 메모리(클러스터 사용량 사용) | 메모리(단일 노드 min-max) | CPU 클러스터 | CPU 단일 노드 |
|---|---|---|---|---|
| 3 | 289GB | 64GB - 110GB | 90 | 44 |
