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 서비스 계정에서 격리된 전용 컨트롤 플레인이 있습니다.
기본 옵션 및 자동 AWS IAM(Identity and Access Management) 리소스 생성을 사용하여 HCP 클러스터로 ROSA를 빠르게 생성합니다. ROSA CLI(rosa
)를 사용하여 클러스터를 배포할 수 있습니다.
기존 ROSA 클러스터를 호스팅된 컨트롤 플레인 아키텍처로 업그레이드하거나 변환할 수 없으므로 HCP 기능과 함께 ROSA를 사용할 새 클러스터를 생성해야 합니다.
HCP 클러스터가 있는 ROSA는 AWS STS(Security Token Service) 인증만 지원합니다.
추가 읽기
- ROSA와 HCP 및 ROSA Classic의 비교는 Comparing architecture models 문서를 참조하십시오.
- ROSA CLI를 자동 모드에서 사용하여 HCP로 ROSA 시작하기에 대한 자세한 내용은 AWS 설명서를 참조하십시오.
추가 리소스
지원되는 인증서의 전체 목록은 "AWS에서 Red Hat OpenShift Service에 대한 이해 프로세스 및 보안"의 규정 준수 섹션을 참조하십시오.
자동 생성 모드에 대한 고려 사항
이 문서의 절차에서는 ROSA CLI의 auto
모드를 사용하여 현재 AWS 계정을 사용하여 필요한 IAM 리소스를 즉시 생성합니다. 필요한 리소스에는 계정 전체의 IAM 역할 및 정책, 클러스터별 Operator 역할 및 정책, OIDC(OpenID Connect) ID 공급자가 포함됩니다.
또는 수동
모드를 사용할 수 있습니다. 이 모드를 사용하면 자동으로 배포하는 대신 IAM 리소스를 생성하는 데 필요한 aws
명령을 출력할 수 있습니다. 수동
모드 또는 사용자 정의 기능을 사용하여 HCP 클러스터와 함께 ROSA를 배포하는 단계는 사용자 정의를 사용하여 클러스터 생성을 참조하십시오.
다음 단계
- AWS 사전 요구 사항을 완료했는지 확인합니다.
1.1. 기본 클러스터 사양 개요
기본 설치 옵션을 사용하여 STS(Security Token Service)를 사용하여 HCP 클러스터로 ROSA를 빠르게 생성할 수 있습니다. 다음 요약에서는 기본 클러스터 사양을 설명합니다.
표 1.1. 기본 ROSA with HCP 클러스터 사양
구성 요소 | 기본 사양 |
---|---|
계정 및 역할 |
|
클러스터 설정 |
|
암호화 |
|
컴퓨팅 노드 시스템 풀 |
|
네트워킹 구성 |
|
CIDR(Classless Inter-Domain Routing) 범위 |
|
클러스터 역할 및 정책 |
|
클러스터 업데이트 전략 |
|
1.2. HCP 사전 요구 사항이 있는 ROSA
HCP 클러스터를 사용하여 ROSA를 생성하려면 다음 항목이 있어야 합니다.
- 구성된 VPC(가상 프라이빗 클라우드)
- 계정 전체 역할
- OIDC 구성
- Operator 역할
1.2.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>
다음 명령을 실행하여 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.2. VPC에 대한 요구사항
요구 사항 | 세부 정보 |
---|---|
VPC 이름 | 클러스터를 생성할 때 특정 VPC 이름과 ID가 있어야합니다. |
CIDR 범위 | VPC CIDR 범위는 머신 CIDR과 일치해야 합니다. |
가용성 영역 | 단일 영역에 하나의 가용성 영역이 필요하며, 다중 영역의 가용성 영역인 경우 3개가 필요합니다. |
퍼블릭 서브넷 | 공용 클러스터에 대해 NAT 게이트웨이가 있는 퍼블릭 서브넷이 1개 있어야 합니다. 프라이빗 클러스터에는 퍼블릭 서브넷이 필요하지 않습니다. |
DNS 호스트 이름 및 확인 | DNS 호스트 이름 및 확인이 활성화되어 있는지 확인해야 합니다. |
서브넷 태그 지정
VPC를 사용하여 HCP 클러스터로 ROSA를 생성하려면 먼저 VPC 서브넷을 태그해야 합니다. 자동화된 서비스 preflight 검사에서는 이러한 리소스를 사용하기 전에 이러한 리소스가 올바르게 태그되었는지 확인합니다. 다음 표에서는 리소스에 다음 태그를 지정하는 방법을 보여줍니다.
리소스 | 키 | 현재의 |
---|---|---|
퍼블릭 서브넷 |
|
|
프라이빗 서브넷 |
|
|
하나 이상의 프라이빗 서브넷과 해당하는 경우 공용 서브넷과 퍼블릭 서브넷을 태그해야 합니다.
사전 요구 사항
- VPC를 생성했습니다.
-
aws
CLI가 설치되어 있습니다.
절차
다음 명령을 실행하여 터미널에서 리소스를 태그합니다.
퍼블릭 서브넷의 경우 다음을 실행합니다.
$ aws ec2 create-tags --resources <public-subnet-id> --tags Key=kubernetes.io/role/elb,Value=1
프라이빗 서브넷의 경우 다음을 실행합니다.
$ aws ec2 create-tags --resources <private-subnet-id> --tags Key=kubernetes.io/role/internal-elb,Value=1
검증
다음 명령을 실행하여 태그가 올바르게 적용되었는지 확인합니다.
$ aws ec2 describe-tags --filters "Name=resource-id,Values=<subnet_id>"
출력 예
TAGS Name <subnet-id> subnet <prefix>-subnet-public1-us-east-1a TAGS kubernetes.io/role/elb <subnet-id> subnet 1
1.2.2. 계정 전체 STS 역할 및 정책 생성
ROSA(Red Hat OpenShift Service on AWS) CLI(rosa
)를 사용하여 호스팅된 컨트롤 플레인(HCP) 클러스터가 있는 AWS(ROSA)에서 Red Hat OpenShift Service를 생성하기 전에 Operator 정책을 포함하여 필요한 계정 전체 역할 및 정책을 생성합니다.
HCP 클러스터를 사용하는 ROSA에는 AWS 관리 정책이 연결된 계정 및 Operator 역할이 필요합니다. 고객 관리 정책은 지원되지 않습니다. HCP 클러스터의 ROSA 관리 정책에 대한 자세한 내용은 ROSA 계정 역할에 대한 AWS 관리 정책을 참조하십시오.
사전 요구 사항
- HCP를 사용하여 ROSA에 대한 AWS 사전 요구 사항을 완료했습니다.
- 사용 가능한 AWS 서비스 할당량이 있습니다.
- AWS 콘솔에서 ROSA 서비스를 활성화했습니다.
-
설치 호스트에 최신 ROSA CLI(
rosa
)를 설치하고 구성했습니다. - ROSA CLI를 사용하여 Red Hat 계정에 로그인했습니다.
절차
AWS 계정에 없는 경우 필요한 계정 전체 STS 역할을 생성하고 다음 명령을 실행하여 정책을 연결합니다.
$ rosa create account-roles --hosted-cp
선택 사항: 다음 명령을 실행하여 접두사를 환경 변수로 설정합니다.
$ export ACCOUNT_ROLES_PREFIX=<account_role_prefix>
다음 명령을 실행하여 변수 값을 확인합니다.
$ echo $ACCOUNT_ROLES_PREFIX
출력 예
ManagedOpenShift
ROSA의 AWS 관리 IAM 정책에 대한 자세한 내용은 ROSA의 AWS 관리 IAM 정책을 참조하십시오.
1.2.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 수동
에 대한aws
CLI 출력에 따라 이러한 값을 결정해야합니다.선택 사항: 나중에 사용할 수 있도록 OIDC 구성 ID를 변수로 저장할 수 있습니다. 다음 명령을 실행하여 변수를 저장합니다.
$ export OIDC_ID=<oidc_config_id>1
- 1
- 위의 출력 예에서 OIDC 구성 ID는 13cdr6b입니다.
다음 명령을 실행하여 변수 값을 확인합니다.
$ echo $OIDC_ID
출력 예
13cdr6b
검증
사용자 조직과 연결된 클러스터에 사용 가능한 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.2.4. Operator 역할 및 정책 생성
HCP 클러스터와 함께 ROSA를 사용하는 경우 HCP(Hosted Control Planes) 배포에서 Red Hat OpenShift Service on AWS(ROSA)에 필요한 Operator IAM 역할을 생성해야 합니다. 클러스터 Operator는 Operator 역할을 사용하여 백엔드 스토리지, 클라우드 공급자 인증 정보 관리, 클러스터에 대한 외부 액세스와 같은 클러스터 작업을 수행하는 데 필요한 임시 권한을 얻습니다.
사전 요구 사항
- HCP를 사용하여 ROSA에 대한 AWS 사전 요구 사항을 완료했습니다.
-
설치 호스트에 AWS ROSA CLI(
rosa
)에 최신 Red Hat OpenShift Service를 설치하고 구성했습니다. - 계정 전체 AWS 역할을 생성하셨습니다.
절차
다음 명령을 사용하여 접두사 이름을 환경 변수로 설정합니다.
$ export OPERATOR_ROLES_PREFIX=<prefix_name>
Operator 역할을 생성하려면 다음 명령을 실행합니다.
$ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX --oidc-config-id=$OIDC_ID --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role
다음 분석에서는 Operator 역할 생성에 대한 옵션을 제공합니다.
$ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX 1 --oidc-config-id=$OIDC_ID 2 --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role 3
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>-HCP-ROSA-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.3. CLI를 사용하여 HCP 클러스터로 ROSA 생성
ROSA(Red Hat OpenShift Service on AWS) CLI인 rosa
를 사용하여 클러스터를 생성하는 경우 기본 옵션을 선택하여 클러스터를 빠르게 생성할 수 있습니다.
사전 요구 사항
- HCP를 사용하여 ROSA에 대한 AWS 사전 요구 사항을 완료했습니다.
- 사용 가능한 AWS 서비스 할당량이 있습니다.
- AWS 콘솔에서 ROSA 서비스를 활성화했습니다.
-
설치 호스트에 최신 ROSA CLI(
rosa
)를 설치하고 구성했습니다.rosa 버전을
실행하여 현재 설치된 ROSA CLI 버전을 확인합니다. 최신 버전을 사용할 수 있는 경우 CLI는 이 업그레이드를 다운로드할 수 있는 링크를 제공합니다. - ROSA CLI를 사용하여 Red Hat 계정에 로그인했습니다.
- OIDC 구성을 생성했습니다.
- AWS 계정에 ELB(Elastic Load Balancing) 서비스 역할이 있는지 확인했습니다.
절차
다음 명령 중 하나를 사용하여 HCP 클러스터로 ROSA를 생성합니다.
참고HCP 클러스터를 사용하여 ROSA를 생성할 때 기본 머신 Classless Inter-Domain Routing (CIDR)은
10.0.0.0/16
입니다. VPC 서브넷의 CIDR 범위에 해당하지 않는 경우 다음 명령에--machine-cidr <address_block
>을 추가합니다. AWS의 Red Hat OpenShift Service의 기본 CIDR 범위에 대한 자세한 내용은 CIDR 범위 정의를 참조하십시오.환경 변수를 설정하지 않은 경우 다음 명령을 실행합니다.
$ rosa create cluster --cluster-name=<cluster_name> \ <.> --mode=auto --hosted-cp [--private] \ <.> --operator-roles-prefix <operator-role-prefix> \ <.> --oidc-config-id <id-of-oidc-configuration> \ --subnet-ids=<public-subnet-id>,<private-subnet-id>
<.> 클러스터 이름을 지정합니다. 클러스터 이름이 15자보다 긴 경우 openshiftapps.com에서 프로비저닝된 클러스터의 하위 도메인으로 자동 생성된 도메인 접두사가 포함됩니다. 하위 도메인을 사용자 지정하려면
--domain-prefix
플래그를 사용합니다. 도메인 접두사는 15자를 초과할 수 없으며 고유해야 하며 클러스터 생성 후에는 변경할 수 없습니다. <.> 선택 사항: HCP 클러스터를 사용하여 개인 ROSA를 생성하는 데--private
인수가 사용됩니다. 이 인수를 사용하는 경우--subnet-ids
에 프라이빗 서브넷 ID만 사용해야 합니다. <.> 기본적으로 클러스터별 Operator 역할 이름 앞에는 클러스터 이름 및 임의의 4자리 해시가 추가됩니다. 선택 옵션으로 역할 이름에 <cluster_name>-<hash
>를 대체할 사용자 지정 접두사를 지정할 수 있습니다. 접두사는 클러스터별 Operator IAM 역할을 생성할 때 적용됩니다. 접두사에 대한 자세한 내용은 사용자 정의 Operator IAM 역할 접두사 정보를 참조하십시오.참고연결된 계정 전체 역할을 생성할 때 사용자 정의 ARN 경로를 지정한 경우 사용자 정의 경로가 자동으로 감지됩니다. 사용자 정의 경로는 이후 단계에서 생성할 때 클러스터별 Operator 역할에 적용됩니다.
환경 변수를 설정하는 경우 다음 명령을 실행하여 공개적으로 사용 가능한 API 및 공개적으로 사용 가능한 Ingress를 사용하여 단일 초기 머신 풀로 클러스터를 생성합니다.
$ rosa create cluster --private --cluster-name=<cluster_name> \ --mode=auto --hosted-cp --operator-roles-prefix=$OPERATOR_ROLES_PREFIX \ --oidc-config-id=$OIDC_ID --subnet-ids=$SUBNET_IDS
환경 변수를 설정하는 경우 다음 명령을 실행하여 단일 초기 머신 풀, 공개적으로 사용 가능한 API 및 공개적으로 사용 가능한 Ingress로 클러스터를 생성합니다.
$ rosa create cluster --cluster-name=<cluster_name> --mode=auto \ --hosted-cp --operator-roles-prefix=$OPERATOR_ROLES_PREFIX \ --oidc-config-id=$OIDC_CONFIG --subnet-ids=$SUBNET_IDS
다음 명령을 실행하여 클러스터 상태를 확인합니다.
$ 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 \ <.>
<.> 선택 사항: 설치가 진행되는 동안 새 로그 메시지를 조사하려면
--watch
인수를 사용합니다.
1.4. 다음 단계
1.5. 추가 리소스
- 수동 모드를 사용하여 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장. 사용자 정의 AWS KMS 암호화 키를 사용하여 HCP 클러스터로 ROSA 생성
사용자 지정 AWS KMS(Key Management Service) 키를 사용하여 호스팅되는 컨트롤 플레인(HCP) 클러스터를 사용하여 AWS(ROSA)에서 Red Hat OpenShift Service를 생성합니다.
2.1. HCP 사전 요구 사항이 있는 ROSA
HCP 클러스터를 사용하여 ROSA를 생성하려면 다음 항목이 있어야 합니다.
- 구성된 VPC(가상 프라이빗 클라우드)
- 계정 전체 역할
- OIDC 구성
- Operator 역할
2.1.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>
다음 명령을 실행하여 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는 다음 표에 표시된 요구 사항을 충족해야 합니다.
표 2.1. VPC에 대한 요구사항
요구 사항 | 세부 정보 |
---|---|
VPC 이름 | 클러스터를 생성할 때 특정 VPC 이름과 ID가 있어야합니다. |
CIDR 범위 | VPC CIDR 범위는 머신 CIDR과 일치해야 합니다. |
가용성 영역 | 단일 영역에 하나의 가용성 영역이 필요하며, 다중 영역의 가용성 영역인 경우 3개가 필요합니다. |
퍼블릭 서브넷 | 공용 클러스터에 대해 NAT 게이트웨이가 있는 퍼블릭 서브넷이 1개 있어야 합니다. 프라이빗 클러스터에는 퍼블릭 서브넷이 필요하지 않습니다. |
DNS 호스트 이름 및 확인 | DNS 호스트 이름 및 확인이 활성화되어 있는지 확인해야 합니다. |
2.1.2. 계정 전체 STS 역할 및 정책 생성
ROSA(Red Hat OpenShift Service on AWS) CLI(rosa
)를 사용하여 호스팅된 컨트롤 플레인(HCP) 클러스터가 있는 AWS(ROSA)에서 Red Hat OpenShift Service를 생성하기 전에 Operator 정책을 포함하여 필요한 계정 전체 역할 및 정책을 생성합니다.
HCP 클러스터를 사용하는 ROSA에는 AWS 관리 정책이 연결된 계정 및 Operator 역할이 필요합니다. 고객 관리 정책은 지원되지 않습니다. HCP 클러스터의 ROSA 관리 정책에 대한 자세한 내용은 ROSA 계정 역할에 대한 AWS 관리 정책을 참조하십시오.
사전 요구 사항
- HCP를 사용하여 ROSA에 대한 AWS 사전 요구 사항을 완료했습니다.
- 사용 가능한 AWS 서비스 할당량이 있습니다.
- AWS 콘솔에서 ROSA 서비스를 활성화했습니다.
-
설치 호스트에 최신 ROSA CLI(
rosa
)를 설치하고 구성했습니다. - ROSA CLI를 사용하여 Red Hat 계정에 로그인했습니다.
절차
AWS 계정에 없는 경우 필요한 계정 전체 STS 역할을 생성하고 다음 명령을 실행하여 정책을 연결합니다.
$ rosa create account-roles --hosted-cp
선택 사항: 다음 명령을 실행하여 접두사를 환경 변수로 설정합니다.
$ export ACCOUNT_ROLES_PREFIX=<account_role_prefix>
다음 명령을 실행하여 변수 값을 확인합니다.
$ echo $ACCOUNT_ROLES_PREFIX
출력 예
ManagedOpenShift
ROSA의 AWS 관리 IAM 정책에 대한 자세한 내용은 ROSA의 AWS 관리 IAM 정책을 참조하십시오.
2.1.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 수동
에 대한aws
CLI 출력에 따라 이러한 값을 결정해야합니다.선택 사항: 나중에 사용할 수 있도록 OIDC 구성 ID를 변수로 저장할 수 있습니다. 다음 명령을 실행하여 변수를 저장합니다.
$ export OIDC_ID=<oidc_config_id>1
- 1
- 위의 출력 예에서 OIDC 구성 ID는 13cdr6b입니다.
다음 명령을 실행하여 변수 값을 확인합니다.
$ echo $OIDC_ID
출력 예
13cdr6b
검증
사용자 조직과 연결된 클러스터에 사용 가능한 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
2.1.4. Operator 역할 및 정책 생성
HCP 클러스터와 함께 ROSA를 사용하는 경우 HCP(Hosted Control Planes) 배포에서 Red Hat OpenShift Service on AWS(ROSA)에 필요한 Operator IAM 역할을 생성해야 합니다. 클러스터 Operator는 Operator 역할을 사용하여 백엔드 스토리지, 클라우드 공급자 인증 정보 관리, 클러스터에 대한 외부 액세스와 같은 클러스터 작업을 수행하는 데 필요한 임시 권한을 얻습니다.
사전 요구 사항
- HCP를 사용하여 ROSA에 대한 AWS 사전 요구 사항을 완료했습니다.
-
설치 호스트에 AWS ROSA CLI(
rosa
)에 최신 Red Hat OpenShift Service를 설치하고 구성했습니다. - 계정 전체 AWS 역할을 생성하셨습니다.
절차
다음 명령을 사용하여 접두사 이름을 환경 변수로 설정합니다.
$ export OPERATOR_ROLES_PREFIX=<prefix_name>
Operator 역할을 생성하려면 다음 명령을 실행합니다.
$ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX --oidc-config-id=$OIDC_ID --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role
다음 분석에서는 Operator 역할 생성에 대한 옵션을 제공합니다.
$ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX 1 --oidc-config-id=$OIDC_ID 2 --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role 3
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>-HCP-ROSA-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 계정과 연결된 모든 접두사를 표시하고 이 접두사와 연결된 역할 수를 기록합니다. 이러한 역할과 세부 정보를 모두 확인해야 하는 경우 세부 정보 프롬프트에 이러한 역할을 나열하도록 "예"를 입력합니다.
2.1.5. 사용자 정의 AWS KMS 키를 사용하여 ROSA 클러스터 생성
노드 루트 볼륨, etcd 데이터베이스 또는 둘 다를 암호화하는 데 사용되는 고객 제공 KMS 키를 사용하여 AWS (ROSA) 클러스터에서 Red Hat OpenShift Service를 생성할 수 있습니다. 각 옵션에 대해 다른 KMS 키 ARN을 제공할 수 있습니다.
HCP를 사용하는 ROSA는 고객 제공 KMS 키로 영구 볼륨을 암호화하도록 기본
스토리지 클래스를 자동으로 구성하지 않습니다. 이는 설치 후 클러스터 내에서 구성할 수 있는 것입니다.
절차
다음 명령을 실행하여 사용자 정의 AWS 고객 관리 KMS 키를 생성합니다.
$ KMS_ARN=$(aws kms create-key --region $AWS_REGION --description 'Custom ROSA Encryption Key' --tags TagKey=red-hat,TagValue=true --query KeyMetadata.Arn --output text)
이 명령은 추가 단계를 위해 이 사용자 지정 키의 Amazon 리소스 이름(ARN) 출력을 저장합니다.
참고고객은 고객 KMS 키에 필요한
--tags TagKey=red-hat,TagValue=true
인수를 제공해야 합니다.다음 명령을 실행하여 KMS 키가 생성되었는지 확인합니다.
$ echo $KMS_ARN
AWS 계정 ID를 환경 변수로 설정합니다.
$ AWS_ACCOUNT_ID=<aws_account_id>
이전 단계에서 생성한 계정 전체 설치 관리자 역할 및 Operator 역할의 ARN을 파일의
Statement.Principal.AWS
섹션에 추가합니다. 다음 예에서는 기본ManagedOpenShift-HCP-ROSA-Installer-Role
역할에 대한 ARN이 추가되었습니다.{ "Version": "2012-10-17", "Id": "key-rosa-policy-1", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Installer Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/ManagedOpenShift-HCP-ROSA-Installer-Role" }, "Action": [ "kms:CreateGrant", "kms:DescribeKey", "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": "*" }, { "Sid": "ROSA KubeControllerManager Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/<operator_role_prefix>-kube-system-kube-controller-manager" }, "Action": "kms:DescribeKey", "Resource": "*" }, { "Sid": "ROSA KMS Provider Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/<operator_role_prefix>-kube-system-kms-provider" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" }, { "Sid": "ROSA NodeManager Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/<operator_role_prefix>-kube-system-capa-controller-manager" }, "Action": [ "kms:DescribeKey", "kms:GenerateDataKeyWithoutPlaintext", "kms:CreateGrant" ], "Resource": "*" } ] }
다음 명령을 실행하여 생성된 정책 파일의 세부 정보를 확인합니다.
$ cat rosa-key-policy.json
다음 명령을 실행하여 새로 생성된 키 정책을 사용자 정의 KMS 키에 적용합니다.
$ aws kms put-key-policy --key-id $KMS_ARN \ --policy file://rosa-key-policy.json \ --policy-name default
다음 명령을 실행하여 클러스터를 생성합니다.
참고클러스터 이름이 15자보다 긴 경우
*.openshiftapps.com
에서 프로비저닝된 클러스터의 하위 도메인으로 자동 생성된 도메인 접두사가 포함됩니다.하위 도메인을 사용자 지정하려면
--domain-prefix
플래그를 사용합니다. 도메인 접두사는 15자를 초과할 수 없으며 고유해야 하며 클러스터 생성 후에는 변경할 수 없습니다.$ rosa create cluster --cluster-name <cluster_name> \ --subnet-ids <private_subnet_id>,<public_subnet_id> \ --sts \ --mode auto \ --machine-cidr 10.0.0.0/16 \ --compute-machine-type m5.xlarge \ --hosted-cp \ --region <aws_region> \ --oidc-config-id $OIDC_ID \ --kms-key-arn $KMS_ARN \ 1 --etcd-encryption-kms-arn $KMS_ARN \ 2 --operator-roles-prefix $OPERATOR_ROLES_PREFIX
검증
OpenShift Cluster Manager 를 사용하여 KMS 키가 작동하는지 확인할 수 있습니다.
- OpenShift Cluster Manager 로 이동하여 인스턴스를 선택합니다.
- 인스턴스를 선택합니다.
- 스토리지 탭을 클릭합니다.
- KMS 키 ID 를 복사합니다.
- 키 관리 서비스를 검색하고 선택합니다.
- 필터 필드에 복사된 KMS 키 ID 를 입력합니다.
2.2. 다음 단계
2.3. 추가 리소스
- CLI를 사용하여 클러스터를 생성하는 방법에 대한 자세한 내용은 CLI를 사용하여 HCP 클러스터로 ROSA 생성을 참조하십시오.
- 수동 모드를 사용하여 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 공급자를 사용하는 방법에 대한 자세한 내용은 OIDC( OpenID Connect) ID 공급자 생성 을 참조하십시오.
- ROSA 클러스터 설치 문제 해결에 대한 자세한 내용은 설치 문제 해결을 참조하십시오.
- Red Hat 지원에 문의하려면 AWS에서 Red Hat OpenShift Service에 대한 지원 받기를 참조하십시오.
3장. HCP를 사용하여 ROSA에 개인 클러스터 생성
이 문서에서는 호스팅되는 컨트롤 플레인(HCP) 프라이빗 클러스터를 사용하여 AWS(ROSA)에서 Red Hat OpenShift Service를 생성하는 방법을 설명합니다.
3.1. AWS 프라이빗 클러스터 생성
ROSA CLI(명령줄 인터페이스)를 사용하여 ROSA에 여러 가용 영역(Multi-AZ)이 있는 프라이빗 클러스터를 생성할 수 있습니다
.
사전 요구 사항
- 사용 가능한 AWS 서비스 할당량이 있습니다.
- AWS 콘솔에서 ROSA 서비스를 활성화했습니다.
- 설치 호스트에 ROSA CLI의 최신 버전을 설치하고 구성했습니다.
절차
호스팅된 컨트롤 플레인을 사용하여 클러스터를 생성하는 데 약 10분이 걸릴 수 있습니다.
프라이빗 서브넷이 하나 이상 있는 VPC를 생성합니다. 시스템의 클래스리스 도메인 간 라우팅(CIDR)이 가상 프라이빗 클라우드의 CIDR과 일치하는지 확인합니다. 자세한 내용은 자체 VPC 및 VPC 유효성 검사 사용에 대한 요구 사항을 참조하십시오.
중요방화벽을 사용하는 경우 ROSA가 작동하는 데 필요한 사이트에 액세스할 수 있도록 방화벽을 구성해야 합니다.
자세한 내용은 "AWS PrivateLink 방화벽 사전 요구 사항" 섹션을 참조하십시오.
다음 명령을 실행하여 계정 전체 IAM 역할을 생성합니다.
$ rosa create account-roles --hosted-cp
다음 명령을 실행하여 OIDC 구성을 생성합니다.
$ rosa create oidc-config --mode=auto --yes
Operator 역할을 생성하는 데 필요하므로 OIDC 구성 ID를 저장합니다.
출력 예
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 28s4avcdt2l318r1jbk3ifmimkurk384 If you are going to create a Hosted Control Plane cluster please include '--hosted-cp' I: Creating OIDC provider using 'arn:aws:iam::46545644412:user/user' I: Created OIDC provider with ARN 'arn:aws:iam::46545644412:oidc-provider/oidc.op1.openshiftapps.com/28s4avcdt2l318r1jbk3ifmimkurk384'
다음 명령을 실행하여 Operator 역할을 생성합니다.
$ rosa create operator-roles --hosted-cp --prefix <operator_roles_prefix> --oidc-config-id <oidc_config_id> --installer-role-arn arn:aws:iam::$<account_roles_prefix>:role/$<account_roles_prefix>-HCP-ROSA-Installer-Role
다음 명령을 실행하여 HCP 클러스터를 사용하여 개인 ROSA를 생성합니다.
$ rosa create cluster --private --cluster-name=<cluster-name> --sts --mode=auto --hosted-cp --operator-roles-prefix <operator_role_prefix> --oidc-config-id <oidc_config_id> [--machine-cidr=<VPC CIDR>/16] --subnet-ids=<private-subnet-id1>[,<private-subnet-id2>,<private-subnet-id3>]
다음 명령을 입력하여 클러스터 상태를 확인합니다. 클러스터 생성 중에 출력의
State
필드가보류
중에서설치
로 전환되고 마지막으로ready
로 전환됩니다.$ rosa describe cluster --cluster=<cluster_name>
참고설치에 실패하거나
State
필드가 10분 후에준비
되도록 변경되지 않는 경우 추가 리소스 섹션의 "Red Hat OpenShift Service on AWS 설치 관련 문제 해결" 설명서를 참조하십시오.다음 명령을 입력하여 OpenShift 설치 프로그램 로그를 따라 클러스터의 진행 상황을 추적합니다.
$ rosa logs install --cluster=<cluster_name> --watch
3.2. API에 액세스하도록 AWS 보안 그룹 구성
HCP 프라이빗 클러스터를 사용하는 ROSA를 사용하면 고객의 VPC에 노출되는 AWS PrivateLink 끝점에 기본 보안 그룹이 있습니다. 이 보안 그룹은 VPC 또는 VPC CIDR 범위와 연결된 IP 주소가 있는 리소스 내에만 존재하는 PrivateLink 엔드포인트에 액세스할 수 있습니다. VPC 피어 및 전송 게이트웨이를 통해 VPC 외부의 모든 엔터티에 대한 액세스 권한을 부여하려면 다른 보안 그룹을 생성하고 PrivateLink 엔드포인트에 연결하여 필요한 액세스 권한을 부여해야 합니다.
사전 요구 사항
- 회사 네트워크 또는 기타 VPC가 연결되어 있습니다.
- VPC 내에서 보안 그룹을 생성하고 연결할 수 있는 권한이 있습니다.
절차
다음 명령을 실행하여 클러스터 이름을 환경 변수로 설정합니다.
$ export CLUSTER_NAME=<cluster_name>
다음 명령을 실행하여 변수가 설정되었는지 확인할 수 있습니다.
$ echo $CLUSTER_NAME
출력 예
hcp-private
다음 명령을 실행하여 VPC 끝점(VPCE) ID 및 VPC ID를 찾습니다.
$ read -r VPCE_ID VPC_ID <<< $(aws ec2 describe-vpc-endpoints --filters "Name=tag:api.openshift.com/id,Values=$(rosa describe cluster -c ${CLUSTER_NAME} -o yaml | grep '^id: ' | cut -d' ' -f2)" --query 'VpcEndpoints[].[VpcEndpointId,VpcId]' --output text)
다음 명령을 실행하여 보안 그룹을 생성합니다.
$ export SG_ID=$(aws ec2 create-security-group --description "Granting API access to ${CLUSTER_NAME} from outside of VPC" --group-name "${CLUSTER_NAME}-api-sg" --vpc-id $VPC_ID --output text)
다음 명령을 실행하여 보안 그룹에 수신 규칙을 추가합니다.
$ aws ec2 authorize-security-group-ingress --group-id $SG_ID --ip-permissions FromPort=443,ToPort=443,IpProtocol=tcp,IpRanges=[{CidrIp=0.0.0.0/0}]
다음 명령을 실행하여 VPCE에 새 보안 그룹을 추가합니다.
$ aws ec2 modify-vpc-endpoint --vpc-endpoint-id $VPCE_ID --add-security-group-ids $SG_ID
이제 HCP 프라이빗 클러스터를 사용하여 ROSA를 사용하여 API에 액세스할 수 있습니다.
3.3. 다음 단계
3.4. 추가 리소스
4장. 외부 인증을 사용하여 HCP 클러스터를 사용하여 ROSA 생성
외부 인증을 사용하여 액세스 토큰을 발행하는 호스팅된 컨트롤 플레인(HCP) 클러스터를 사용하여 AWS(ROSA)에서 Red Hat OpenShift Service를 생성할 수 있습니다.
기존 ROSA 클러스터를 호스팅된 컨트롤 플레인 아키텍처로 업그레이드하거나 변환할 수 없으므로 HCP 기능과 함께 ROSA를 사용할 새 클러스터를 생성해야 합니다. 또한 외부 인증 공급자를 사용하여 내부 OAuth2 서버를 사용하도록 생성된 클러스터를 변환할 수 없습니다. 또한 새 클러스터를 생성해야 합니다.
HCP 클러스터가 있는 ROSA는 STS(Security Token Service) 인증만 지원합니다.
추가 읽기
- ROSA와 HCP 및 ROSA Classic의 비교는 Comparing architecture models 문서를 참조하십시오.
- ROSA CLI를 자동 모드에서 사용하여 HCP로 ROSA 시작하기에 대한 자세한 내용은 AWS 설명서를 참조하십시오.
추가 리소스
지원되는 인증서의 전체 목록은 "AWS에서 Red Hat OpenShift Service에 대한 이해 프로세스 및 보안"의 규정 준수 섹션을 참조하십시오.
4.1. HCP 사전 요구 사항이 있는 ROSA
HCP 클러스터를 사용하여 ROSA를 생성하려면 다음 단계를 완료해야 합니다.
4.2. 외부 인증 공급자를 사용하는 HCP 클러스터를 사용하여 ROSA 생성
ROSA CLI에서 --external-auth-providers-enabled
플래그를 사용하여 외부 인증 서비스를 사용하는 클러스터를 생성합니다.
HCP 클러스터를 사용하여 ROSA를 생성할 때 기본 머신 Classless Inter-Domain Routing (CIDR)은 10.0.0.0/16
입니다. VPC 서브넷의 CIDR 범위에 해당하지 않는 경우 다음 명령에 --machine-cidr <address_block
>을 추가합니다.
절차
OIDC_ID
,SUBNET_IDS
,OPERATOR_ROLES_PREFIX
변수를 사용하여 환경을 준비한 경우 클러스터를 생성할 때 해당 변수를 계속 사용할 수 있습니다. 예를 들어 다음 명령을 실행합니다.$ rosa create cluster --hosted-cp --subnet-ids=$SUBNET_IDS \ --oidc-config-id=$OIDC_ID --cluster-name=<cluster_name> \ --operator-roles-prefix=$OPERATOR_ROLES_PREFIX \ --external-auth-providers-enabled
환경 변수를 설정하지 않은 경우 다음 명령을 실행합니다.
$ 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> \ --external-auth-providers-enabled \ --subnet-ids=<public-subnet-id>,<private-subnet-id>
검증
다음 명령을 실행하여 클러스터 세부 정보에 외부 인증이 활성화되어 있는지 확인합니다.
$ rosa describe cluster --cluster=<cluster_name>
Name: rosa-ext-test Display Name: rosa-ext-test ID: <cluster_id> External ID: <cluster_ext_id> Control Plane: ROSA Service Hosted OpenShift Version: 4.15.3 Channel Group: stable DNS: <dns> AWS Account: <AWS_id> AWS Billing Account: <AWS_id> API URL: <ocm_api> Console URL: Region: us-east-1 Availability: - Control Plane: MultiAZ - Data Plane: SingleAZ Nodes: - Compute (desired): 2 - Compute (current): 0 Network: - Type: OVNKubernetes - Service CIDR: <service_cidr> - Machine CIDR: <machine_cidr> - Pod CIDR: <pod_cidr> - Host Prefix: /23 - Subnets: <subnet_ids> EC2 Metadata Http Tokens: optional Role (STS) ARN: arn:aws:iam::<AWS_id>:role/<account_roles_prefix>-HCP-ROSA-Installer-Role Support Role ARN: arn:aws:iam::<AWS_id>:role/<account_roles_prefix>-HCP-ROSA-Support-Role Instance IAM Roles: - Worker: arn:aws:iam::<AWS_id>:role/<account_roles_prefix>-HCP-ROSA-Worker-Role Operator IAM Roles: - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-cloud-network-config-controller-clo - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-capa-controller-manager - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-control-plane-operator - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-kms-provider - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-kube-controller-manager - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-image-registry-installer-cloud-cred - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-ingress-operator-cloud-credentials - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-cluster-csi-drivers-ebs-cloud-crede Managed Policies: Yes State: ready Private: No Created: Mar 29 2024 14:25:52 UTC User Workload Monitoring: Enabled Details Page: https://<url> OIDC Endpoint URL: https://<endpoint> (Managed) Audit Log Forwarding: Disabled External Authentication: Enabled 1
- 1
외부 인증
플래그가 활성화되어 있으며 이제 외부 인증 공급자를 생성할 수 있습니다.
4.3. 외부 인증 공급자 생성
외부 인증 공급자에 대해 활성화된 옵션을 사용하여 HCP 클러스터가 있는 ROSA를 생성한 후에는 ROSA CLI를 사용하여 공급자를 생성해야 합니다.
ROSA CLI에서 rosa create|delete|list idp[s]
명령과 유사하게 rosa create external-auth-provider
를 사용하여 생성한 기존 ID 공급자를 편집할 수 없습니다. 대신 외부 인증 공급자를 삭제하고 새 공급자를 생성해야 합니다.
다음 표는 외부 인증 공급자를 생성할 때 사용할 수 있는 CLI 플래그를 보여줍니다.
CLI Flag | 설명 |
---|---|
| 클러스터의 이름 또는 ID입니다. |
| 외부 인증 공급자를 참조하는 데 사용되는 이름입니다. |
| 이 문자열은 계정을 애플리케이션과 연결하는 데 사용되는 클라이언트 시크릿입니다. 클라이언트 시크릿을 포함하지 않으면 이 명령에서 공용 OIDC OAuthClient를 사용합니다. |
| 쉼표로 구분된 토큰 대상 목록입니다. |
| 토큰 발행자의 URL입니다. |
| 클러스터 ID의 사용자 이름을 구성하는 데 사용해야 하는 클레임의 이름입니다. |
| 클러스터 ID에 대한 그룹 이름을 구성하는 데 사용해야 하는 클레임의 이름입니다. |
절차
대화형 명령 인터페이스를 사용하려면 다음 명령을 실행합니다.
$ rosa create external-auth-provider -c <cluster_name>
I: Enabling interactive mode ? Name: 1 ? Issuer audiences: 2 ? The serving url of the token issuer: 3 ? CA file path (optional): 4 ? Claim mapping username: 5 ? Claim mapping groups: 6 ? Claim validation rule (optional): 7 ? Console client id (optional): 8
- 1
- 외부 인증 공급자의 이름입니다. 이 이름은 숫자와 대시가 있는 소문자여야 합니다.
- 2
- 이 인증 공급자가 토큰을 발행하는 대상 ID입니다.
- 3
- 토큰을 제공하는 발행자의 URL입니다.
- 4
- 선택 사항: 요청을 수행할 때 사용할 인증서 파일입니다.
- 5
이메일
사용과 같이 클러스터 ID의 사용자 이름을 구성하는 데 사용되는 클레임의 이름입니다.- 6
- ID 토큰을 클러스터 ID로 변환하는 방법(예:
그룹
사용 ). - 7
- 선택 사항: 사용자를 인증하는 토큰 클레임을 확인하는 데 도움이 되는 규칙입니다. 이 필드는
:<required_value> 형식으로 포맷해야 합니다
. - 8
- 선택 사항: 앱 등록에서 콘솔에 사용하는 애플리케이션 또는 클라이언트 ID입니다.
다음 명령을 사용하여 외부 인증 공급자를 생성하는 데 필요한 ID를 포함할 수 있습니다.
rosa create external-auth-provider --cluster=<cluster_id> \ --name=<provider_name> --issuer-url=<issuing_url> \ --issuer-audiences=<audience_id> \ --claim-mapping-username-claim=email \ --claim-mapping-groups-claim=groups \ --console-client-id=<client_id_for_app_registration> \ --console-client-secret=<client_secret>
출력 예
I: Successfully created an external authentication provider for cluster '<cluster_id>'
검증
외부 인증 공급자를 확인하려면 다음 옵션 중 하나를 실행합니다.
다음 명령을 사용하여 지정된 클러스터의 외부 인증 구성을 나열합니다.
$ rosa list external-auth-provider -c <cluster_name>
출력 예
다음 예제에서는 구성된 Microsoft Entra ID 외부 인증 공급자를 보여줍니다.
NAME ISSUER URL m-entra-id https://login.microsoftonline.com/<group_id>/v2.0
다음 명령을 사용하여 지정된 클러스터의 외부 인증 구성을 표시합니다.
$ rosa describe external-auth-provider \ -c <cluster_name> --name <name_of_external_authentication>
출력 예
ID: ms-entra-id Cluster ID: <cluster_id> Issuer audiences: - <audience_id> Issuer Url: https://login.microsoftonline.com/<group_id>/v2.0 Claim mappings group: groups Claim mappings username: email
추가 리소스
- IDP에 대한 Entra ID 구성에 대한 자세한 내용은 Azure 문서의 What is Microsoft Entra ID? 또는 The Configuring Microsoft Entra ID (이전 Azure Active Directory) as an identity provider tutorial section을 참조하십시오.
-
ROSA CLI의 유사한
idps
툴에 대한 자세한 내용은create idp
를 참조하십시오. -
ROSA CLI의 옵션에 대한 자세한 내용은
create external-auth-provider
,list external-auth-provider
,external-auth-provider 삭제
를 참조하십시오.
4.4. HCP 클러스터를 사용하여 ROSA에 대한 break glass 인증 정보 생성
HCP 클러스터 소유자가 있는 ROSA는 break glass 인증 정보를 사용하여 임시 관리 클라이언트 인증 정보를 생성하여 사용자 정의 OpenID Connect(OIDC) 토큰 발행자로 구성된 클러스터에 액세스할 수 있습니다. break glass 인증 정보를 생성하면 새 cluster-admin kubeconfig
파일이 생성됩니다. kubeconfig
파일에는 CLI에서 클라이언트를 올바른 클러스터 및 API 서버에 연결하는 데 사용하는 클러스터에 대한 정보가 포함되어 있습니다. 새로 생성된 kubeconfig
파일을 사용하여 HCP 클러스터에서 ROSA에 대한 액세스를 허용할 수 있습니다.
사전 요구 사항
- 외부 인증이 활성화된 HCP 클러스터가 있는 ROSA를 생성했습니다. 자세한 내용은 외부 인증 공급자를 사용하는 HCP 클러스터를 사용하여 ROSA 생성 을 참조하십시오.
- 외부 인증 공급자를 생성했습니다. 자세한 내용은 외부 인증 공급자 생성을 참조하십시오.
-
클러스터 관리자
권한이 있는 계정이 있어야 합니다.
절차
다음 명령 중 하나를 사용하여 break glass 인증 정보를 생성합니다.
대화형 명령 인터페이스를 사용하여 사용자 지정 설정을 대화식으로 지정하여 break glass 인증 정보를 생성하려면 다음 명령을 실행합니다.
$ rosa create break-glass-credential -c <cluster_name> -i 1
- 1
- <cluster_name>을 클러스터 이름으로 바꿉니다.
이 명령은 대화형 CLI 프로세스를 시작합니다.
출력 예
I: Enabling interactive mode ? Username (optional): 1 ? Expiration duration (optional): 2 I: Successfully created a break glass credential for cluster 'ac-hcp-test'.
지정된 값이 있는
mycluster
라는 클러스터에 대한 중단 유리 인증 정보를 생성하려면 다음을 수행합니다.$ rosa create break-glass-credential -c mycluster --username test-username --expiration 1h
다음 명령을 실행하여
mycluster
라는 클러스터에 사용할 수 있는 break glass 인증 정보 ID, 상태 및 관련 사용자를 나열합니다.$ rosa list break-glass-credential -c mycluster
출력 예
ID USERNAME STATUS 2a7jli9n4phe6c02ul7ti91djtv2o51d test-user issued
참고명령에
-o json
인수를 추가하여 JSON 출력에서 인증 정보를 볼 수도 있습니다.break glass 인증 정보의 상태를 보려면 다음 명령을 실행하여 <break_glass_credential_id>를 break glass 인증 정보 ID로 바꿉니다.
$ rosa describe break-glass-credential <break_glass_credential_id> -c <cluster_name>
출력 예
ID: 2a7jli9n4phe6c02ul7ti91djtv2o51d Username: test-user Expire at: Dec 28 2026 10:23:05 EDT Status: issued
다음은 사용 가능한
Status
필드 값 목록입니다.-
유리 인증 정보가 발행되었으며 사용할 준비가 되어 있습니다.
-
expired
off glass 인증 정보가 만료되었으며 더 이상 사용할 수 없습니다. -
break glass 인증 정보를 생성하지 못했습니다.
이 경우 실패를 자세히 설명하는 서비스 로그가 표시됩니다. 서비스 로그에 대한 자세한 내용은 AWS 클러스터에서 Red Hat OpenShift Service의 서비스 로그 액세스를 참조하십시오. Red Hat 지원에 문의하려면 지원 받기를 참조하십시오.
-
awaiting_revocation
break glass 인증 정보는 현재 취소되고 있습니다. 즉, 사용할 수 없습니다. -
유리 인증 정보가 취소되어 더 이상 사용할 수 없습니다.
-
유리 인증 정보가 발행되었으며 사용할 준비가 되어 있습니다.
kubeconfig
를 검색하려면 다음 명령을 실행합니다.kubeconfig 디렉터리를
생성합니다.$ mkdir ~/kubeconfigs
새로 생성된
kubeconfig
파일을 내보내 <cluster_name>을 클러스터 이름으로 교체합니다.$ export CLUSTER_NAME=<cluster_name> && export KUBECONFIG=~/kubeconfigs/break-glass-${CLUSTER_NAME}.kubeconfig
kubeconfig
를 확인합니다.$ rosa describe break-glass-credential <break_glass_credential_id> -c mycluster --kubeconfig
출력 예
apiVersion: v1 clusters: - cluster: server: <server_url> name: cluster contexts: - context: cluster: cluster namespace: default user: test-username name: admin current-context: admin kind: Config preferences: {} users: - name: test-user user: client-certificate-data: <client-certificate-data> 1 client-key-data: <client-key-data> 2
선택 사항:
kubeconfig
를 저장하려면 다음 명령을 실행합니다.$ rosa describe break-glass-credential <break_glass_credential_id> -c mycluster --kubeconfig > $KUBECONFIG
추가 리소스
- 외부 인증이 활성화된 HCP 클러스터를 사용하여 ROSA를 생성하는 방법에 대한 자세한 내용은 외부 인증 공급자를 사용하는 HCP 클러스터를 사용하여 ROSA 생성 을 참조하십시오.
- CLI 구성에 대한 자세한 내용은 CLI 프로필 관리를 참조하십시오.
4.5. 유리 인증 정보를 사용하여 HCP 클러스터로 ROSA에 액세스
break glass 인증 정보의 새 kubeconfig
를 사용하여 HCP 클러스터의 ROSA에 대한 임시 관리자 액세스 권한을 얻습니다.
사전 요구 사항
- 외부 인증이 활성화된 HCP 클러스터를 사용하여 ROSA에 액세스할 수 있습니다. 자세한 내용은 외부 인증 공급자를 사용하는 HCP 클러스터를 사용하여 ROSA 생성 을 참조하십시오.
-
oc
및kubectl
CLI를 설치했습니다. -
새
kubeconfig
를 구성했습니다. 자세한 내용은 HCP 클러스터를 사용하여 ROSA에 대한 break glass 인증 정보 생성을 참조하십시오.
절차
클러스터 세부 정보에 액세스합니다.
$ rosa describe break-glass-credential <break_glass_credential_id> -c <cluster_name> --kubeconfig > $KUBECONFIG
클러스터의 노드를 나열합니다.
$ oc get nodes
출력 예
NAME STATUS ROLES AGE VERSION ip-10-0-0-27.ec2.internal Ready worker 8m v1.28.7+f1b5f6c ip-10-0-0-67.ec2.internal Ready worker 9m v1.28.7+f1b5f6c
올바른 인증 정보가 있는지 확인합니다.
$ kubectl auth whoami
출력 예
ATTRIBUTE VALUE Username system:customer-break-glass:test-user Groups [system:masters system:authenticated]
외부 OIDC 공급자에 정의된 그룹에 대해
ClusterRoleBinding
을 적용합니다.ClusterRoleBinding
은 Microsoft Entra ID에서 생성된rosa-hcp-admins
그룹을 HCP 클러스터의 ROSA의 그룹에 매핑합니다.$ oc apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: rosa-hcp-admins roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: f715c264-ab90-45d5-8a29-2e91a609a895 EOF
출력 예
clusterrolebinding.rbac.authorization.k8s.io/rosa-hcp-admins created
참고ClusterRoleBinding
이 적용되면 HCP 클러스터가 포함된 ROSA가 구성되고rosa
CLI 및 Red Hat Hybrid Cloud Console 은 외부 OpenID Connect(OIDC) 공급자를 통해 인증됩니다. 이제 클러스터에 역할 할당 및 애플리케이션을 배포할 수 있습니다.
추가 리소스
- 클러스터 역할 바인딩에 대한 자세한 내용은 RBAC를 사용하여 권한 정의 및 적용을 참조하십시오.
4.6. HCP 클러스터를 사용하여 ROSA에 대한 중단 유리 인증 정보 취소
revoke break-glass-credentials
명령을 사용하여 언제든지 프로비저닝한 모든 중단 유리 인증 정보에 대한 액세스를 취소할 수 있습니다.
사전 요구 사항
- 유리 인증 정보를 생성했습니다.
- 클러스터 소유자입니다.
절차
다음 명령을 실행하여 HCP 클러스터를 사용하여 ROSA의 중단 유리 인증 정보를 취소합니다.
중요이 명령을 실행하면 클러스터와 관련된 모든 중단 유리 인증 정보에 대한 액세스 권한이 취소됩니다.
$ rosa revoke break-glass-credentials -c <cluster_name> 1
- 1
- <cluster_name>을 클러스터 이름으로 바꿉니다.
출력 예
? Are you sure you want to revoke all the break glass credentials on cluster 'my-cluster'?: Yes I: Successfully requested revocation for all break glass credentials from cluster 'my-cluster'
검증
취소 프로세스는 몇 분 정도 걸릴 수 있습니다. 다음 명령 중 하나를 실행하여 클러스터의 break glass 인증 정보가 취소되었는지 확인할 수 있습니다.
모든 break glass 인증 정보를 나열하고 각 인증 정보의 상태를 확인합니다.
$ rosa list break-glass-credential -c <cluster_name>
출력 예
ID USERNAME STATUS 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 test-user awaiting_revocation
개별 인증 정보를 확인하여 상태를 확인할 수도 있습니다.
$ rosa describe break-glass-credential <break_glass_credential_id> -c <cluster_name>
출력 예
ID: 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 Username: test-user Expire at: Dec 28 2026 10:23:05 EDT Status: issued Revoked at: Dec 27 2026 15:30:33 EDT
4.7. 외부 인증 공급자 삭제
ROSA CLI를 사용하여 외부 인증 공급자를 삭제합니다.
절차
다음 명령을 실행하여 클러스터에 외부 인증 공급자를 표시합니다.
$ rosa list external-auth-provider -c <cluster_name>
출력 예
NAME ISSUER URL entra-test https://login.microsoftonline.com/<group_id>/v2.0
다음 명령을 실행하여 외부 인증 공급자를 삭제합니다.
$ rosa delete external-auth-provider <name_of_provider> -c <cluster_name>
출력 예
? Are you sure you want to delete external authentication provider entra-test on cluster rosa-ext-test? Yes I: Successfully deleted external authentication provider 'entra-test' from cluster 'rosa-ext-test'
검증
다음 명령을 실행하여 클러스터의 외부 인증 공급자를 쿼리합니다.
$ rosa list external-auth-provider -c <cluster_name>
출력 예
E: there are no external authentication providers for this cluster
4.8. 추가 리소스
- 수동 모드를 사용하여 ROSA 클러스터를 배포하는 단계는 사용자 지정을 사용하여 클러스터 생성을 참조하십시오.
- STS를 사용하여 AWS에 Red Hat OpenShift Service를 배포하는 데 필요한 IAM(Identity Access Management) 리소스에 대한 자세한 내용은 STS를 사용하는 클러스터의 IAM 리소스 정보를 참조하십시오.
- AWS의 Red Hat OpenShift Service의 기본 CIDR 범위에 대한 자세한 내용은 CIDR 범위 정의를 참조하십시오.
- 필요한 경우 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에 대한 지원 받기를 참조하십시오.
5장. HCP 클러스터에서 ROSA에서 Node Tuning Operator 사용
HCP(Host Control Planes)가 있는 ROSA(Red Hat OpenShift Service on AWS)는 Node Tuning Operator를 지원하여 HCP 클러스터가 있는 ROSA에서 노드의 성능을 향상시킵니다. 노드 튜닝 구성을 생성하기 전에 사용자 정의 튜닝 사양을 생성해야 합니다.
목적
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가 활성화된 경우 성능 프로필에서 원하는 동작을 얻지 못할 수 있습니다. 성능 프로필을 사용하는 경우에는 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의 일부입니다.
5.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 }, "match": [ 3 { "label": <label_information> 4 }, ] }, ] }
<match>
는 다음과 같이 재귀적으로 정의되는 선택사항 목록입니다.
"match": [
{
"label": 1
},
]
- 1
- 노드 또는 Pod 라벨 이름입니다.
<match>
를 생략하지 않으면 모든 중첩 <match>
섹션도 true
로 평가되어야 합니다. 생략하면 false
로 가정하고 해당 <match>
섹션이 있는 프로필을 적용하지 않거나 권장하지 않습니다. 따라서 중첩(하위 <match>
섹션)은 논리 AND 연산자 역할을 합니다. 반대로 <match>
목록의 항목이 일치하면 전체 <match>
목록이 true
로 평가됩니다. 따라서 이 목록이 논리 OR 연산자 역할을 합니다.
예: 노드 또는 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": [ { "priority": 20, "profile": "openshift-node-custom" } ] } }
클라우드 공급자별 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
프로필 및 해당 하위 프로필로 덮어씁니다.
5.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" } ] } } ]
5.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" } ] }
5.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'
6장. HCP 클러스터를 사용하여 ROSA 삭제
호스팅된 컨트롤 플레인(HCP) 클러스터가 있는 AWS(ROSA)에서 Red Hat OpenShift Service를 삭제하려면 Red Hat OpenShift Cluster Manager 또는 ROSA CLI(명령줄 인터페이스)(rosa
)를 사용할 수 있습니다. 클러스터를 삭제한 후 클러스터에서 사용하는 AWS IAM(Identity and Access Management) 리소스도 삭제할 수 있습니다.
6.1. HCP 클러스터 및 클러스터별 IAM 리소스를 사용하여 ROSA 삭제
ROSA CLI(명령줄 인터페이스) 또는 Red Hat OpenShift Cluster Manager를 사용하여 HCP 클러스터의 ROSA를 삭제할 수 있습니다.
클러스터를 삭제한 후 ROSA CLI를 사용하여 AWS 계정의 클러스터별 IAM(Identity and Access Management) 리소스를 정리할 수 있습니다. 클러스터별 리소스에는 Operator 역할 및 OpenID Connect(OIDC) 공급자가 포함됩니다.
클러스터 삭제 및 프로세스에서 리소스가 사용되므로 IAM 리소스를 제거하기 전에 클러스터 삭제를 완료해야 합니다.
애드온이 설치되면 클러스터를 삭제하기 전에 추가 기능이 제거되므로 클러스터 삭제 시간이 오래 걸립니다. 시간 양은 애드온의 수와 크기에 따라 다릅니다.
사전 요구 사항
- HCP 클러스터가 있는 ROSA를 설치했습니다.
-
설치 호스트에 최신 ROSA CLI(
rosa
)를 설치하고 구성했습니다.
절차
다음 명령을 실행하여 클러스터 ID, 클러스터별 Operator 역할의 ARMN(Amazon Resource Names) 및 OIDC 공급자의 끝점 URL을 가져옵니다.
$ rosa describe cluster --cluster=<cluster_name>
출력 예
Name: test_cluster Domain Prefix: test_cluster Display Name: test_cluster ID: <cluster_id> 1 External ID: <external_id> Control Plane: ROSA Service Hosted OpenShift Version: 4.15.0 Channel Group: stable DNS: test_cluster.l3cn.p3.openshiftapps.com AWS Account: <AWS_id> AWS Billing Account: <AWS_id> API URL: https://api.test_cluster.l3cn.p3.openshiftapps.com:443 Console URL: Region: us-east-1 Availability: - Control Plane: MultiAZ - Data Plane: SingleAZ Nodes: - Compute (desired): 2 - Compute (current): 0 Network: - Type: OVNKubernetes - Service CIDR: 172.30.0.0/16 - Machine CIDR: 10.0.0.0/16 - Pod CIDR: 10.128.0.0/14 - Host Prefix: /23 - Subnets: <subnet_ids> EC2 Metadata Http Tokens: optional Role (STS) ARN: arn:aws:iam::<AWS_id>:role/test_cluster-HCP-ROSA-Installer-Role Support Role ARN: arn:aws:iam::<AWS_id>:role/test_cluster-HCP-ROSA-Support-Role Instance IAM Roles: - Worker: arn:aws:iam::<AWS_id>:role/test_cluster-HCP-ROSA-Worker-Role Operator IAM Roles: 2 - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-cloud-network-config-controller-cloud-crede - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-image-registry-installer-cloud-credentials - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-ingress-operator-cloud-credentials - arn:aws:iam::<AWS_id>:role/test_cluster-kube-system-kube-controller-manager - arn:aws:iam::<AWS_id>:role/test_cluster-kube-system-capa-controller-manager - arn:aws:iam::<AWS_id>:role/test_cluster-kube-system-control-plane-operator - arn:aws:iam::<AWS_id>:role/hcpcluster-kube-system-kms-provider - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-cluster-csi-drivers-ebs-cloud-credentials Managed Policies: Yes State: ready Private: No Created: Apr 16 2024 20:32:06 UTC User Workload Monitoring: Enabled Details Page: https://console.redhat.com/openshift/details/s/<cluster_id> OIDC Endpoint URL: https://oidc.op1.openshiftapps.com/<cluster_id> (Managed) 3 Audit Log Forwarding: Disabled External Authentication: Disabled
중요클러스터를 삭제한 후 ROSA CLI를 사용하여 클러스터별 STS 리소스를 삭제하려면 클러스터 ID가 필요합니다.
OpenShift Cluster Manager 또는 ROSA CLI(
rosa
)를 사용하여 클러스터를 삭제합니다.OpenShift Cluster Manager를 사용하여 클러스터를 삭제하려면 다음을 수행합니다.
- OpenShift Cluster Manager 로 이동합니다.
- 클러스터 옆에 있는 옵션 메뉴 를 클릭하고 클러스터 삭제 를 선택합니다.
- 클러스터 이름을 프롬프트에 입력하고 삭제 를 클릭합니다.
ROSA CLI를 사용하여 클러스터를 삭제하려면 다음을 수행합니다.
다음 명령을 실행하여 <
cluster_name>
을 클러스터의 이름 또는 ID로 바꿉니다.$ rosa delete cluster --cluster=<cluster_name> --watch
중요Operator 역할 및 OIDC 공급자를 제거하기 전에 클러스터 삭제가 완료될 때까지 기다려야 합니다.
다음 명령을 실행하여 클러스터별 Operator IAM 역할을 삭제합니다.
$ rosa delete operator-roles --prefix <operator_role_prefix>
다음 명령을 실행하여 OIDC 공급자를 삭제합니다.
$ rosa delete oidc-provider --oidc-config-id <oidc_config_id>
문제 해결
- IAM 역할이 누락되어 클러스터를 삭제할 수 없는 경우 삭제할 수 없는 클러스터 복구를 참조하십시오.
다른 이유로 클러스터를 삭제할 수 없는 경우:
- 하이브리드 클라우드 콘솔에서 보류 중인 클러스터에 대한 애드온이 없는지 확인합니다.
- Amazon Web Console에서 모든 AWS 리소스 및 종속 항목이 삭제되었는지 확인합니다.
6.2. 계정 전체 IAM 리소스 삭제
계정 전체 AWS IAM(Identity and Access Management) 리소스에 의존하는 호스팅된 컨트롤 플레인(HCP) 클러스터를 사용하여 AWS(ROSA)에서 모든 Red Hat OpenShift Service를 삭제한 후 계정 전체 리소스를 삭제할 수 있습니다.
Red Hat OpenShift Cluster Manager를 사용하여 HCP 클러스터와 함께 ROSA를 더 이상 설치할 필요가 없는 경우 OpenShift Cluster Manager 및 사용자 IAM 역할도 삭제할 수 있습니다.
동일한 AWS 계정의 다른 ROSA와 HCP 클러스터에서 계정 전체 IAM 역할 및 정책을 사용할 수 있습니다. 다른 클러스터에 필요하지 않은 경우에만 리소스를 제거합니다.
OpenShift Cluster Manager를 사용하여 동일한 AWS 계정의 AWS 클러스터에서 다른 Red Hat OpenShift Service를 설치, 관리 및 삭제하려면 OpenShift Cluster Manager 및 사용자 IAM 역할이 필요합니다. OpenShift Cluster Manager를 사용하여 계정의 AWS 클러스터에 Red Hat OpenShift Service를 더 이상 설치할 필요가 없는 경우에만 역할을 제거합니다. 삭제 전에 이러한 역할이 제거된 경우 클러스터 복구에 대한 자세한 내용은 클러스터 배포 문제 해결에서 "삭제할 수 없는 클러스터 복구"를 참조하십시오.
추가 리소스
6.2.1. 계정 전체 IAM 역할 및 정책 삭제
이 섹션에서는 계정 전체 Operator 정책과 함께 HCP 배포와 함께 ROSA에 대해 생성한 계정 전체 IAM 역할 및 정책을 삭제하는 단계를 제공합니다. 계정 전체 AWS IAM(Identity and Access Management) 역할 및 정책을 삭제하는 HCP 클러스터를 사용하는 모든 ROSA를 삭제한 후에만 삭제할 수 있습니다.
동일한 AWS 계정의 다른 Red Hat OpenShift Service에서 계정 전체 IAM 역할 및 정책을 사용할 수 있습니다. 다른 클러스터에 필요하지 않은 경우에만 역할을 제거합니다.
사전 요구 사항
- 삭제하려는 계정 전체 IAM 역할이 있습니다.
-
설치 호스트에 최신 ROSA CLI(
rosa
)를 설치하고 구성했습니다.
절차
계정 전체 역할을 삭제합니다.
ROSA CLI(
rosa
)를 사용하여 AWS 계정의 계정 전체 역할을 나열합니다.$ rosa list account-roles
출력 예
I: Fetching account roles ROLE NAME ROLE TYPE ROLE ARN OPENSHIFT VERSION AWS Managed ManagedOpenShift-HCP-ROSA-Installer-Role Installer arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Installer-Role 4.15 Yes ManagedOpenShift-HCP-ROSA-Support-Role Support arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Support-Role 4.15 Yes ManagedOpenShift-HCP-ROSA-Worker-Role Worker arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Worker-Role 4.15 Yes
계정 전체 역할을 삭제합니다.
$ rosa delete account-roles --prefix <prefix> --mode auto 1
- 1
--<prefix> 인수를
포함해야 합니다. <prefix
>를 삭제할 계정 전체 역할의 접두사로 바꿉니다. 계정 전체 역할을 생성할 때 사용자 지정 접두사를 지정하지 않은 경우 기본 접두사인ManagedOpenShift
를 지정합니다.
중요계정 전체 IAM 역할은 동일한 AWS 계정의 다른 ROSA 클러스터에서 사용할 수 있습니다. 다른 클러스터에 필요하지 않은 경우에만 역할을 제거합니다.
출력 예
W: There are no classic account roles to be deleted I: Deleting hosted CP account roles ? Delete the account role 'delete-rosa-HCP-ROSA-Installer-Role'? Yes I: Deleting account role 'delete-rosa-HCP-ROSA-Installer-Role' ? Delete the account role 'delete-rosa-HCP-ROSA-Support-Role'? Yes I: Deleting account role 'delete-rosa-HCP-ROSA-Support-Role' ? Delete the account role 'delete-rosa-HCP-ROSA-Worker-Role'? Yes I: Deleting account role 'delete-rosa-HCP-ROSA-Worker-Role' I: Successfully deleted the hosted CP account roles
계정 전체 인라인 및 Operator 정책을 삭제합니다.
AWS IAM 콘솔 의 정책 페이지에서 계정 전체 역할 및 정책을 생성할 때 지정한 접두사로 정책 목록을 필터링합니다.
참고계정 전체 역할을 생성할 때 사용자 지정 접두사를 지정하지 않은 경우 기본 접두사인
ManagedOpenShift
를 검색합니다.AWS IAM 콘솔 을 사용하여 계정 전체 인라인 정책 및 Operator 정책을 삭제합니다. AWS IAM 콘솔을 사용하여 IAM 정책 삭제에 대한 자세한 내용은 AWS 문서의 IAM 정책 삭제 를 참조하십시오.
중요동일한 AWS 계정의 다른 ROSA에서 계정 전체 인라인 및 Operator IAM 정책을 사용할 수 있습니다. 다른 클러스터에 필요하지 않은 경우에만 역할을 제거합니다.
6.2.2. OpenShift Cluster Manager 및 사용자 IAM 역할 연결 해제 및 삭제
Red Hat OpenShift Cluster Manager를 사용하여 HCP 클러스터로 ROSA를 설치할 때 Red Hat 조직에 연결되는 OpenShift Cluster Manager 및 사용자 IAM(Identity and Access Management) 역할도 생성합니다. 클러스터를 삭제한 후 ROSA CLI(rosa
)를 사용하여 역할을 연결 해제하고 삭제할 수 있습니다.
OpenShift Cluster Manager를 사용하여 동일한 AWS 계정에서 HCP를 사용하여 다른 ROSA를 설치하고 관리하려면 OpenShift Cluster Manager 및 사용자 IAM 역할이 필요합니다. 더 이상 OpenShift Cluster Manager를 사용하여 HCP 클러스터와 함께 ROSA를 설치할 필요가 없는 경우에만 역할을 제거합니다.
사전 요구 사항
- OpenShift Cluster Manager 및 사용자 IAM 역할을 생성하여 Red Hat 조직에 연결합니다.
-
설치 호스트에 최신 ROSA CLI(
rosa
)를 설치하고 구성했습니다. - Red Hat 조직에는 조직 관리자 권한이 있습니다.
절차
Red Hat 조직에서 OpenShift Cluster Manager IAM 역할을 연결 해제하고 역할을 삭제합니다.
AWS 계정의 OpenShift Cluster Manager IAM 역할을 나열합니다.
$ rosa list ocm-roles
출력 예
I: Fetching ocm roles ROLE NAME ROLE ARN LINKED ADMIN AWS Managed ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> Yes Yes Yes
OpenShift Cluster Manager IAM 역할이 이전 명령의 출력에 연결된 것으로 표시되면 다음 명령을 실행하여 Red Hat 조직의 역할을 연결 해제합니다.
$ rosa unlink ocm-role --role-arn <arn> 1
- 1
- &
lt;arn
>을 OpenShift Cluster Manager IAM 역할의 ARM(Amazon Resource Name)으로 바꿉니다. ARN은 이전 명령의 출력에 지정됩니다. 이전 예에서 ARN은arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id
> 형식으로 되어 있습니다.
출력 예
I: Unlinking OCM role ? Unlink the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' role from organization '<red_hat_organization_id>'? Yes I: Successfully unlinked role-arn 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' from organization account '<red_hat_organization_id>'
OpenShift Cluster Manager IAM 역할 및 정책을 삭제합니다.
$ rosa delete ocm-role --role-arn <arn>
출력 예
I: Deleting OCM role ? OCM Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> ? Delete 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' ocm role? Yes ? OCM role deletion mode: auto 1 I: Successfully deleted the OCM role
- 1
- 삭제 모드를 지정합니다.
자동
모드를 사용하여 OpenShift Cluster Manager IAM 역할 및 정책을 자동으로 삭제할 수 있습니다.수동
모드에서 ROSA CLI는 역할 및 정책을 삭제하는 데 필요한aws
명령을 생성합니다.수동
모드를 사용하면aws
명령을 수동으로 실행하기 전에 세부 정보를 검토할 수 있습니다.
Red Hat 조직에서 사용자 IAM 역할을 연결 해제하고 역할을 삭제합니다.
AWS 계정의 사용자 IAM 역할을 나열합니다.
$ rosa list user-roles
출력 예
I: Fetching user roles ROLE NAME ROLE ARN LINKED ManagedOpenShift-User-<ocm_user_name>-Role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role Yes
사용자 IAM 역할이 이전 명령의 출력에 연결된 것으로 표시되면 Red Hat 조직의 역할을 연결 해제합니다.
$ rosa unlink user-role --role-arn <arn> 1
- 1
- &
lt;arn
>을 사용자 IAM 역할의 Amazon 리소스 이름(ARN)으로 바꿉니다. ARN은 이전 명령의 출력에 지정됩니다. 위 예에서 ARN은arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role
형식으로 되어 있습니다.
출력 예
I: Unlinking user role ? Unlink the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' role from the current account '<ocm_user_account_id>'? Yes I: Successfully unlinked role ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' from account '<ocm_user_account_id>'
사용자 IAM 역할을 삭제합니다.
$ rosa delete user-role --role-arn <arn>
출력 예
I: Deleting user role ? User Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role ? Delete the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' role from the AWS account? Yes ? User role deletion mode: auto 1 I: Successfully deleted the user role
- 1
- 삭제 모드를 지정합니다.
자동
모드를 사용하여 사용자 IAM 역할을 자동으로 삭제할 수 있습니다.수동
모드에서 ROSA CLI는 역할을 삭제하는 데 필요한aws
명령을 생성합니다.수동
모드를 사용하면aws
명령을 수동으로 실행하기 전에 세부 정보를 검토할 수 있습니다.