View a markdown version of this page

를 사용하는 ROSA 클래식 클러스터 생성 AWS PrivateLink - Red Hat OpenShift Service on AWS
사전 조건Amazon VPC 아키텍처 생성ROSA CLI 및를 사용하여 ROSA 클래식 클러스터 생성 AWS PrivateLinkAWS PrivateLink DNS 전달 구성자격 증명 공급자 구성 및 클러스터 액세스 권한 부여사용자에게에 대한 액세스 권한 부여 클러스터cluster-admin 권한 구성dedicated-admin 권한 구성Red Hat Hybrid Cloud 콘솔을 클러스터 통해에 액세스개발자 카탈로그에서 애플리케이션 배포사용자의 cluster-admin 권한 취소사용자의 dedicated-admin 권한 취소에 대한 사용자 액세스 취소 클러스터클러스터 및 AWS STS 리소스 삭제

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

를 사용하는 ROSA 클래식 클러스터 생성 AWS PrivateLink

ROSA 클래식 클러스터는 퍼블릭, 프라이빗 또는 프라이빗 등 몇 가지 방법으로 배포할 수 있습니다 AWS PrivateLink. ROSA 클래식에 대한 자세한 내용은 섹션을 참조하세요ROSA 아키텍처. 퍼블릭 및 프라이빗 클러스터 구성 모두에서 OpenShift 클러스터 는 인터넷에 액세스할 수 있으며 애플리케이션 계층의 애플리케이션 워크로드에 개인 정보가 설정됩니다.

클러스터 및 애플리케이션 워크로드를 모두 프라이빗으로 설정해야 하는 경우 ROSA 클래식 AWS PrivateLink 으로를 구성할 수 있습니다. AWS PrivateLink 는를 ROSA 사용하여 AWS 고객 계정의 ROSA 서비스와 클러스터 리소스 간에 프라이빗 연결을 생성하는 가용성과 확장성이 뛰어난 기술입니다. AWS PrivateLink Red Hat 사이트 신뢰성 엔지니어링(SRE) 팀은 클러스터의 AWS PrivateLink 엔드포인트에 연결된 프라이빗 서브넷을 사용하여 지원 및 문제 해결을 위해 클러스터에 액세스할 수 있습니다.

에 대한 자세한 내용은 란 무엇입니까 AWS PrivateLink?를 AWS PrivateLink참조하십시오.

에 나열된 사전 조건 작업을 완료합니다를 사용하도록 설정 ROSA.

다음 절차에서는 클러스터를 호스팅하는 데 사용할 수 있는 Amazon VPC 아키텍처를 생성합니다. 모든 클러스터 리소스는 프라이빗 서브넷에서 호스팅됩니다. 퍼블릭 서브넷은 NAT 게이트웨이를 통해 프라이빗 서브넷에서 퍼블릭 인터넷으로 아웃바운드 트래픽을 라우팅합니다. 이 예에서는 CIDR 블록 10.0.0.0/16를 Amazon VPC에 사용합니다. 하지만 다른 CIDR 블록을 선택할 수도 있습니다. 자세한 내용은 VPC 크기 조정을 참조하세요.

중요

Amazon VPC 요구 사항이 충족되지 않으면 클러스터 생성이 실패합니다.

예
Amazon VPC console

  1. Amazon VPC 콘솔을 엽니다.

  2. VPC 대시보드에서 VPC 생성을 선택합니다.

  3. 생성할 리소스에서 VPC 등을 선택합니다.

  4. 이름 태그 자동 생성을 선택한 상태로 유지하여 VPC 리소스에 이름 태그를 생성하거나 선택을 취소하여 VPC 리소스에 고유한 이름 태그를 제공합니다.

  5. IPv4 CIDR 블록에 VPC의 IPv4 주소 범위를 입력합니다. VPC는 IPv4 주소 범위를 가져야 합니다.

  6. (선택 사항) IPv6 트래픽을 지원하려면 IPv6 CIDR 블록, Amazon 제공 IPv6 CIDR 블록을 선택합니다.

  7. 테넌시를 로 둡니다Default.

  8. 가용 영역(AZs) 수에서 필요한 번호를 선택합니다. 다중 AZ 배포의 경우 에는 세 개의 가용 영역이 ROSA 필요합니다. 서브넷의 AZ를 선택하려면 AZ 사용자 지정을 확장합니다.

    참고

    일부 ROSA 인스턴스 유형은 일부 가용 영역에서만 사용할 수 있습니다. ROSA CLI 명령 rosa list instance-types 명령을 사용하여 사용 가능한 모든 ROSA 인스턴스 유형을 나열할 수 있습니다. 지정된 가용 영역에 인스턴스 유형을 사용할 수 있는지 확인하려면 AWS CLI 명령을 사용합니다aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>".

  9. 서브넷을 구성하려면 퍼블릭 서브넷 수 및 프라이빗 서브넷 수의 값을 선택합니다. 서브넷의 IP 주소 범위를 선택하려면 서브넷 CIDR 블록 사용자 지정을 확장합니다.

    참고

    ROSA 에서는 고객이 클러스터를 생성하는 데 사용되는 가용 영역당 하나 이상의 프라이빗 서브넷을 구성해야 합니다.

  10. 프라이빗 서브넷의 리소스에 IPv4를 통해 퍼블릭 인터넷에 대한 액세스 권한을 부여하려면 NAT 게이트웨이의 경우 NAT 게이트웨이를 생성할 AZs 수를 선택합니다. 프로덕션 환경에서는 퍼블릭 인터넷에 액세스해야 하는 리소스가 있는 각 AZ에 NAT 게이트웨이를 배포하는 것이 좋습니다.

  11. (선택 사항) VPC에서 Amazon S3 직접에 액세스해야 하는 경우 VPC 엔드포인트인 S3 Gateway를 선택합니다.

  12. 기본 DNS 옵션을 선택한 상태로 둡니다. VPC에서 DNS 호스트 이름 지원이 ROSA 필요합니다.

  13. VPC 생성을 선택합니다.

AWS CLI

  1. CIDR 블록이 10.0.0.0/16인 VPC를 만듭니다.

     aws ec2 create-vpc \
     --cidr-block 10.0.0.0/16 \
     --query Vpc.VpcId \
     --output text

    앞의 명령은 VPC ID를 반환합니다. 다음은 예시 출력입니다.

    vpc-1234567890abcdef0

  2. 환경 변수에 VPC ID를 저장합니다.

    export VPC_ID=vpc-1234567890abcdef0

  3. VPC_ID 환경 변수를 사용하여 VPC에 대한 Name 태그를 생성합니다.

    aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=MyVPC

  4. VPC에서 DNS 호스트 이름 지원을 활성화합니다.

    aws ec2 modify-vpc-attribute \
    --vpc-id $VPC_ID \
    --enable-dns-hostnames

  5. 리소스를 생성해야 하는 가용 영역을 지정하여 VPC에 퍼블릭 및 프라이빗 서브넷을 생성합니다.

    중요

    ROSA 에서는 고객이 클러스터를 생성하는 데 사용되는 가용 영역당 하나 이상의 프라이빗 서브넷을 구성해야 합니다. 다중 AZ 배포의 경우 3개의 가용 영역이 필요합니다. 이러한 요구 사항이 충족되지 않으면 클러스터 생성에 실패합니다.

    참고

    일부 ROSA 인스턴스 유형은 일부 가용 영역에서만 사용할 수 있습니다. ROSA CLI 명령 rosa list instance-types 명령을 사용하여 사용 가능한 모든 ROSA 인스턴스 유형을 나열할 수 있습니다. 지정된 가용 영역에 인스턴스 유형을 사용할 수 있는지 확인하려면 AWS CLI 명령을 사용합니다aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>".

    aws ec2 create-subnet \
    --vpc-id $VPC_ID \
    --cidr-block 10.0.1.0/24 \
    --availability-zone us-east-1a \
    --query Subnet.SubnetId \
    --output text
aws ec2 create-subnet \
    --vpc-id $VPC_ID \
    --cidr-block 10.0.0.0/24 \
    --availability-zone us-east-1a \
    --query Subnet.SubnetId \
    --output text

  6. 퍼블릭 및 프라이빗 서브넷 IDs 환경 변수에 저장합니다.

    export PUBLIC_SUB=subnet-1234567890abcdef0
export PRIVATE_SUB=subnet-0987654321fedcba0

  7. 아웃바운드 트래픽에 대한 인터넷 게이트웨이와 라우팅 테이블을 생성합니다. 프라이빗 트래픽에 대한 라우팅 테이블과 탄력적 IP 주소를 생성합니다.

    aws ec2 create-internet-gateway \
    --query InternetGateway.InternetGatewayId \
    --output text
aws ec2 create-route-table \
    --vpc-id $VPC_ID \
    --query RouteTable.RouteTableId \
    --output text
aws ec2 allocate-address \
    --domain vpc \
    --query AllocationId \
    --output text
aws ec2 create-route-table \
    --vpc-id $VPC_ID \
    --query RouteTable.RouteTableId \
    --output text

  8. 환경 변수에 IDs 저장합니다.

    export IGW=igw-1234567890abcdef0
export PUBLIC_RT=rtb-0987654321fedcba0
export EIP=eipalloc-0be6ecac95EXAMPLE
export PRIVATE_RT=rtb-1234567890abcdef0

  9. 인터넷 게이트웨이를 VPC에 연결합니다.

    aws ec2 attach-internet-gateway \
    --vpc-id $VPC_ID \
    --internet-gateway-id $IGW

  10. 퍼블릭 라우팅 테이블을 퍼블릭 서브넷에 연결하고 인터넷 게이트웨이로 라우팅하도록 트래픽을 구성합니다.

    aws ec2 associate-route-table \
    --subnet-id $PUBLIC_SUB \
    --route-table-id $PUBLIC_RT
aws ec2 create-route \
    --route-table-id $PUBLIC_RT \
    --destination-cidr-block 0.0.0.0/0 \
    --gateway-id $IGW

  11. NAT 게이트웨이를 생성하고 탄력적 IP 주소와 연결하여 프라이빗 서브넷으로의 트래픽을 활성화합니다.

    aws ec2 create-nat-gateway \
    --subnet-id $PUBLIC_SUB \
    --allocation-id $EIP \
    --query NatGateway.NatGatewayId \
    --output text

  12. 프라이빗 라우팅 테이블을 프라이빗 서브넷에 연결하고 NAT 게이트웨이로 라우팅하도록 트래픽을 구성합니다.

    aws ec2 associate-route-table \
    --subnet-id $PRIVATE_SUB \
    --route-table-id $PRIVATE_RT
aws ec2 create-route \
    --route-table-id $PRIVATE_RT \
    --destination-cidr-block 0.0.0.0/0 \
    --gateway-id $NATGW

  13. (선택 사항) 다중 AZ 배포의 경우 위의 단계를 반복하여 퍼블릭 및 프라이빗 서브넷이 있는 두 개의 추가 가용 영역을 구성합니다.

ROSA CLI 및를 사용하여 단일 가용 영역(단일 AWS PrivateLink AZ) 또는 다중 가용 영역(다중 AZ) 클러스터 으로를 생성할 수 있습니다. 어느 경우든 시스템의 CIDR 값이 VPC의 CIDR 값과 일치해야 합니다.

다음 절차에서는 rosa create cluster 명령을 사용하여 ROSA 클래식을 생성합니다 클러스터. 다중 AZ를 생성하려면 명령--multi-az에서를 클러스터지정한 다음 메시지가 표시되면 사용할 프라이빗 서브넷 IDs를 선택합니다.

참고

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

자세한 내용은 Red Hat 설명서의 Requirements for using AWS PrivateLink clusters를 참조하세요.

  1. --mode auto 또는를 사용하여 필요한 IAM 계정 역할 및 정책을 생성합니다--mode manual.

    • rosa create account-roles --classic --mode auto

    • rosa create account-roles --classic --mode manual
      참고

      오프라인 액세스 토큰이 만료된 경우 ROSA CLI는 권한 부여 토큰을 업데이트해야 한다는 오류 메시지를 출력합니다. 문제 해결 단계는 섹션을 참조하세요ROSA CLI 만료된 오프라인 액세스 토큰 문제 해결.

  2. 다음 명령 중 하나를 실행 클러스터 하여를 생성합니다.

    • 단일 AZ

      rosa create cluster --private-link --cluster-name=<CLUSTER_NAME> --machine-cidr=10.0.0.0/16 --subnet-ids=<PRIVATE_SUBNET_ID>

    • 다중 AZ

      rosa create cluster --private-link --multi-az --cluster-name=<CLUSTER_NAME> --machine-cidr=10.0.0.0/16
      참고

      AWS Security Token Service (AWS STS) 단기 자격 증명과 AWS PrivateLink 함께를 사용하는 클러스터--sts --mode manual를 생성하려면 rosa create cluster 명령 끝에 --sts --mode auto 또는를 추가합니다.

  3. 대화형 프롬프트에 따라 클러스터 연산자 IAM 역할을 생성합니다.

    rosa create operator-roles --interactive -c <CLUSTER_NAME>

  4. 클러스터 운영자가 인증에 사용하는 OpenID Connect(OIDC) 공급자를 생성합니다.

    rosa create oidc-provider --interactive -c <CLUSTER_NAME>

  5. 의 상태를 확인합니다 클러스터.

    rosa describe cluster -c <CLUSTER_NAME>
    참고

    State 필드가 ready 상태를 표시하는 데 최대 40분이 클러스터 걸릴 수 있습니다. 프로비저닝이 실패하거나 40분 ready 후에 로 표시되지 않는 경우 섹션을 참조하세요문제 해결. 지원 또는 Red Hat 지원팀에 문의하여 지원을 받으려면 섹션을 참조하세요ROSA 지원 받기.

  6. OpenShift 설치 관리자 로그를 확인하여 클러스터 생성 진행 상황을 추적합니다.

    rosa logs install -c <CLUSTER_NAME> --watch

를 사용하는 클러스터는에서 퍼블릭 호스팅 영역과 프라이빗 호스팅 영역을 AWS PrivateLink 생성합니다 Route 53. Route 53 프라이빗 호스팅 영역 내의 레코드는 할당된 VPC 내에서만 확인할 수 있습니다.

Let's Encrypt DNS-01 검증에는 유효하고 공개적으로 신뢰할 수 있는 인증서를 도메인에 발급할 수 있는 공개 영역이 필요합니다. 검증 레코드는 Let's Encrypt 검증이 완료된 후에 삭제됩니다. 영역은 인증서를 발급하고 갱신하는 데 계속 필요하며, 일반적으로 60일마다 필요합니다. 영역은 일반적으로 비어 있는 것처럼 보이지만 검증 프로세스에서 공개 영역의 역할은 중요합니다.

AWS 프라이빗 호스팅 영역에 대한 자세한 내용은 프라이빗 영역 작업을 참조하세요. 퍼블릭 호스팅 영역에 대한 자세한 정보는 퍼블릭 호스팅 영역 작업을 참조하세요.

  1. api.<cluster_domain> 및와 같은 레코드가 VPC 외부에서 확인*.apps.<cluster_domain>되도록 하려면 Route 53 Resolver 인바운드 엔드포인트를 구성합니다.

    참고

    인바운드 엔드포인트를 구성할 때 중복성을 위해 최소 2개의 IP 주소를 지정해야 합니다. 최소한 2개의 가용 영역에 IP 주소를 지정하는 것이 좋습니다. 선택적으로 그러한 가용 영역 또는 다른 가용 영역에 추가 IP 주소를 지정할 수 있습니다.

  2. 인바운드 엔드포인트를 구성할 때 클러스터를 생성할 때 사용된 VPC 및 프라이빗 서브넷을 선택합니다.

Route 53 Resolver 내부 엔드포인트가 연결되고 작동한 후 네트워크의 지정된 서버에서 DNS 쿼리를 처리할 수 있도록 DNS 전달을 구성합니다.

  1. DNS 쿼리를 최상위 도메인의 IP 주소(예:drow-pl-01.htno.p1.openshiftapps.com)로 전달하도록 회사 네트워크를 구성합니다.

  2. 한 VPC에서 다른 VPC로 DNS 쿼리를 전달하는 경우 전달 규칙 관리 지침을 따르세요.

  3. 원격 네트워크 DNS 서버를 구성하는 경우 특정 DNS 서버 설명서를 참조하여 설치된 클러스터 도메인에 대한 선택적 DNS 전달을 구성합니다.

ROSA 에는 기본 제공 OAuth 서버가 포함되어 있습니다. ROSA 클러스터 생성 이후 ID 공급자를 사용하려면 OAuth를 구성해야 합니다. 그런 다음 구성된 ID 공급자에 사용자를 추가하여 클러스터액세스 권한을 부여할 수 있습니다. 필요에 따라 이러한 사용자에게 cluster-admin 또는 dedicated-admin 권한을 부여할 수 있습니다.

클러스터에 맞게 다양한 ID 제공자 유형을 구성할 수 있습니다 . 지원되는 유형으로는 GitHub, GitHub Enterprise, GitLab, Google, LDAP, OpenID Connect, HTPasswd ID 공급자 등이 있습니다.

중요

HTPasswd ID 공급자는 한 명의 정적 관리자 사용자를 생성할 수 있도록 하기 위한 용도로만 포함됩니다. HTPassWD는 ROSA범용 ID 공급자로는 지원되지 않습니다.

다음 절차는 GitHub ID 공급자를 예로 구성합니다. 지원되는 각 ID 제공자 유형을 구성하는 방법에 대한 지침은 AWS STS ID 제공자 구성을 참조하세요.

  1. github.com으로 이동하여 GitHub 계정에 로그인합니다.

  2. ROSA 클러스터 ID 프로비저닝에 사용할 GitHub 조직이 없는 경우 하나 생성합니다. 자세한 내용을 알아보려면 GitHub의 설명서의 단계를 참조하세요.

  3. ROSA CLI의 대화형 모드를 사용하여 다음 명령을 실행하여 클러스터의 자격 증명 공급자를 구성합니다.

    rosa create idp --cluster=<CLUSTER_NAME> --interactive

  4. 출력의 구성 프롬프트에 따라 GitHub 조직의 멤버에 대한 클러스터 액세스를 제한합니다.

    I: Interactive mode enabled.
Any optional fields can be left empty and a default will be selected.
? Type of identity provider: github
? Identity provider name: github-1
? Restrict to members of: organizations
? GitHub organizations: <GITHUB_ORG_NAME>
? To use GitHub as an identity provider, you must first register the application:
  - Open the following URL:
    https://github.com/organizations/<GITHUB_ORG_NAME>/settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=<CLUSTER_NAME>&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com
  - Click on 'Register application'
...

  5. 출력에서 URL을 열고 <GITHUB_ORG_NAME>를 GitHub 조직의 이름으로 대체합니다.

  6. GitHub 웹 페이지에서 애플리케이션 등록을 선택하여 GitHub 조직에 새 OAuth 애플리케이션을 등록합니다.

  7. GitHub OAuth 페이지의 정보를 사용하여 나머지 rosa create idp 대화형 프롬프트를 채우고 GitHub OAuth 애플리케이션의 자격 증명으로 <GITHUB_CLIENT_ID> 및 <GITHUB_CLIENT_SECRET>을 대체합니다.

    ...
? Client ID: <GITHUB_CLIENT_ID>
? Client Secret: [? for help] <GITHUB_CLIENT_SECRET>
? GitHub Enterprise Hostname (optional):
? Mapping method: claim
I: Configuring IDP for cluster '<CLUSTER_NAME>'
I: Identity Provider 'github-1' has been created.
   It will take up to 1 minute for this configuration to be enabled.
   To add cluster administrators, see 'rosa grant user --help'.
   To login into the console, open https://console-openshift-console.apps.<CLUSTER_NAME>.<RANDOM_STRING>.p1.openshiftapps.com and click on github-1.
    참고

    ID 공급자 구성이 활성화되는 데 2분 정도 걸릴 수 있습니다. cluster-admin 사용자를 구성한 경우 oc get pods -n openshift-authentication --watch 명령을 실행하여 업데이트된 구성으로 OAuth 포드가 재배포되는 것을 관찰할 수 있습니다.

  8. ID 공급자가 올바르게 구성됐는지 확인합니다.

    rosa list idps --cluster=<CLUSTER_NAME>

구성된 자격 증명 공급자에 추가하여 사용자에게에 대한 액세스 권한을 부여할 수 클러스터 있습니다.

다음 절차는 클러스터에 ID를 프로비저닝하도록 구성된 GitHub 조직에 사용자를 추가합니다.

  1. github.com으로 이동하여 GitHub 계정에 로그인합니다.

  2. GitHub 조직에 클러스터 액세스해야 하는 사용자를 초대합니다. 자세한 내용은 GitHub 설명서에서 조직에 가입하도록 사용자 초대하기를 참조하세요.

  1. 다음 명령을 사용하여 cluster-admin 권한을 부여합니다. <IDP_USER_NAME> 및 <CLUSTER_NAME>을 사용자 및 클러스터 이름으로 바꿉니다.

    rosa grant user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. 사용자가 cluster-admins 그룹 구성원으로 등록되어 있는지 확인합니다.

    rosa list users --cluster=<CLUSTER_NAME>

  1. 다음 명령으로 dedicated-admin 권한을 부여합니다. <IDP_USER_NAME> 및 <CLUSTER_NAME>를 사용자 및 클러스터 이름으로 바꿉니다.

    rosa grant user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. 사용자가 cluster-admins 그룹 구성원으로 등록되어 있는지 확인합니다.

    rosa list users --cluster=<CLUSTER_NAME>

클러스터 관리자 사용자를 생성하거나 구성된 자격 증명 공급자에 사용자를 추가한 후 Red Hat Hybrid Cloud 콘솔을 클러스터 통해에 로그인할 수 있습니다.

  1. 다음 명령을 클러스터 사용하여의 콘솔 URL을 가져옵니다. 를의 이름으로 <CLUSTER_NAME> 바꿉니다 클러스터.

    rosa describe cluster -c <CLUSTER_NAME> | grep Console

  2. 출력에서 콘솔 URL로 이동하여 로그인합니다.

    • cluster-admin 사용자를 생성한 경우 제공된 보안 인증 정보를 사용하여 로그인합니다.

    • 에 대한 자격 증명 공급자를 구성한 경우 로그인... 대화 상자에서 자격 클러스터증명 공급자 이름을 선택하고 공급자가 제시한 권한 부여 요청을 완료합니다.

Red Hat 하이브리드 클라우드 콘솔에서 개발자 카탈로그 테스트 애플리케이션을 배포하고 경로를 통해 공개할 수 있습니다.

  1. Red Hat 하이브리드 클라우드 콘솔로 이동하여 앱을 배포할 클러스터를 선택합니다.

  2. 클러스터 페이지에서 콘솔 열기를 선택합니다.

  3. 관리자 시점에서 홈 > 프로젝트 > 프로젝트 생성을 선택합니다.

  4. 프로젝트 이름을 입력하고 선택적으로 표시 이름 및 설명을 추가합니다.

  5. 프로젝트를 생성하려면 생성을 선택합니다.

  6. 개발자 시점으로 전환하고 +추가를 선택합니다. 선택한 프로젝트가 방금 만든 프로젝트인지 확인합니다.

  7. 개발자 카탈로그 대화 상자에서 모든 서비스를 선택합니다.

  8. 개발자 카탈로그 페이지의 메뉴에서 언어 > JavaScript를 선택합니다.

  9. Node.js를 선택한 다음 애플리케이션 생성을 선택하여 Source-to-Image 애플리케이션 생성 페이지를 엽니다.

    참고

    Node.js 옵션을 표시하려면 모든 필터 지우기를 선택해야 할 수도 있습니다.

  10. Git 섹션에서 샘플 사용해보기를 선택합니다.

  11. 이름 필드에 고유한 이름을 추가합니다.

  12. 생성(Create)을 선택합니다.

    참고

    새 애플리케이션을 배포하는 데 몇 분 정도 걸립니다.

  13. 배포가 완료되면 애플리케이션 경로 URL을 선택합니다.

    브라우저의 새 탭이 열리고 다음과 비슷한 메시지가 표시됩니다.

    Welcome to your Node.js application on OpenShift

  14. (선택 사항) 애플리케이션을 삭제하고 리소스를 정리합니다.

    1. 관리자 시점에서 홈 > 프로젝트를 선택합니다.

    2. 프로젝트의 작업 메뉴를 열고 프로젝트 삭제를 선택합니다.

  1. 다음 명령을 사용하여 cluster-admin 권한을 취소합니다. <IDP_USER_NAME> 및 <CLUSTER_NAME>를 사용자 및 클러스터 이름으로 바꿉니다.

    rosa revoke user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. 사용자가 cluster-admins 그룹 구성원으로 등록되어 있지 않은지 확인합니다.

    rosa list users --cluster=<CLUSTER_NAME>

  1. 다음 명령을 사용하여 dedicated-admin 권한을 취소합니다. <IDP_USER_NAME> 및 <CLUSTER_NAME>를 사용자 및 클러스터 이름으로 바꿉니다.

    rosa revoke user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. 사용자가 dedicated-admins 그룹 구성원으로 등록되어 있지 않은지 확인합니다.

    rosa list users --cluster=<CLUSTER_NAME>

구성된 자격 증명 공급자에서 자격 증명 공급자를 제거하여 자격 증명 공급자 사용자의 클러스터 액세스를 취소할 수 있습니다.

클러스터에 다양한 ID 공급자 유형을 구성할 수 있습니다. 다음 절차는 GitHub 조직의 멤버에 대한 클러스터 액세스를 취소합니다.

  1. github.com으로 이동하여 GitHub 계정에 로그인합니다.

  2. GitHub 조직에서 사용자를 제거합니다. 자세한 내용은 GitHub 설명서에서 조직에서 사용자 제거하기를 참조하세요.

ROSA CLI를 사용하여 AWS Security Token Service ()를 사용하는 클러스터 를 삭제할 수 있습니다AWS STS. ROSA CLI를 사용하여에서 생성한 IAM 역할 및 OIDC 공급자를 삭제할 수도 있습니다 ROSA. 에서 생성한 IAM 정책을 삭제하려면 IAM 콘솔을 사용할 ROSA수 있습니다.

중요

IAM 에서 생성한 역할 및 정책은 동일한 계정의 다른 ROSA 클러스터에서 사용할 ROSA 수 있습니다.

  1. 를 삭제 클러스터 하고 로그를 확인합니다. <CLUSTER_NAME>을 클러스터이름 또는 ID로 바꿉니다.

    rosa delete cluster --cluster=<CLUSTER_NAME> --watch
    중요

    IAM 역할, 정책 및 OIDC 공급자 클러스터 를 제거하기 전에가 완전히 삭제될 때까지 기다려야 합니다. 설치 관리자가 생성한 리소스를 삭제하려면 계정 IAM 역할이 필요합니다. OpenShift 운영자가 생성한 리소스를 정리하려면 운영자 IAM 역할이 필요합니다. 운영자는 인증 시 OIDC 공급자를 사용합니다.

  2. 다음 명령을 실행하여 클러스터 운영자가 인증에 사용하는 OIDC 공급자를 삭제합니다.

    rosa delete oidc-provider -c <CLUSTER_ID> --mode auto

  3. 클러스터별 연산자 IAM 역할을 삭제합니다.

    rosa delete operator-roles -c <CLUSTER_ID> --mode auto

  4. 다음 명령을 사용하여 계정 IAM 역할을 삭제합니다. <PREFIX>를 삭제할 계정 IAM 역할의 접두사로 바꿉니다. 계정 IAM 역할을 생성할 때 사용자 지정 접두사를 지정한 경우 기본 ManagedOpenShift 접두사를 지정합니다.

    rosa delete account-roles --prefix <PREFIX> --mode auto

  5. 에서 생성한 IAM 정책을 삭제합니다 ROSA.

    1. IAM 콘솔에 로그인합니다.

    2. 왼쪽 메뉴의 액세스 관리에서 정책을 선택합니다.

    3. 삭제하려는 정책을 선택하고 작업 > 삭제를 선택합니다.

    4. 정책 이름을 입력하고 삭제를 선택합니다.

    5. 이 단계를 반복하여 클러스터에 대한 IAM 정책을 각각 삭제합니다.