18장. AWS 로컬 영역 작업
AWS(Amazon Web Services)에 OpenShift Container Platform을 설치한 후 필요에 맞게 클러스터를 확장하고 사용자 정의할 수 있도록 AWS 로컬 영역과 엣지 컴퓨팅 풀을 추가로 구성할 수 있습니다.
18.1. AWS 로컬 영역을 사용하도록 기존 클러스터 확장
설치 후, AWS(Amazon Web Services)에서 기존 OpenShift Container Platform 클러스터를 확장하여 AWS Local Zones를 사용할 수 있습니다.
노드를 로컬 영역 위치로 확장하려면 다음 단계로 구성됩니다.
- MTU(클러스터 네트워크 최대 전송 단위) 조정
- 로컬 영역 그룹에서 AWS 로컬 영역으로 선택
- 로컬 영역 위치에 대한 기존 VPC에 서브넷 생성
- 머신 세트 매니페스트 생성 후 각 로컬 영역 위치에 노드 생성
로컬 영역을 사용하도록 AWS에서 기존 OpenShift Container Platform 클러스터를 확장하기 전에 기존 VPC에 사용 가능한 CIDR(Classless Inter-Domain Routing) 블록이 포함되어 있는지 확인합니다. 이러한 블록은 서브넷을 만드는 데 필요합니다.
추가 리소스
- 지원되는 인스턴스 유형 및 서비스에 대한 자세한 내용은 AWS 문서의 AWS 로컬 영역 기능을 참조하십시오.
18.1.1. 엣지 컴퓨팅 풀 및 AWS 로컬 영역
엣지 작업자 노드는 AWS 로컬 영역 위치에서 실행되는 테인트된 작업자 노드입니다.
로컬 영역을 사용하는 클러스터를 배포할 때 다음 사항을 고려하십시오.
- 로컬 영역의 Amazon EC2 인스턴스는 가용성 영역의 Amazon EC2 인스턴스보다 비용이 많이 듭니다.
- 애플리케이션과 최종 사용자 간의 대기 시간은 로컬 영역에서 적고 대기 시간은 위치에 따라 다를 수 있습니다. 예를 들어 Ingress 트래픽이 로컬 영역과 가용성 영역 간에 혼합되는 경우 일부 워크로드에 대기 시간 영향이 있습니다.
일반적으로 로컬 영역의 Amazon EC2 인스턴스와 리전의 Amazon EC2 인스턴스 간 MTU(최대 전송 단위)는 1300입니다. 자세한 내용은 AWS 문서에서 로컬 영역이 작동하는 방법을 참조하십시오. 오버헤드를 고려하려면 클러스터 네트워크 MTU가 EC2 MTU보다 항상 작아야 합니다. 특정 오버헤드는 네트워크 플러그인에 의해 결정됩니다. 예를 들면 다음과 같습니다.
-
OVN-Kubernetes:
100 bytes
-
OpenShift SDN:
50바이트
네트워크 플러그인은 IPsec과 같은 추가 기능을 제공할 수 있으며 MTU도 줄여야 합니다. 자세한 내용은 설명서를 참조하십시오.
OpenShift Container Platform 4.12에서는 원격 영역에서 사용하도록 설계된 새로운 컴퓨팅 풀 에지 를 도입했습니다. 엣지 컴퓨팅 풀 구성은 AWS 로컬 영역 위치 간에 일반적입니다. 로컬 영역 리소스의 EC2 및 EBS와 같은 리소스의 유형 및 크기 제한으로 인해 기본 인스턴스 유형은 기존 작업자 풀에 따라 다를 수 있습니다.
로컬 영역 위치의 기본 EBS(Elastic Block Store)는 일반 작업자 풀과 다른 gp2
입니다. 에지 컴퓨팅 풀의 각 로컬 영역에 사용되는 인스턴스 유형도 영역에서 제공되는 인스턴스에 따라 작업자 풀과 다를 수 있습니다.
엣지 컴퓨팅 풀은 개발자가 AWS 로컬 영역 노드에 애플리케이션을 배포하는 데 사용할 수 있는 새 레이블을 생성합니다. 새 레이블은 다음과 같습니다.
-
node-role.kubernetes.io/edge=''
-
machine.openshift.io/zone-type=local-zone
-
machine.openshift.io/zone-group=$ZONE_GROUP_NAME
기본적으로 에지 컴퓨팅 풀의 머신 세트는 일반 워크로드가 로컬 영역 인스턴스에 분배되지 않도록 NoSchedule
의 테인트를 정의합니다. 사용자는 Pod 사양에서 허용 오차를 정의하는 경우에만 사용자 워크로드를 실행할 수 있습니다.
18.1.2. AWS 로컬 영역 서브넷을 지원하도록 클러스터 네트워크 MTU 변경
클러스터 인프라에서 로컬 영역 서브넷을 지원할 수 있도록 클러스터 네트워크의 최대 전송 단위(MTU) 값을 변경해야 할 수 있습니다.
18.1.2.1. 클러스터 MTU 정보
설치 중에 클러스터 네트워크의 최대 전송 단위(MTU)는 클러스터에 있는 노드의 기본 네트워크 인터페이스의 MTU를 기반으로 자동으로 감지됩니다. 일반적으로 감지된 MTU를 재정의할 필요가 없습니다.
다음과 같은 이유로 클러스터 네트워크의 MTU를 변경할 수 있습니다.
- 클러스터 설치 중에 감지된 MTU는 인프라에 적합하지 않습니다.
- 이제 최적의 성능을 위해 다른 MTU가 필요한 노드 추가와 같이 클러스터 인프라에 다른 MTU가 필요합니다.
OVN-Kubernetes 및 OpenShift SDN 클러스터 네트워크 플러그인에 대해서만 클러스터 MTU를 변경할 수 있습니다.
18.1.2.1.1. 서비스 중단 고려 사항
클러스터에서 MTU 변경을 시작하면 다음과 같은 영향이 서비스 가용성에 영향을 미칠 수 있습니다.
- 새 MTU로의 마이그레이션을 완료하려면 두 개 이상의 롤링 재부팅이 필요합니다. 이 기간 동안 일부 노드를 다시 시작할 수 없으므로 사용할 수 없습니다.
- 절대 TCP 시간 간격보다 짧은 시간 초과 간격으로 클러스터에 배포된 특정 애플리케이션은 MTU 변경 중에 중단될 수 있습니다.
18.1.2.1.2. MTU 값 선택
MTU 마이그레이션을 계획할 때 고려해야 할 두 가지 관련 MTU 값이 있습니다.
- 하드웨어 MTU: 이 MTU 값은 네트워크 인프라의 세부 사항에 따라 설정됩니다.
클러스터 네트워크 MTU: 이 MTU 값은 클러스터 네트워크 오버레이 오버헤드를 고려하여 하드웨어 MTU보다 항상 적습니다. 특정 오버헤드는 네트워크 플러그인에 의해 결정됩니다.
-
OVN-Kubernetes:
100
바이트 -
OpenShift SDN:
50
바이트
-
OVN-Kubernetes:
클러스터에 다른 노드에 대한 다른 MTU 값이 필요한 경우 클러스터의 모든 노드에서 사용하는 가장 낮은 MTU 값에서 네트워크 플러그인의 오버헤드 값을 제거해야 합니다. 예를 들어, 클러스터의 일부 노드에 9001
의 MTU가 있고 일부에는 1500
의 MTU가 있는 경우 이 값을 1400
으로 설정해야 합니다.
18.1.2.1.3. 마이그레이션 프로세스의 작동 방식
다음 표는 프로세스의 사용자 시작 단계와 마이그레이션이 수행하는 작업 간에 분할하여 마이그레이션 프로세스를 요약합니다.
사용자 시작 단계 | OpenShift Container Platform 활동 |
---|---|
Cluster Network Operator 구성에서 다음 값을 설정합니다.
| CNO(Cluster Network Operator): 각 필드가 유효한 값으로 설정되어 있는지 확인합니다.
제공된 값이 유효한 경우 CNO는 MCO(Machine Config Operator): 클러스터의 각 노드에 대해 롤링 재부팅을 수행합니다. |
클러스터의 노드에 대한 기본 네트워크 인터페이스의 MTU를 재구성합니다. 다음을 포함하여 다양한 방법을 사용하여 이 작업을 수행할 수 있습니다.
| 해당 없음 |
네트워크 플러그인의 CNO 구성에서 | MCO(Machine Config Operator): 새 MTU 구성으로 클러스터의 각 노드를 롤링 재부팅합니다. |
18.1.2.2. 클러스터 MTU 변경
클러스터 관리자는 클러스터의 최대 전송 단위(MTU)를 변경할 수 있습니다. 마이그레이션은 중단되고 MTU 업데이트 롤아웃으로 클러스터의 노드를 일시적으로 사용할 수 없을 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다. 클러스터의 대상 MTU를 확인했습니다. 올바른 MTU는 클러스터가 사용하는 네트워크 플러그인에 따라 다릅니다.
-
OVN-Kubernetes: 클러스터 MTU는 클러스터에서 가장 낮은 하드웨어 MTU 값보다
100
으로 설정되어야 합니다. -
OpenShift SDN: 클러스터 MTU는 클러스터에서 가장 낮은 하드웨어 MTU 값보다
50
미만으로 설정해야 합니다.
-
OVN-Kubernetes: 클러스터 MTU는 클러스터에서 가장 낮은 하드웨어 MTU 값보다
프로세스
클러스터 네트워크의 MTU를 늘리거나 줄이려면 다음 절차를 완료합니다.
클러스터 네트워크의 현재 MTU를 가져오려면 다음 명령을 입력합니다.
$ oc describe network.config cluster
출력 예
... Status: Cluster Network: Cidr: 10.217.0.0/22 Host Prefix: 23 Cluster Network MTU: 1400 Network Type: OpenShiftSDN Service Network: 10.217.4.0/23 ...
MTU 마이그레이션을 시작하려면 다음 명령을 입력하여 마이그레이션 구성을 지정합니다. Machine Config Operator는 MTU 변경을 준비하기 위해 클러스터에서 노드를 롤링 재부팅합니다.
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'
다음과 같습니다.
<overlay_from>
- 현재 클러스터 네트워크 MTU 값을 지정합니다.
<overlay_to>
-
클러스터 네트워크의 대상 MTU를 지정합니다. 이 값은 <
machine_to
> 값을 기준으로 설정되며 OVN-Kubernetes의 경우100
미만이어야 하며 OpenShift SDN의 경우50
미만이어야 합니다. <machine_to>
- 기본 호스트 네트워크의 기본 네트워크 인터페이스에 대한 MTU를 지정합니다.
클러스터 MTU를 늘리는 예
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'
MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.
$ oc get mcp
업데이트된 노드의 상태가
UPDATED=true
,UPDATING=false
,DEGRADED=false
입니다.참고기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.
호스트의 새 머신 구성 상태를 확인합니다.
머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.
$ oc describe node | egrep "hostname|machineconfig"
출력 예
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
다음 구문이 올바른지 확인합니다.
-
machineconfiguration.openshift.io/state
필드의 값은Done
입니다. -
machineconfiguration.openshift.io/currentConfig
필드의 값은machineconfiguration.openshift.io/desiredConfig
필드의 값과 동일합니다.
-
머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.
$ oc get machineconfig <config_name> -o yaml | grep ExecStart
여기서
<config_name>
은machineconfiguration.openshift.io/currentConfig
필드에서 머신 구성의 이름입니다.머신 구성은 다음 업데이트를 systemd 구성에 포함해야 합니다.
ExecStart=/usr/local/bin/mtu-migration.sh
MTU 마이그레이션을 완료하려면 다음 명령 중 하나를 입력합니다.
OVN-Kubernetes 네트워크 플러그인을 사용하는 경우:
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'
다음과 같습니다.
<mtu>
-
<
overlay_to>로 지정한 새 클러스터 네트워크 MTU를 지정합니다
.
OpenShift SDN 네트워크 플러그인을 사용하는 경우:
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'
다음과 같습니다.
<mtu>
-
<
overlay_to>로 지정한 새 클러스터 네트워크 MTU를 지정합니다
.
MTU 마이그레이션을 완료한 후 각 MCP 노드가 하나씩 재부팅됩니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.
$ oc get mcp
업데이트된 노드의 상태가
UPDATED=true
,UPDATING=false
,DEGRADED=false
입니다.
검증
다음 명령을 입력하여 클러스터의 노드에서 이전 절차에서 지정한 MTU를 사용하는지 확인합니다.
$ oc describe network.config cluster
18.1.3. AWS 로컬 영역 선택
AWS 로컬 영역에서 서브넷을 만들려면 각 영역 그룹을 별도로 선택해야 합니다.
사전 요구 사항
- AWS CLI를 설치했습니다.
- OpenShift Container Platform 클러스터를 배포할 AWS 리전을 확인했습니다.
영역 그룹에 옵트인하는 사용자 또는 역할 계정에 허용 IAM 정책을 연결했습니다. 다음 구성을 예제 IAM 정책으로 고려하십시오.
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:ModifyAvailabilityZoneGroup" ], "Effect": "Allow", "Resource": "*" } ] }
프로세스
다음 명령을 실행하여 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
를 지정합니다(미국 동부 뉴질랜드).
18.1.4. AWS 로컬 영역을 사용하도록 기존 클러스터 확장
Machine API가 원격 영역 위치에 Amazon EC2 인스턴스를 생성하려면 로컬 영역 위치에 서브넷을 생성해야 합니다. Ansible 또는 Terraform과 같은 프로비저닝 툴을 사용하여 기존 VPC(Virtual Private Cloud)에서 서브넷을 만들 수 있습니다. 요구 사항을 충족하도록 CloudFormation 템플릿을 구성할 수 있습니다.
다음 하위 섹션에는 CloudFormation 템플릿을 사용하는 단계가 포함되어 있습니다. AWS 로컬 영역의 NAT 게이트웨이 제한 사항을 고려할 때 CloudFormation 템플릿은 퍼블릭 서브넷만 지원합니다. 템플릿을 재사용하여 클러스터를 확장해야 하는 각 에지 위치에 대한 퍼블릭 서브넷을 생성할 수 있습니다.
18.1.4.1. AWS 로컬 영역에서 서브넷 생성
OpenShift Container Platform 클러스터에 대한 작업자 머신 세트를 구성하기 전에 AWS 로컬 영역에 서브넷을 생성해야 합니다.
작업자 노드를 배포할 각 로컬 영역에 대해 다음 프로세스를 반복해야 합니다.
제공된 CloudFormation 템플릿과 사용자 정의 매개변수 파일을 사용하여 서브넷을 나타내는 AWS 리소스 스택을 생성할 수 있습니다.
AWS 인프라를 생성하는 데 제공된 CloudFormation 템플릿을 사용하지 않는 경우, 제공된 정보를 검토하고 수동으로 인프라를 생성해야 합니다. 클러스터가 올바르게 초기화되지 않은 경우, Red Hat 지원팀에 설치 로그를 제시하여 문의해야 할 수도 있습니다.
사전 요구 사항
- AWS 계정을 구성했습니다.
-
aws 구성
을 실행하여 AWS 키와 리전을 로컬 AWS 프로필에 추가하셨습니다. - 로컬 영역 그룹을 선택했습니다.
프로세스
템플릿에 필요한 매개변수 값이 포함된 JSON 파일을 생성합니다.
[ { "ParameterKey": "VpcId", "ParameterValue": "<value_of_VpcId>" 1 }, { "ParameterKey": "PublicRouteTableId", "ParameterValue": "<value_of_PublicRouteTableId>" 2 }, { "ParameterKey": "ZoneName", "ParameterValue": "<value_of_ZoneName>" 3 }, { "ParameterKey": "SubnetName", "ParameterValue": "<value_of_SubnetName>" }, { "ParameterKey": "PublicSubnetCidr", "ParameterValue": "10.0.192.0/20" 4 } ]
- 1
- VPC ID를 지정합니다. 이는 CloudFormation 템플릿의 출력에서
VpcID
값인 VPC ID를 지정합니다. - 2
- VPC의 CloudFormation 스택에서
PublicRouteTableId
의 값인 Route Table ID를 지정합니다. - 3
- "AWS Local Zones" 섹션에서 검색한
AvailabilityZones
오브젝트의ZoneName
필드 값인 AWS 로컬 영역 이름을 지정합니다. - 4
- Local Zone 서브넷을 생성하는 데 사용되는 CIDR 블록을 지정합니다. 이 블록은 VPC CIDR 블록
VpcCidr
의 일부여야 합니다.
- 이 항목의 서브넷 섹션에 대한 CloudFormation 템플릿 섹션에서 템플릿을 복사하여 사용자 컴퓨터에 YAML 파일로 저장합니다. 이 템플릿은 클러스터에 필요한 VPC를 설명합니다.
CloudFormation 템플릿을 시작하여 다음 명령을 실행하여 VPC를 나타내는 AWS 리소스 스택을 생성합니다.
중요명령은 한 줄로 입력해야 합니다.
$ aws cloudformation create-stack --stack-name <subnet_stack_name> \ 1 --template-body file://<template>.yaml \ 2 --parameters file://<parameters>.json 3
출력 예
arn:aws:cloudformation:us-east-1:123456789012:stack/<subnet_stack_name>/dbedae40-2fd3-11eb-820e-12a48460849f
다음 명령을 실행하여 템플릿 구성 요소가 있는지 확인합니다.
$ aws cloudformation describe-stacks --stack-name <subnet_stack_name>
StackStatus
에CREATE_COMPLETE
이 표시된 후 다음 매개변수의 출력 값이 표시됩니다. 클러스터를 생성하기 위해 실행하는 다른 CloudFormation 템플릿에 이러한 매개변수 값을 제공해야 합니다.PublicSubnetIds
새 퍼블릭 서브넷의 ID입니다.
18.1.4.2. AWS 로컬 영역을 사용하는 서브넷의 CloudFormation 템플릿
다음 CloudFormation 템플릿을 사용하여 AWS Local Zones를 사용하는 OpenShift Container Platform 클러스터에 필요한 서브넷을 배포할 수 있습니다.
예 18.1. 서브넷용 CloudFormation 템플릿
# CloudFormation template used to create Local Zone subnets and dependencies AWSTemplateFormatVersion: 2010-09-09 Description: Template for create Public Local Zone subnets Parameters: VpcId: Description: VPC Id Type: String ZoneName: Description: Local Zone Name (Example us-east-1-nyc-1a) Type: String SubnetName: Description: Local Zone Name (Example cluster-public-us-east-1-nyc-1a) Type: String PublicRouteTableId: Description: Public Route Table ID to associate the Local Zone subnet Type: String 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 Resources: PublicSubnet: Type: "AWS::EC2::Subnet" Properties: VpcId: !Ref VpcId CidrBlock: !Ref PublicSubnetCidr AvailabilityZone: !Ref ZoneName Tags: - Key: Name Value: !Ref SubnetName - Key: kubernetes.io/cluster/unmanaged Value: "true" PublicSubnetRouteTableAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref PublicSubnet RouteTableId: !Ref PublicRouteTableId Outputs: PublicSubnetIds: Description: Subnet IDs of the public subnets. Value: !Join ["", [!Ref PublicSubnet]]
18.1.5. AWS Local Zones 노드의 머신 세트 매니페스트 생성
AWS 로컬 영역에서 서브넷을 생성한 후 머신 세트 매니페스트를 생성할 수 있습니다.
설치 프로그램은 클러스터 설치 시 에지
머신 풀에 대해 다음 레이블을 설정합니다.
-
machine.openshift.io/parent-zone-name: <value_of_ParentZoneName>
-
machine.openshift.io/zone-group: <value_of_ZoneGroup>
-
machine.openshift.io/zone-type: <value_of_ZoneType>
다음 절차에서는 에지
컴퓨팅 풀 구성과 일치하는 머신 세트 configuraton을 생성하는 방법을 자세히 설명합니다.
사전 요구 사항
- AWS 로컬 영역에 서브넷을 생성했습니다.
프로세스
AWS API를 수집하여 머신 세트 매니페스트를 생성할 때
에지
머신 풀 레이블을 수동으로 유지합니다. 이 작업을 완료하려면 CLI(명령줄 인터페이스)에 다음 명령을 입력합니다.$ aws ec2 describe-availability-zones --region <value_of_Region> \1 --query 'AvailabilityZones[].{ ZoneName: ZoneName, ParentZoneName: ParentZoneName, GroupName: GroupName, ZoneType: ZoneType}' \ --filters Name=zone-name,Values=<value_of_ZoneName> \2 --all-availability-zones
로컬 영역 us-east-1-nyc-1a
의 출력 예
[ { "ZoneName": "us-east-1-nyc-1a", "ParentZoneName": "us-east-1f", "GroupName": "us-east-1-nyc-1", "ZoneType": "local-zone" } ]
18.1.5.1. AWS에서 컴퓨팅 머신 세트 사용자 정의 리소스의 샘플 YAML
이 샘플 YAML은 us-east-1-nyc-1a
AWS (Amazon Web Services) 영역에서 실행되는 컴퓨팅 머신 세트를 정의하고 node-role.kubernetes.io/edge: ""
로 레이블이 지정된 노드를 생성합니다.
이 샘플에서 < infrastructure_id
>는 클러스터를 프로비저닝할 때 설정한 클러스터 ID를 기반으로 하는 인프라 ID 레이블이며 < edge
>는 추가할 노드 레이블입니다.
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 name: <infrastructure_id>-edge-<zone> 2 namespace: openshift-machine-api spec: replicas: 1 selector: matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 3 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-edge-<zone> template: metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 4 machine.openshift.io/cluster-api-machine-role: edge 5 machine.openshift.io/cluster-api-machine-type: edge 6 machine.openshift.io/cluster-api-machineset: <infrastructure_id>-edge-<zone> 7 spec: metadata: labels: machine.openshift.io/parent-zone-name: <value_of_ParentZoneName> machine.openshift.io/zone-group: <value_of_GroupName> machine.openshift.io/zone-type: <value_of_ZoneType> node-role.kubernetes.io/edge: "" 8 providerSpec: value: ami: id: ami-046fe691f52a953f9 9 apiVersion: machine.openshift.io/v1beta1 blockDevices: - ebs: iops: 0 volumeSize: 120 volumeType: gp2 credentialsSecret: name: aws-cloud-credentials deviceIndex: 0 iamInstanceProfile: id: <infrastructure_id>-worker-profile 10 instanceType: m6i.large kind: AWSMachineProviderConfig placement: availabilityZone: <zone> 11 region: <region> 12 securityGroups: - filters: - name: tag:Name values: - <infrastructure_id>-worker-sg 13 subnet: id: <value_of_PublicSubnetIds> 14 publicIp: true tags: - name: kubernetes.io/cluster/<infrastructure_id> 15 value: owned - name: <custom_tag_name> 16 value: <custom_tag_value> 17 userDataSecret: name: worker-user-data taints: 18 - key: node-role.kubernetes.io/edge effect: NoSchedule
- 1 3 4 10 13 15
- 클러스터를 프로비저닝할 때 설정한 클러스터 ID를 기반으로 하는 인프라 ID를 지정합니다. OpenShift CLI 패키지가 설치되어 있으면 다음 명령을 실행하여 인프라 ID를 얻을 수 있습니다.
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
- 2 7
- 인프라 ID,
에지
역할 노드 레이블 및 영역 이름을 지정합니다. - 5 6 8
에지
역할 노드 레이블을 지정합니다.- 9
- OpenShift Container Platform 노드의 AWS 영역에 유효한 RHCOS(Red Hat Enterprise Linux CoreOS) Amazon 머신 이미지(AMI)를 지정합니다. AWS Marketplace 이미지를 사용하려면 해당 리전의 AMI ID를 받으려면 AWS Marketplace 에서 OpenShift Container Platform 서브스크립션을 완료해야 합니다.
$ oc -n openshift-machine-api \ -o jsonpath='{.spec.template.spec.providerSpec.value.ami.id}{"\n"}' \ get machineset/<infrastructure_id>-<role>-<zone>
- 16 17
- 선택 사항: 클러스터의 사용자 지정 태그 데이터를 지정합니다. 예를 들어 이메일
:admin-email@example.com의
주소를 추가할 수 있습니다.이름:값
쌍을 지정하여 관리자 연락처 이메일참고install-config.yml
파일에서 설치 중에 사용자 지정 태그를 지정할 수도 있습니다.install-config.yml
파일과 머신 세트에 동일한이름
데이터가 있는 태그가 포함된 경우 머신 세트의 태그 값이install-config.yml
파일의 태그 값보다 우선합니다. - 11
- 영역 이름을 지정합니다(예:
us-east-1-nyc-1a
). - 12
- 리전을 지정합니다(예:
us-east-1
). - 14
- AWS 로컬 영역에서 생성한 공용 서브넷의 ID입니다. "AWS 로컬 영역에서 서브넷 생성" 절차를 완료할 때 이 공용 서브넷 ID를 생성했습니다.
- 18
- 사용자 워크로드가
에지
노드에서 예약되지 않도록 테인트를 지정합니다.참고인프라 노드에
NoSchedule
테인트를 추가하면 해당 노드에서 실행 중인 기존 DNS Pod가잘못 예약
됨으로 표시됩니다.잘못 스케줄링된
DNS Pod에서 허용 오차를 삭제하거나 추가해야 합니다.
18.1.5.2. 컴퓨팅 머신 세트 생성
설치 프로그램에서 생성한 컴퓨팅 머신 세트 외에도 고유한 머신 세트를 생성하여 선택한 특정 워크로드의 머신 컴퓨팅 리소스를 동적으로 관리할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터를 배포합니다.
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로oc
에 로그인합니다.
프로세스
컴퓨팅 머신 세트 CR(사용자 정의 리소스) 샘플이 포함된 새 YAML 파일을 만들고
<file_name>.yaml
이라는 이름을 지정합니다.<clusterID>
및<role>
매개 변수 값을 설정해야 합니다.선택 사항: 특정 필드에 설정할 값이 확실하지 않은 경우 클러스터에서 기존 컴퓨팅 머신 세트를 확인할 수 있습니다.
클러스터의 컴퓨팅 머신 세트를 나열하려면 다음 명령을 실행합니다.
$ oc get machinesets -n openshift-machine-api
출력 예
NAME DESIRED CURRENT READY AVAILABLE AGE agl030519-vplxk-worker-us-east-1a 1 1 1 1 55m agl030519-vplxk-worker-us-east-1b 1 1 1 1 55m agl030519-vplxk-worker-us-east-1c 1 1 1 1 55m agl030519-vplxk-worker-us-east-1d 0 0 55m agl030519-vplxk-worker-us-east-1e 0 0 55m agl030519-vplxk-worker-us-east-1f 0 0 55m
특정 컴퓨팅 머신 세트 CR(사용자 정의 리소스)의 값을 보려면 다음 명령을 실행합니다.
$ oc get machineset <machineset_name> \ -n openshift-machine-api -o yaml
출력 예
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 name: <infrastructure_id>-<role> 2 namespace: openshift-machine-api spec: replicas: 1 selector: matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> template: metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> machine.openshift.io/cluster-api-machine-role: <role> machine.openshift.io/cluster-api-machine-type: <role> machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> spec: providerSpec: 3 ...
다음 명령을 실행하여
MachineSet
CR을 생성합니다.$ oc create -f <file_name>.yaml
검증
다음 명령을 실행하여 컴퓨팅 머신 세트 목록을 확인합니다.
$ oc get machineset -n openshift-machine-api
출력 예
NAME DESIRED CURRENT READY AVAILABLE AGE agl030519-vplxk-edge-us-east-1-nyc-1a 1 1 1 1 11m agl030519-vplxk-worker-us-east-1a 1 1 1 1 55m agl030519-vplxk-worker-us-east-1b 1 1 1 1 55m agl030519-vplxk-worker-us-east-1c 1 1 1 1 55m agl030519-vplxk-worker-us-east-1d 0 0 55m agl030519-vplxk-worker-us-east-1e 0 0 55m agl030519-vplxk-worker-us-east-1f 0 0 55m
새 컴퓨팅 머신 세트를 사용할 수 있으면
DESIRED
및CURRENT
값이 일치합니다. 컴퓨팅 머신 세트를 사용할 수 없는 경우 몇 분 기다렸다가 명령을 다시 실행합니다.선택 사항: 에지 머신에서 생성한 노드를 확인하려면 다음 명령을 실행합니다.
$ 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