3.11. AWS 로컬 영역에 컴퓨팅 노드로 클러스터 설치
install-config.yaml
파일의 에지 컴퓨팅 풀에 영역 이름을 설정하거나 로컬 영역 서브넷이 있는 기존 Amazon VPC(Virtual Private Cloud)에 클러스터를 설치하여 AWS(Amazon Web Services) 로컬 영역에 OpenShift Container Platform 클러스터를 빠르게 설치할 수 있습니다.
AWS 로컬 영역은 대도시 지역에 클라우드 리소스를 배치하는 인프라입니다. 자세한 내용은 AWS 로컬 영역 문서를 참조하십시오.
3.11.1. 인프라 사전 요구 사항
- OpenShift Container Platform 설치 및 업데이트 프로세스에 대한 세부 사항을 검토했습니다.
- 클러스터 설치 방법 선택 및 사용자를 위한 준비에 익숙합니다.
클러스터를 호스팅할 AWS 계정을 구성했습니다.
주의컴퓨터에 AWS 프로필이 저장되어 있는 경우 다단계 인증 장치를 사용하는 동안 생성한 임시 세션 토큰을 해당 프로필이 사용해서는 안 됩니다. 클러스터는 클러스터의 전체 수명 동안 현재 AWS 인증 정보를 계속 사용하여 AWS 리소스를 생성하므로 키 기반 장기 인증 정보를 사용해야 합니다. 적절한 키를 생성하려면 AWS 문서의 IAM 사용자의 액세스 키 관리를 참조하십시오. 설치 프로그램을 실행할 때 키를 제공할 수 있습니다.
- AWS CLI를 다운로드하여 컴퓨터에 설치했습니다. AWS 문서의 번들 설치 관리자를 사용하여 AWS CLI 설치(Linux, macOS 또는 UNIX) 를 참조하십시오.
- 방화벽을 사용하는 경우 클러스터가 액세스해야 하는 사이트를 허용하도록 방화벽을 구성했습니다.
- 리전과 지원되는 AWS 로컬 영역 위치를 기록하여 네트워크 리소스를 생성합니다.
- AWS 문서에서 AWS 로컬 영역 기능을 읽습니다.
IAM(Identity and Access Management) 사용자 또는 역할에 AWS 로컬 영역을 지원하는 네트워크 리소스를 생성하는 권한을 추가했습니다. 다음 예제에서는 AWS Local Zones를 지원하는 네트워크 리소스를 생성하기 위해 사용자 또는 역할 액세스를 제공할 수 있는 영역 그룹을 활성화합니다.
IAM 사용자 또는 역할에 연결된
ec2:ModifyAvailabilityZoneGroup
권한이 있는 추가 IAM 정책의 예.{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:ModifyAvailabilityZoneGroup" ], "Effect": "Allow", "Resource": "*" } ] }
3.11.2. AWS 로컬 영역 및 엣지 컴퓨팅 풀 정보
다음 섹션을 읽고 AWS 로컬 영역 환경의 인프라 동작 및 클러스터 제한 사항을 파악합니다.
3.11.2.1. AWS 로컬 영역의 클러스터 제한 사항
AWS(Amazon Web Services) 로컬 영역에 기본 설치 구성으로 클러스터를 배포하려고 할 때 몇 가지 제한 사항이 있습니다.
다음 목록은 사전 구성된 AWS 영역에 클러스터를 배포할 때 제한 사항입니다.
-
영역의 Amazon EC2 인스턴스와 리전의 Amazon EC2 인스턴스 간 MTU(최대 전송 단위)는
1300
입니다. 이로 인해 배포와 함께 사용되는 네트워크 플러그인에 따라 클러스터 전체 네트워크 MTU가 변경됩니다. - NLB(Network Load Balancer), Classic Load Balancer 및 NAT(Network Address Translation) 게이트웨이와 같은 네트워크 리소스는 전역적으로 지원되지 않습니다.
-
AWS의 OpenShift Container Platform 클러스터의 경우 AWS EBS(Elastic Block Storage)
gp3
유형 볼륨이 노드 볼륨의 기본값이며 스토리지 클래스의 기본값입니다. 이 볼륨 유형은 영역 위치에서 전역적으로 사용할 수 없습니다. 기본적으로 영역에서 실행되는 노드는gp2
EBS 볼륨으로 배포됩니다. 영역 노드에서 워크로드를 생성할 때gp2-csi
StorageClass
매개변수를 설정해야 합니다.
설치 프로그램이 OpenShift Container Platform 클러스터의 로컬 영역 서브넷을 자동으로 생성하도록 하려면 이 방법을 사용하여 특정 구성 제한 사항이 적용됩니다.
다음 설정 제한은 설치 프로그램을 설정하여 OpenShift Container Platform 클러스터의 서브넷을 자동으로 생성할 때 적용됩니다.
- 설치 프로그램이 AWS Local Zones에서 프라이빗 서브넷을 생성할 때 프로그램은 각 서브넷을 상위 영역의 경로 테이블에 연결합니다. 이 작업을 수행하면 각 프라이빗 서브넷이 AWS 리전의 NAT 게이트웨이를 통해 송신 트래픽을 인터넷으로 라우팅할 수 있습니다.
- 클러스터 설치 중에 상위 영역 경로 테이블이 없는 경우 설치 프로그램은 프라이빗 서브넷을 Amazon VPC(Virtual Private Cloud)에서 사용 가능한 첫 번째 프라이빗 경로 테이블에 연결합니다. 이 방법은 OpenShift Container Platform 클러스터의 AWS 로컬 영역 서브넷에만 유효합니다.
3.11.2.2. 엣지 컴퓨팅 풀 정보
엣지 컴퓨팅 노드는 AWS 로컬 영역 위치에서 실행되는 테인트된 컴퓨팅 노드입니다.
로컬 영역을 사용하는 클러스터를 배포할 때 다음 사항을 고려하십시오.
- 로컬 영역의 Amazon EC2 인스턴스는 가용성 영역의 Amazon EC2 인스턴스보다 비용이 많이 듭니다.
- AWS Local Zones에서 실행되는 애플리케이션과 최종 사용자 간에 대기 시간이 낮습니다. 예를 들어 Ingress 트래픽이 로컬 영역과 가용성 영역 간에 혼합되는 경우 일부 워크로드에 대기 시간 영향이 있습니다.
일반적으로 로컬 영역의 Amazon EC2 인스턴스와 리전의 Amazon EC2 인스턴스 간 MTU(최대 전송 단위)는 1300입니다. 오버헤드를 고려하려면 클러스터 네트워크 MTU가 EC2 MTU보다 항상 작아야 합니다. 특정 오버헤드는 네트워크 플러그인에 의해 결정됩니다. 예를 들어 OVN-Kubernetes에는 100바이트
의 오버헤드가 있습니다.
네트워크 플러그인은 MTU 크기 조정에도 영향을 미치는 IPsec과 같은 추가 기능을 제공할 수 있습니다.
자세한 내용은 AWS 문서에서 로컬 영역이 작동하는 방법을 참조하십시오.
OpenShift Container Platform 4.12에서는 원격 영역에서 사용하도록 설계된 새로운 컴퓨팅 풀 에지 를 도입했습니다. 엣지 컴퓨팅 풀 구성은 AWS 로컬 영역 위치 간에 일반적입니다. 로컬 영역 리소스의 EC2 및 EBS와 같은 리소스의 유형 및 크기 제한으로 인해 기본 인스턴스 유형은 기존 컴퓨팅 풀에 따라 다를 수 있습니다.
로컬 영역의 기본 EBS(Elastic Block Store) 위치는 GPG 2
이며, 이는 최신이 아닌 컴퓨팅 풀과 다릅니다. 에지 컴퓨팅 풀의 각 로컬 영역에 사용되는 인스턴스 유형도 영역에 있는 인스턴스에 따라 다른 컴퓨팅 풀과 다를 수 있습니다.
엣지 컴퓨팅 풀은 개발자가 AWS 로컬 영역 노드에 애플리케이션을 배포하는 데 사용할 수 있는 새 레이블을 생성합니다. 새 레이블은 다음과 같습니다.
-
node-role.kubernetes.io/edge=''
-
machine.openshift.io/zone-type=local-zone
-
machine.openshift.io/zone-group=$ZONE_GROUP_NAME
기본적으로 에지 컴퓨팅 풀의 머신 세트는 다른 워크로드가 로컬 영역 인스턴스에 분배되지 않도록 NoSchedule
의 테인트를 정의합니다. 사용자는 Pod 사양에서 허용 오차를 정의하는 경우에만 사용자 워크로드를 실행할 수 있습니다.
3.11.3. 설치 사전 요구 사항
AWS 로컬 영역 환경에 클러스터를 설치하기 전에 로컬 영역 기능을 채택할 수 있도록 인프라를 구성해야 합니다.
3.11.3.1. AWS 로컬 영역 선택
AWS 로컬 영역에서 서브넷을 만들려면 각 영역 그룹을 별도로 선택해야 합니다.
사전 요구 사항
- AWS CLI를 설치했습니다.
- OpenShift Container Platform 클러스터를 배포할 AWS 리전을 확인했습니다.
- 영역 그룹에 옵트인하는 사용자 또는 역할 계정에 허용 IAM 정책을 연결했습니다.
프로세스
다음 명령을 실행하여 AWS 리전에서 사용할 수 있는 영역을 나열합니다.
AWS 리전에서 사용 가능한 AWS 로컬 영역을 나열하는 명령의 예
$ aws --region "<value_of_AWS_Region>" ec2 describe-availability-zones \ --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \ --filters Name=zone-type,Values=local-zone \ --all-availability-zones
AWS 리전에 따라 사용 가능한 영역 목록이 길 수 있습니다. 이 명령은 다음 필드를 반환합니다.
ZoneName
- 로컬 영역의 이름입니다.
GroupName
- 영역으로 구성된 그룹입니다. 리전을 선택하려면 이름을 저장합니다.
상태
-
로컬 영역 그룹의 상태입니다.
상태가opted-in
인 경우 다음 단계에 설명된 대로GroupName
을 선택해야 합니다.
다음 명령을 실행하여 AWS 계정의 영역 그룹을 선택합니다.
$ aws ec2 modify-availability-zone-group \ --group-name "<value_of_GroupName>" \1 --opt-in-status opted-in
- 1
- &
lt;value_of_GroupName
>을 서브넷을 만들 로컬 영역의 그룹 이름으로 바꿉니다. 예를 들어us-east-1-nyc-1
A 영역을 사용하려면us-east-1-nyc-1a
를 지정합니다(미국 동부 뉴질랜드).
3.11.3.2. AWS Marketplace 이미지 가져오기
AWS Marketplace 이미지를 사용하여 OpenShift Container Platform 클러스터를 배포하는 경우 먼저 AWS를 통해 등록해야 합니다. 이 프로모션을 구독하면 설치 프로그램이 컴퓨팅 노드를 배포하는 데 사용하는 AMI ID가 제공됩니다.
사전 요구 사항
- 서비스를 구매할 AWS 계정이 있습니다. 이 계정은 클러스터를 설치하는 데 사용되는 계정과 같을 필요는 없습니다.
프로세스
- AWS Marketplace 에서 OpenShift Container Platform 서브스크립션을 완료합니다.
특정 AWS 리전의 AMI ID를 기록합니다. 설치 프로세스의 일부로 클러스터를 배포하기 전에
install-config.yaml
파일을 이 값으로 업데이트해야 합니다.AWS Marketplace 컴퓨팅 노드가 있는 샘플
install-config.yaml
파일apiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker platform: aws: amiID: ami-06c4d345f7c207239 1 type: m5.4xlarge replicas: 3 metadata: name: test-cluster platform: aws: region: us-east-2 2 sshKey: ssh-ed25519 AAAA... pullSecret: '{"auths": ...}'
3.11.4. 설치 준비
노드를 로컬 영역으로 확장하기 전에 클러스터 설치 환경을 위한 특정 리소스를 준비해야 합니다.
3.11.4.1. 클러스터 설치를 위한 최소 리소스 요구 사항
각 클러스터 시스템이 다음과 같은 최소 요구사항을 충족해야 합니다.
머신 | 운영 체제 | vCPU [1] | 가상 RAM | 스토리지 | 초당 입력/출력(IOPS)[2] |
---|---|---|---|---|---|
부트스트랩 | RHCOS | 4 | 16GB | 100GB | 300 |
컨트롤 플레인 | RHCOS | 4 | 16GB | 100GB | 300 |
Compute | RHCOS, RHEL 8.6 이상 [3] | 2 | 8GB | 100GB | 300 |
- SMT(동시 멀티 스레딩) 또는 Hyper-Threading이 활성화되지 않은 경우 하나의 vCPU는 하나의 물리적 코어와 동일합니다. 활성화하면 다음과 같은 공식을 사용하여 해당 비율을 계산합니다. (코어 당 스레드 수 × 코어 수) × 소켓 수 = vCPU 수
- OpenShift Container Platform 및 Kubernetes는 디스크 성능에 민감하며 특히 10ms p99 fsync 기간이 필요한 컨트롤 플레인 노드의 etcd에 더 빠른 스토리지가 권장됩니다. 많은 클라우드 플랫폼에서 스토리지 크기와 IOPS를 함께 확장되므로 충분한 성능을 얻으려면 스토리지 볼륨을 과도하게 할당해야 할 수 있습니다.
- 사용자가 프로비저닝한 모든 설치와 마찬가지로 클러스터에서 RHEL 컴퓨팅 머신을 사용하기로 선택한 경우 시스템 업데이트 수행, 패치 적용 및 기타 필요한 모든 작업 실행을 포함한 모든 운영 체제의 라이프 사이클 관리 및 유지 관리에 대한 책임이 있습니다. RHEL 7 컴퓨팅 머신 사용은 더 이상 사용되지 않으며 OpenShift Container Platform 4.10 이상에서 제거되었습니다.
OpenShift Container Platform 버전 4.13부터 RHCOS는 RHEL 버전 9.2를 기반으로 하며 마이크로 아키텍처 요구 사항을 업데이트합니다. 다음 목록에는 각 아키텍처에 필요한 최소 명령 세트 아키텍처(ISA)가 포함되어 있습니다.
- x86-64 아키텍처에는 x86-64-v2 ISA가 필요합니다.
- ARM64 아키텍처에는 ARMv8.0-A ISA가 필요합니다.
- IBM Power 아키텍처에는 Power 9 ISA가 필요합니다.
- s390x 아키텍처에는 z14 ISA가 필요합니다.
자세한 내용은 RHEL 아키텍처를 참조하십시오.
플랫폼의 인스턴스 유형이 클러스터 머신의 최소 요구 사항을 충족하는 경우 OpenShift Container Platform에서 사용할 수 있습니다.
3.11.4.2. AWS에서 테스트된 인스턴스 유형
다음 AWS(Amazon Web Services) 인스턴스 유형은 AWS Local Zones에서 사용하기 위해 OpenShift Container Platform에서 테스트되었습니다.
AWS 인스턴스의 다음 차트에 포함된 머신 유형을 사용합니다. 차트에 나열되지 않은 인스턴스 유형을 사용하는 경우 사용하는 인스턴스 크기가 "클러스터 설치에 대한 최소 리소스 요구 사항" 섹션에 나열된 최소 리소스 요구 사항과 일치하는지 확인합니다.
예 3.31. AWS 로컬 영역의 64비트 x86 아키텍처를 기반으로 하는 머신 유형
-
c5.*
-
c5d.*
-
m6i.*
-
m5.*
-
r5.*
-
t3.*
추가 리소스
- AWS 문서의 AWS 로컬 영역 기능을 참조하십시오.
3.11.4.3. 설치 구성 파일 만들기
설치 프로그램이 클러스터를 배포하는 데 필요한 설치 구성 파일을 생성하고 사용자 지정합니다.
사전 요구 사항
- 사용자가 프로비저닝한 인프라의 OpenShift Container Platform 설치 프로그램과 클러스터의 풀 시크릿을 받으셨습니다.
-
Red Hat에서 게시한 RHCOS(Red Hat Enterprise Linux CoreOS) AMI와 함께 AWS 리전에 클러스터를 배포하고 있는지 확인했습니다. AWS GovCloud 리전과 같은 사용자 지정 AMI가 필요한 AWS 리전에 배포하는 경우
install-config.yaml
파일을 수동으로 생성해야 합니다.
프로세스
install-config.yaml
파일을 생성합니다.설치 프로그램이 포함된 디렉터리로 변경하고 다음 명령을 실행합니다.
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
는 설치 프로그램이 생성하는 파일을 저장할 디렉터리 이름을 지정합니다.
중요비어 있는 디렉터리를 지정합니다. 부트스트랩 X.509 인증서와 같은 일부 설치 자산은 단기간에 만료되므로 설치 디렉터리를 재사용해서는 안 됩니다. 다른 클러스터 설치의 개별 파일을 재사용하려면 해당 파일을 사용자 디렉터리에 복사하면 됩니다. 그러나 설치 자산의 파일 이름은 릴리스간에 변경될 수 있습니다. 따라서 이전 OpenShift Container Platform 버전에서 설치 파일을 복사할 때는 주의하십시오.
화면에 나타나는 지시에 따라 클라우드에 대한 구성 세부 사항을 입력합니다.
선택사항: 클러스터 시스템에 액세스하는 데 사용할 SSH 키를 선택합니다.
참고설치 디버깅 또는 재해 복구를 수행하려는 프로덕션 OpenShift Container Platform 클러스터의 경우
ssh-agent
프로세스가 사용하는 SSH 키를 지정합니다.- 대상 플랫폼으로 aws를 선택합니다.
컴퓨터에 AWS 프로필이 저장되어 있지 않은 경우 설치 프로그램을 실행하도록 구성한 사용자의 AWS 액세스 키 ID와 시크릿 액세스 키를 입력합니다.
참고AWS 액세스 키 ID와 시크릿 액세스 키는 설치 호스트에 있는 현재 사용자의 홈 디렉터리에서
~/.aws/credentials
에 저장됩니다. 내보낸 프로필의 인증 정보가 파일에 없으면 설치 프로그램에서 인증 정보에 대한 메시지를 표시합니다. 설치 프로그램에 사용자가 제공하는 인증 정보는 파일에 저장됩니다.- 클러스터를 배포할 AWS 리전을 선택합니다.
- 클러스터에 대해 구성한 Route53 서비스의 기본 도메인을 선택합니다.
- 클러스터를 설명할 수 있는 이름을 입력합니다.
- Red Hat OpenShift Cluster Manager에서 풀 시크릿을 붙여넣습니다.
선택사항:
install-config.yaml
파일을 백업합니다.중요install-config.yaml
파일은 설치 과정에서 사용됩니다. 이 파일을 재사용하려면 지금 백업해야 합니다.
3.11.4.4. 엣지 컴퓨팅 풀이 있는 설치 구성 파일의 예
다음 예제에서는 에지 머신 풀 구성이 포함된 install-config.yaml
파일을 보여줍니다.
사용자 지정 인스턴스 유형과 함께 에지 풀을 사용하는 구성
apiVersion: v1 baseDomain: devcluster.openshift.com metadata: name: ipi-edgezone compute: - name: edge platform: aws: type: r5.2xlarge platform: aws: region: us-west-2 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA...
인스턴스 유형은 위치마다 다릅니다. 클러스터가 실행되는 로컬 영역에서 가용성을 확인하려면 AWS 설명서를 참조하십시오.
사용자 지정 Amazon Elastic Block Store(EBS) 유형의 에지 풀을 사용하는 구성
apiVersion: v1 baseDomain: devcluster.openshift.com metadata: name: ipi-edgezone compute: - name: edge platform: aws: zones: - us-west-2-lax-1a - us-west-2-lax-1b - us-west-2-phx-2a rootVolume: type: gp3 size: 120 platform: aws: region: us-west-2 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA...
EBS(Elastic Block Storage) 유형은 위치마다 다릅니다. AWS 문서를 확인하여 클러스터가 실행되는 로컬 영역에서 가용성을 확인합니다.
사용자 지정 보안 그룹과 함께 에지 풀을 사용하는 구성
apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
name: ipi-edgezone
compute:
- name: edge
platform:
aws:
additionalSecurityGroupIDs:
- sg-1 1
- sg-2
platform:
aws:
region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...
- 1
- Amazon EC2 콘솔에 표시될 보안 그룹의 이름을 지정합니다.
sg
접두사를 포함해야 합니다.
3.11.4.5. 클러스터 네트워크 MTU 사용자 정의
AWS에 클러스터를 배포하기 전에 인프라의 요구 사항을 충족하도록 클러스터 네트워크에 대한 클러스터 네트워크 최대 전송 단위(MTU)를 사용자 지정할 수 있습니다.
기본적으로 지원되는 로컬 영역 기능이 있는 클러스터를 설치하면 클러스터 네트워크의 MTU 값이 네트워크 플러그인이 허용하는 가장 낮은 값으로 자동으로 조정됩니다.
로컬 영역 인프라에서 작동하는 EC2 인스턴스에 지원되지 않는 MTU 값을 설정하면 OpenShift Container Platform 클러스터에 문제가 발생할 수 있습니다.
로컬 영역이 로컬 영역과 AWS 리전의 EC2 인스턴스 간에 더 높은 MTU 값을 지원하는 경우 클러스터 네트워크의 네트워크 성능을 높이기 위해 더 높은 값을 수동으로 구성할 수 있습니다.
install-config.yaml
구성 파일에 networking.clusterNetworkMTU
매개변수를 지정하여 클러스터의 MTU를 사용자 지정할 수 있습니다.
로컬 영역의 모든 서브넷은 해당 영역의 각 노드가 AWS 리전의 서비스와 성공적으로 통신하고 워크로드를 배포할 수 있도록 더 높은 MTU 값을 지원해야 합니다.
기본 MTU 값 덮어쓰기 예
apiVersion: v1 baseDomain: devcluster.openshift.com metadata: name: edge-zone networking: clusterNetworkMTU: 8901 compute: - name: edge platform: aws: zones: - us-west-2-lax-1a - us-west-2-lax-1b platform: aws: region: us-west-2 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA...
추가 리소스
- 지원되는 최대 MTU(최대 전송 단위) 값에 대한 자세한 내용은 AWS 문서의 로컬 영역에서 지원되는 AWS 리소스 를 참조하십시오.
3.11.5. AWS 로컬 영역 환경의 클러스터 설치 옵션
다음 설치 옵션 중 하나를 선택하여 로컬 영역에 정의된 엣지 컴퓨팅 노드가 있는 AWS에 OpenShift Container Platform 클러스터를 설치합니다.
- 완전 자동화된 옵션: 클러스터 설치로 컴퓨팅 노드를 에지 컴퓨팅 풀로 빠르게 확장할 수 있습니다. 여기서 설치 프로그램은 OpenShift Container Platform 클러스터에 대한 인프라 리소스를 자동으로 생성합니다.
-
기존 VPC 옵션:
install-config.yaml
파일에 로컬 영역 서브넷을 제공하는 기존 VPC에 AWS의 클러스터를 설치합니다.
다음 단계
다음 옵션 중 하나를 선택하여 AWS Local Zones 환경에 OpenShift Container Platform 클러스터를 설치합니다.
3.11.6. AWS 로컬 영역에 빠르게 클러스터 설치
OpenShift Container Platform 4.17의 경우 AWS(Amazon Web Services)에 클러스터를 빠르게 설치하여 컴퓨팅 노드를 로컬 영역 위치로 확장할 수 있습니다. 이 설치 경로를 사용하면 설치 프로그램이 구성 파일에 정의된 각 영역에 대한 네트워크 리소스 및 로컬 영역 서브넷을 자동으로 생성합니다. 설치를 사용자 지정하려면 클러스터를 배포하기 전에 install-config.yaml
파일에서 매개변수를 수정해야 합니다.
3.11.6.1. AWS 로컬 영역을 사용하도록 설치 구성 파일 수정
AWS 로컬 영역을 포함하도록 install-config.yaml
파일을 수정합니다.
사전 요구 사항
- AWS 계정을 구성했습니다.
-
aws 구성
을 실행하여 AWS 키와 AWS 리전을 로컬 AWS 프로필에 추가했습니다. - 설치 프로그램을 지정하여 OpenShift Container Platform 클러스터의 서브넷을 자동으로 생성할 때 적용되는 구성 제한 사항을 잘 알고 있습니다.
- 각 영역의 로컬 영역 그룹을 선택했습니다.
-
"설치 구성 파일 생성" 절차를 사용하여
install-config.yaml
파일을 생성했습니다.
프로세스
에지 컴퓨팅 풀의
platform.aws.zones
속성에 로컬 영역 이름을 지정하여install-config.yaml
파일을 수정합니다.# ... platform: aws: region: <region_name> 1 compute: - name: edge platform: aws: zones: 2 - <local_zone_name> #...
us-west-2
AWS 리전에 클러스터를 설치하는 구성의 예는 엣지 노드를로스앤젤레스
및라스베가스
위치의 로컬 영역으로 확장합니다.apiVersion: v1 baseDomain: example.com metadata: name: cluster-name platform: aws: region: us-west-2 compute: - name: edge platform: aws: zones: - us-west-2-lax-1a - us-west-2-lax-1b - us-west-2-las-1a pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' #...
- 클러스터를 배포합니다.
다음 단계
3.11.7. 로컬 영역 서브넷이 있는 기존 VPC에 클러스터 설치
AWS(Amazon Web Services)의 기존 Amazon VPC(Virtual Private Cloud)에 클러스터를 설치할 수 있습니다. 설치 프로그램이 나머지 필수 인프라를 프로비저닝하며, 이후에 추가로 사용자 지정할 수 있습니다. 설치를 사용자 지정하려면 클러스터를 설치하기 전에 install-config.yaml
파일에서 매개변수를 수정합니다.
AWS의 클러스터를 기존 VPC에 설치하려면 AWS Local Zones를 사용하여 컴퓨팅 노드를 Cloud Infrastructure의 에지로 확장해야 합니다.
로컬 영역 서브넷은 일반 컴퓨팅 노드를 에지 네트워크로 확장합니다. 각 엣지 컴퓨팅 노드는 사용자 워크로드를 실행합니다. AWS(Amazon Web Service) 로컬 영역 환경을 생성하고 클러스터를 배포한 후 에지 컴퓨팅 노드를 사용하여 로컬 영역 서브넷에서 사용자 워크로드를 생성할 수 있습니다.
프라이빗 서브넷을 생성하려면 제공된 CloudFormation 템플릿을 수정하거나 고유한 템플릿을 생성해야 합니다.
제공된 CloudFormation 템플릿을 사용하여 네트워크 리소스를 생성할 수 있습니다. 또한 템플릿을 수정하여 인프라를 사용자 지정하거나 포함된 정보를 사용하여 회사의 정책에 따라 AWS 리소스를 생성할 수 있습니다.
설치 관리자 프로비저닝 인프라 설치를 수행하는 단계는 예시용으로만 제공됩니다. 기존 VPC에 클러스터를 설치하려면 클라우드 공급자 및 OpenShift Container Platform 설치 프로세스에 대한 지식이 있어야 합니다. CloudFormation 템플릿을 사용하여 이러한 단계를 완료하거나 자체 클러스터 설치를 모델링하는 데 도움이 될 수 있습니다. CloudFormation 템플릿을 사용하여 리소스를 생성하는 대신 다른 방법을 사용하여 이러한 리소스를 생성하도록 결정할 수 있습니다.
3.11.7.1. AWS에서 VPC 생성
OpenShift Container Platform 클러스터의 AWS(Amazon Web Services) 위치에서 컴퓨팅 노드를 에지 위치로 확장하기 위해 VPC(Virtual Private Cloud) 및 모든 로컬 영역의 서브넷을 생성할 수 있습니다. VPN 및 라우팅 테이블을 포함하여 요구 사항에 맞게 VPC를 추가로 사용자 지정할 수 있습니다. 초기 배포 시 포함되지 않은 새 로컬 영역 서브넷을 추가할 수도 있습니다.
제공된 CloudFormation 템플릿과 사용자 정의 매개변수 파일을 사용하여 VPC를 나타내는 AWS 리소스 스택을 생성할 수 있습니다.
AWS 인프라를 생성하는 데 제공된 CloudFormation 템플릿을 사용하지 않는 경우, 제공된 정보를 검토하고 수동으로 인프라를 생성해야 합니다. 클러스터가 올바르게 초기화되지 않은 경우, Red Hat 지원팀에 설치 로그를 제시하여 문의해야 할 수도 있습니다.
사전 요구 사항
- AWS 계정을 구성했습니다.
-
aws 구성
을 실행하여 AWS 키와 AWS 리전을 로컬 AWS 프로필에 추가했습니다. - AWS 계정의 AWS 로컬 영역을 선택했습니다.
프로세스
CloudFormation 템플릿에 필요한 매개변수 값이 포함된 JSON 파일을 만듭니다.
[ { "ParameterKey": "VpcCidr", 1 "ParameterValue": "10.0.0.0/16" 2 }, { "ParameterKey": "AvailabilityZoneCount", 3 "ParameterValue": "3" 4 }, { "ParameterKey": "SubnetBits", 5 "ParameterValue": "12" 6 } ]
- "CloudFormation template for the VPC"라는 문서의 섹션으로 이동한 다음 제공된 템플릿에서 구문을 복사합니다. 복사한 템플릿 구문을 로컬 시스템에 YAML 파일로 저장합니다. 이 템플릿은 클러스터에 필요한 VPC를 설명합니다.
CloudFormation 템플릿을 시작하여 다음 명령을 실행하여 VPC를 나타내는 AWS 리소스 스택을 생성합니다.
중요명령은 한 줄로 입력해야 합니다.
$ aws cloudformation create-stack --stack-name <name> \1 --template-body file://<template>.yaml \2 --parameters file://<parameters>.json 3
출력 예
arn:aws:cloudformation:us-east-1:123456789012:stack/cluster-vpc/dbedae40-2fd3-11eb-820e-12a48460849f
다음 명령을 실행하여 템플릿 구성 요소가 있는지 확인합니다.
$ aws cloudformation describe-stacks --stack-name <name>
StackStatus
에CREATE_COMPLETE
이 표시된 후 다음 매개변수의 출력 값이 표시됩니다. 클러스터를 생성하기 위해 실행하는 다른 CloudFormation 템플릿에 이러한 매개변수 값을 제공해야 합니다.VpcId
VPC의 ID입니다.
PublicSubnetIds
새 퍼블릭 서브넷의 ID입니다.
PrivateSubnetIds
새 프라이빗 서브넷의 ID입니다.
PublicRouteTableId
새 공용 경로 테이블 ID의 ID입니다.
3.11.7.2. VPC용 CloudFormation 템플릿
다음 CloudFormation 템플릿을 사용하여 OpenShift Container Platform 클러스터에 필요한 VPC를 배포할 수 있습니다.
예 3.32. VPC용 CloudFormation 템플릿
AWSTemplateFormatVersion: 2010-09-09 Description: Template for Best Practice VPC with 1-3 AZs Parameters: VpcCidr: AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$ ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24. Default: 10.0.0.0/16 Description: CIDR block for VPC. Type: String AvailabilityZoneCount: ConstraintDescription: "The number of availability zones. (Min: 1, Max: 3)" MinValue: 1 MaxValue: 3 Default: 1 Description: "How many AZs to create VPC subnets for. (Min: 1, Max: 3)" Type: Number SubnetBits: ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/19-27. MinValue: 5 MaxValue: 13 Default: 12 Description: "Size of each subnet to create within the availability zones. (Min: 5 = /27, Max: 13 = /19)" Type: Number Metadata: AWS::CloudFormation::Interface: ParameterGroups: - Label: default: "Network Configuration" Parameters: - VpcCidr - SubnetBits - Label: default: "Availability Zones" Parameters: - AvailabilityZoneCount ParameterLabels: AvailabilityZoneCount: default: "Availability Zone Count" VpcCidr: default: "VPC CIDR" SubnetBits: default: "Bits Per Subnet" Conditions: DoAz3: !Equals [3, !Ref AvailabilityZoneCount] DoAz2: !Or [!Equals [2, !Ref AvailabilityZoneCount], Condition: DoAz3] Resources: VPC: Type: "AWS::EC2::VPC" Properties: EnableDnsSupport: "true" EnableDnsHostnames: "true" CidrBlock: !Ref VpcCidr PublicSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VPC CidrBlock: !Select [0, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref "AWS::Region" PublicSubnet2: Type: "AWS::EC2::Subnet" Condition: DoAz2 Properties: VpcId: !Ref VPC CidrBlock: !Select [1, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 1 - Fn::GetAZs: !Ref "AWS::Region" PublicSubnet3: Type: "AWS::EC2::Subnet" Condition: DoAz3 Properties: VpcId: !Ref VPC CidrBlock: !Select [2, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 2 - Fn::GetAZs: !Ref "AWS::Region" InternetGateway: Type: "AWS::EC2::InternetGateway" GatewayToInternet: Type: "AWS::EC2::VPCGatewayAttachment" Properties: VpcId: !Ref VPC InternetGatewayId: !Ref InternetGateway PublicRouteTable: Type: "AWS::EC2::RouteTable" Properties: VpcId: !Ref VPC PublicRoute: Type: "AWS::EC2::Route" DependsOn: GatewayToInternet Properties: RouteTableId: !Ref PublicRouteTable DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway PublicSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PublicSubnet RouteTableId: !Ref PublicRouteTable PublicSubnetRouteTableAssociation2: Type: "AWS::EC2::SubnetRouteTableAssociation" Condition: DoAz2 Properties: SubnetId: !Ref PublicSubnet2 RouteTableId: !Ref PublicRouteTable PublicSubnetRouteTableAssociation3: Condition: DoAz3 Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PublicSubnet3 RouteTableId: !Ref PublicRouteTable PrivateSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VPC CidrBlock: !Select [3, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 0 - Fn::GetAZs: !Ref "AWS::Region" PrivateRouteTable: Type: "AWS::EC2::RouteTable" Properties: VpcId: !Ref VPC PrivateSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PrivateSubnet RouteTableId: !Ref PrivateRouteTable NAT: DependsOn: - GatewayToInternet Type: "AWS::EC2::NatGateway" Properties: AllocationId: "Fn::GetAtt": - EIP - AllocationId SubnetId: !Ref PublicSubnet EIP: Type: "AWS::EC2::EIP" Properties: Domain: vpc Route: Type: "AWS::EC2::Route" Properties: RouteTableId: Ref: PrivateRouteTable DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: Ref: NAT PrivateSubnet2: Type: "AWS::EC2::Subnet" Condition: DoAz2 Properties: VpcId: !Ref VPC CidrBlock: !Select [4, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 1 - Fn::GetAZs: !Ref "AWS::Region" PrivateRouteTable2: Type: "AWS::EC2::RouteTable" Condition: DoAz2 Properties: VpcId: !Ref VPC PrivateSubnetRouteTableAssociation2: Type: "AWS::EC2::SubnetRouteTableAssociation" Condition: DoAz2 Properties: SubnetId: !Ref PrivateSubnet2 RouteTableId: !Ref PrivateRouteTable2 NAT2: DependsOn: - GatewayToInternet Type: "AWS::EC2::NatGateway" Condition: DoAz2 Properties: AllocationId: "Fn::GetAtt": - EIP2 - AllocationId SubnetId: !Ref PublicSubnet2 EIP2: Type: "AWS::EC2::EIP" Condition: DoAz2 Properties: Domain: vpc Route2: Type: "AWS::EC2::Route" Condition: DoAz2 Properties: RouteTableId: Ref: PrivateRouteTable2 DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: Ref: NAT2 PrivateSubnet3: Type: "AWS::EC2::Subnet" Condition: DoAz3 Properties: VpcId: !Ref VPC CidrBlock: !Select [5, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]] AvailabilityZone: !Select - 2 - Fn::GetAZs: !Ref "AWS::Region" PrivateRouteTable3: Type: "AWS::EC2::RouteTable" Condition: DoAz3 Properties: VpcId: !Ref VPC PrivateSubnetRouteTableAssociation3: Type: "AWS::EC2::SubnetRouteTableAssociation" Condition: DoAz3 Properties: SubnetId: !Ref PrivateSubnet3 RouteTableId: !Ref PrivateRouteTable3 NAT3: DependsOn: - GatewayToInternet Type: "AWS::EC2::NatGateway" Condition: DoAz3 Properties: AllocationId: "Fn::GetAtt": - EIP3 - AllocationId SubnetId: !Ref PublicSubnet3 EIP3: Type: "AWS::EC2::EIP" Condition: DoAz3 Properties: Domain: vpc Route3: Type: "AWS::EC2::Route" Condition: DoAz3 Properties: RouteTableId: Ref: PrivateRouteTable3 DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: Ref: NAT3 S3Endpoint: Type: AWS::EC2::VPCEndpoint Properties: PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: '*' Action: - '*' Resource: - '*' RouteTableIds: - !Ref PublicRouteTable - !Ref PrivateRouteTable - !If [DoAz2, !Ref PrivateRouteTable2, !Ref "AWS::NoValue"] - !If [DoAz3, !Ref PrivateRouteTable3, !Ref "AWS::NoValue"] ServiceName: !Join - '' - - com.amazonaws. - !Ref 'AWS::Region' - .s3 VpcId: !Ref VPC Outputs: VpcId: Description: ID of the new VPC. Value: !Ref VPC PublicSubnetIds: Description: Subnet IDs of the public subnets. Value: !Join [ ",", [!Ref PublicSubnet, !If [DoAz2, !Ref PublicSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PublicSubnet3, !Ref "AWS::NoValue"]] ] PrivateSubnetIds: Description: Subnet IDs of the private subnets. Value: !Join [ ",", [!Ref PrivateSubnet, !If [DoAz2, !Ref PrivateSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PrivateSubnet3, !Ref "AWS::NoValue"]] ] PublicRouteTableId: Description: Public Route table ID Value: !Ref PublicRouteTable PrivateRouteTableIds: Description: Private Route table IDs Value: !Join [ ",", [ !Join ["=", [ !Select [0, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable ]], !If [DoAz2, !Join ["=", [!Select [1, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable2]], !Ref "AWS::NoValue" ], !If [DoAz3, !Join ["=", [!Select [2, "Fn::GetAZs": !Ref "AWS::Region"], !Ref PrivateRouteTable3]], !Ref "AWS::NoValue" ] ] ]
3.11.7.3. 로컬 영역에서 서브넷 생성
OpenShift Container Platform 클러스터에서 에지 컴퓨팅 노드에 대한 머신 세트를 구성하기 전에 로컬 영역에서 서브넷을 생성해야 합니다. 컴퓨팅 노드를 배포할 각 로컬 영역에 대해 다음 절차를 완료합니다.
제공된 CloudFormation 템플릿을 사용하고 CloudFormation 스택을 생성할 수 있습니다. 그런 다음 이 스택을 사용하여 서브넷을 사용자 지정 프로비저닝할 수 있습니다.
AWS 인프라를 생성하는 데 제공된 CloudFormation 템플릿을 사용하지 않는 경우, 제공된 정보를 검토하고 수동으로 인프라를 생성해야 합니다. 클러스터가 올바르게 초기화되지 않은 경우, Red Hat 지원팀에 설치 로그를 제시하여 문의해야 할 수도 있습니다.
사전 요구 사항
- AWS 계정을 구성했습니다.
-
aws 구성
을 실행하여 AWS 키와 리전을 로컬 AWS 프로필에 추가하셨습니다. - 로컬 영역 그룹을 선택했습니다.
프로세스
- "CloudFormation template for the VPC subnet"이라는 문서의 섹션으로 이동하여 템플릿에서 구문을 복사합니다. 복사한 템플릿 구문을 로컬 시스템에 YAML 파일로 저장합니다. 이 템플릿은 클러스터에 필요한 VPC를 설명합니다.
다음 명령을 실행하여 VPC를 나타내는 AWS 리소스 스택을 생성하는 CloudFormation 템플릿을 배포합니다.
$ aws cloudformation create-stack --stack-name <stack_name> \1 --region ${CLUSTER_REGION} \ --template-body file://<template>.yaml \2 --parameters \ ParameterKey=VpcId,ParameterValue="${VPC_ID}" \3 ParameterKey=ClusterName,ParameterValue="${CLUSTER_NAME}" \4 ParameterKey=ZoneName,ParameterValue="${ZONE_NAME}" \5 ParameterKey=PublicRouteTableId,ParameterValue="${ROUTE_TABLE_PUB}" \6 ParameterKey=PublicSubnetCidr,ParameterValue="${SUBNET_CIDR_PUB}" \7 ParameterKey=PrivateRouteTableId,ParameterValue="${ROUTE_TABLE_PVT}" \8 ParameterKey=PrivateSubnetCidr,ParameterValue="${SUBNET_CIDR_PVT}" 9
- 1
<stack_name
>은 CloudFormation 스택의 이름입니다(예:cluster-wl-<local_zone_shortname
>). 클러스터를 제거하는 경우 이 스택의 이름이 필요합니다.- 2
<template
>은 상대 경로이며 저장한 CloudFormation 템플릿 YAML 파일의 이름입니다.- 3
${VPC_ID}
는 VPC의 CloudFormation 템플릿 출력에 있는VpcID
값인 VPC ID입니다.- 4
${ZONE_NAME}
은 서브넷을 생성할 로컬 영역 이름 값입니다.- 5
${CLUSTER_NAME}
은 새 AWS 리소스 이름의 접두사로 사용할 ClusterName 의 값입니다.- 6
${SUBNET_CIDR_PUB}
는 공용 서브넷을 생성하는 데 사용되는 유효한 CIDR 블록입니다. 이 블록은 VPC CIDR 블록VpcCidr
의 일부여야 합니다.- 7
${ROUTE_ Cryostat_PVT}
는 VPC의 CloudFormation 스택 출력에서 추출된 PrivateRouteTableId 입니다.- 8
${SUBNET_CIDR_PVT}
는 개인 서브넷을 만드는 데 사용되는 유효한 CIDR 블록입니다. 이 블록은 VPC CIDR 블록VpcCidr
의 일부여야 합니다.
출력 예
arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-820e-11eb-2fd3-12a48460849f
검증
다음 명령을 실행하여 템플릿 구성 요소가 있는지 확인합니다.
$ aws cloudformation describe-stacks --stack-name <stack_name>
StackStatus
에CREATE_COMPLETE
이 표시된 후 다음 매개변수의 출력 값이 표시됩니다. 이러한 매개변수 값을 클러스터에 생성하기 위해 실행하는 다른 CloudFormation 템플릿에 제공해야 합니다.PublicSubnetId
CloudFormation 스택에서 생성한 공용 서브넷의 ID입니다.
PrivateSubnetId
CloudFormation 스택에서 생성한 프라이빗 서브넷의 ID입니다.
3.11.7.4. VPC 서브넷용 CloudFormation 템플릿
다음 CloudFormation 템플릿을 사용하여 로컬 영역 인프라의 영역에 프라이빗 및 퍼블릭 서브넷을 배포할 수 있습니다.
예 3.33. VPC 서브넷용 CloudFormation 템플릿
AWSTemplateFormatVersion: 2010-09-09 Description: Template for Best Practice Subnets (Public and Private) Parameters: VpcId: Description: VPC ID that comprises all the target subnets. Type: String AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$ ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*. ClusterName: Description: Cluster name or prefix name to prepend the Name tag for each subnet. Type: String AllowedPattern: ".+" ConstraintDescription: ClusterName parameter must be specified. ZoneName: Description: Zone Name to create the subnets, such as us-west-2-lax-1a. Type: String AllowedPattern: ".+" ConstraintDescription: ZoneName parameter must be specified. PublicRouteTableId: Description: Public Route Table ID to associate the public subnet. Type: String AllowedPattern: ".+" ConstraintDescription: PublicRouteTableId parameter must be specified. PublicSubnetCidr: AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$ ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24. Default: 10.0.128.0/20 Description: CIDR block for public subnet. Type: String PrivateRouteTableId: Description: Private Route Table ID to associate the private subnet. Type: String AllowedPattern: ".+" ConstraintDescription: PrivateRouteTableId parameter must be specified. PrivateSubnetCidr: AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$ ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24. Default: 10.0.128.0/20 Description: CIDR block for private subnet. Type: String Resources: PublicSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VpcId CidrBlock: !Ref PublicSubnetCidr AvailabilityZone: !Ref ZoneName Tags: - Key: Name Value: !Join ['-', [!Ref ClusterName, "public", !Ref ZoneName]] PublicSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PublicSubnet RouteTableId: !Ref PublicRouteTableId PrivateSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VpcId CidrBlock: !Ref PrivateSubnetCidr AvailabilityZone: !Ref ZoneName Tags: - Key: Name Value: !Join ['-', [!Ref ClusterName, "private", !Ref ZoneName]] PrivateSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PrivateSubnet RouteTableId: !Ref PrivateRouteTableId Outputs: PublicSubnetId: Description: Subnet ID of the public subnets. Value: !Join ["", [!Ref PublicSubnet]] PrivateSubnetId: Description: Subnet ID of the private subnets. Value: !Join ["", [!Ref PrivateSubnet]]
추가 리소스
- AWS CloudFormation 콘솔로 이동하여 생성하는 CloudFormation 스택에 대한 세부 정보를 볼 수 있습니다.
3.11.7.5. AWS 로컬 영역 서브넷을 사용하도록 설치 구성 파일 수정
로컬 영역 서브넷을 포함하도록 install-config.yaml
파일을 수정합니다.
사전 요구 사항
- "로컬 영역에서 서브넷 생성" 절차를 사용하여 서브넷을 생성했습니다.
-
"설치 구성 파일 생성" 절차를 사용하여
install-config.yaml
파일을 생성했습니다.
프로세스
platform.aws.subnets
매개변수에 로컬 영역 서브넷을 지정하여install-config.yaml
구성 파일을 수정합니다.로컬 영역 서브넷이 있는 설치 구성 파일의 예
# ... platform: aws: region: us-west-2 subnets: 1 - publicSubnetId-1 - publicSubnetId-2 - publicSubnetId-3 - privateSubnetId-1 - privateSubnetId-2 - privateSubnetId-3 - publicSubnetId-LocalZone-1 # ...
- 1
- 영역에서 생성된 서브넷 ID 목록: 가용성 및 로컬 영역.
추가 리소스
- 생성한 CloudFormation 스택을 보는 방법에 대한 자세한 내용은 AWS CloudFormation 콘솔 을 참조하십시오.
- AWS 프로필 및 인증 정보 구성에 대한 자세한 내용은 AWS 문서의 구성 및 인증 정보 파일 설정을 참조하십시오.
다음 단계
3.11.8. 선택 사항: AWS 보안 그룹
기본적으로 설치 프로그램은 보안 그룹을 생성하고 컨트롤 플레인 및 컴퓨팅 시스템에 연결합니다. 기본 보안 그룹과 연결된 규칙은 수정할 수 없습니다.
그러나 기존 VPC와 연결된 기존 AWS 보안 그룹을 컨트롤 플레인 및 컴퓨팅 머신에 적용할 수 있습니다. 사용자 지정 보안 그룹을 적용하면 이러한 시스템의 수신 또는 발신 트래픽을 제어해야 하는 경우 조직의 보안 요구 사항을 충족하는 데 도움이 될 수 있습니다.
설치 프로세스의 일부로 클러스터를 배포하기 전에 install-config.yaml
파일을 수정하여 사용자 지정 보안 그룹을 적용합니다.
자세한 내용은 "Edge 컴퓨팅 풀 및 AWS Local Zones"를 참조하십시오.
3.11.9. 선택 사항: 공용 IP 주소를 엣지 컴퓨팅 노드에 할당
워크로드에 로컬 영역 인프라의 퍼블릭 서브넷에 에지 컴퓨팅 노드를 배포해야 하는 경우 클러스터를 설치할 때 머신 세트 매니페스트를 구성할 수 있습니다.
AWS 로컬 영역 인프라는 지정된 영역의 네트워크 트래픽에 액세스하므로 애플리케이션은 해당 영역에 더 가까운 최종 사용자를 제공할 때 대기 시간을 단축할 수 있습니다.
프라이빗 서브넷에 컴퓨팅 노드를 배포하는 기본 설정은 요구 사항을 충족하지 않을 수 있으므로 인프라에 더 많은 사용자 지정을 적용하려면 퍼블릭 서브넷에 에지 컴퓨팅 노드를 만드는 것이 좋습니다.
기본적으로 OpenShift Container Platform은 프라이빗 서브넷에 컴퓨팅 노드를 배포합니다. 최상의 성능을 위해 퍼블릭 IP 주소가 서브넷에 연결된 서브넷에 컴퓨팅 노드를 배치하는 것이 좋습니다.
추가 보안 그룹을 생성해야 하지만 실제로 필요할 때 인터넷을 통한 그룹 규칙만 열어야 합니다.
프로세스
설치 프로그램이 포함된 디렉터리로 변경하고 매니페스트 파일을 생성합니다. 설치 매니페스트가
openshift
및manifests
디렉터리 수준에서 생성되었는지 확인합니다.$ ./openshift-install create manifests --dir <installation_directory>
매니페스트가 퍼블릭 서브넷에 배포되도록 설치 프로그램이 로컬 영역에 생성하는 머신 세트 매니페스트를 편집합니다.
spec.template.spec.providerSpec.value.publicIP
매개변수에true
를 지정합니다.로컬 영역에 빠르게 클러스터를 설치하기 위한 머신 세트 매니페스트 구성의 예
spec: template: spec: providerSpec: value: publicIp: true subnet: filters: - name: tag:Name values: - ${INFRA_ID}-public-${ZONE_NAME}
로컬 영역 서브넷이 있는 기존 VPC에 클러스터를 설치하기 위한 머신 세트 매니페스트 구성의 예
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: name: <infrastructure_id>-edge-<zone> namespace: openshift-machine-api spec: template: spec: providerSpec: value: publicIp: true
3.11.10. 클러스터 배포
호환되는 클라우드 플랫폼에 OpenShift Container Platform을 설치할 수 있습니다.
최초 설치 과정에서 설치 프로그램의 create cluster
명령을 한 번만 실행할 수 있습니다.
사전 요구 사항
- 클러스터를 호스팅하는 클라우드 플랫폼으로 계정을 구성했습니다.
- OpenShift Container Platform 설치 프로그램과 클러스터의 풀 시크릿이 있습니다.
- 호스트의 클라우드 공급자 계정에 클러스터를 배포할 수 있는 올바른 권한이 있는지 확인했습니다. 잘못된 권한이 있는 계정으로 인해 누락된 권한이 표시되는 오류 메시지와 함께 설치 프로세스가 실패합니다.
프로세스
설치 프로그램이 포함된 디렉터리로 변경하고 클러스터 배포를 초기화합니다.
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
선택사항: 클러스터를 설치하는 데 사용한 IAM 계정에서
AdministratorAccess
정책을 제거하거나 비활성화합니다.참고AdministratorAccess
정책에서 제공하는 승격된 권한은 설치 중에만 필요합니다.
검증
클러스터 배포가 성공적으로 완료되면 다음을 수행합니다.
-
터미널에는 웹 콘솔에 대한 링크 및
kubeadmin
사용자의 인증 정보를 포함하여 클러스터에 액세스하는 지침이 표시됩니다. -
인증 정보도 <
installation_directory>/.openshift_install.log
로 출력합니다.
설치 프로그램 또는 설치 프로그램이 생성하는 파일을 삭제하지 마십시오. 클러스터를 삭제하려면 두 가지가 모두 필요합니다.
출력 예
... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com INFO Login to the console with user: "kubeadmin", and password: "password" INFO Time elapsed: 36m22s
-
설치 프로그램에서 생성하는 Ignition 구성 파일에 24시간 후에 만료되는 인증서가 포함되어 있습니다. 이 인증서는 그 후에 갱신됩니다. 인증서를 갱신하기 전에 클러스터가 종료되고 24시간이 지난 후에 클러스터가 다시 시작되면 클러스터는 만료된 인증서를 자동으로 복구합니다. 예외적으로 kubelet 인증서를 복구하려면 대기 중인
node-bootstrapper
인증서 서명 요청(CSR)을 수동으로 승인해야 합니다. 자세한 내용은 만료된 컨트롤 플레인 인증서에서 복구 문서를 참조하십시오. - 24 시간 인증서는 클러스터를 설치한 후 16시간에서 22시간으로 인증서가 교체되기 때문에 생성된 후 12시간 이내에 Ignition 구성 파일을 사용하는 것이 좋습니다. 12시간 이내에 Ignition 구성 파일을 사용하면 설치 중에 인증서 업데이트가 실행되는 경우 설치 실패를 방지할 수 있습니다.
3.11.11. 배포된 클러스터의 상태 확인
OpenShift Container Platform이 AWS 로컬 영역에 성공적으로 배포되었는지 확인합니다.
3.11.11.1. CLI를 사용하여 클러스터에 로그인
클러스터 kubeconfig
파일을 내보내서 기본 시스템 사용자로 클러스터에 로그인할 수 있습니다. kubeconfig
파일에는 CLI에서 올바른 클러스터 및 API 서버에 클라이언트를 연결하는 데 사용하는 클러스터에 대한 정보가 포함되어 있습니다. 이 파일은 클러스터별로 고유하며 OpenShift Container Platform 설치 과정에서 생성됩니다.
사전 요구 사항
- OpenShift Container Platform 클러스터를 배포했습니다.
-
oc
CLI를 설치했습니다.
프로세스
kubeadmin
인증 정보를 내보냅니다.$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
는 설치 파일을 저장한 디렉터리의 경로를 지정합니다.
내보낸 구성을 사용하여
oc
명령을 성공적으로 실행할 수 있는지 확인합니다.$ oc whoami
출력 예
system:admin
3.11.11.2. 웹 콘솔을 사용하여 클러스터에 로그인
kubeadmin
사용자는 OpenShift Container Platform 설치 후 기본적으로 존재합니다. OpenShift Container Platform 웹 콘솔을 사용하여 kubeadmin
사용자로 클러스터에 로그인할 수 있습니다.
사전 요구 사항
- 설치 호스트에 대한 액세스 권한이 있어야 합니다.
- 클러스터 설치를 완료했으며 모든 클러스터 Operator를 사용할 수 있습니다.
프로세스
설치 호스트의
kubeadmin-password
파일에서kubeadmin
사용자의 암호를 가져옵니다.$ cat <installation_directory>/auth/kubeadmin-password
참고대안으로 설치 호스트의
<installation_directory>/.openshift_install.log
로그 파일에서kubeadmin
암호를 가져올 수 있습니다.OpenShift Container Platform 웹 콘솔 경로를 나열합니다.
$ oc get routes -n openshift-console | grep 'console-openshift'
참고대안으로 설치 호스트의
<installation_directory>/.openshift_install.log
로그 파일에서 OpenShift Container Platform 경로를 가져올 수 있습니다.출력 예
console console-openshift-console.apps.<cluster_name>.<base_domain> console https reencrypt/Redirect None
-
웹 브라우저의 이전 명령 출력에 자세히 설명된 경로로 이동하고
kubeadmin
사용자로 로그인합니다.
추가 리소스
3.11.11.3. 엣지 컴퓨팅 풀을 사용하여 생성된 노드 확인
AWS Local Zones 인프라를 사용하는 클러스터를 설치한 후 설치 중에 생성된 머신 세트 매니페스트에 의해 생성된 머신의 상태를 확인합니다.
install-config.yaml
파일에 추가한 서브넷에서 생성된 머신 세트를 확인하려면 다음 명령을 실행합니다.$ oc get machineset -n openshift-machine-api
출력 예
NAME DESIRED CURRENT READY AVAILABLE AGE cluster-7xw5g-edge-us-east-1-nyc-1a 1 1 1 1 3h4m cluster-7xw5g-worker-us-east-1a 1 1 1 1 3h4m cluster-7xw5g-worker-us-east-1b 1 1 1 1 3h4m cluster-7xw5g-worker-us-east-1c 1 1 1 1 3h4m
머신 세트에서 생성된 머신을 확인하려면 다음 명령을 실행합니다.
$ oc get machines -n openshift-machine-api
출력 예
NAME PHASE TYPE REGION ZONE AGE cluster-7xw5g-edge-us-east-1-nyc-1a-wbclh Running c5d.2xlarge us-east-1 us-east-1-nyc-1a 3h cluster-7xw5g-master-0 Running m6i.xlarge us-east-1 us-east-1a 3h4m cluster-7xw5g-master-1 Running m6i.xlarge us-east-1 us-east-1b 3h4m cluster-7xw5g-master-2 Running m6i.xlarge us-east-1 us-east-1c 3h4m cluster-7xw5g-worker-us-east-1a-rtp45 Running m6i.xlarge us-east-1 us-east-1a 3h cluster-7xw5g-worker-us-east-1b-glm7c Running m6i.xlarge us-east-1 us-east-1b 3h cluster-7xw5g-worker-us-east-1c-qfvz4 Running m6i.xlarge us-east-1 us-east-1c 3h
에지 역할이 있는 노드를 확인하려면 다음 명령을 실행합니다.
$ oc get nodes -l node-role.kubernetes.io/edge
출력 예
NAME STATUS ROLES AGE VERSION ip-10-0-207-188.ec2.internal Ready edge,worker 172m v1.25.2+d2e245f
다음 단계
- 설치를 검증합니다.
- 필요한 경우 원격 상태를 옵트아웃 할 수 있습니다.