클러스터 관리
AWS 클러스터에서 Red Hat OpenShift Service 구성
초록
1장. 프라이빗 연결 구성
1.1. 프라이빗 연결 구성
ROLE(Red Hat OpenShift Service on AWS) 환경의 요구 사항에 맞게 개인 클러스터 액세스를 구현할 수 있습니다.
절차
ROSA AWS 계정에 액세스하여 다음 방법 중 하나 이상을 사용하여 클러스터에 대한 개인 연결을 설정합니다.
- AWS VPC 피어링 구성: VPC 피어링 을 사용하여 두 개인 IP 주소 간에 네트워크 트래픽을 라우팅할 수 있습니다.
- AWS VPN 구성: 가상 사설 네트워크를 설정하여 프라이빗 네트워크를 Amazon Virtual Private Cloud에 안전하게 연결합니다.
- AWS Direct Connect 구성: 개인 네트워크와 AWS Direct Connect 위치 간의 전용 네트워크 연결을 설정하도록 AWS Direct Connect를 구성합니다.
- ROSA에서 개인 클러스터를 구성합니다.
1.2. AWS VPC 피어링 구성
이 샘플 프로세스는 다른 AWS VPC 네트워크와 피어링하기 위해 AWS 클러스터의 Red Hat OpenShift Service가 포함된 AWS(Amazon Web Services) VPC를 구성합니다. AWS VPC 피어링 연결 또는 기타 가능한 구성을 생성하는 방법에 대한 자세한 내용은 AWS VPC 피어링 가이드를 참조하십시오.
1.2.1. VPC 피어링 용어
두 개의 별도의 AWS 계정에서 두 VPC 간에 VPC 피어링 연결을 설정할 때 다음 용어가 사용됩니다.
| Red Hat OpenShift Service on AWS Account | AWS 클러스터의 Red Hat OpenShift Service가 포함된 AWS 계정입니다. |
| AWS Cluster VPC의 Red Hat OpenShift Service | AWS 클러스터의 Red Hat OpenShift Service가 포함된 VPC입니다. |
| 고객 AWS 계정 | 공유하려는 AWS 계정의 Red Hat OpenShift Service가 아닌 경우. |
| Customer VPC | 공유하려는 AWS 계정의 VPC입니다. |
| 고객 VPC 리전 | 고객의 VPC가 있는 리전입니다. |
2018년 7월 현재 AWS는 중국을 제외한 모든 상용 리전 간에 리전 간 VPC 피어링을 지원합니다.
1.2.2. VPC 피어 요청 시작
AWS 계정의 Red Hat OpenShift Service에서 고객 AWS 계정으로 VPC 피어링 연결 요청을 보낼 수 있습니다.
사전 요구 사항
피어 요청을 시작하는 데 필요한 고객 VPC에 대한 다음 정보를 수집합니다.
- 고객 AWS 계정 번호
- Customer VPC ID
- 고객 VPC 리전
- 고객 VPC CIDR
- AWS Cluster VPC의 Red Hat OpenShift Service에서 사용하는 CIDR 블록을 확인합니다. 고객 VPC의 CIDR 블록과 겹치거나 일치하는 경우 이 두 VPC 간의 피어링이 불가능합니다. 자세한 내용은 Amazon VPC Unsupported VPC Peering 구성 문서를 참조하십시오. CIDR 블록이 겹치지 않으면 절차를 계속할 수 있습니다.
절차
- AWS 계정의 Red Hat OpenShift Service용 웹 콘솔에 로그인하고 클러스터가 호스팅되는 리전의 VPC 대시 보드로 이동합니다.
- Peering Connections 페이지로 이동하여 Create Peering Connection 버튼을 클릭합니다.
로그인한 계정의 세부 정보와 연결 중인 계정 및 VPC의 세부 정보를 확인합니다.
- 피어링 연결 이름 태그: VPC 피어링 연결에 대한 설명적 이름을 설정합니다.
- VPC (Requester): 드롭다운 * 목록에서 AWS Cluster VPC ID에서 Red Hat OpenShift Service를 선택합니다.
- 계정: 다른 계정을 선택하고 고객 AWS 계정 *(대시 제외)를 입력합니다.
- 리전: Customer VPC Region이 현재 리전과 다른 경우 다른 리전 을 선택하고 드롭다운 목록에서 고객 VPC 리전을 선택합니다.
- VPC (Accepter): 고객 VPC ID 설정
- Create Peering Connection 을 클릭합니다.
- 요청이 Pending (보류 중) 상태가 되고 있는지 확인합니다. Failed 상태가 되면 세부 사항을 확인하고 프로세스를 반복합니다.
1.2.3. VPC 피어 요청 수락
VPC 피어링 연결을 생성한 후 고객 AWS 계정의 요청을 수락해야 합니다.
사전 요구 사항
- VPC 피어 요청을 시작합니다.
절차
- AWS 웹 콘솔에 로그인합니다.
- VPC 서비스로 이동합니다.
- 피어링 연결로 이동합니다.
- Pending peering 연결을 클릭합니다.
- 요청이 시작된 AWS 계정 및 VPC ID를 확인합니다. AWS 계정의 Red Hat OpenShift Service 및 AWS Cluster VPC의 Red Hat OpenShift Service에서 사용해야 합니다.
- 요청 수락 을 클릭합니다.
1.2.4. 라우팅 테이블 구성
VPC 피어링 요청을 수락한 후 두 VPC가 피어 연결 간에 통신하도록 경로를 구성해야 합니다.
사전 요구 사항
- VPC 피어 요청을 시작하고 수락합니다.
절차
- AWS 계정의 Red Hat OpenShift Service용 AWS 웹 콘솔에 로그인합니다.
- VPC 서비스로 이동한 다음 경로 표 로 이동합니다.
AWS Cluster VPC에서 Red Hat OpenShift Service의 경로 테이블을 선택합니다.
참고일부 클러스터에서는 특정 VPC에 대해 둘 이상의 라우팅 테이블이 있을 수 있습니다. 명시적으로 연결된 서브넷이 여러 개인 개인을 선택합니다.
- 경로 탭을 선택한 다음 편집 을 선택합니다.
- 대상 텍스트 상자에 Customer VPC CIDR 블록을 입력합니다.
- 대상 텍스트 상자에 피어링 연결 ID를 입력합니다.
- 저장을 클릭합니다.
다른 VPC의 CIDR 블록과 동일한 프로세스를 완료해야 합니다.
- 고객 AWS Web Console → VPC 서비스 → 경로 테이블에 로그인합니다.
- VPC의 경로 테이블을 선택합니다.
- 경로 탭을 선택한 다음 편집 을 선택합니다.
- 대상 텍스트 상자에 AWS Cluster VPC CIDR 블록을 Red Hat OpenShift Service를 입력합니다.
- 대상 텍스트 상자에 피어링 연결 ID를 입력합니다.
- 저장을 클릭합니다.
이제 VPC 피어링 연결이 완료되었습니다. 확인 절차에 따라 피어링 연결의 연결이 작동하는지 확인합니다.
1.2.5. VPC 피어링 확인 및 문제 해결
VPC 피어링 연결을 설정한 후에는 해당 연결이 구성되어 있고 올바르게 작동하는지 확인하는 것이 가장 좋습니다.
사전 요구 사항
- VPC 피어 요청을 시작하고 수락합니다.
- 라우팅 테이블을 구성합니다.
절차
AWS 콘솔에서 피어링된 클러스터 VPC의 경로 테이블을 확인합니다. 라우팅 테이블 구성 단계를 따르고 VPC CIDR 범위 대상을 피어링 연결 대상을 가리키는 경로 테이블 항목이 있는지 확인합니다.
경로가 AWS Cluster VPC 경로 테이블의 Red Hat OpenShift Service 테이블과 Customer VPC 경로 테이블 모두에서 올바르게 표시되면 아래의
netcat방법을 사용하여 연결을 테스트해야 합니다. 테스트 호출이 성공하면 VPC 피어링이 올바르게 작동합니다.엔드포인트 장치에 대한 네트워크 연결을 테스트하기 위해
nc(또는netcat)는 문제 해결에 유용한 도구입니다. 기본 이미지에 포함되어 있으며 연결을 설정할 수 있는 경우 빠르고 명확한 출력을 제공합니다.자체 후에 정리되는
busybox이미지를 사용하여 임시 Pod를 생성합니다.$ oc run netcat-test \ --image=busybox -i -t \ --restart=Never --rm \ -- /bin/shnc를 사용하여 연결을 확인합니다.연결 결과의 예:
/ nc -zvv 192.168.1.1 8080 10.181.3.180 (10.181.3.180:8080) open sent 0, rcvd 0
실패한 연결 결과의 예:
/ nc -zvv 192.168.1.2 8080 nc: 10.181.3.180 (10.181.3.180:8081): Connection refused sent 0, rcvd 0
컨테이너를 종료하면 Pod가 자동으로 삭제됩니다.
/ exit
1.3. AWS VPN 구성
이 샘플 프로세스는 고객의 온사이트 하드웨어 VPN 장치를 사용하도록 AWS(Amazon Web Services) Red Hat OpenShift Service를 구성합니다.
AWS VPN은 현재 VPN 트래픽에 NAT를 적용하는 관리형 옵션을 제공하지 않습니다. 자세한 내용은 AWS Knowledge Center 에서 참조하십시오.
개인 연결을 통해 모든 트래픽(예: 0.0.0.0/0 )을 라우팅하는 것은 지원되지 않습니다. 이를 위해서는 SRE 관리 트래픽을 비활성화하는 인터넷 게이트웨이를 삭제해야 합니다.
하드웨어 VPN 장치를 사용하여 AWS VPC를 원격 네트워크에 연결하는 방법에 대한 자세한 내용은 Amazon VPC VPN 연결 설명서를 참조하십시오.
1.3.1. VPN 연결 생성
다음 절차를 사용하여 고객의 현장 하드웨어 VPN 장치를 사용하도록 AWS 클러스터에서 AWS(Amazon Web Services) Red Hat OpenShift Service를 구성할 수 있습니다.
사전 요구 사항
- 하드웨어 VPN 게이트웨이 장치 모델 및 소프트웨어 버전 (예: Cisco ASA 버전 8.3을 실행함) AWS에서 게이트웨이 장치를 지원하는지 확인하려면 Amazon VPC 네트워크 관리자 가이드를 참조하십시오.
- VPN 게이트웨이 장치의 공용 고정 IP 주소입니다.
- BGP 또는 정적 라우팅: BGP인 경우 ASN이 필요합니다. 정적 라우팅인 경우 하나 이상의 정적 경로를 구성해야 합니다.
- 선택 사항: VPN 연결을 테스트하기 위한 연결 서비스의 IP 및 포트/프로토어입니다.
1.3.1.1. VPN 연결 구성
절차
- AWS AWS 계정 대시보드에서 Red Hat OpenShift Service에 로그인하고 VPC 대시보드로 이동합니다.
- VPC 를 클릭하고 AWS 클러스터에서 Red Hat OpenShift Service가 포함된 VPC의 이름과 VPC ID를 확인합니다.
- VPC 대시보드에서 Customer Gateway 를 클릭합니다.
- Create Customer Gateway 를 클릭하고 의미 있는 이름을 지정합니다.
- 라우팅 방법( Dynamic 또는 Static )을 선택합니다.
- Dynamic인 경우 표시되는 필드에 BGP ASN을 입력합니다.
- VPN 게이트웨이 끝점 IP 주소에 붙여넣습니다.
- 생성을 클릭합니다.
의도한 VPC에 가상 프라이빗 게이트웨이가 아직 연결되어 있지 않은 경우:
- VPC 대시보드에서 Virtual Private Gateway 를 클릭합니다.
- 가상 프라이빗 게이트웨이 만들기 를 클릭하고 의미 있는 이름을 지정한 다음 생성을 클릭합니다.
- 기본 Amazon 기본값 ASN을 그대로 둡니다.
- 새로 생성된 게이트웨이를 선택하고 VPC에 연결한 다음 이전에 확인한 클러스터 VPC에 연결합니다.
1.3.1.2. VPN 연결 설정
절차
- VPC 대시보드에서 사이트 간 VPN 연결을 클릭합니다.
VPN 연결 생성을 클릭합니다.
- 의미 있는 이름 태그를 지정합니다.
- 이전에 만든 가상 개인 게이트웨이를 선택합니다.
- Customer Gateway에 대해 Existing 을 선택합니다.
- 이름으로 고객 게이트웨이 장치를 선택합니다.
- VPN에서 BGP를 사용하는 경우 Dynamic 을 선택하고, 그렇지 않으면 Static 을 선택합니다. 고정 IP CIDR을 입력합니다. CIDR이 여러 개인 경우 각 CIDR을 Another Rule 으로 추가합니다.
- 생성을 클릭합니다.
- VPN 상태가 사용 가능 으로 변경될 때까지 약 5분에서 10분 정도 기다립니다.
방금 만든 VPN을 선택하고 구성 다운로드를 클릭합니다.
- 드롭다운 목록에서 고객 게이트웨이 장치의 공급 업체, 플랫폼 및 버전을 선택한 다음 다운로드를 클릭합니다.
- 일반 공급 업체 구성은 일반 텍스트 형식으로 정보를 검색하는 데도 사용할 수 있습니다.
VPN 연결이 설정된 후 Route Propagation을 설정하거나 VPN이 예상대로 작동하지 않을 수 있습니다.
구성에 추가해야 하는 VPC 서브넷 정보를 원격 네트워크로 기록해 둡니다.
1.3.1.3. VPN 경로 전파 활성화
VPN 연결을 설정한 후에는 필요한 경로가 VPC의 경로 테이블에 추가되도록 경로 전파가 활성화되어 있는지 확인해야 합니다.
절차
- VPC 대시보드에서 경로 테이블을 클릭합니다.
AWS 클러스터의 Red Hat OpenShift Service가 포함된 VPC와 연결된 프라이빗 경로 테이블을 선택합니다.
참고일부 클러스터에서는 특정 VPC에 대해 둘 이상의 라우팅 테이블이 있을 수 있습니다. 명시적으로 연결된 서브넷이 여러 개인 개인을 선택합니다.
- Route Propagation 탭을 클릭합니다.
표시되는 표에는 이전에 만든 가상 개인 게이트웨이가 표시되어야 합니다. Propagate 열의 값을 확인합니다.
- Propagate가 No 로 설정된 경우 경로 전파 편집 을 클릭하고 가상 개인 게이트웨이 이름 옆에 있는 Propagate 확인란을 선택한 다음 저장 을 클릭합니다.
VPN 터널을 구성하고 AWS가 이를 Up 으로 탐지하면 static 또는 BGP 경로가 경로 테이블에 자동으로 추가됩니다.
1.3.2. VPN 연결 확인
VPN 터널을 설정한 후에는 터널이 AWS 콘솔에 있고 터널이 작동하는지 확인할 수 있습니다.
사전 요구 사항
- VPN 연결을 생성했습니다.
절차
터널이 AWS에 있는지 확인합니다.
- VPC 대시보드에서 VPN 연결을 클릭합니다.
- 이전에 만든 VPN 연결을 선택하고 Details 탭을 클릭합니다.
- VPN 터널 중 하나 이상이 Up 임을 확인할 수 있습니다.
연결을 확인합니다.
엔드포인트 장치에 대한 네트워크 연결을 테스트하기 위해
nc(또는netcat)는 문제 해결에 유용한 도구입니다. 기본 이미지에 포함되어 있으며 연결을 설정할 수 있는 경우 빠르고 명확한 출력을 제공합니다.자체 후에 정리되는
busybox이미지를 사용하여 임시 Pod를 생성합니다.$ oc run netcat-test \ --image=busybox -i -t \ --restart=Never --rm \ -- /bin/shnc를 사용하여 연결을 확인합니다.연결 결과의 예:
/ nc -zvv 192.168.1.1 8080 10.181.3.180 (10.181.3.180:8080) open sent 0, rcvd 0
실패한 연결 결과의 예:
/ nc -zvv 192.168.1.2 8080 nc: 10.181.3.180 (10.181.3.180:8081): Connection refused sent 0, rcvd 0
컨테이너를 종료하면 Pod가 자동으로 삭제됩니다.
/ exit
1.3.3. VPN 연결 문제 해결
터널이 연결되지 않음
터널 연결이 여전히 Down 이면 다음과 같은 몇 가지 사항을 확인할 수 있습니다.
- AWS 터널은 VPN 연결을 시작하지 않습니다. 연결 시도는 고객 게이트웨이에서 시작되어야 합니다.
- 소스 트래픽이 구성된 고객 게이트웨이와 동일한 IP에서 제공되는지 확인합니다. AWS는 소스 IP 주소가 일치하지 않는 게이트웨이에 대한 모든 트래픽을 자동으로 삭제합니다.
- 구성이 AWS에서 지원하는 값과 일치하는지 확인합니다. 여기에는 IKE 버전, DH 그룹, IKE 수명 등이 포함됩니다.
- VPC의 경로 테이블을 다시 확인합니다. 전파가 활성화되어 있고 이전에 대상으로 만든 가상 개인 게이트웨이가 있는 경로 테이블에 항목이 있는지 확인합니다.
- 중단을 일으킬 수 있는 방화벽 규칙이 없는지 확인합니다.
- 정책 기반 VPN을 사용하고 있는지 확인합니다. 이로 인해 구성된 방법에 따라 복잡성이 발생할 수 있습니다.
- 추가 문제 해결 단계는 AWS Knowledge Center 에서 확인할 수 있습니다.
터널은 연결되어 있지 않습니다.
터널 연결에 지속적으로 유지되는 데 문제가 있는 경우 모든 AWS 터널 연결을 게이트웨이에서 시작해야 합니다. AWS 터널 은 터널링을 시작하지 않습니다.
Red Hat은 터널 옆에 SLA 모니터(Cisco ASA) 또는 일부 장치를 IP CIDR 범위 내에 구성된 모든 IP 주소로 "중요" 트래픽(예: ping,nc 또는 telnet )을 지속적으로 전송하는 것을 권장합니다. 연결이 성공하든 트래픽이 터널로 전달되는지 여부는 중요하지 않습니다.
Down 상태의 보조 터널
VPN 터널이 생성되면 AWS는 추가 페일오버 터널을 생성합니다. 게이트웨이 장치에 따라 보조 터널이 Down 상태로 표시되는 경우가 있습니다.
AWS 알림은 다음과 같습니다.
You have new non-redundant VPN connections One or more of your vpn connections are not using both tunnels. This mode of operation is not highly available and we strongly recommend you configure your second tunnel. View your non-redundant VPN connections.
1.4. AWS Direct Connect 구성
이 프로세스에서는 AWS의 Red Hat OpenShift Service에서 AWS Direct Connect 가상 인터페이스를 수락하는 방법을 설명합니다. AWS Direct Connect 유형 및 구성에 대한 자세한 내용은 AWS Direct Connect 구성 요소 설명서를 참조하십시오.
1.4.1. AWS Direct Connect 방법
Direct Connect 연결을 위해서는 Direct Connect Gateway(DXGateway)에 연결된 호스팅 가상 인터페이스(VIF)가 필요합니다. 이 인터페이스는 동일한 계정 또는 원격 VPC에 액세스하기 위해 VGW(Virtual Gateway) 또는 Transit Gateway에 연결됩니다.
기존 DXGateway가 없는 경우 일반적인 프로세스는 호스팅된 VIF 생성과 함께 AWS AWS 계정의 Red Hat OpenShift Service에서 DXGateway 및 VGW를 생성하는 것입니다.
하나 이상의 기존 VGW에 연결된 기존 DXGateway가 있는 경우 이 프로세스는 DXGateway 소유자로 association Proposal을 전송하는 AWS 계정의 Red Hat OpenShift Service를 포함합니다. DXGateway 소유자는 제안된 CIDR이 연결된 다른 VGW와 충돌하지 않는지 확인해야 합니다.
자세한 내용은 다음 AWS 설명서를 참조하십시오.
기존 DXGateway에 연결할 때 비용에 대한 책임이 있습니다.
다음 두 가지 구성 옵션을 사용할 수 있습니다.
| 방법 1 | 호스팅된 VIF를 만든 다음 DXGateway 및 VGW를 만듭니다. |
| 방법 2 | 보유 중인 기존 Direct Connect Gateway를 통해 연결을 요청합니다. |
1.4.2. 호스팅된 가상 인터페이스 생성
사전 요구 사항
- AWS 계정 ID에서 Red Hat OpenShift Service를 수집합니다.
1.4.2.1. Direct Connect 연결 유형 확인
Direct Connect 가상 인터페이스 세부 정보를 보고 연결 유형을 결정합니다.
절차
- AWS AWS 계정 대시보드에서 Red Hat OpenShift Service에 로그인하고 올바른 리전을 선택합니다.
- 서비스 메뉴에서 Direct Connect 를 선택합니다.
- 하나 이상의 가상 인터페이스가 수락되기를 기다리고 있으며 그 중 하나를 선택하여 요약 을 확인합니다.
- 가상 인터페이스 유형(공개 또는 공용) 보기.
- Amazon 사이드 ASN 값을 기록합니다.
Direct Connect 가상 인터페이스 유형이 프라이빗인 경우 가상 프라이빗 게이트웨이가 생성됩니다. Direct Connect Virtual Interface가 공용인 경우 Direct Connect Gateway가 생성됩니다.
1.4.2.2. 개인 직접 연결 생성
Direct Connect 가상 인터페이스 유형이 프라이빗인 경우 개인 Direct Connect가 생성됩니다.
절차
- AWS AWS 계정 대시보드에서 Red Hat OpenShift Service에 로그인하고 올바른 리전을 선택합니다.
- AWS 리전의 서비스 메뉴에서 VPC 를 선택합니다.
- VPN 연결에서 가상 개인 게이트웨이를 선택합니다.
- 가상 개인 게이트웨이 생성을 클릭합니다.
- 가상 개인 게이트웨이에 적절한 이름을 지정합니다.
- 사용자 지정 ASN 을 선택하고 이전에 수집한 Amazon 사이드 ASN 값을 입력합니다.
- 가상 개인 게이트웨이 만들기.
- 새로 생성된 가상 프라이빗 게이트웨이를 클릭하고 Actions 탭에서 VPC에 연결을 선택합니다.
- 목록에서 AWS Cluster VPC의 Red Hat OpenShift Service를 선택하고 VPC에 가상 프라이빗 게이트웨이를 연결합니다.
- Services 메뉴에서 Direct Connect 를 클릭합니다. 목록에서 직접 연결 가상 인터페이스 중 하나를 선택합니다.
- I understand that Direct Connect port charges apply once I click Accept Connection message, select Accept Connection 을 선택합니다.
- 가상 개인 게이트웨이 연결을 수락하고 이전 단계에서 만든 가상 개인 게이트웨이를 선택합니다.
- 연결을 수락 하려면 수락을 선택합니다.
- 가상 인터페이스가 두 개 이상인 경우 이전 단계를 반복합니다.
1.4.2.3. 공용 직접 연결 생성
Direct Connect 가상 인터페이스 유형이 공용인 경우 공용 Direct Connect가 생성됩니다.
절차
- AWS AWS 계정 대시보드에서 Red Hat OpenShift Service에 로그인하고 올바른 리전을 선택합니다.
- AWS 계정의 Red Hat OpenShift Service 리전의 서비스 메뉴에서 Direct Connect 를 선택합니다.
- Direct Connect Gateways 및 Direct Connect Gateway 만들기를 선택합니다.
- Direct Connect Gateway에 적절한 이름을 지정합니다.
- Amazon 측 ASN 에서 이전에 수집된 Amazon 사이드 ASN 값을 입력합니다.
- Direct Connect Gateway를 만듭니다.
- 서비스 메뉴에서 Direct Connect 를 선택합니다.
- 목록에서 Direct Connect Virtual Interfaces 중 하나를 선택합니다.
- I understand that Direct Connect port charges apply once I click Accept Connection message, select Accept Connection 을 선택합니다.
- Direct Connect Gateway 연결을 수락하고 이전 단계에서 만든 Direct Connect Gateway를 선택합니다.
- 수락 을 클릭하여 연결을 수락합니다.
- 가상 인터페이스가 두 개 이상인 경우 이전 단계를 반복합니다.
1.4.2.4. 가상 인터페이스 확인
Direct Connect 가상 인터페이스가 허용되면 단기간에 기다렸다가 인터페이스 상태를 확인합니다.
절차
- AWS AWS 계정 대시보드에서 Red Hat OpenShift Service에 로그인하고 올바른 리전을 선택합니다.
- AWS 계정의 Red Hat OpenShift Service 리전의 서비스 메뉴에서 Direct Connect 를 선택합니다.
- 목록에서 Direct Connect Virtual Interfaces 중 하나를 선택합니다.
- 인터페이스 상태가 사용가능한지 확인
- Interface BGP 상태가 Up 인지 확인합니다.
- 나머지 Direct Connect 인터페이스에 대해 이 확인을 반복합니다.
Direct Connect 가상 인터페이스를 사용할 수 있게 되면 AWS 계정 대시보드의 Red Hat OpenShift Service에 로그인하고 사이드 구성을 위해 Direct Connect 구성 파일을 다운로드할 수 있습니다.
1.4.3. 기존 Direct Connect 게이트웨이에 연결
사전 요구 사항
- AWS VPC에서 Red Hat OpenShift Service의 CIDR 범위가 연결된 다른 VGW와 충돌하지 않는지 확인합니다.
다음 정보를 수집합니다.
- Direct Connect Gateway ID입니다.
- 가상 인터페이스와 연결된 AWS 계정 ID입니다.
- DXGateway에 할당된 BGP ASN입니다. 선택사항: Amazon 기본 ASN도 사용할 수 있습니다.
절차
- AWS AWS 계정 대시보드에서 Red Hat OpenShift Service에 로그인하고 올바른 리전을 선택합니다.
- AWS 계정의 Red Hat OpenShift Service 리전의 서비스 메뉴에서 VPC 를 선택합니다.
- VPN 연결에서 가상 개인 게이트웨이를 선택합니다.
- 가상 개인 게이트웨이 생성을 선택합니다.
- 가상 개인 게이트웨이에 적절한 이름을 지정합니다.
- Custom ASN 을 클릭하고 이전에 수집된 Amazon 사이드 ASN 값을 입력하거나 Amazon Provided ASN을 사용합니다.
- 가상 개인 게이트웨이 만들기.
- AWS AWS 계정 대시보드의 Red Hat OpenShift Service 탐색 창에서 가상 개인 게이트웨이를 선택하고 가상 개인 게이트웨이를 선택합니다. 세부 정보 보기 를 선택합니다.
- Direct Connect 게이트웨이 연결을 선택하고 Direct Connect 게이트웨이 연결을 클릭합니다.
- terminate account type 에서 계정 소유자의 경우 Another account 를 선택합니다.
- Direct Connect 게이트웨이 소유자의 경우 Direct Connect 게이트웨이를 소유한 AWS 계정의 ID를 입력합니다.
- association 설정에서 Direct Connect 게이트웨이 ID에 대해 Direct Connect 게이트웨이의 ID를 입력합니다.
- association 설정에서 Virtual interface owner에 대해 연결을 위한 가상 인터페이스를 소유한 AWS 계정의 ID를 입력합니다.
- 선택 사항: 허용 접두사에 접두사를 추가하고 쉼표를 사용하여 분리합니다.
- Associate Direct Connect Gateway를 선택합니다.
- association 제안서를 보낸 후, 귀하의 수락을 기다리고 있을 것입니다. 수행해야 하는 최종 단계는 AWS 설명서에서 확인할 수 있습니다.
1.4.4. Direct Connect 문제 해결
추가 문제 해결은 AWS Direct Connect 문제 해결 설명서에서 확인할 수 있습니다.
2장. 노드
2.1. 머신 풀 정보
Red Hat OpenShift Service on AWS는 클라우드 인프라를 기반으로 시스템 풀을 탄력적이고 동적인 프로비저닝 방법으로 사용합니다.
기본 리소스는 시스템, 컴퓨팅 머신 세트, 시스템 풀입니다.
AWS 버전 4.8.35의 Red Hat OpenShift Service, 4.9.26, 4.10.6, AWS 기본값인 Red Hat OpenShift Service는 4096 입니다. 이 PID 제한을 활성화하려면 AWS 클러스터에서 이러한 버전 이상으로 Red Hat OpenShift Service를 업그레이드해야 합니다. 이전 버전이 있는 AWS 클러스터의 Red Hat OpenShift Service는 기본 PID 제한 1024 를 사용합니다.
AWS 클러스터의 모든 Red Hat OpenShift Service에서 Pod별 PID 제한을 구성할 수 없습니다.
2.1.1. Machine
머신은 작업자 노드의 호스트를 설명하는 기본 단위입니다.
2.1.2. 머신 세트
MachineSet 리소스는 컴퓨팅 머신 그룹입니다. 더 많은 시스템이 필요하거나 규모를 줄여야 하는 경우 컴퓨팅 시스템 세트가 속하는 시스템 풀의 복제본 수를 변경합니다.
머신 세트는 ROSA에서 직접 수정할 수 없습니다.
2.1.3. 머신 풀
머신 풀은 컴퓨팅 머신 세트에 대한 더 높은 수준의 구성 요소입니다.
시스템 풀은 모두 가용성 영역에서 동일한 구성을 복제하는 컴퓨팅 머신 세트를 생성합니다. 머신 풀은 작업자 노드에서 모든 호스트 노드 프로비저닝 관리 작업을 수행합니다. 더 많은 머신이 필요하거나 규모를 줄여야하는 경우 컴퓨팅 요구 사항에 맞게 시스템 풀의 복제본 수를 변경합니다. 스케일링을 수동으로 구성하거나 자동 스케일링을 설정할 수 있습니다.
기본적으로 클러스터에는 하나의 시스템 풀이 있습니다. 클러스터 설치 중에 이 머신 풀에 레이블을 지정할 수 있습니다. 클러스터가 설치되면 Default 머신 풀을 삭제할 수 없으며 해당 노드 유형 또는 크기를 변경할 수 없습니다.
클러스터 설치 후 다음을 수행합니다.
-
기본머신 풀의 레이블을 다시 지정할 수 있습니다. 기존 클러스터에 머신 풀을 추가할 수 있습니다.
참고머신 풀 노드 유형 또는 크기는 변경할 수 없습니다. 머신 풀 노드 유형 또는 크기는 생성 중에만 지정됩니다. 다른 노드 유형 또는 크기가 필요한 경우 머신 풀을 다시 생성하고 필요한 노드 유형 또는 크기 값을 지정해야 합니다.
- 추가된 각 머신 풀에 레이블을 추가할 수 있습니다.
-
Default머신 풀을 삭제할 수 없습니다. 그러나 기본이 아닌 머신 풀을 삭제할 수 있습니다.
단일 클러스터에 여러 머신 풀이 존재할 수 있으며 각 머신 풀에는 고유한 노드 유형 및 노드 크기 구성이 포함될 수 있습니다.
2.1.4. 여러 영역 클러스터의 머신 풀
다중 가용성 영역(Multi-AZ) 클러스터에 머신 풀을 생성할 때 하나의 머신 풀에 3개의 영역이 있습니다. 시스템 풀은 차례로 클러스터의 각 영역에 하나씩 총 3개의 컴퓨팅 머신 세트를 생성합니다. 각 컴퓨팅 시스템 세트는 해당 가용성 영역에 있는 하나 이상의 시스템을 관리합니다.
새 Multi-AZ 클러스터를 생성하면 머신 풀이 해당 영역에 자동으로 복제됩니다. 기존 Multi-AZ에 머신 풀을 추가하면 해당 영역에 새 풀이 자동으로 생성됩니다. 마찬가지로 머신 풀을 삭제하면 모든 영역에서 삭제됩니다. 이러한 다기능 효과 때문에 Multi-AZ 클러스터에서 머신 풀을 사용하면 머신 풀을 생성할 때 특정 리전에 더 많은 프로젝트의 할당량을 사용할 수 있습니다.
2.1.5. 추가 리소스
2.2. 컴퓨팅 노드 관리
이 문서에서는 ROSA(Red Hat OpenShift Service on AWS)를 사용하여 컴퓨팅(작업자라고도 함) 노드를 관리하는 방법을 설명합니다.
컴퓨팅 노드의 대부분의 변경 사항은 시스템 풀에 구성됩니다. 머신 풀은 동일한 구성이 있어 쉽게 관리할 수 있는 클러스터의 컴퓨팅 노드 그룹입니다.
스케일링, 노드 레이블 추가, 테인트 추가와 같은 머신 풀 구성 옵션을 편집할 수 있습니다.
2.2.1. 머신 풀 생성
ROSA(Red Hat OpenShift Service) 클러스터에 Red Hat OpenShift Service를 설치할 때 기본 머신 풀이 생성됩니다. 설치 후 OpenShift Cluster Manager 또는 ROSA CLI(rosa)를 사용하여 클러스터에 대한 추가 머신 풀을 생성할 수 있습니다.
2.2.1.1. OpenShift Cluster Manager를 사용하여 머신 풀 생성
OpenShift Cluster Manager를 사용하여 ROSA(Red Hat OpenShift Service on AWS) 클러스터에 대한 추가 머신 풀을 생성할 수 있습니다.
사전 요구 사항
- ROSA 클러스터를 생성하셨습니다.
절차
- OpenShift Cluster Manager Hybrid Cloud Console 로 이동하여 클러스터를 선택합니다.
- 머신 풀 탭에서 머신 풀 추가 를 클릭합니다.
- 머신 풀 이름을 추가합니다.
드롭다운 메뉴에서 작업자 노드 인스턴스 유형을 선택합니다. 인스턴스 유형은 시스템 풀의 각 계산 노드에 대한 vCPU 및 메모리 할당을 정의합니다.
참고풀을 생성한 후에는 머신 풀의 인스턴스 유형을 변경할 수 없습니다.
선택 사항: 머신 풀의 자동 스케일링을 구성합니다.
- 배포 요구에 맞게 자동 스케일링 활성화를 선택하여 머신 풀의 머신 수를 자동으로 스케일링합니다.
자동 스케일링에 대한 최소 및 최대 노드 수 제한을 설정합니다. 클러스터 자동 스케일러는 지정한 제한을 초과하여 머신 풀 노드 수를 줄이거나 늘리지 않습니다.
- 단일 가용성 영역을 사용하여 클러스터를 배포한 경우 최소 및 최대 노드 수 를 설정합니다. 이는 가용성 영역에 최소 및 최대 컴퓨팅 노드 제한을 정의합니다.
여러 가용성 영역을 사용하여 클러스터를 배포한 경우 영역당 최소 노드 및 영역당 최대 노드를 설정합니다. 이는 영역당 최소 및 최대 컴퓨팅 노드 제한을 정의합니다.
참고또는 머신 풀을 생성한 후 머신 풀에 대한 자동 스케일링 기본 설정을 설정할 수 있습니다.
자동 스케일링을 활성화하지 않은 경우 컴퓨팅 노드 수를 선택합니다.
- 단일 가용성 영역을 사용하여 클러스터를 배포한 경우 드롭다운 메뉴에서 작업자 노드 수 를 선택합니다. 이 명령은 영역의 시스템 풀에 프로비저닝할 컴퓨팅 노드 수를 정의합니다.
- 여러 가용성 영역을 사용하여 클러스터를 배포한 경우 드롭다운 메뉴에서 작업자 노드 수(지역당) 를 선택합니다. 이는 영역당 시스템 풀에 프로비저닝할 컴퓨팅 노드 수를 정의합니다.
선택사항: 머신 풀의 노드 레이블 및 테인트를 추가합니다.
- Edit node labels and taints 메뉴를 확장합니다.
- 노드 라벨 에서 노드 레이블에 대한 Key 및 Value 항목을 추가합니다.
- 테인트에서 테인트의 키 및 값 항목을 추가합니다.
각 테인트에 대해 드롭다운 메뉴에서 Effect 를 선택합니다. 사용 가능한 옵션에는
NoSchedule,PreferNoSchedule및NoExecute가 포함됩니다.참고또는 머신 풀을 생성한 후 노드 레이블 및 테인트를 추가할 수 있습니다.
선택 사항: 머신 풀을 구성하여 보장되지 않는 AWS Spot 인스턴스로 머신을 구성하려면 Amazon EC2 Spot 인스턴스를 사용합니다.
- Amazon EC2 Spot 인스턴스 사용을 선택합니다.
온 디맨드 인스턴스 가격을 사용하도록 선택한 온 디맨드 인스턴스 가격은 그대로 둡니다. 또는 최대 가격 설정을 선택하여 Spot 인스턴스의 최대 시간당 가격을 정의합니다.
Amazon EC2 Spot 인스턴스에 대한 자세한 내용은 AWS 설명서 를 참조하십시오.
중요언제든지 Amazon EC2 Spot 인스턴스가 중단될 수 있습니다. 중단을 허용할 수 있는 워크로드에만 Amazon EC2 Spot 인스턴스를 사용합니다.
참고머신 풀에 Amazon EC2 Spot 인스턴스 사용을 선택하는 경우 머신 풀을 생성한 후에는 옵션을 비활성화할 수 없습니다.
- 머신 풀 추가 를 클릭하여 머신 풀을 생성합니다.
검증
- 시스템 풀이 머신 풀 페이지에 표시되고 구성이 예상대로 표시되는지 확인합니다.
2.2.1.2. ROSA CLI를 사용하여 머신 풀 생성
ROSA CLI(로사 )를 사용하여 ROSA(Red Hat OpenShift Service on AWS) 클러스터에 대한 추가 머신 풀을 생성할 수있습니다.
사전 요구 사항
-
워크스테이션에 최신 Red Hat OpenShift Service on AWS(ROSA) CLI
를설치하고 구성하셨습니다. -
ROSA CLI(
rosa)를 사용하여 Red Hat 계정에 로그인했습니다. - ROSA 클러스터를 생성하셨습니다.
절차
자동 스케일링을 사용하지 않는 머신 풀을 추가하려면 머신 풀을 생성하고 인스턴스 유형, 컴퓨팅(작업자) 노드 수 및 노드 레이블을 정의합니다.
$ rosa create machinepool --cluster=<cluster-name> \ --name=<machine_pool_id> \ 1 --replicas=<replica_count> \ 2 --instance-type=<instance_type> \ 3 --labels=<key>=<value>,<key>=<value> \ 4 --taints=<key>=<value>:<effect>,<key>=<value>:<effect> \ 5 --use-spot-instances \ 6 --spot-max-price=0.5 7- 1
- 시스템 풀의 이름을 지정합니다. &
lt;machine_pool_id>를 머신 풀 이름으로 바꿉니다. - 2
- 프로비저닝할 컴퓨팅 노드 수를 지정합니다. 단일 가용성 영역을 사용하여 ROSA를 배포한 경우 영역의 머신 풀에 프로비저닝할 컴퓨팅 노드 수를 정의합니다. 여러 가용성 영역을 사용하여 클러스터를 배포하는 경우 모든 영역에서 총 프로비저닝할 컴퓨팅 노드 수를 정의하고 개수는 3개 중 일부여야 합니다. 자동 스케일링이 구성되지 않은 경우
--replicas인수가 필요합니다. - 3
- 선택 사항: 시스템 풀의 컴퓨팅 노드의 인스턴스 유형을 설정합니다. 인스턴스 유형은 풀의 각 계산 노드에 대한 vCPU 및 메모리 할당을 정의합니다. <
;instance_type>을 인스턴스 유형으로 바꿉니다. 기본값은m5.xlarge입니다. 풀을 생성한 후에는 머신 풀의 인스턴스 유형을 변경할 수 없습니다. - 4
- 선택 사항: 머신 풀의 레이블을 정의합니다. <
key>=<value>,<key>=<value>를 쉼표로 구분된 키-값 쌍 목록(예:--labels=key1=value1,key2=value2)로 바꿉니다. - 5
- 선택 사항: 머신 풀의 테인트를 정의합니다. <
key>=<value>:<effect>,<key>=<value>:<effect>:<effect>를 각 테인트의 키, 값 및 효과(예:--taints=key1=value1:NoSchedule,key2=value2:NoSchedule,key2=value2:NoExecute)로 바꿉니다. 사용 가능한 효과에는NoSchedule,PreferNoSchedule및NoExecute가 포함됩니다. - 6
- 선택 사항: 머신 풀을 구성하여 머신을 보장되지 않는 AWS Spot 인스턴스로 배포합니다. 자세한 내용은 AWS 문서의 Amazon EC2 Spot 인스턴스를 참조하십시오. 머신 풀에 Amazon EC2 Spot 인스턴스 사용을 선택하는 경우 머신 풀을 생성한 후에는 옵션을 비활성화할 수 없습니다.
- 7
- 선택 사항: Spot 인스턴스를 사용하도록 선택한 경우 이 인수를 지정하여 Spot 인스턴스의 최대 시간당 가격을 정의할 수 있습니다. 이 인수를 지정하지 않으면 온 디맨드 가격이 사용됩니다.
중요언제든지 Amazon EC2 Spot 인스턴스가 중단될 수 있습니다. 중단을 허용할 수 있는 워크로드에만 Amazon EC2 Spot 인스턴스를 사용합니다.
다음 예제에서는
m5.xlarge인스턴스 유형을 사용하고 컴퓨팅 노드 복제본이 2개인mymachinepool이라는 시스템 풀을 생성합니다. 이 예제에서는 두 개의 워크로드별 라벨도 추가합니다.$ rosa create machinepool --cluster=mycluster --name=mymachinepool --replicas=2 --instance-type=m5.xlarge --labels=app=db,tier=backend
출력 예
I: Machine pool 'mymachinepool' created successfully on cluster 'mycluster' I: To view all machine pools, run 'rosa list machinepools -c mycluster'
자동 스케일링을 사용하는 머신 풀을 추가하려면 머신 풀을 생성하고 자동 스케일링 구성, 인스턴스 유형 및 노드 레이블을 정의합니다.
$ rosa create machinepool --cluster=<cluster-name> \ --name=<machine_pool_id> \ 1 --enable-autoscaling \ 2 --min-replicas=<minimum_replica_count> \ 3 --max-replicas=<maximum_replica_count> \ 4 --instance-type=<instance_type> \ 5 --labels=<key>=<value>,<key>=<value> \ 6 --taints=<key>=<value>:<effect>,<key>=<value>:<effect> \ 7 --use-spot-instances \ 8 --spot-max-price=0.5 9- 1
- 시스템 풀의 이름을 지정합니다. &
lt;machine_pool_id>를 머신 풀 이름으로 바꿉니다. - 2
- 머신 풀에서 자동 스케일링을 활성화하여 배포 요구 사항을 충족할 수 있습니다.
- 3 4
- 최소 및 최대 컴퓨팅 노드 제한을 정의합니다. 클러스터 자동 스케일러는 지정한 제한을 초과하여 머신 풀 노드 수를 줄이거나 늘리지 않습니다. 단일 가용성 영역을 사용하여 ROSA를 배포한 경우
--min-replicas및--max-replicas인수는 영역의 시스템 풀에 자동 스케일링 제한을 정의합니다. 여러 가용성 영역을 사용하여 클러스터를 배포하는 경우 인수는 모든 영역에서 총 자동 스케일링 제한을 정의하고 개수는 3개여야 합니다. - 5
- 선택 사항: 시스템 풀의 컴퓨팅 노드의 인스턴스 유형을 설정합니다. 인스턴스 유형은 풀의 각 계산 노드에 대한 vCPU 및 메모리 할당을 정의합니다. <
;instance_type>을 인스턴스 유형으로 바꿉니다. 기본값은m5.xlarge입니다. 풀을 생성한 후에는 머신 풀의 인스턴스 유형을 변경할 수 없습니다. - 6
- 선택 사항: 머신 풀의 레이블을 정의합니다. <
key>=<value>,<key>=<value>를 쉼표로 구분된 키-값 쌍 목록(예:--labels=key1=value1,key2=value2)로 바꿉니다. - 7
- 선택 사항: 머신 풀의 테인트를 정의합니다. <
key>=<value>:<effect>,<key>=<value>:<effect>:<effect>를 각 테인트의 키, 값 및 효과(예:--taints=key1=value1:NoSchedule,key2=value2:NoSchedule,key2=value2:NoExecute)로 바꿉니다. 사용 가능한 효과에는NoSchedule,PreferNoSchedule및NoExecute가 포함됩니다. - 8
- 선택 사항: 머신 풀을 구성하여 머신을 보장되지 않는 AWS Spot 인스턴스로 배포합니다. 자세한 내용은 AWS 문서의 Amazon EC2 Spot 인스턴스를 참조하십시오. 머신 풀에 Amazon EC2 Spot 인스턴스 사용을 선택하는 경우 머신 풀을 생성한 후에는 옵션을 비활성화할 수 없습니다.
- 9
- 선택 사항: Spot 인스턴스를 사용하도록 선택한 경우 이 인수를 지정하여 Spot 인스턴스의 최대 시간당 가격을 정의할 수 있습니다. 이 인수를 지정하지 않으면 온 디맨드 가격이 사용됩니다.
중요언제든지 Amazon EC2 Spot 인스턴스가 중단될 수 있습니다. 중단을 허용할 수 있는 워크로드에만 Amazon EC2 Spot 인스턴스를 사용합니다.
다음 예제에서는
m5.xlarge인스턴스 유형을 사용하고 자동 스케일링이 활성화된mymachinepool이라는 시스템 풀을 생성합니다. 최소 컴퓨팅 노드 제한은 3이며 최대값은 총 6개입니다. 이 예제에서는 두 개의 워크로드별 라벨도 추가합니다.$ rosa create machinepool --cluster=mycluster --name=mymachinepool --enable-autoscaling --min-replicas=3 --max-replicas=6 --instance-type=m5.xlarge --labels=app=db,tier=backend
출력 예
I: Machine pool 'mymachinepool' created successfully on cluster 'mycluster' I: To view all machine pools, run 'rosa list machinepools -c mycluster'
검증
클러스터에서 사용 가능한 머신 풀을 나열합니다.
$ rosa list machinepools --cluster=<cluster_name>
출력 예
ID AUTOSCALING REPLICAS INSTANCE TYPE LABELS TAINTS AVAILABILITY ZONES SPOT INSTANCES Default No 3 m5.xlarge us-east-1a, us-east-1b, us-east-1c N/A mymachinepool Yes 3-6 m5.xlarge app=db, tier=backend us-east-1a, us-east-1b, us-east-1c No
- 시스템 풀이 출력에 포함되어 있고 구성이 예상대로 구성되어 있는지 확인합니다.
추가 리소스
-
rosa create machinepool하위 명령에 사용할 수 있는 인수의 자세한 목록은 ROSA CLI를 사용하여 오브젝트 관리를 참조하십시오.
2.2.2. 머신 풀 삭제
워크로드 요구 사항이 변경되고 현재 머신 풀이 더 이상 요구 사항을 충족하지 않는 경우 머신 풀을 삭제할 수 있습니다.
Openshift Cluster Manager 또는 ROSA CLI(rosa)를 사용하여 머신 풀을 삭제할 수 있습니다.
기본 머신 풀은 삭제할 수 없습니다.
2.2.2.1. OpenShift Cluster Manager를 사용하여 머신 풀 삭제
OpenShift Cluster Manager를 사용하여 AWS(ROSA) 클러스터에서 Red Hat OpenShift Service의 머신 풀을 삭제할 수 있습니다.
사전 요구 사항
- ROSA 클러스터를 생성하셨습니다.
- 클러스터가 ready 상태입니다.
- 테인트 없이 기존 머신 풀이 있고 단일 AZ 클러스터용 인스턴스가 두 개 이상 있거나 다중 AZ 클러스터의 경우 세 개의 인스턴스가 있습니다.
절차
- OpenShift Cluster Manager Hybrid Cloud Console 에서 Clusters 페이지로 이동하여 삭제할 시스템 풀이 포함된 클러스터를 선택합니다.
- 선택한 클러스터에서 머신 풀 탭을 선택합니다.
-
머신 풀 탭에서 삭제하려는 머신 풀의 옵션 메뉴
를 클릭합니다.
- 삭제를 클릭합니다.
선택한 머신 풀이 삭제됩니다.
2.2.2.2. ROSA CLI를 사용하여 머신 풀 삭제
ROSA CLI를 사용하여 AWS(ROSA) 클러스터에서 Red Hat OpenShift Service의 머신 풀을 삭제할 수 있습니다.
사전 요구 사항
- ROSA 클러스터를 생성하셨습니다.
- 클러스터가 ready 상태입니다.
- 테인트 없이 기존 머신 풀이 있고 단일 AZ 클러스터용 인스턴스가 두 개 이상 있거나 다중 AZ 클러스터의 경우 세 개의 인스턴스가 있습니다.
절차
ROSA CLI에서 다음 명령을 실행합니다.
$ rosa delete machinepool -c=<cluster_name> <machine_pool_ID>
출력 예
? Are you sure you want to delete machine pool <machine_pool_ID> on cluster <cluster_name>? (y/N)
'y'를 입력하여 머신 풀을 삭제합니다.
선택한 머신 풀이 삭제됩니다.
2.2.3. 수동으로 컴퓨팅 노드 확장
머신 풀에 자동 스케일링을 활성화하지 않은 경우 배포 요구에 맞게 풀의 컴퓨팅 (작업자라고도 함) 노드 수를 수동으로 스케일링할 수 있습니다.
각 머신 풀을 별도로 스케일링해야 합니다.
사전 요구 사항
-
워크스테이션에 최신 Red Hat OpenShift Service on AWS(ROSA) CLI
를설치하고 구성하셨습니다. -
ROSA CLI(
rosa)를 사용하여 Red Hat 계정에 로그인했습니다. - ROSA(Red Hat OpenShift Service on AWS) 클러스터를 생성하셨습니다.
- 기존 머신 풀이 있습니다.
절차
클러스터의 머신 풀을 나열합니다.
$ rosa list machinepools --cluster=<cluster_name>
출력 예
ID AUTOSCALING REPLICAS INSTANCE TYPE LABELS TAINTS AVAILABILITY ZONES default No 2 m5.xlarge us-east-1a mp1 No 2 m5.xlarge us-east-1a
머신 풀에서 컴퓨팅 노드 복제본 수를 늘리거나 줄입니다.
$ rosa edit machinepool --cluster=<cluster_name> \ --replicas=<replica_count> \ 1 <machine_pool_id> 2
검증
클러스터에서 사용 가능한 머신 풀을 나열합니다.
$ rosa list machinepools --cluster=<cluster_name>
출력 예
ID AUTOSCALING REPLICAS INSTANCE TYPE LABELS TAINTS AVAILABILITY ZONES default No 2 m5.xlarge us-east-1a mp1 No 3 m5.xlarge us-east-1a
-
이전 명령의 출력에서 계산 노드 복제본 수가 시스템 풀에 대해 예상대로 표시되는지 확인합니다. 예제 출력에서 iPXE
1머신 풀의 컴퓨팅 노드 복제본 수가 3으로 확장됩니다.
2.2.4. 노드 라벨
레이블은 Node 오브젝트에 적용되는 키-값 쌍입니다. 라벨을 사용하여 오브젝트 세트를 구성하고 Pod 예약을 제어할 수 있습니다.
클러스터 생성 중 또는 이후에 라벨을 추가할 수 있습니다. 레이블은 언제든지 수정하거나 업데이트할 수 있습니다.
추가 리소스
- 라벨에 대한 자세한 내용은 Kubernetes 라벨 및 선택자 개요를 참조하십시오.
2.2.4.1. 머신 풀에 노드 라벨 추가
언제든지 compute(작업자라고도 함) 노드의 라벨을 추가하거나 편집하여 사용자와 관련된 방식으로 노드를 관리합니다. 예를 들어 특정 노드에 워크로드 유형을 할당할 수 있습니다.
레이블은 키-값 쌍으로 할당됩니다. 각 키는 할당된 오브젝트에 고유해야 합니다.
사전 요구 사항
-
워크스테이션에 최신 Red Hat OpenShift Service on AWS(ROSA) CLI
를설치하고 구성하셨습니다. -
ROSA CLI(
rosa)를 사용하여 Red Hat 계정에 로그인했습니다. - ROSA(Red Hat OpenShift Service on AWS) 클러스터를 생성하셨습니다.
- 기존 머신 풀이 있습니다.
절차
클러스터의 머신 풀을 나열합니다.
$ rosa list machinepools --cluster=<cluster_name>
출력 예
ID AUTOSCALING REPLICAS INSTANCE TYPE LABELS TAINTS AVAILABILITY ZONES SPOT INSTANCES Default No 2 m5.xlarge us-east-1a N/A db-nodes-mp No 2 m5.xlarge us-east-1a No
머신 풀의 노드 레이블을 추가하거나 업데이트합니다.
자동 스케일링을 사용하지 않는 머신 풀의 노드 레이블을 추가하거나 업데이트하려면 다음 명령을 실행합니다.
$ rosa edit machinepool --cluster=<cluster_name> \ --replicas=<replica_count> \ 1 --labels=<key>=<value>,<key>=<value> \ 2 <machine_pool_id>- 1
- 자동 스케일링을 사용하지 않는 머신 풀의 경우 노드 라벨을 추가할 때 복제본 수를 제공해야 합니다.
--replicas인수를 지정하지 않으면 명령이 완료되기 전에 복제본 수를 입력하라는 메시지가 표시됩니다. 단일 가용성 영역을 사용하여 AWS(ROSA)에 Red Hat OpenShift Service를 배포한 경우 복제본 수는 영역의 시스템 풀에 프로비저닝할 컴퓨팅 노드 수를 정의합니다. 여러 가용성 영역을 사용하여 클러스터를 배포하는 경우 count는 모든 영역에 걸쳐 시스템 풀의 총 컴퓨팅 노드 수를 정의하고 3개 중 여러 개여야 합니다. - 2
- <
key>=<value>,<key>=<value>를 쉼표로 구분된 키-값 쌍 목록(예:--labels=key1=value1,key2=value2)로 바꿉니다. 이 목록은 노드 레이블에 대한 변경 사항을 지속적으로 덮어씁니다.
다음 예제에서는
db-nodes-mp머신 풀에 라벨을 추가합니다.$ rosa edit machinepool --cluster=mycluster --replicas=2 --labels=app=db,tier=backend db-nodes-mp
출력 예
I: Updated machine pool 'db-nodes-mp' on cluster 'mycluster'
자동 스케일링을 사용하는 머신 풀의 노드 레이블을 추가하거나 업데이트하려면 다음 명령을 실행합니다.
$ rosa edit machinepool --cluster=<cluster_name> \ --min-replicas=<minimum_replica_count> \ 1 --max-replicas=<maximum_replica_count> \ 2 --labels=<key>=<value>,<key>=<value> \ 3 <machine_pool_id>- 1 2
- 자동 스케일링을 사용하는 머신 풀의 경우 최소 및 최대 컴퓨팅 노드 복제본 제한을 제공해야 합니다. 인수를 지정하지 않으면 명령이 완료되기 전에 값을 입력하라는 메시지가 표시됩니다. 클러스터 자동 스케일러는 지정한 제한을 초과하여 머신 풀 노드 수를 줄이거나 늘리지 않습니다. 단일 가용성 영역을 사용하여 ROSA를 배포한 경우
--min-replicas및--max-replicas인수는 영역의 시스템 풀에 자동 스케일링 제한을 정의합니다. 여러 가용성 영역을 사용하여 클러스터를 배포하는 경우 인수는 모든 영역에서 총 자동 스케일링 제한을 정의하고 개수는 3개여야 합니다. - 3
- <
key>=<value>,<key>=<value>를 쉼표로 구분된 키-값 쌍 목록(예:--labels=key1=value1,key2=value2)로 바꿉니다. 이 목록은 노드 레이블에 대한 변경 사항을 지속적으로 덮어씁니다.
다음 예제에서는
db-nodes-mp머신 풀에 라벨을 추가합니다.$ rosa edit machinepool --cluster=mycluster --min-replicas=2 --max-replicas=3 --labels=app=db,tier=backend db-nodes-mp
출력 예
I: Updated machine pool 'db-nodes-mp' on cluster 'mycluster'
검증
클러스터에서 사용 가능한 머신 풀을 나열합니다.
$ rosa list machinepools --cluster=<cluster_name>
출력 예
ID AUTOSCALING REPLICAS INSTANCE TYPE LABELS TAINTS AVAILABILITY ZONES SPOT INSTANCES Default No 2 m5.xlarge us-east-1a N/A db-nodes-mp No 2 m5.xlarge app=db, tier=backend us-east-1a No
- 출력의 시스템 풀에 레이블이 포함되어 있는지 확인합니다.
2.2.5. 머신 풀에 테인트 추가
머신 풀에서 compute(작업자라고도 함) 노드의 테인트를 추가하여 예약된 Pod를 제어할 수 있습니다. 머신 풀에 테인트를 적용하면 Pod 사양에 테인트에 대한 허용 오차가 포함되지 않는 한 스케줄러는 풀의 노드에 Pod를 배치할 수 없습니다. 테인트는 OpenShift Cluster Manager 또는 Red Hat OpenShift Service on AWS(ROSA) CLI, rosa 를 사용하여 머신 풀에 추가할 수 있습니다.
클러스터에 테인트가 포함되지 않은 하나 이상의 머신 풀이 있어야 합니다.
2.2.5.1. Openshift Cluster Manager를 사용하여 머신 풀에 테인트 추가
OpenShift Cluster Manager를 사용하여 AWS(ROSA) 클러스터의 Red Hat OpenShift Service에 대한 머신 풀에 테인트를 추가할 수 있습니다.
사전 요구 사항
- ROSA(Red Hat OpenShift Service on AWS) 클러스터를 생성하셨습니다.
- 기존 머신 풀에는 테인트가 포함되지 않고 두 개 이상의 인스턴스가 포함됩니다.
절차
- OpenShift Cluster Manager Hybrid Cloud Console 로 이동하여 클러스터를 선택합니다.
-
머신 풀 탭에서 테인트를 추가할 머신 풀의 옵션 메뉴
를 클릭합니다.
- 테인트 편집을 선택합니다.
- 테인트에 대한 키 및 값 항목을 추가합니다.
-
드롭다운 메뉴에서 테인트의 영향을 선택합니다. 사용 가능한 옵션에는
NoSchedule,PreferNoSchedule및NoExecute가 포함됩니다. - 선택 사항: 머신 풀에 테인트 를 추가하려면 테인트 추가를 선택합니다.
- 저장을 클릭하여 머신 풀에 테인트를 적용합니다.
검증
- 머신 풀 탭에서 머신 풀 옆에 있는 >을 선택하여 뷰를 확장합니다.
- 확장된 보기의 Taints 아래에 테인트가 나열되어 있는지 확인합니다.
2.2.5.2. ROSA CLI를 사용하여 머신 풀에 테인트 추가
ROSA CLI를 사용하여 AWS(ROSA) 클러스터의 Red Hat OpenShift Service에 대한 머신 풀에 테인트를 추가할 수 있습니다.
사전 요구 사항
-
워크스테이션에 최신 AWS(
aws), ROSA(rosa), OpenShift(oc) CLI를 설치하고 구성하셨습니다. -
rosaCLI를 사용하여 Red Hat 계정에 로그인했습니다. - ROSA(Red Hat OpenShift Service on AWS) 클러스터를 생성하셨습니다.
- 기존 머신 풀에는 테인트가 포함되지 않고 두 개 이상의 인스턴스가 포함됩니다.
절차
다음 명령을 실행하여 클러스터의 머신 풀을 나열합니다.
$ rosa list machinepools --cluster=<cluster_name>
출력 예
ID AUTOSCALING REPLICAS INSTANCE TYPE LABELS TAINTS AVAILABILITY ZONES SPOT INSTANCES Default No 2 m5.xlarge us-east-1a N/A db-nodes-mp No 2 m5.xlarge us-east-1a No
머신 풀의 테인트를 추가하거나 업데이트합니다.
자동 스케일링을 사용하지 않는 머신 풀의 테인트를 추가하거나 업데이트하려면 다음 명령을 실행합니다.
$ rosa edit machinepool --cluster=<cluster_name> \ --replicas=<replica_count> \ 1 --taints=<key>=<value>:<effect>,<key>=<value>:<effect> \ 2 <machine_pool_id>- 1
- 자동 스케일링을 사용하지 않는 머신 풀의 경우 테인트를 추가할 때 복제본 수를 제공해야 합니다.
--replicas인수를 지정하지 않으면 명령이 완료되기 전에 복제본 수를 입력하라는 메시지가 표시됩니다. 단일 가용성 영역을 사용하여 AWS(ROSA)에 Red Hat OpenShift Service를 배포한 경우 복제본 수는 영역의 시스템 풀에 프로비저닝할 컴퓨팅 노드 수를 정의합니다. 여러 가용성 영역을 사용하여 클러스터를 배포하는 경우 count는 모든 영역에 걸쳐 시스템 풀의 총 컴퓨팅 노드 수를 정의하고 3개 중 여러 개여야 합니다. - 2
- <
key>=<value>:<effect>,<key>=<value>:<effect>:<effect>를 각 테인트의 키, 값 및 효과(예:--taints=key1=value1:NoSchedule,key2=value2:NoSchedule,key2=value2:NoExecute)로 바꿉니다. 사용 가능한 효과에는NoSchedule,PreferNoSchedule및NoExecute가 포함됩니다. 이 목록은 노드 테인트에 대한 수정 사항을 지속적으로 덮어씁니다.
다음 예제에서는
db-nodes-mp머신 풀에 테인트를 추가합니다.$ rosa edit machinepool --cluster=mycluster --replicas 2 --taints=key1=value1:NoSchedule,key2=value2:NoExecute db-nodes-mp
출력 예
I: Updated machine pool 'db-nodes-mp' on cluster 'mycluster'
자동 스케일링을 사용하는 머신 풀의 테인트를 추가하거나 업데이트하려면 다음 명령을 실행합니다.
$ rosa edit machinepool --cluster=<cluster_name> \ --min-replicas=<minimum_replica_count> \ 1 --max-replicas=<maximum_replica_count> \ 2 --taints=<key>=<value>:<effect>,<key>=<value>:<effect> \ 3 <machine_pool_id>- 1 2
- 자동 스케일링을 사용하는 머신 풀의 경우 최소 및 최대 컴퓨팅 노드 복제본 제한을 제공해야 합니다. 인수를 지정하지 않으면 명령이 완료되기 전에 값을 입력하라는 메시지가 표시됩니다. 클러스터 자동 스케일러는 지정한 제한을 초과하여 머신 풀 노드 수를 줄이거나 늘리지 않습니다. 단일 가용성 영역을 사용하여 ROSA를 배포한 경우
--min-replicas및--max-replicas인수는 영역의 시스템 풀에 자동 스케일링 제한을 정의합니다. 여러 가용성 영역을 사용하여 클러스터를 배포하는 경우 인수는 모든 영역에서 총 자동 스케일링 제한을 정의하고 개수는 3개여야 합니다. - 3
- <
key>=<value>:<effect>,<key>=<value>:<effect>:<effect>를 각 테인트의 키, 값 및 효과(예:--taints=key1=value1:NoSchedule,key2=value2:NoSchedule,key2=value2:NoExecute)로 바꿉니다. 사용 가능한 효과에는NoSchedule,PreferNoSchedule및NoExecute가 포함됩니다. 이 목록은 노드 테인트에 대한 모든 수정 사항을 지속적으로 덮어씁니다.
다음 예제에서는
db-nodes-mp머신 풀에 테인트를 추가합니다.$ rosa edit machinepool --cluster=mycluster --min-replicas=2 --max-replicas=3 --taints=key1=value1:NoSchedule,key2=value2:NoExecute db-nodes-mp
출력 예
I: Updated machine pool 'db-nodes-mp' on cluster 'mycluster'
검증
다음 명령을 실행하여 클러스터에서 사용 가능한 머신 풀을 나열합니다.
$ rosa list machinepools --cluster=<cluster_name>
출력 예
ID AUTOSCALING REPLICAS INSTANCE TYPE LABELS TAINTS AVAILABILITY ZONES SPOT INSTANCES Default No 2 m5.xlarge us-east-1a N/A db-nodes-mp No 2 m5.xlarge key1=value1:NoSchedule, key2=value2:NoExecute us-east-1a No
- 출력에서 머신 풀에 테인트가 포함되어 있는지 확인합니다.
2.2.6. 머신 풀에 노드 튜닝 추가
머신 풀에서 컴퓨팅 (작업자라고도 함) 노드의 튜닝을 추가하여 구성을 제어할 수 있습니다.
사전 요구 사항
-
워크스테이션에 최신 Red Hat OpenShift Service on AWS(ROSA) CLI
를설치하고 구성하셨습니다. -
ROSA CLI(
rosa)를 사용하여 Red Hat 계정에 로그인했습니다. - ROSA 클러스터를 생성하셨습니다.
- 기존 머신 풀이 있습니다.
- 기존 튜닝 구성이 있어야 합니다.
절차
클러스터의 머신 풀을 나열합니다.
$ rosa list machinepools --cluster=<cluster_name>
출력 예
ID AUTOSCALING REPLICAS INSTANCE TYPE LABELS TAINTS AVAILABILITY ZONES SUBNET VERSION AUTOREPAIR TUNING CONFIGS MESSAGE Default No 2 m5.xlarge us-east-1a N/A 4.12.14 Yes db-nodes-mp No 2 m5.xlarge us-east-1a No 4.12.14 Yes
기존 또는 새 머신 풀에 튜닝 구성을 추가할 수 있습니다.
머신 풀을 생성할 때 튜닝을 추가합니다.
$ rosa create machinepool -c <cluster-name> <machinepoolname> --tuning-configs <tuning_config_name>
출력 예
? Tuning configs: sample-tuning I: Machine pool 'db-nodes-mp' created successfully on hosted cluster 'sample-cluster' I: To view all machine pools, run 'rosa list machinepools -c sample-cluster'
머신 풀의 튜닝을 추가하거나 업데이트합니다.
$ rosa edit machinepool -c <cluster-name> <machinepoolname> --tuning-configs <tuningconfigname>
출력 예
I: Updated machine pool 'db-nodes-mp' on cluster 'mycluster'
검증
클러스터에서 사용 가능한 머신 풀을 나열합니다.
$ rosa list machinepools --cluster=<cluster_name>
출력 예
ID AUTOSCALING REPLICAS INSTANCE TYPE LABELS TAINTS AVAILABILITY ZONES SUBNET VERSION AUTOREPAIR TUNING CONFIGS MESSAGE Default No 2 m5.xlarge us-east-1a N/A 4.12.14 Yes db-nodes-mp No 2 m5.xlarge us-east-1a No 4.12.14 Yes sample-tuning
- 출력에서 머신 풀에 튜닝 구성이 포함되어 있는지 확인합니다.
2.2.7. 추가 리소스
2.3. 로컬 영역에서 머신 풀 구성
이 문서에서는 ROSA(Red Hat OpenShift Service on AWS)를 사용하여 시스템 풀에서 로컬 영역을 구성하는 방법을 설명합니다.
2.3.1. 로컬 영역에서 머신 풀 구성
다음 단계를 사용하여 로컬 영역에서 시스템 풀을 구성합니다.
AWS 로컬 영역은 AWS 4.12의 Red Hat OpenShift Service에서 지원됩니다. 로컬 영역 활성화 방법에 대한 자세한 내용은 Red Hat Knowledgebase 문서를 참조하십시오.
사전 요구 사항
- Red Hat OpenShift Service on AWS (ROSA)는 일반적으로 선택한 상위 리전에서 사용할 수 있습니다. 특정 AWS 리전에서 사용할 수 있는 로컬 영역을 확인하려면 AWS 일반적으로 사용 가능한 위치 목록을 참조하십시오.
- ROSA 클러스터는 처음에 기존 Amazon VPC(BYO-VPC)로 구축되었습니다.
ROSA 클러스터의 최대 전송 단위(MTU)는 1200으로 설정됩니다.
중요일반적으로 로컬 영역의 Amazon EC2 인스턴스와 리전의 Amazon EC2 인스턴스 간 최대 전송 단위(MTU)는 1300입니다. AWS 문서 의 로컬 영역 작동 방식을 참조하십시오. 오버헤드를 설명하려면 클러스터 네트워크 MTU가 항상 EC2 MTU보다 작아야 합니다. 특정 오버헤드는 네트워크 플러그인에 의해 결정됩니다. 예를 들면 다음과 같습니다.
-
OVN-Kubernetes:
100바이트 -
OpenShift SDN:
50바이트
네트워크 플러그인은 MTU를 줄일 수 있는 추가 기능을 제공할 수 있습니다. 자세한 내용은 설명서를 확인하십시오.
-
OVN-Kubernetes:
- AWS 계정에는 로컬 영역이 활성화되어 있습니다.
- AWS 계정에는 클러스터와 동일한 VPC에 대한 로컬 영역 서브넷 이 있습니다.
- AWS 계정에는 NAT 게이트웨이로의 경로가 있는 라우팅 테이블과 연결된 서브넷이 있습니다.
- AWS 계정에는 연결된 서브넷에 'kubernetes.io/cluster/<infra_id>: shared' 태그가 있습니다.
절차
다음 ROSA CLI(
rosa) 명령을 실행하여 클러스터에 머신 풀을 만듭니다.$ rosa create machinepool -c <cluster-name> -i
ROSA CLI에서 머신 풀의 서브넷 및 인스턴스 유형을 추가합니다. 몇 분 후에 클러스터에서 노드를 프로비저닝합니다.
I: Enabling interactive mode 1 ? Machine pool name: xx-lz-xx 2 ? Create multi-AZ machine pool: No 3 ? Select subnet for a single AZ machine pool (optional): Yes 4 ? Subnet ID: subnet-<a> (region-info) 5 ? Enable autoscaling (optional): No 6 ? Replicas: 2 7 I: Fetching instance types 8
- 로컬 영역에서 머신 풀을 프로비저닝할 서브넷 ID를 제공합니다.
일반적으로 사용 가능한 AWS 로컬 영역 위치 목록은 AWS 로컬 영역의 AWS 로컬 영역 목록을 참조하십시오.
2.4. 클러스터의 노드 자동 스케일링 정보
자동 스케일러 옵션은 클러스터의 머신 수를 자동으로 확장하도록 구성할 수 있습니다.
리소스가 부족하여 현재 노드에서 pod를 예약할 수 없거나 배포 요구를 충족시키기 위해 다른 노드가 필요한 경우 클러스터 자동 스케일러는 클러스터 크기를 늘립니다. 클러스터 자동 스케일러는 사용자가 지정한 제한을 초과하여 클러스터 리소스를 늘리지 않습니다.
또한 클러스터 자동 스케일러는 리소스 사용이 적고 중요한 pod가 모두 다른 노드에 적합한 경우와 같이 상당한 기간 동안 일부 노드가 지속적으로 필요하지 않은 경우 클러스터 크기를 줄입니다.
자동 스케일링을 활성화하는 경우 최소 및 최대 작업자 노드 수를 설정해야 합니다.
클러스터 소유자 및 조직 관리자만 클러스터를 확장하거나 삭제할 수 있습니다.
2.4.1. 클러스터에서 노드 자동 스케일링 활성화
작업자 노드에서 자동 스케일링을 활성화하여 기존 클러스터에 대한 머신 풀 정의를 편집하여 사용 가능한 노드 수를 늘리거나 줄일 수 있습니다.
Red Hat OpenShift Cluster Manager를 사용하여 기존 클러스터에서 노드 자동 스케일링 활성화
OpenShift Cluster Manager 콘솔에서 머신 풀 정의에서 작업자 노드에 대한 자동 스케일링을 활성화합니다.
절차
- OpenShift Cluster Manager Hybrid Cloud Console 에서 클러스터 페이지로 이동하여 자동 스케일링을 활성화할 클러스터를 선택합니다.
- 선택한 클러스터에서 머신 풀 탭을 선택합니다.
-
자동 스케일링을 활성화하려는 머신 풀 끝에 있는 옵션 메뉴
를 클릭하고 스케일링을 선택합니다.
- 노드 수 편집 대화 상자에서 자동 스케일링 활성화 확인란을 선택합니다.
- 적용을 선택하여 이러한 변경 사항을 저장하고 클러스터에 대한 자동 스케일링을 활성화합니다.
또한 대화식 모드를 사용하여 클러스터를 생성할 때 기본 머신 풀에서 자동 스케일링을 구성할 수도 있습니다.
ROSA CLI를 사용하여 기존 클러스터에서 노드 자동 스케일링 활성화
로드를 기반으로 작업자 노드 수를 동적으로 확장 또는 축소하도록 자동 스케일링을 구성합니다.
자동 스케일링은 AWS 계정에 올바른 AWS 리소스 할당량을 보유하는 데 따라 달라집니다. AWS 콘솔에서 리소스 할당량 및 요청 할당량 증가를 확인합니다.
절차
클러스터에서 머신 풀 ID를 식별하려면 다음 명령을 입력합니다.
$ rosa list machinepools --cluster=<cluster_name>
출력 예
ID AUTOSCALING REPLICAS INSTANCE TYPE LABELS TINTS AVAILABILITY ZONES default No 2 m5.xlarge us-east-1a mp1 No 2 m5.xlarge us-east-1a
- 구성할 머신 풀의 ID를 가져옵니다.
머신 풀에서 자동 스케일링을 활성화하려면 다음 명령을 입력합니다.
$ rosa edit machinepool --cluster=<cluster_name> <machinepool_ID> --enable-autoscaling --min-replicas=<number> --max-replicas=<number>
예제
2에서 5개의 작업자 노드 사이를 스케일링하도록 복제본 수가 설정된
mycluster클러스터에서 ID iPXE1이 있는 머신 풀에서 자동 스케일링을 활성화합니다.$ rosa edit machinepool --cluster=mycluster mp1 --enable-autoscaling --min-replicas=2 --max-replicas=5
2.4.2. 클러스터에서 자동 스케일링 노드 비활성화
작업자 노드에서 자동 스케일링을 비활성화하여 기존 클러스터에 대한 머신 풀 정의를 편집하여 사용 가능한 노드 수를 늘리거나 줄일 수 있습니다.
OpenShift Cluster Manager 콘솔 또는 AWS CLI의 Red Hat OpenShift Service를 사용하여 클러스터에서 자동 스케일링을 비활성화할 수 있습니다.
또한 대화식 모드를 사용하여 클러스터를 생성할 때 기본 머신 풀에서 자동 스케일링을 구성할 수도 있습니다.
Red Hat OpenShift Cluster Manager를 사용하여 기존 클러스터에서 자동 스케일링 노드 비활성화
OpenShift Cluster Manager 콘솔에서 시스템 풀 정의에서 작업자 노드의 자동 스케일링을 비활성화합니다.
절차
- OpenShift Cluster Manager Hybrid Cloud Console 에서 클러스터 페이지로 이동하여 비활성화해야 하는 자동 스케일링으로 클러스터를 선택합니다.
- 선택한 클러스터에서 머신 풀 탭을 선택합니다.
-
자동 스케일링을 사용하여 머신 풀 끝에 있는 옵션 메뉴
를 클릭하고 스케일링 을 선택합니다.
- "노드 수 편집" 대화 상자에서 Enable autoscaling 확인란을 선택 취소합니다.
- 적용을 선택하여 이러한 변경 사항을 저장하고 클러스터에서 자동 스케일링을 비활성화합니다.
ROSA CLI를 사용하여 기존 클러스터에서 자동 스케일링 노드 비활성화
ROSA(Red Hat OpenShift Service on AWS) CLI, rosa 를 사용하여 시스템 풀 정의에서 작업자 노드의 자동 스케일링을 비활성화합니다.
절차
다음 명령을 실행합니다.
$ rosa edit machinepool --cluster=<cluster_name> <machinepool_ID> --enable-autoscaling=false --replicas=<number>
예제
mycluster라는 클러스터에서기본머신 풀에서 자동 스케일링을 비활성화합니다.$ rosa edit machinepool --cluster=mycluster default --enable-autoscaling=false --replicas=3