HCP 클러스터를 사용하여 ROSA 설치
ROSA(AWS) 클러스터에 Red Hat OpenShift Service 설치, 액세스 및 삭제.
초록
1장. 기본 옵션을 사용하여 HCP 클러스터로 ROSA 생성
ROSA Classic에 대한 빠른 시작 가이드를 찾고 계신 경우 Red Hat OpenShift Service on AWS 빠른 시작 가이드를 참조하십시오.
호스팅된 컨트롤 플레인(HCP)이 있는 Red Hat OpenShift Service on AWS(ROSA)는 AWS(ROSA) 클러스터에서 Red Hat OpenShift Service를 생성하기 위한 보다 효율적이고 안정적인 아키텍처를 제공합니다. ROSA HCP가 있는 경우 각 클러스터에는 ROSA 서비스 계정에서 격리된 전용 컨트롤 플레인이 있습니다.
HCP(Host Control Planes)가 있는 ROSA(Red Hat OpenShift Service on AWS)는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
기본 옵션 및 자동 AWS IAM(Identity and Access Management) 리소스 생성을 사용하여 HCP 클러스터로 ROSA를 빠르게 생성합니다. ROSA CLI(rosa)를 사용하여 클러스터를 배포할 수 있습니다.
기존 ROSA 클러스터를 호스팅된 컨트롤 플레인 아키텍처로 업그레이드하거나 변환할 수 없으므로 HCP 기능과 함께 ROSA를 사용할 새 클러스터를 생성해야 합니다.
HCP 클러스터가 있는 ROSA는 AWS STS(Security Token Service) 인증만 지원합니다.
1.1. ROSA와 호스팅된 컨트롤 플레인 및 ROSA Classic 비교
HCP(Red Hat OpenShift Service on AWS)는 AWS(ROSA) 클러스터에서 관리되는 Red Hat OpenShift Service를 생성하는 다른 방법을 제공합니다. HCP를 사용한 ROSA는 신뢰성과 효율성에 중점을 두고 비용 절감 솔루션을 제공합니다. 효율성에 중점을 두고 새 클러스터를 빠르게 생성하고 몇 분 내에 애플리케이션을 배포할 수 있습니다.
HCP를 사용하는 ROSA에는 최소 두 개의 노드 만 있으면 소규모 프로젝트에 이상적인 반면 대규모 프로젝트와 엔터프라이즈를 지원하도록 확장할 수 있습니다.
표 1.1. ROSA 아키텍처 비교 테이블
| | 호스트 컨트롤 플레인 | 클래식 |
|---|---|---|
| 클러스터 인프라 호스팅 | HCP를 사용한 ROSA는 etcd, API 서버 및 oauth와 같은 컨트롤 플레인 구성 요소를 Red Hat 소유 및 관리 계정의 AWS에서 별도로 호스팅합니다. | ROSA Classic은 고객의 동일한 AWS 계정에서 함께 호스팅되는 인프라 및 작업자 노드와 함께 컨트롤 플레인 구성 요소를 배포합니다. |
| 프로비저닝 시간 | 약 10분 | 약 40분 |
| 아키텍처 |
|
|
| Minimum Amazon EC2 footprint | 하나의 클러스터에는 최소 두 개의 노드가 필요합니다. | 하나의 클러스터에는 최소 7개의 노드가 필요합니다. |
| Deployment |
|
|
| 업그레이드 | 컨트롤 플레인 및 머신 풀을 선택적으로 별도로 업그레이드 | 전체 클러스터가 한 번에 업그레이드 |
| 지역 가용성 |
| AWS 리전 가용성은 AWS 끝점의 Red Hat OpenShift Service 및 AWS 문서의 할당량을 참조하십시오. |
| 컴플라이언스 |
|
|
1.1.1. ROSA 아키텍처 네트워크 비교
HCP를 사용하는 ROSA Classic 및 ROSA는 퍼블릭 및 프라이빗 네트워크에 클러스터를 설치할 수 있는 옵션을 제공합니다. 다음 이미지는 이러한 옵션의 차이점을 보여줍니다.
그림 1.1. 공개 및 개인 네트워크에 배포된 ROSA Classic
그림 1.2. 공용 네트워크에 HCP가 배포된 ROSA

그림 1.3. 개인 네트워크에 HCP가 배포된 ROSA

추가 리소스
지원되는 인증서의 전체 목록은 "AWS에서 Red Hat OpenShift Service에 대한 이해 프로세스 및 보안"의 규정 준수 섹션을 참조하십시오.
자동 생성 모드에 대한 고려 사항
이 문서의 절차에서는 ROSA CLI의 auto 모드를 사용하여 현재 AWS 계정을 사용하여 필요한 IAM 리소스를 즉시 생성합니다. 필요한 리소스에는 계정 전체의 IAM 역할 및 정책, 클러스터별 Operator 역할 및 정책, OIDC(OpenID Connect) ID 공급자가 포함됩니다.
또는 수동 모드를 사용할 수 있습니다. 이 모드를 사용하면 자동으로 배포하는 대신 IAM 리소스를 생성하는 데 필요한 aws 명령을 출력할 수 있습니다. 수동 모드 또는 사용자 정의 기능을 사용하여 HCP 클러스터와 함께 ROSA를 배포하는 단계는 사용자 정의를 사용하여 클러스터 생성을 참조하십시오.
다음 단계
- AWS 사전 요구 사항을 완료했는지 확인하십시오.
1.2. 기본 클러스터 사양 개요
기본 설치 옵션을 사용하여 AWS STS(Security Token Service)를 사용하여 HCP 클러스터로 ROSA를 빠르게 생성할 수 있습니다. 다음 요약에서는 기본 클러스터 사양을 설명합니다.
표 1.2. 기본 ROSA with HCP 클러스터 사양
| 구성 요소 | 기본 사양 |
|---|---|
| 계정 및 역할 |
|
| 클러스터 설정 |
|
| 암호화 |
|
| 컴퓨팅 노드 시스템 풀 |
|
| 네트워킹 구성 |
|
| CIDR(Classless Inter-Domain Routing) 범위 |
|
| 클러스터 역할 및 정책 |
|
| 클러스터 업데이트 전략 |
|
1.3. HCP 사전 요구 사항이 있는 ROSA
HCP 클러스터를 사용하여 ROSA를 생성하려면 다음 항목이 있어야 합니다.
- 구성된 VPC(가상 프라이빗 클라우드)
- 계정 전체 역할
- OIDC 구성
- Operator 역할
1.3.1. HCP 클러스터를 사용하여 ROSA용 가상 프라이빗 클라우드 생성
HCP 클러스터를 사용하여 ROSA를 생성하려면 VPC(Virtual Private Cloud)가 있어야 합니다. 다음 방법을 사용하여 VPC를 생성할 수 있습니다.
- Terraform 템플릿을 사용하여 VPC 생성
- AWS 콘솔에서 VPC 리소스 수동 생성
Terraform 지침은 테스트 및 시연을 목적으로 합니다. 자체 설치를 수행하려면 VPC를 일부 수정해야 합니다. 또한 이 Terraform 스크립트를 사용할 때 클러스터를 설치하려는 리전과 동일한 지역에 있는지 확인해야 합니다. 이 예제에서는 us-east-2 를 사용합니다.
Terraform을 사용하여 가상 사설 클라우드 생성
Terraform은 설정된 템플릿을 사용하여 다양한 리소스를 생성할 수 있는 툴입니다. 다음 프로세스는 HCP 클러스터를 사용하여 ROSA를 생성하는 데 필요한 기본 옵션을 사용합니다. Terraform 사용에 대한 자세한 내용은 추가 리소스를 참조하십시오.
사전 요구 사항
- 시스템에 Terraform 버전 1.4.0 이상을 설치했습니다.
- 시스템에 Git을 설치했습니다.
절차
쉘 프롬프트를 열고 다음 명령을 실행하여 Terraform VPC 리포지토리를 복제합니다.
$ git clone https://github.com/openshift-cs/terraform-vpc-example
다음 명령을 실행하여 생성된 디렉터리로 이동합니다.
$ cd terraform-vpc-example
다음 명령을 실행하여 Terraform 파일을 시작합니다.
$ terraform init
이 프로세스가 완료되면 초기화를 확인하는 메시지가 표시됩니다.
기존 Terraform 템플릿을 기반으로 VPC Terraform 계획을 빌드하려면
plan명령을 실행합니다. AWS 리전을 포함해야 합니다. 클러스터 이름을 지정하도록 선택할 수 있습니다.rosa.tfplan파일은테라폼계획이 완료된 후hypershift-tf디렉토리에 추가됩니다. 자세한 옵션은 Terraform VPC 리포지토리의 README 파일을 참조하십시오.$ terraform plan -out rosa.tfplan -var region=<region> [-var cluster_name=<cluster_name>]
다음 명령을 실행하여 VPC를 빌드하려면 이 계획 파일을 적용합니다.
$ terraform apply rosa.tfplan
선택 사항: 다음 명령을 실행하여 HCP 클러스터로 ROSA를 생성할 때 사용할 Terraform-provisioned 개인, 공용 및 머신 풀 서브넷 ID 값을 환경 변수로 캡처할 수 있습니다.
$ export SUBNET_IDS=$(terraform output -raw cluster-subnets-string)
검증
다음 명령을 사용하여 변수가 올바르게 설정되었는지 확인할 수 있습니다.
$ echo $SUBNET_IDS
샘플 출력
$ subnet-0a6a57e0f784171aa,subnet-078e84e5b10ecf5b0
추가 리소스
- 필요에 맞게 VPC를 사용자 정의할 때 사용할 수 있는 모든 옵션의 자세한 목록은 Terraform VPC 리포지터리를 참조하십시오.
수동으로 가상 프라이빗 클라우드 생성
Terraform을 사용하는 대신 VPC(Virtual Private Cloud)를 수동으로 생성하도록 선택하는 경우 AWS 콘솔의 VPC 페이지로 이동합니다. VPC는 다음 표에 표시된 요구 사항을 충족해야 합니다.
표 1.3. VPC에 대한 요구사항
| 요구 사항 | 세부 정보 |
|---|---|
| VPC 이름 | 클러스터를 생성할 때 특정 VPC 이름과 ID가 있어야합니다. |
| CIDR 범위 | VPC CIDR 범위는 머신 CIDR과 일치해야 합니다. |
| 가용성 영역 | 단일 영역에 하나의 가용성 영역이 필요하며, 다중 영역의 가용성 영역인 경우 3개가 필요합니다. |
| 퍼블릭 서브넷 | NAT 게이트웨이가 있는 공용 서브넷이 한 개 있어야 합니다. |
| DNS 호스트 이름 및 확인 | DNS 호스트 이름 및 확인이 활성화되어 있는지 확인해야 합니다. |
1.3.2. 계정 전체 STS 역할 및 정책 생성
ROSA(Red Hat OpenShift Service on AWS) CLI, rosa 를 사용하여 호스팅된 컨트롤 플레인(HCP) 클러스터가 있는 AWS(ROSA)에서 Red Hat OpenShift Service를 생성하기 전에 Operator 정책을 포함하여 필요한 계정 전체 역할 및 정책을 생성합니다.
사전 요구 사항
- HCP를 사용하여 ROSA에 대한 AWS 사전 요구 사항을 완료했습니다.
- 사용 가능한 AWS 서비스 할당량이 있습니다.
- AWS 콘솔에서 ROSA 서비스를 활성화했습니다.
설치 호스트에 최신 ROSA CLI(
rosa)를 설치하고 구성했습니다.참고HCP 클러스터와 함께 ROSA를 성공적으로 설치하려면 최신 버전의 ROSA CLI(
rosa)를 사용합니다.- ROSA CLI를 사용하여 Red Hat 계정에 로그인했습니다.
절차
AWS 계정에 없는 경우 다음 명령을 실행하여 필요한 계정 전체 STS 역할 및 정책을 생성합니다.
$ rosa create account-roles --force-policy-creation
--force-policy-creation매개변수는 존재하는 기존 역할 및 정책을 업데이트합니다. 역할 및 정책이 없는 경우 명령에서 이러한 리소스를 대신 생성합니다.
1.3.3. OpenID Connect 구성 생성
HCP 클러스터와 함께 ROSA를 사용하는 경우 클러스터를 생성하기 전에 OIDC(OpenID Connect) 구성을 생성해야 합니다. 이 구성은 OpenShift Cluster Manager와 함께 사용하도록 등록됩니다.
사전 요구 사항
- HCP를 사용하여 ROSA에 대한 AWS 사전 요구 사항을 완료했습니다.
- AWS에서 Red Hat OpenShift Service에 대한 AWS 사전 요구 사항을 완료했습니다.
-
설치 호스트에 최신 Red Hat OpenShift Service on AWS(ROSA) CLI를 설치하고 구성했습니다.
절차
AWS 리소스와 함께 OIDC 구성을 생성하려면 다음 명령을 실행합니다.
$ rosa create oidc-config --mode=auto --yes
이 명령은 다음 정보를 반환합니다.
샘플 출력
? Would you like to create a Managed (Red Hat hosted) OIDC Configuration Yes I: Setting up managed OIDC configuration I: To create Operator Roles for this OIDC Configuration, run the following command and remember to replace <user-defined> with a prefix of your choice: rosa create operator-roles --prefix <user-defined> --oidc-config-id 13cdr6b If you are going to create a Hosted Control Plane cluster please include '--hosted-cp' I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' ? Create the OIDC provider? Yes I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/13cdr6b'
클러스터를 생성할 때 OIDC 구성 ID를 제공해야 합니다. CLI 출력은
--mode auto에 대해 이 값을 제공합니다. 그렇지 않으면--mode 수동에 대한awsCLI 출력에 따라 이러한 값을 결정해야합니다.선택 사항: 나중에 사용할 수 있도록 OIDC 구성 ID를 변수로 저장할 수 있습니다. 다음 명령을 실행하여 변수를 저장합니다.
$ export OIDC_ID=30f5dqmk
다음 명령으로 실행하여 변수 값을 확인합니다.
$ echo $OIDC_ID
샘플 출력
$ 30f5dqmk
검증
사용자 조직과 연결된 클러스터에 사용 가능한 OIDC 구성을 나열할 수 있습니다. 다음 명령을 실행합니다.
$ rosa list oidc-config
샘플 출력
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
1.3.4. Operator 역할 및 정책 생성
HCP 클러스터와 함께 ROSA를 사용하는 경우 HCP(Hosted Control Planes) 배포에서 Red Hat OpenShift Service on AWS(ROSA)에 필요한 Operator IAM 역할을 생성해야 합니다. 클러스터 Operator는 Operator 역할을 사용하여 백엔드 스토리지, 클라우드 공급자 인증 정보 관리, 클러스터에 대한 외부 액세스와 같은 클러스터 작업을 수행하는 데 필요한 임시 권한을 얻습니다.
사전 요구 사항
- HCP를 사용하여 ROSA에 대한 AWS 사전 요구 사항을 완료했습니다.
-
설치 호스트에 최신 Red Hat OpenShift Service on AWS(ROSA) CLI를 설치하고 구성했습니다.
- 계정 전체 AWS 역할을 생성하셨습니다.
절차
Operator 역할을 생성하려면 다음 명령을 실행합니다.
$ rosa create operator-roles --hosted-cp --prefix <prefix-name> --oidc-config-id <oidc-config-id>
다음 분석에서는 Operator 역할 생성에 대한 옵션을 제공합니다.
$ rosa create operator-roles --hosted-cp --prefix <prefix-name> 1 --oidc-config-id <oidc-config-id> 2
HCP 클러스터의 ROSA에 올바른 역할을 생성하려면
--hosted-cp매개변수를 포함해야 합니다. 이 명령은 다음 정보를 반환합니다.샘플 출력
? Role creation mode: auto ? Operator roles prefix: <pre-filled_prefix> 1 ? OIDC Configuration ID: 23soa2bgvpek9kmes9s7os0a39i13qm4 | https://dvbwgdztaeq9o.cloudfront.net/23soa2bgvpek9kmes9s7os0a39i13qm4 2 ? Create hosted control plane operator roles: Yes W: More than one Installer role found ? Installer role ARN: arn:aws:iam::4540112244:role/<prefix>-Installer-Role ? Permissions boundary ARN (optional): I: Reusable OIDC Configuration detected. Validating trusted relationships to operator roles: I: Creating roles using 'arn:aws:iam::4540112244:user/<userName>' I: Created role '<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials' I: Created role '<prefix>-openshift-cloud-network-config-controller-cloud-credenti' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti' I: Created role '<prefix>-kube-system-kube-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager' I: Created role '<prefix>-kube-system-capa-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager' I: Created role '<prefix>-kube-system-control-plane-operator' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator' I: Created role '<prefix>-kube-system-kms-provider' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider' I: Created role '<prefix>-openshift-image-registry-installer-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials' I: Created role '<prefix>-openshift-ingress-operator-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials' I: To create a cluster with these roles, run the following command: rosa create cluster --sts --oidc-config-id 23soa2bgvpek9kmes9s7os0a39i13qm4 --operator-roles-prefix <prefix> --hosted-cp
이제 Operator 역할이 생성되어 HCP 클러스터를 사용하여 ROSA를 생성할 준비가 되었습니다.
검증
ROSA 계정과 연결된 Operator 역할을 나열할 수 있습니다. 다음 명령을 실행합니다.
$ rosa list operator-roles
샘플 출력
I: Fetching operator roles ROLE PREFIX AMOUNT IN BUNDLE <prefix> 8 ? Would you like to detail a specific prefix Yes 1 ? Operator Role Prefix: <prefix> ROLE NAME ROLE ARN VERSION MANAGED <prefix>-kube-system-capa-controller-manager arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager 4.13 No <prefix>-kube-system-control-plane-operator arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator 4.13 No <prefix>-kube-system-kms-provider arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider 4.13 No <prefix>-kube-system-kube-controller-manager arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager 4.13 No <prefix>-openshift-cloud-network-config-controller-cloud-credenti arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti 4.13 No <prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials 4.13 No <prefix>-openshift-image-registry-installer-cloud-credentials arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials 4.13 No <prefix>-openshift-ingress-operator-cloud-credentials arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials 4.13 No- 1
- 명령을 실행한 후 AWS 계정과 연결된 모든 접두사를 표시하고 이 접두사와 연결된 역할 수를 기록합니다. 이러한 역할과 세부 정보를 모두 확인해야 하는 경우 세부 정보 프롬프트에 이러한 역할을 나열하도록 "예"를 입력합니다.
추가 리소스
- Operator 접두사에 대한 자세한 내용은 사용자 정의 Operator IAM 역할 접두사 정보를 참조하십시오.
1.4. CLI를 사용하여 HCP 클러스터로 ROSA 생성
ROSA(Red Hat OpenShift Service on AWS) CLI인 rosa 를 사용하여 클러스터를 생성하는 경우 기본 옵션을 선택하여 클러스터를 빠르게 생성할 수 있습니다.
사전 요구 사항
- HCP를 사용하여 ROSA에 대한 AWS 사전 요구 사항을 완료했습니다.
- 사용 가능한 AWS 서비스 할당량이 있습니다.
- AWS 콘솔에서 ROSA 서비스를 활성화했습니다.
설치 호스트에 최신 ROSA CLI(
rosa)를 설치하고 구성했습니다.참고ROSA 클러스터를 성공적으로 설치하려면 최신 버전의 ROSA CLI(로사)를 사용합니다.
rosa 버전을실행하여 현재 설치된 ROSA CLI 버전을 확인합니다. 최신 버전을 사용할 수 있는 경우 CLI는 이 업그레이드를 다운로드할 수 있는 링크를 제공합니다.- ROSA CLI를 사용하여 Red Hat 계정에 로그인했습니다.
- OIDC 구성을 생성했습니다.
- AWS 계정에 ELB(Elastic Load Balancing) 서비스 역할이 있는지 확인했습니다.
절차
다음 명령 중 하나를 사용하여 HCP 클러스터를 사용하여 ROSA를 생성할 수 있습니다.
다음 명령을 실행하여 단일 초기 머신 풀, 공개적으로 사용 가능한 API 및 공개적으로 사용 가능한 Ingress로 클러스터를 생성합니다.
$ rosa create cluster --cluster-name=<cluster_name> \ --sts --mode=auto --hosted-cp --operator-roles-prefix <operator-role-prefix> \ --oidc-config-id <ID-of-OIDC-configuration> --subnet-ids=<public-subnet-id>,<private-subnet-id>다음 명령을 실행하여 단일 초기 머신 풀, 비공개로 사용 가능한 API 및 비공개로 사용 가능한 Ingress로 클러스터를 생성합니다.
$ rosa create cluster --private --cluster-name=<cluster_name> \ --sts --mode=auto --hosted-cp --subnet-ids=<private-subnet-id>OIDC_ID및SUBNET_IDS와 같은 변수를 사용한 경우 클러스터를 생성할 때 해당 참조를 사용할 수 있습니다. 예를 들어 다음 명령을 실행합니다.$ rosa create cluster --hosted-cp --subnet-ids=$SUBNET_IDS --oidc-config-id=$OIDC_ID --cluster-name=<cluster_name>
다음 명령을 실행하여 클러스터 상태를 확인합니다.
$ rosa describe cluster --cluster=<cluster_name>
클러스터 설치가 진행됨에 따라 다음
상태필드 변경 사항이 출력에 나열됩니다.-
보류 (사전 계정) -
설치 ( 진행 중인 DNS 설정) -
설치 Ready참고설치에 실패하거나 10분 이상
State필드가준비상태가 아닌 경우 자세한 내용은 설치 문제 해결 설명서를 확인하십시오. 자세한 내용은 설치 문제 해결을 참조하십시오. Red Hat 지원에 문의하여 지원을 받으려면 AWS에서 Red Hat OpenShift Service 지원 가져오기 를 참조하십시오.
-
AWS 설치 프로그램 로그의 Red Hat OpenShift Service를 확인하여 클러스터 생성 진행 상황을 추적합니다. 로그를 확인하려면 다음 명령을 실행합니다.
$ rosa logs install --cluster=<cluster_name> --watch 1- 1
- 선택 사항: 설치가 진행되는 동안 새 로그 메시지를 조사하려면
--watch인수를 사용합니다.
1.5. 다음 단계
1.6. 추가 리소스
- 수동 모드를 사용하여 ROSA 클러스터를 배포하는 단계는 사용자 지정을 사용하여 클러스터 생성을 참조하십시오.
- STS를 사용하여 AWS에 Red Hat OpenShift Service를 배포하는 데 필요한 IAM(Identity Access Management) 리소스에 대한 자세한 내용은 STS를 사용하는 클러스터의 IAM 리소스 정보를 참조하십시오.
- 필요한 경우 Operator 역할 이름 접두사 설정에 대한 자세한 내용은 사용자 정의 Operator IAM 역할 접두사 정보를 참조하십시오.
- STS를 사용하여 ROSA를 설치하기 위한 사전 요구 사항에 대한 자세한 내용은 STS를 사용하여 ROSA의 AWS 사전 요구 사항을 참조하십시오.
-
자동및수동모드를 사용하여 필요한 STS 리소스를 생성하는 방법에 대한 자세한 내용은 자동 및 수동 배포 모드 이해를 참조하십시오. - AWS IAM에서 OpenID Connect(OIDC) ID 공급자를 사용하는 방법에 대한 자세한 내용은 AWS 문서의 OpenID Connect (OIDC) ID 공급자 생성을 참조하십시오.
- ROSA 클러스터 설치 문제 해결에 대한 자세한 내용은 설치 문제 해결을 참조하십시오.
- Red Hat 지원에 문의하여 지원을 받으려면 AWS에서 Red Hat OpenShift Service 지원 가져오기 를 참조하십시오.
2장. HCP 클러스터에서 ROSA에서 Node Tuning Operator 사용
HCP(Host Control Planes)가 있는 ROSA(Red Hat OpenShift Service on AWS)는 Node Tuning Operator를 지원하여 HCP 클러스터가 있는 ROSA에서 노드의 성능을 향상시킵니다. 노드 튜닝 구성을 생성하기 전에 사용자 정의 튜닝 사양을 생성해야 합니다.
HCP(Host Control Planes)가 있는 ROSA(Red Hat OpenShift Service on AWS)는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
목적
Node Tuning Operator는 TuneD 데몬을 오케스트레이션하여 노드 수준 튜닝을 관리하고 Performance Profile 컨트롤러를 사용하여 짧은 대기 시간 성능을 달성하는 데 도움이 됩니다. 대부분의 고성능 애플리케이션에는 일정 수준의 커널 튜닝이 필요합니다. Node Tuning Operator는 노드 수준 sysctls 사용자에게 통합 관리 인터페이스를 제공하며 사용자의 필요에 따라 지정되는 사용자 정의 튜닝을 추가할 수 있는 유연성을 제공합니다.
Operator는 AWS의 Red Hat OpenShift Service의 컨테이너화된 TuneD 데몬을 Kubernetes 데몬 세트로 관리합니다. 클러스터에서 실행되는 모든 컨테이너화된 TuneD 데몬에 사용자 정의 튜닝 사양이 데몬이 이해할 수 있는 형식으로 전달되도록 합니다. 데몬은 클러스터의 모든 노드에서 노드당 하나씩 실행됩니다.
컨테이너화된 TuneD 데몬을 통해 적용되는 노드 수준 설정은 프로필 변경을 트리거하는 이벤트 시 또는 컨테이너화된 TuneD 데몬이 종료 신호를 수신하고 처리하여 정상적으로 종료될 때 롤백됩니다.
Node Tuning Operator는 Performance Profile 컨트롤러를 사용하여 자동 튜닝을 구현하여 AWS 애플리케이션에서 Red Hat OpenShift Service에 대해 짧은 대기 시간 성능을 달성합니다. 클러스터 관리자는 다음과 같은 노드 수준 설정을 정의하도록 성능 프로필을 구성합니다.
- 커널을 kernel-rt로 업데이트합니다.
- 하우스키핑을 위한 CPU 선택.
- 워크로드 실행을 위한 CPU 선택.
현재 cgroup v2에서는 CPU 부하 분산을 비활성화하지 않습니다. 따라서 cgroup v2가 활성화된 경우 성능 프로필에서 원하는 동작을 얻지 못할 수 있습니다. performace 프로필을 사용하는 경우 cgroup v2를 활성화하는 것은 권장되지 않습니다.
Node Tuning Operator는 버전 4.1 이상에서 AWS의 표준 Red Hat OpenShift Service의 일부입니다.
AWS의 이전 Red Hat OpenShift Service 버전에서 Performance Addon Operator는 OpenShift 애플리케이션의 짧은 대기 시간 성능을 달성하기 위해 자동 튜닝을 구현하는 데 사용되었습니다. AWS 4.11 이상의 Red Hat OpenShift Service에서 이 기능은 Node Tuning Operator의 일부입니다.
2.1. 사용자 정의 튜닝 사양
Operator의 CR(사용자 정의 리소스)에는 두 가지 주요 섹션이 있습니다. 첫 번째 섹션인 profile:은 TuneD 프로필 및 해당 이름의 목록입니다. 두 번째인 recommend:은 프로필 선택 논리를 정의합니다.
여러 사용자 정의 튜닝 사양은 Operator의 네임스페이스에 여러 CR로 존재할 수 있습니다. 새로운 CR의 존재 또는 오래된 CR의 삭제는 Operator에서 탐지됩니다. 기존의 모든 사용자 정의 튜닝 사양이 병합되고 컨테이너화된 TuneD 데몬의 해당 오브젝트가 업데이트됩니다.
관리 상태
Operator 관리 상태는 기본 Tuned CR을 조정하여 설정됩니다. 기본적으로 Operator는 Managed 상태이며 기본 Tuned CR에는 spec.managementState 필드가 없습니다. Operator 관리 상태에 유효한 값은 다음과 같습니다.
- Managed: 구성 리소스가 업데이트되면 Operator가 해당 피연산자를 업데이트합니다.
- Unmanaged: Operator가 구성 리소스에 대한 변경을 무시합니다.
- Removed: Operator가 프로비저닝한 해당 피연산자 및 리소스를 Operator가 제거합니다.
프로필 데이터
profile: 섹션에는 TuneD 프로필 및 해당 이름이 나열됩니다.
{
"profile": [
{
"name": "tuned_profile_1",
"data": "# TuneD profile specification\n[main]\nsummary=Description of tuned_profile_1 profile\n\n[sysctl]\nnet.ipv4.ip_forward=1\n# ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD\n"
},
{
"name": "tuned_profile_n",
"data": "# TuneD profile specification\n[main]\nsummary=Description of tuned_profile_n profile\n\n# tuned_profile_n profile settings\n"
}
]
}권장 프로필
profile: 선택 논리는 CR의 recommend: 섹션에 의해 정의됩니다. recommend: 섹션은 선택 기준에 따라 프로필을 권장하는 항목의 목록입니다.
"recommend": [
{
"recommend-item-1": details_of_recommendation,
# ...
"recommend-item-n": details_of_recommendation,
}
]목록의 개별 항목은 다음과 같습니다.
{
"profile": [
{
# ...
}
],
"recommend": [
{
"profile": <tuned_profile_name>, 1
"priority": <priority>, 2
"machineConfigLabels": { <Key_Pair_for_MachineConfig> 3
},
"match": [ 4
{
"label": <label_information> 5
},
]
},
]
}
<match>는 다음과 같이 재귀적으로 정의되는 선택사항 목록입니다.
"match": [
{
"label": 1
},
]- 1
- 노드 또는 Pod 라벨 이름입니다.
<match>를 생략하지 않으면 모든 중첩 <match> 섹션도 true로 평가되어야 합니다. 생략하면 false로 가정하고 해당 <match> 섹션이 있는 프로필을 적용하지 않거나 권장하지 않습니다. 따라서 중첩(하위 <match> 섹션)은 논리 AND 연산자 역할을 합니다. 반대로 <match> 목록의 항목이 일치하면 전체 <match> 목록이 true로 평가됩니다. 따라서 이 목록이 논리 OR 연산자 역할을 합니다.
machineConfigLabels가 정의되면 지정된 recommend: 목록 항목에 대해 머신 구성 풀 기반 일치가 설정됩니다. <mcLabels>는 머신 구성의 라벨을 지정합니다. 머신 구성은 <tuned_profile_name> 프로필에 대해 커널 부팅 매개변수와 같은 호스트 설정을 적용하기 위해 자동으로 생성됩니다. 여기에는 <mcLabels>와 일치하는 머신 구성 선택기가 있는 모든 머신 구성 풀을 찾고 머신 구성 풀이 할당된 모든 노드에서 <tuned_profile_name> 프로필을 설정하는 작업이 포함됩니다. 마스터 및 작업자 역할이 모두 있는 노드를 대상으로 하려면 마스터 역할을 사용해야 합니다.
목록 항목 match 및 machineConfigLabels는 논리 OR 연산자로 연결됩니다. match 항목은 단락 방식으로 먼저 평가됩니다. 따라서 true로 평가되면 machineConfigLabels 항목이 고려되지 않습니다.
머신 구성 풀 기반 일치를 사용하는 경우 동일한 하드웨어 구성을 가진 노드를 동일한 머신 구성 풀로 그룹화하는 것이 좋습니다. 이 방법을 따르지 않으면 TuneD 피연산자가 동일한 머신 구성 풀을 공유하는 두 개 이상의 노드에 대해 충돌하는 커널 매개변수를 계산할 수 있습니다.
예: 노드 또는 Pod 라벨 기반 일치
[
{
"match": [
{
"label": "tuned.openshift.io/elasticsearch",
"match": [
{
"label": "node-role.kubernetes.io/master"
},
{
"label": "node-role.kubernetes.io/infra"
}
],
"type": "pod"
}
],
"priority": 10,
"profile": "openshift-control-plane-es"
},
{
"match": [
{
"label": "node-role.kubernetes.io/master"
},
{
"label": "node-role.kubernetes.io/infra"
}
],
"priority": 20,
"profile": "openshift-control-plane"
},
{
"priority": 30,
"profile": "openshift-node"
}
]
위의 CR은 컨테이너화된 TuneD 데몬의 프로필 우선 순위에 따라 recommended.conf 파일로 변환됩니다. 우선 순위가 가장 높은 프로필(10)이 openshift-control-plane-es이므로 이 프로필을 첫 번째로 고려합니다. 지정된 노드에서 실행되는 컨테이너화된 TuneD 데몬은 tuned.openshift.io/elasticsearch 라벨이 설정된 동일한 노드에서 실행되는 Pod가 있는지 확인합니다. 없는 경우 전체 <match> 섹션이 false로 평가됩니다. 라벨이 있는 Pod가 있는 경우 <match> 섹션을 true로 평가하려면 노드 라벨도 node-role.kubernetes.io/master 또는 node-role.kubernetes.io/infra여야 합니다.
우선 순위가 10인 프로필의 라벨이 일치하면 openshift-control-plane-es 프로필이 적용되고 다른 프로필은 고려되지 않습니다. 노드/Pod 라벨 조합이 일치하지 않으면 두 번째로 높은 우선 순위 프로필(openshift-control-plane)이 고려됩니다. 컨테이너화된 TuneD Pod가 node-role.kubernetes.io/master 또는 node-role.kubernetes.io/infra. 라벨이 있는 노드에서 실행되는 경우 이 프로필이 적용됩니다.
마지막으로, openshift-node 프로필은 우선 순위가 가장 낮은 30입니다. 이 프로필에는 <match> 섹션이 없으므로 항상 일치합니다. 지정된 노드에서 우선 순위가 더 높은 다른 프로필이 일치하지 않는 경우 openshift-node 프로필을 설정하는 데 catch-all 프로필 역할을 합니다.

예: 머신 구성 풀 기반 일치
{
"apiVersion": "tuned.openshift.io/v1",
"kind": "Tuned",
"metadata": {
"name": "openshift-node-custom",
"namespace": "openshift-cluster-node-tuning-operator"
},
"spec": {
"profile": [
{
"data": "[main]\nsummary=Custom OpenShift node profile with an additional kernel parameter\ninclude=openshift-node\n[bootloader]\ncmdline_openshift_node_custom=+skew_tick=1\n",
"name": "openshift-node-custom"
}
],
"recommend": [
{
"machineConfigLabels": {
"machineconfiguration.openshift.io/role": "worker-custom"
},
"priority": 20,
"profile": "openshift-node-custom"
}
]
}
}
노드 재부팅을 최소화하려면 머신 구성 풀의 노드 선택기와 일치하는 라벨로 대상 노드에 라벨을 지정한 후 위의 Tuned CR을 생성하고 마지막으로 사용자 정의 머신 구성 풀을 생성합니다.
클라우드 공급자별 TuneD 프로필
이 기능을 사용하면 모든 클라우드 공급자 관련 노드에 AWS 클러스터의 Red Hat OpenShift Service에서 지정된 클라우드 공급자에 특별히 맞춰진 TuneD 프로필을 편리하게 할당할 수 있습니다. 이 작업은 노드 레이블을 추가하거나 노드를 머신 구성 풀에 그룹화하지 않고 수행할 수 있습니다.
이 기능은 <cloud-provider> ://<cloud-provider-specific-id> 형식의 노드 오브젝트 값을 활용하고 NTO 피연산자 컨테이너의 < spec.provider IDcloud-provider> 값으로 파일을 기록합니다. 그런 다음 이 파일의 내용은 TuneD에서 이러한 프로필이 존재하는 경우 /var/lib/tuned/provider provider-<cloud-provider > 프로필을 로드하는 데 사용됩니다.
및 openshift -control-planeopenshift-node 프로필 모두 의 설정을 상속하는 openshift 프로파일이 조건부 프로파일 로드를 사용하여 이 기능을 사용하도록 업데이트되었습니다. 현재 NTO 및 TuneD에는 클라우드 공급자별 프로필이 포함되어 있지 않습니다. 그러나 모든 클라우드 공급자별 클러스터 노드에 적용할 사용자 지정 프로필 provider-<cloud- provider>를 생성할 수 있습니다.
GCE 클라우드 공급자 프로필의 예
{
"apiVersion": "tuned.openshift.io/v1",
"kind": "Tuned",
"metadata": {
"name": "provider-gce",
"namespace": "openshift-cluster-node-tuning-operator"
},
"spec": {
"profile": [
{
"data": "[main]\nsummary=GCE Cloud provider-specific profile\n# Your tuning for GCE Cloud provider goes here.\n",
"name": "provider-gce"
}
]
}
}
프로필 상속으로 인해 provider-< cloud-provider > 프로필에 지정된 모든 설정은 openshift 프로필 및 해당 하위 프로필로 덮어씁니다.
2.2. HCP를 사용하여 ROSA에서 노드 튜닝 구성 생성
ROSA(Red Hat OpenShift Service on AWS) CLI, rosa 를 사용하여 튜닝 구성을 생성할 수 있습니다.
사전 요구 사항
- ROSA CLI의 최신 버전을 다운로드했습니다.
- 최신 버전에 클러스터가 있어야 합니다.
- 노드 튜닝을 위해 사양 파일이 구성되어 있습니다.
절차
다음 명령을 실행하여 튜닝 구성을 생성합니다.
$ rosa create tuning-config -c <cluster_id> --name <name_of_tuning> --spec-path <path_to_spec_file>
spec.json파일의 경로를 제공하거나 명령에서 오류를 반환해야 합니다.샘플 출력
$ I: Tuning config 'sample-tuning' has been created on cluster 'cluster-example'. $ I: To view all tuning configs, run 'rosa list tuning-configs -c cluster-example'
검증
다음 명령을 사용하여 계정에서 적용되는 기존 튜닝 구성을 확인할 수 있습니다.
$ rosa list tuning-configs -c <cluster_name> [-o json]
구성 목록에 원하는 출력 유형을 지정할 수 있습니다.
출력 유형을 지정하지 않으면 튜닝 구성의 ID와 이름이 표시됩니다.
출력 유형을 지정하지 않은 샘플 출력
ID NAME 20468b8e-edc7-11ed-b0e4-0a580a800298 sample-tuning
json과 같은 출력 유형을 지정하는 경우 튜닝 구성을 JSON 텍스트로 받습니다.참고다음 JSON 출력에는 읽기 명확성을 위해 하드 라인 반환이 있습니다. JSON 문자열에서 줄 바꿈을 제거하지 않는 한 이 JSON 출력은 유효하지 않습니다.
JSON 출력을 지정하는 샘플 출력
[ { "kind": "TuningConfig", "id": "20468b8e-edc7-11ed-b0e4-0a580a800298", "href": "/api/clusters_mgmt/v1/clusters/23jbsevqb22l0m58ps39ua4trff9179e/tuning_configs/20468b8e-edc7-11ed-b0e4-0a580a800298", "name": "sample-tuning", "spec": { "profile": [ { "data": "[main]\nsummary=Custom OpenShift profile\ninclude=openshift-node\n\n[sysctl]\nvm.dirty_ratio=\"55\"\n", "name": "tuned-1-profile" } ], "recommend": [ { "priority": 20, "profile": "tuned-1-profile" } ] } } ]
2.3. HCP를 사용하여 ROSA의 노드 튜닝 구성 수정
ROSA(Red Hat OpenShift Service on AWS) CLI, rosa 를 사용하여 노드 튜닝 구성을 보고 업데이트할 수 있습니다.
사전 요구 사항
- ROSA CLI의 최신 버전을 다운로드했습니다.
- 최신 버전에 클러스터가 있어야 합니다.
- 클러스터에 노드 튜닝 구성이 추가되어 있습니다.
절차
rosa describe명령을 사용하여 튜닝 구성을 확인합니다.$ rosa describe tuning-config -c <cluster_id> 1 --name <name_of_tuning> 2 [-o json] 3
이 사양 파일의 다음 항목은 다음과 같습니다.
출력 유형을 지정하지 않은 샘플 출력
Name: sample-tuning ID: 20468b8e-edc7-11ed-b0e4-0a580a800298 Spec: { "profile": [ { "data": "[main]\nsummary=Custom OpenShift profile\ninclude=openshift-node\n\n[sysctl]\nvm.dirty_ratio=\"55\"\n", "name": "tuned-1-profile" } ], "recommend": [ { "priority": 20, "profile": "tuned-1-profile" } ] }JSON 출력을 지정하는 샘플 출력
{ "kind": "TuningConfig", "id": "20468b8e-edc7-11ed-b0e4-0a580a800298", "href": "/api/clusters_mgmt/v1/clusters/23jbsevqb22l0m58ps39ua4trff9179e/tuning_configs/20468b8e-edc7-11ed-b0e4-0a580a800298", "name": "sample-tuning", "spec": { "profile": [ { "data": "[main]\nsummary=Custom OpenShift profile\ninclude=openshift-node\n\n[sysctl]\nvm.dirty_ratio=\"55\"\n", "name": "tuned-1-profile" } ], "recommend": [ { "priority": 20, "profile": "tuned-1-profile" } ] } }튜닝 구성을 확인한 후
rosa edit명령을 사용하여 기존 구성을 편집합니다.$ rosa edit tuning-config -c <cluster_id> --name <name_of_tuning> --spec-path <path_to_spec_file>
이 명령에서는
spec.json파일을 사용하여 구성을 편집합니다.
검증
rosa describe명령을 다시 실행하여spec.json파일에 대한 변경 사항이 튜닝 구성에서 업데이트되었는지 확인합니다.$ rosa describe tuning-config -c <cluster_id> --name <name_of_tuning>
샘플 출력
Name: sample-tuning ID: 20468b8e-edc7-11ed-b0e4-0a580a800298 Spec: { "profile": [ { "data": "[main]\nsummary=Custom OpenShift profile\ninclude=openshift-node\n\n[sysctl]\nvm.dirty_ratio=\"55\"\n", "name": "tuned-2-profile" } ], "recommend": [ { "priority": 10, "profile": "tuned-2-profile" } ] }
2.4. HCP를 사용하여 ROSA에서 노드 튜닝 구성 삭제
ROSA(Red Hat OpenShift Service on AWS) CLI( rosa )를 사용하여 튜닝 구성을 삭제할 수 있습니다.
머신 풀에서 참조되는 튜닝 구성을 삭제할 수 없습니다. 먼저 모든 머신 풀에서 튜닝 구성을 제거해야 삭제할 수 있습니다.
사전 요구 사항
- ROSA CLI의 최신 버전을 다운로드했습니다.
- 최신 버전에 클러스터가 있어야 합니다.
- 클러스터에는 삭제할 노드 튜닝 구성이 있습니다.
절차
튜닝 구성을 삭제하려면 다음 명령을 실행합니다.
$ rosa delete tuning-config -c <cluster_id> <name_of_tuning>
클러스터의 튜닝 구성이 삭제됨
샘플 출력
? Are you sure you want to delete tuning config sample-tuning on cluster sample-cluster? Yes I: Successfully deleted tuning config 'sample-tuning' from cluster 'sample-cluster'