HCP 클러스터를 사용하여 ROSA 설치

Red Hat OpenShift Service on AWS 4

ROSA(AWS) 클러스터에 Red Hat OpenShift Service 설치, 액세스 및 삭제.

Red Hat OpenShift Documentation Team

초록

이 문서에서는 호스팅된 컨트롤 플레인을 사용하는 AWS(ROSA) 클러스터에 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) 인증만 지원합니다.

추가 읽기

추가 리소스

지원되는 인증서의 전체 목록은 "AWS에서 Red Hat OpenShift Service에 대한 이해 프로세스 및 보안"의 규정 준수 섹션을 참조하십시오.

자동 생성 모드에 대한 고려 사항

이 문서의 절차에서는 ROSA CLI의 auto 모드를 사용하여 현재 AWS 계정을 사용하여 필요한 IAM 리소스를 즉시 생성합니다. 필요한 리소스에는 계정 전체의 IAM 역할 및 정책, 클러스터별 Operator 역할 및 정책, OIDC(OpenID Connect) ID 공급자가 포함됩니다.

또는 수동 모드를 사용할 수 있습니다. 이 모드를 사용하면 자동으로 배포하는 대신 IAM 리소스를 생성하는 데 필요한 aws 명령을 출력할 수 있습니다. 수동 모드 또는 사용자 정의 기능을 사용하여 HCP 클러스터와 함께 ROSA를 배포하는 단계는 사용자 정의를 사용하여 클러스터 생성을 참조하십시오.

다음 단계

1.1. 기본 클러스터 사양 개요

기본 설치 옵션을 사용하여 STS(Security Token Service)를 사용하여 HCP 클러스터로 ROSA를 빠르게 생성할 수 있습니다. 다음 요약에서는 기본 클러스터 사양을 설명합니다.

표 1.1. 기본 ROSA with HCP 클러스터 사양

구성 요소기본 사양

계정 및 역할

  • 기본 IAM 역할 접두사: ManagedOpenShift
  • 클러스터 관리자 역할이 생성되지 않음

클러스터 설정

  • 기본 클러스터 버전: Latest
  • ROSA CLI(rosa)를 사용한 설치를 위한 기본 AWS 리전: aws CLI 구성에 의해 정의됨
  • 기본 EC2 IMDS 끝점 (v1 및 v2)이 활성화됨
  • 가용성: 데이터 플레인의 단일 영역
  • 사용자 정의 프로젝트 모니터링: 활성화

암호화

  • 클라우드 스토리지는 미사용 상태에서 암호화됩니다.
  • 추가 etcd 암호화가 활성화되지 않음
  • 기본 AWS KMS(Key Management Service) 키는 영구 데이터의 암호화 키로 사용됩니다.

컴퓨팅 노드 시스템 풀

  • 컴퓨팅 노드 인스턴스 유형: m5.xlarge (4 vCPU 16, GiB RAM)
  • 컴퓨팅 노드 수: 2
  • autoscaling: Not enabled
  • 추가 노드 라벨이 없음

네트워킹 구성

  • 클러스터 개인 정보 보호: 공개
  • 자체 VPC(Virtual Private Cloud)를 구성해야합니다.
  • 클러스터 전체 프록시가 구성되지 않음

CIDR(Classless Inter-Domain Routing) 범위

  • 시스템 CIDR: 10.0.0.0/16
  • Service CIDR: 172.30.0.0/16
  • Pod CIDR: 10.128.0.0/16
  • 호스트 접두사: /23

    참고

    ROSA를 HCP와 함께 사용하면 고정 IP 주소 172.20.0.1 이 내부 Kubernetes API 주소용으로 예약되어 있습니다. 시스템, Pod 및 서비스 CIDR 범위가 이 IP 주소와 충돌해서는 안 됩니다.

클러스터 역할 및 정책

  • Operator 역할 및 OIDC(OpenID Connect) 공급자를 생성하는 데 사용되는 모드: auto

    참고

    하이브리드 클라우드 콘솔에서 OpenShift Cluster Manager를 사용하는 설치의 경우 auto 모드에는 관리자 권한이 있는 OpenShift Cluster Manager 역할이 필요합니다.

  • 기본 Operator 역할 접두사: < cluster_name>-<4_digit_random_string>

클러스터 업데이트 전략

  • 개별 업데이트
  • 노드를 드레이닝하기 위한 1시간 유예 기간

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을 설치했습니다.

절차

  1. 쉘 프롬프트를 열고 다음 명령을 실행하여 Terraform VPC 리포지토리를 복제합니다.

    $ git clone https://github.com/openshift-cs/terraform-vpc-example
  2. 다음 명령을 실행하여 생성된 디렉터리로 이동합니다.

    $ cd terraform-vpc-example
  3. 다음 명령을 실행하여 Terraform 파일을 시작합니다.

    $ terraform init

    이 프로세스가 완료되면 초기화를 확인하는 메시지가 표시됩니다.

  4. 기존 Terraform 템플릿을 기반으로 VPC Terraform 계획을 빌드하려면 plan 명령을 실행합니다. AWS 리전을 포함해야 합니다. 클러스터 이름을 지정하도록 선택할 수 있습니다. rosa.tfplan 파일은 테라폼 계획이 완료된 후 hypershift-tf 디렉토리에 추가됩니다. 자세한 옵션은 Terraform VPC 리포지토리의 README 파일을 참조하십시오.

    $ terraform plan -out rosa.tfplan -var region=<region>
  5. 다음 명령을 실행하여 VPC를 빌드하려면 이 계획 파일을 적용합니다.

    $ terraform apply rosa.tfplan
    1. 선택 사항: 다음 명령을 실행하여 HCP 클러스터로 ROSA를 생성할 때 사용할 Terraform-provisioned 개인, 공용 및 머신 풀 서브넷 ID 값을 환경 변수로 캡처할 수 있습니다.

      $ export SUBNET_IDS=$(terraform output -raw cluster-subnets-string)
    2. 다음 명령을 사용하여 변수가 올바르게 설정되었는지 확인합니다.

      $ 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 검사에서는 이러한 리소스를 사용하기 전에 이러한 리소스가 올바르게 태그되었는지 확인합니다. 다음 표에서는 리소스에 다음 태그를 지정하는 방법을 보여줍니다.

리소스현재의

퍼블릭 서브넷

kubernetes.io/role/elb

1 또는 no value

프라이빗 서브넷

kubernetes.io/role/internal-elb

1 또는 no value

참고

하나 이상의 프라이빗 서브넷과 해당하는 경우 공용 서브넷과 퍼블릭 서브넷을 태그해야 합니다.

사전 요구 사항

  • VPC를 생성했습니다.
  • aws CLI가 설치되어 있습니다.

절차

  1. 다음 명령을 실행하여 터미널에서 리소스를 태그합니다.

    1. 퍼블릭 서브넷의 경우 다음을 실행합니다.

      $ aws ec2 create-tags --resources <public-subnet-id> --tags Key=kubernetes.io/role/elb,Value=1
    2. 프라이빗 서브넷의 경우 다음을 실행합니다.

      $ 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 계정에 로그인했습니다.

절차

  1. AWS 계정에 없는 경우 필요한 계정 전체 STS 역할을 생성하고 다음 명령을 실행하여 정책을 연결합니다.

    $ rosa create account-roles --hosted-cp
  2. 선택 사항: 다음 명령을 실행하여 접두사를 환경 변수로 설정합니다.

    $ 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를 설치하고 구성했습니다.

절차

  1. 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 출력에 따라 이러한 값을 결정해야합니다.

  2. 선택 사항: 나중에 사용할 수 있도록 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 역할을 생성하셨습니다.

절차

  1. 다음 명령을 사용하여 접두사 이름을 환경 변수로 설정합니다.

    $ export OPERATOR_ROLES_PREFIX=<prefix_name>
  2. 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
    1
    이러한 Operator 역할을 생성할 때 접두사를 제공해야 합니다. 이렇게 하지 않으면 오류가 발생합니다. Operator 접두사에 대한 자세한 내용은 이 섹션의 추가 리소스를 참조하십시오.
    2
    이 값은 HCP 클러스터를 사용하여 ROSA용으로 생성한 OIDC 구성 ID입니다.
    3
    이 값은 ROSA 계정 역할을 생성할 때 생성한 설치 관리자 역할 ARN입니다.

    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

    1
    이 필드는 초기 생성 명령에서 설정한 접두사로 미리 채워집니다.
    2
    이 필드를 사용하려면 HCP 클러스터를 사용하여 ROSA에 대해 생성한 OIDC 구성을 선택해야 합니다.

    이제 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 계정과 연결된 모든 접두사를 표시하고 이 접두사와 연결된 역할 수를 기록합니다. 이러한 역할과 세부 정보를 모두 확인해야 하는 경우 세부 정보 프롬프트에 이러한 역할을 나열하도록 "예"를 입력합니다.

추가 리소스

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) 서비스 역할이 있는지 확인했습니다.

절차

  1. 다음 명령 중 하나를 사용하여 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
  2. 다음 명령을 실행하여 클러스터 상태를 확인합니다.

    $ rosa describe cluster --cluster=<cluster_name>

    클러스터 설치가 진행됨에 따라 다음 상태 필드 변경 사항이 출력에 나열됩니다.

    • 보류 (사전 계정)
    • 설치 ( 진행 중인 DNS 설정)
    • 설치
    • Ready

      참고

      설치에 실패하거나 10분 이상 State 필드가 준비 상태가 아닌 경우 자세한 내용은 설치 문제 해결 설명서를 확인하십시오. 자세한 내용은 설치 문제 해결을 참조하십시오. Red Hat 지원에 문의하여 지원을 받으려면 AWS에서 Red Hat OpenShift Service 지원 가져오기 를 참조하십시오.

  3. AWS 설치 프로그램 로그의 Red Hat OpenShift Service를 확인하여 클러스터 생성 진행 상황을 추적합니다. 로그를 확인하려면 다음 명령을 실행합니다.

    $ rosa logs install --cluster=<cluster_name> --watch \ <.>

    <.> 선택 사항: 설치가 진행되는 동안 새 로그 메시지를 조사하려면 --watch 인수를 사용합니다.

1.4. 다음 단계

1.5. 추가 리소스

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을 설치했습니다.

절차

  1. 쉘 프롬프트를 열고 다음 명령을 실행하여 Terraform VPC 리포지토리를 복제합니다.

    $ git clone https://github.com/openshift-cs/terraform-vpc-example
  2. 다음 명령을 실행하여 생성된 디렉터리로 이동합니다.

    $ cd terraform-vpc-example
  3. 다음 명령을 실행하여 Terraform 파일을 시작합니다.

    $ terraform init

    이 프로세스가 완료되면 초기화를 확인하는 메시지가 표시됩니다.

  4. 기존 Terraform 템플릿을 기반으로 VPC Terraform 계획을 빌드하려면 plan 명령을 실행합니다. AWS 리전을 포함해야 합니다. 클러스터 이름을 지정하도록 선택할 수 있습니다. rosa.tfplan 파일은 테라폼 계획이 완료된 후 hypershift-tf 디렉토리에 추가됩니다. 자세한 옵션은 Terraform VPC 리포지토리의 README 파일을 참조하십시오.

    $ terraform plan -out rosa.tfplan -var region=<region>
  5. 다음 명령을 실행하여 VPC를 빌드하려면 이 계획 파일을 적용합니다.

    $ terraform apply rosa.tfplan
    1. 선택 사항: 다음 명령을 실행하여 HCP 클러스터로 ROSA를 생성할 때 사용할 Terraform-provisioned 개인, 공용 및 머신 풀 서브넷 ID 값을 환경 변수로 캡처할 수 있습니다.

      $ export SUBNET_IDS=$(terraform output -raw cluster-subnets-string)
    2. 다음 명령을 사용하여 변수가 올바르게 설정되었는지 확인합니다.

      $ 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 계정에 로그인했습니다.

절차

  1. AWS 계정에 없는 경우 필요한 계정 전체 STS 역할을 생성하고 다음 명령을 실행하여 정책을 연결합니다.

    $ rosa create account-roles --hosted-cp
  2. 선택 사항: 다음 명령을 실행하여 접두사를 환경 변수로 설정합니다.

    $ 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를 설치하고 구성했습니다.

절차

  1. 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 출력에 따라 이러한 값을 결정해야합니다.

  2. 선택 사항: 나중에 사용할 수 있도록 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 역할을 생성하셨습니다.

절차

  1. 다음 명령을 사용하여 접두사 이름을 환경 변수로 설정합니다.

    $ export OPERATOR_ROLES_PREFIX=<prefix_name>
  2. 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
    1
    이러한 Operator 역할을 생성할 때 접두사를 제공해야 합니다. 이렇게 하지 않으면 오류가 발생합니다. Operator 접두사에 대한 자세한 내용은 이 섹션의 추가 리소스를 참조하십시오.
    2
    이 값은 HCP 클러스터를 사용하여 ROSA용으로 생성한 OIDC 구성 ID입니다.
    3
    이 값은 ROSA 계정 역할을 생성할 때 생성한 설치 관리자 역할 ARN입니다.

    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

    1
    이 필드는 초기 생성 명령에서 설정한 접두사로 미리 채워집니다.
    2
    이 필드를 사용하려면 HCP 클러스터를 사용하여 ROSA에 대해 생성한 OIDC 구성을 선택해야 합니다.

    이제 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 키로 영구 볼륨을 암호화하도록 기본 스토리지 클래스를 자동으로 구성하지 않습니다. 이는 설치 후 클러스터 내에서 구성할 수 있는 것입니다.

절차

  1. 다음 명령을 실행하여 사용자 정의 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 인수를 제공해야 합니다.

  2. 다음 명령을 실행하여 KMS 키가 생성되었는지 확인합니다.

    $ echo $KMS_ARN
  3. AWS 계정 ID를 환경 변수로 설정합니다.

    $ AWS_ACCOUNT_ID=<aws_account_id>
  4. 이전 단계에서 생성한 계정 전체 설치 관리자 역할 및 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": "*"
              }
          ]
      }
  5. 다음 명령을 실행하여 생성된 정책 파일의 세부 정보를 확인합니다.

    $ cat rosa-key-policy.json
  6. 다음 명령을 실행하여 새로 생성된 키 정책을 사용자 정의 KMS 키에 적용합니다.

    $ aws kms put-key-policy --key-id $KMS_ARN \
    --policy file://rosa-key-policy.json \
    --policy-name default
  7. 다음 명령을 실행하여 클러스터를 생성합니다.

    참고

    클러스터 이름이 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
    1
    이 KMS 키 ARN은 모든 작업자 노드 루트 볼륨을 암호화하는 데 사용됩니다. etcd 데이터베이스 암호화만 필요한 경우에는 필요하지 않습니다.
    2
    이 KMS 키 ARN은 etcd 데이터베이스를 암호화하는 데 사용됩니다. etcd 데이터베이스는 항상 AES 암호화 블록으로 암호화되지만 KMS 키를 사용하여 암호화할 수 있습니다. 노드 루트 볼륨 암호화만 필요한 경우에는 필요하지 않습니다.

검증

OpenShift Cluster Manager 를 사용하여 KMS 키가 작동하는지 확인할 수 있습니다.

  1. OpenShift Cluster Manager 로 이동하여 인스턴스를 선택합니다.
  2. 인스턴스를 선택합니다.
  3. 스토리지 탭을 클릭합니다.
  4. KMS 키 ID 를 복사합니다.
  5. 키 관리 서비스를 검색하고 선택합니다.
  6. 필터 필드에 복사된 KMS 키 ID 를 입력합니다.

2.2. 다음 단계

2.3. 추가 리소스

3장. HCP를 사용하여 ROSA에 개인 클러스터 생성

이 문서에서는 호스팅되는 컨트롤 플레인(HCP) 프라이빗 클러스터를 사용하여 AWS(ROSA)에서 Red Hat OpenShift Service를 생성하는 방법을 설명합니다.

3.1. AWS 프라이빗 클러스터 생성

ROSA CLI(명령줄 인터페이스)를 사용하여 ROSA에 여러 가용 영역(Multi-AZ)이 있는 프라이빗 클러스터를 생성할 수 있습니다.

사전 요구 사항

  • 사용 가능한 AWS 서비스 할당량이 있습니다.
  • AWS 콘솔에서 ROSA 서비스를 활성화했습니다.
  • 설치 호스트에 ROSA CLI의 최신 버전을 설치하고 구성했습니다.

절차

호스팅된 컨트롤 플레인을 사용하여 클러스터를 생성하는 데 약 10분이 걸릴 수 있습니다.

  1. 프라이빗 서브넷이 하나 이상 있는 VPC를 생성합니다. 시스템의 클래스리스 도메인 간 라우팅(CIDR)이 가상 프라이빗 클라우드의 CIDR과 일치하는지 확인합니다. 자세한 내용은 자체 VPC 및 VPC 유효성 검사 사용에 대한 요구 사항을 참조하십시오.

    중요

    방화벽을 사용하는 경우 ROSA가 작동하는 데 필요한 사이트에 액세스할 수 있도록 방화벽을 구성해야 합니다.

    자세한 내용은 "AWS PrivateLink 방화벽 사전 요구 사항" 섹션을 참조하십시오.

  2. 다음 명령을 실행하여 계정 전체 IAM 역할을 생성합니다.

    $ rosa create account-roles --hosted-cp
  3. 다음 명령을 실행하여 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'

  4. 다음 명령을 실행하여 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
  5. 다음 명령을 실행하여 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>]
  6. 다음 명령을 입력하여 클러스터 상태를 확인합니다. 클러스터 생성 중에 출력의 State 필드가 보류 중에서 설치 로 전환되고 마지막으로 ready 로 전환됩니다.

    $ rosa describe cluster --cluster=<cluster_name>
    참고

    설치에 실패하거나 State 필드가 10분 후에 준비 되도록 변경되지 않는 경우 추가 리소스 섹션의 "Red Hat OpenShift Service on AWS 설치 관련 문제 해결" 설명서를 참조하십시오.

  7. 다음 명령을 입력하여 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 내에서 보안 그룹을 생성하고 연결할 수 있는 권한이 있습니다.

절차

  1. 다음 명령을 실행하여 클러스터 이름을 환경 변수로 설정합니다.

    $ export CLUSTER_NAME=<cluster_name>

    다음 명령을 실행하여 변수가 설정되었는지 확인할 수 있습니다.

    $ echo $CLUSTER_NAME

    출력 예

    hcp-private

  2. 다음 명령을 실행하여 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)
  3. 다음 명령을 실행하여 보안 그룹을 생성합니다.

    $ 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)
  4. 다음 명령을 실행하여 보안 그룹에 수신 규칙을 추가합니다.

    $ 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}]
  5. 다음 명령을 실행하여 VPCE에 새 보안 그룹을 추가합니다.

    $ aws ec2 modify-vpc-endpoint --vpc-endpoint-id $VPCE_ID --add-security-group-ids $SG_ID

이제 HCP 프라이빗 클러스터를 사용하여 ROSA를 사용하여 API에 액세스할 수 있습니다.

3.3. 다음 단계

ID 공급자 구성

4장. 외부 인증을 사용하여 HCP 클러스터를 사용하여 ROSA 생성

외부 인증을 사용하여 액세스 토큰을 발행하는 호스팅된 컨트롤 플레인(HCP) 클러스터를 사용하여 AWS(ROSA)에서 Red Hat OpenShift Service를 생성할 수 있습니다.

중요

기존 ROSA 클러스터를 호스팅된 컨트롤 플레인 아키텍처로 업그레이드하거나 변환할 수 없으므로 HCP 기능과 함께 ROSA를 사용할 새 클러스터를 생성해야 합니다. 또한 외부 인증 공급자를 사용하여 내부 OAuth2 서버를 사용하도록 생성된 클러스터를 변환할 수 없습니다. 또한 새 클러스터를 생성해야 합니다.

참고

HCP 클러스터가 있는 ROSA는 STS(Security Token Service) 인증만 지원합니다.

추가 읽기

추가 리소스

지원되는 인증서의 전체 목록은 "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설명

--cluster

클러스터의 이름 또는 ID입니다.

--name

외부 인증 공급자를 참조하는 데 사용되는 이름입니다.

--console-client-secret

이 문자열은 계정을 애플리케이션과 연결하는 데 사용되는 클라이언트 시크릿입니다. 클라이언트 시크릿을 포함하지 않으면 이 명령에서 공용 OIDC OAuthClient를 사용합니다.

--issuer-audiences

쉼표로 구분된 토큰 대상 목록입니다.

--issuer-url

토큰 발행자의 URL입니다.

--claim-mapping-username-claim

클러스터 ID의 사용자 이름을 구성하는 데 사용해야 하는 클레임의 이름입니다.

--claim-mapping-groups-claim

클러스터 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

추가 리소스

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 생성 을 참조하십시오.
  • 외부 인증 공급자를 생성했습니다. 자세한 내용은 외부 인증 공급자 생성을 참조하십시오.
  • 클러스터 관리자 권한이 있는 계정이 있어야 합니다.

절차

  1. 다음 명령 중 하나를 사용하여 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'.

      1
      비워 두면 사용자 이름의 값은 임의로 생성된 username 값이 됩니다.
      2
      break glass 인증 정보의 최소 유효 기간은 10 분이며 최대 유효 기간은 24 시간입니다. 비워 두는 경우 expiration 기간 값은 기본적으로 24시간입니다.
    • 지정된 값이 있는 mycluster 라는 클러스터에 대한 중단 유리 인증 정보를 생성하려면 다음을 수행합니다.

      $ rosa create break-glass-credential -c mycluster --username test-username --expiration 1h
  2. 다음 명령을 실행하여 mycluster 라는 클러스터에 사용할 수 있는 break glass 인증 정보 ID, 상태 및 관련 사용자를 나열합니다.

    $ rosa list break-glass-credential -c mycluster

    출력 예

    ID                                USERNAME    STATUS
    2a7jli9n4phe6c02ul7ti91djtv2o51d  test-user   issued

    참고

    명령에 -o json 인수를 추가하여 JSON 출력에서 인증 정보를 볼 수도 있습니다.

  3. 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 인증 정보는 현재 취소되고 있습니다. 즉, 사용할 수 없습니다.
    • 유리 인증 정보가 취소되어 더 이상 사용할 수 없습니다.
  4. 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

      1
      client-certificate에는 Kubernetes CA(인증 기관)에서 서명한 사용자의 인증서가 포함되어 있습니다.
      2
      client-key에는 클라이언트 인증서에 서명한 키가 포함되어 있습니다.
  5. 선택 사항: kubeconfig 를 저장하려면 다음 명령을 실행합니다.

    $ rosa describe break-glass-credential <break_glass_credential_id> -c mycluster --kubeconfig > $KUBECONFIG

추가 리소스

4.5. 유리 인증 정보를 사용하여 HCP 클러스터로 ROSA에 액세스

break glass 인증 정보의 새 kubeconfig 를 사용하여 HCP 클러스터의 ROSA에 대한 임시 관리자 액세스 권한을 얻습니다.

사전 요구 사항

  • 외부 인증이 활성화된 HCP 클러스터를 사용하여 ROSA에 액세스할 수 있습니다. 자세한 내용은 외부 인증 공급자를 사용하는 HCP 클러스터를 사용하여 ROSA 생성 을 참조하십시오.
  • ockubectl CLI를 설치했습니다.
  • kubeconfig 를 구성했습니다. 자세한 내용은 HCP 클러스터를 사용하여 ROSA에 대한 break glass 인증 정보 생성을 참조하십시오.

절차

  1. 클러스터 세부 정보에 액세스합니다.

    $ rosa describe break-glass-credential <break_glass_credential_id> -c <cluster_name>  --kubeconfig > $KUBECONFIG
  2. 클러스터의 노드를 나열합니다.

    $ 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

  3. 올바른 인증 정보가 있는지 확인합니다.

    $ kubectl auth whoami

    출력 예

    ATTRIBUTE    VALUE
    Username     system:customer-break-glass:test-user
    Groups       [system:masters system:authenticated]

  4. 외부 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) 공급자를 통해 인증됩니다. 이제 클러스터에 역할 할당 및 애플리케이션을 배포할 수 있습니다.

추가 리소스

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를 사용하여 외부 인증 공급자를 삭제합니다.

절차

  1. 다음 명령을 실행하여 클러스터에 외부 인증 공급자를 표시합니다.

    $ rosa list external-auth-provider -c <cluster_name>

    출력 예

    NAME        ISSUER URL
    entra-test  https://login.microsoftonline.com/<group_id>/v2.0

  2. 다음 명령을 실행하여 외부 인증 공급자를 삭제합니다.

    $ 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'

검증

  1. 다음 명령을 실행하여 클러스터의 외부 인증 공급자를 쿼리합니다.

    $ rosa list external-auth-provider -c <cluster_name>

    출력 예

    E: there are no external authentication providers for this cluster

4.8. 추가 리소스

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
        },
      ]
    },
  ]
}
1
일치에 적용할 TuneD 프로필입니다. 예를 들어 tuned_profile_1이 있습니다.
2
프로필 순서 지정 우선 순위입니다. 숫자가 작을수록 우선 순위가 높습니다(0이 가장 높은 우선 순위임).
3
생략하면 우선 순위가 높은 프로필이 먼저 일치하지 않는 한 프로필이 일치하는 것으로 가정합니다.
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> 형식의 spec.provider ID 노드 오브젝트 값을 활용하고 NTO 피연산자 컨테이너의 < cloud-provider> 값으로 /var/lib/tuned/provider 파일을 기록합니다. 그런 다음 이 파일의 내용은 TuneD에서 이러한 프로필이 존재하는 경우 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의 최신 버전을 다운로드했습니다.
  • 최신 버전에 클러스터가 있어야 합니다.
  • 노드 튜닝을 위해 사양 파일이 구성되어 있습니다.

절차

  1. 다음 명령을 실행하여 튜닝 구성을 생성합니다.

    $ 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의 최신 버전을 다운로드했습니다.
  • 최신 버전에 클러스터가 있어야 합니다.
  • 클러스터에 노드 튜닝 구성이 추가되어 있습니다.

절차

  1. rosa describe 명령을 사용하여 튜닝 구성을 확인합니다.

    $ rosa describe tuning-config -c <cluster_id> 1
           --name <name_of_tuning> 2
           [-o json] 3

    이 사양 파일의 다음 항목은 다음과 같습니다.

    1
    노드 튜닝 구성을 적용하려는 클러스터의 클러스터 ID를 제공합니다.
    2
    튜닝 구성의 이름을 제공합니다.
    3
    선택적으로 출력 유형을 제공할 수 있습니다. 출력을 지정하지 않으면 튜닝 구성의 ID와 이름만 표시됩니다.

    출력 유형을 지정하지 않은 샘플 출력

    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"
          }
        ]
      }
    }

  2. 튜닝 구성을 확인한 후 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)를 설치하고 구성했습니다.

절차

  1. 다음 명령을 실행하여 클러스터 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

    1
    클러스터 ID를 나열합니다.
    2
    클러스터별 Operator 역할의 ARN을 지정합니다. 예를 들어 샘플 출력에서 Machine Config Operator에 필요한 역할에 대한 ARN은 arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-machine-api-aws-cloud-credentials 입니다.
    3
    클러스터별 OIDC 공급자의 끝점 URL을 표시합니다.
    중요

    클러스터를 삭제한 후 ROSA CLI를 사용하여 클러스터별 STS 리소스를 삭제하려면 클러스터 ID가 필요합니다.

  2. OpenShift Cluster Manager 또는 ROSA CLI(rosa)를 사용하여 클러스터를 삭제합니다.

    • OpenShift Cluster Manager를 사용하여 클러스터를 삭제하려면 다음을 수행합니다.

      1. OpenShift Cluster Manager 로 이동합니다.
      2. 클러스터 옆에 있는 옵션 메뉴 kebab 를 클릭하고 클러스터 삭제 를 선택합니다.
      3. 클러스터 이름을 프롬프트에 입력하고 삭제 를 클릭합니다.
    • ROSA CLI를 사용하여 클러스터를 삭제하려면 다음을 수행합니다.

      1. 다음 명령을 실행하여 < cluster_name> 을 클러스터의 이름 또는 ID로 바꿉니다.

        $ rosa delete cluster --cluster=<cluster_name> --watch
        중요

        Operator 역할 및 OIDC 공급자를 제거하기 전에 클러스터 삭제가 완료될 때까지 기다려야 합니다.

  3. 다음 명령을 실행하여 클러스터별 Operator IAM 역할을 삭제합니다.

    $ rosa delete operator-roles --prefix <operator_role_prefix>
  4. 다음 명령을 실행하여 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)를 설치하고 구성했습니다.

절차

  1. 계정 전체 역할을 삭제합니다.

    1. 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

    2. 계정 전체 역할을 삭제합니다.

      $ rosa delete account-roles --prefix <prefix> --mode auto 1
      1
      --<prefix> 인수를 포함해야 합니다. & lt;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

  2. 계정 전체 인라인 및 Operator 정책을 삭제합니다.

    1. AWS IAM 콘솔정책 페이지에서 계정 전체 역할 및 정책을 생성할 때 지정한 접두사로 정책 목록을 필터링합니다.

      참고

      계정 전체 역할을 생성할 때 사용자 지정 접두사를 지정하지 않은 경우 기본 접두사인 ManagedOpenShift 를 검색합니다.

    2. 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 조직에는 조직 관리자 권한이 있습니다.

절차

  1. Red Hat 조직에서 OpenShift Cluster Manager IAM 역할을 연결 해제하고 역할을 삭제합니다.

    1. 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

    2. 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>'

    3. 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 명령을 수동으로 실행하기 전에 세부 정보를 검토할 수 있습니다.
  2. Red Hat 조직에서 사용자 IAM 역할을 연결 해제하고 역할을 삭제합니다.

    1. 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

    2. 사용자 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>'

    3. 사용자 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 명령을 수동으로 실행하기 전에 세부 정보를 검토할 수 있습니다.

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.