지원콘솔개발자평가판 시작연락처

8.2. 로컬 영역 또는 Wavelength 영역을 지원하도록 클러스터 네트워크 MTU 변경

클러스터 인프라가 로컬 영역 또는 Wavelength 영역 서브넷을 지원할 수 있도록 클러스터 네트워크의 최대 전송 단위(MTU) 값을 변경해야 할 수 있습니다.

8.2.1. 클러스터 MTU 정보

설치 중에 클러스터 네트워크의 최대 전송 단위(MTU)는 클러스터에 있는 노드의 기본 네트워크 인터페이스의 MTU를 기반으로 자동으로 감지됩니다. 일반적으로 감지된 MTU를 재정의할 필요가 없습니다.

다음과 같은 이유로 클러스터 네트워크의 MTU를 변경할 수 있습니다.

  • 클러스터 설치 중에 감지된 MTU는 인프라에 적합하지 않습니다.
  • 이제 최적의 성능을 위해 다른 MTU가 필요한 노드 추가와 같이 클러스터 인프라에 다른 MTU가 필요합니다.

OVN-Kubernetes 클러스터 네트워크 플러그인만 MTU 값 변경을 지원합니다.

8.2.1.1. 서비스 중단 고려 사항

클러스터에서 MTU 변경을 시작하면 다음과 같은 영향이 서비스 가용성에 영향을 미칠 수 있습니다.

  • 새 MTU로의 마이그레이션을 완료하려면 두 개 이상의 롤링 재부팅이 필요합니다. 이 기간 동안 일부 노드를 다시 시작할 수 없으므로 사용할 수 없습니다.
  • 절대 TCP 시간 간격보다 짧은 시간 초과 간격으로 클러스터에 배포된 특정 애플리케이션은 MTU 변경 중에 중단될 수 있습니다.

8.2.1.2. MTU 값 선택

MTU 마이그레이션을 계획할 때 고려해야 할 두 가지 관련 MTU 값이 있습니다.

  • 하드웨어 MTU: 이 MTU 값은 네트워크 인프라의 세부 사항에 따라 설정됩니다.
  • 클러스터 네트워크 MTU: 이 MTU 값은 클러스터 네트워크 오버레이 오버헤드를 고려하여 하드웨어 MTU보다 항상 적습니다. 특정 오버헤드는 네트워크 플러그인에 따라 결정됩니다. OVN-Kubernetes의 경우 오버헤드는 100 바이트입니다.

클러스터에 다른 노드에 대한 다른 MTU 값이 필요한 경우 클러스터의 모든 노드에서 사용하는 가장 낮은 MTU 값에서 네트워크 플러그인의 오버헤드 값을 제거해야 합니다. 예를 들어, 클러스터의 일부 노드에 9001의 MTU가 있고 일부에는 1500의 MTU가 있는 경우 이 값을 1400으로 설정해야 합니다.

중요

노드에서 허용되지 않는 MTU 값을 선택하지 않으려면 ip -d link 명령을 사용하여 네트워크 인터페이스에서 허용하는 최대 MTU 값(maxmtu)을 확인합니다.

8.2.1.3. 마이그레이션 프로세스의 작동 방식

다음 표는 프로세스의 사용자 시작 단계와 마이그레이션이 수행하는 작업 간에 분할하여 마이그레이션 프로세스를 요약합니다.

표 8.1. 클러스터 MTU의 실시간 마이그레이션
사용자 시작 단계OpenShift Container Platform 활동

Cluster Network Operator 구성에서 다음 값을 설정합니다.

  • spec.migration.mtu.machine.to
  • spec.migration.mtu.network.from
  • spec.migration.mtu.network.to

CNO(Cluster Network Operator): 각 필드가 유효한 값으로 설정되어 있는지 확인합니다.

  • 하드웨어의 MTU가 변경되지 않는 경우 mtu.machine.to 를 새 하드웨어 MTU 또는 현재 하드웨어 MTU로 설정해야 합니다. 이 값은 일시적인 값이며 마이그레이션 프로세스의 일부로 사용됩니다. 별도로 기존 하드웨어 MTU 값과 다른 하드웨어 MTU를 지정하는 경우 머신 구성, DHCP 설정 또는 Linux 커널 명령줄과 같이 다른 방법으로 유지되도록 MTU를 수동으로 구성해야 합니다.
  • mtu.network.from 필드는 클러스터 네트워크의 현재 MTU인 network.status.clusterNetworkMTU 필드와 같아야 합니다.
  • mtu.network.to 필드는 대상 클러스터 네트워크 MTU로 설정해야 하며 네트워크 플러그인의 오버레이 오버헤드를 허용하려면 하드웨어 MTU보다 작아야 합니다. OVN-Kubernetes의 경우 오버헤드는 100 바이트입니다.

제공된 값이 유효한 경우 CNO는 mtu.network.to 필드 값으로 설정된 클러스터 네트워크의 MTU를 사용하여 새 임시 구성을 작성합니다.

MCO(Machine Config Operator): 클러스터의 각 노드에 대해 롤링 재부팅을 수행합니다.

클러스터의 노드에 대한 기본 네트워크 인터페이스의 MTU를 재구성합니다. 다음을 포함하여 다양한 방법을 사용하여 이 작업을 수행할 수 있습니다.

  • MTU 변경으로 새 NetworkManager 연결 프로필 배포
  • DHCP 서버 설정을 통해 MTU 변경
  • 부팅 매개변수를 통해 MTU 변경

해당 없음

네트워크 플러그인의 CNO 구성에서 mtu 값을 설정하고 spec.migration 을 null 로 설정합니다.

MCO(Machine Config Operator): 새 MTU 구성으로 클러스터의 각 노드를 롤링 재부팅합니다.

8.2.1.4. 클러스터 네트워크 MTU 변경

클러스터 관리자는 클러스터의 최대 전송 단위(MTU)를 늘리거나 줄일 수 있습니다.

중요

MTU 업데이트가 적용되므로 마이그레이션이 중단되고 클러스터의 노드를 일시적으로 사용할 수 없게 될 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 계정을 사용하여 클러스터에 액세스할 수 있습니다.
  • 클러스터의 대상 MTU를 식별했습니다. OVN-Kubernetes 네트워크 플러그인의 MTU는 클러스터에서 가장 낮은 하드웨어 MTU 값보다 100 으로 설정해야 합니다.

프로세스

  1. 클러스터 네트워크의 현재 MTU를 가져오려면 다음 명령을 입력합니다. 

    $ oc describe network.config cluster

    출력 예

    ...
Status:
  Cluster Network:
    Cidr:               10.217.0.0/22
    Host Prefix:        23
  Cluster Network MTU:  1400
  Network Type:         OVNKubernetes
  Service Network:
    10.217.4.0/23
...

  2. 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의 경우 이 값은 <machine_to> 값보다 100 미만이어야 합니다.
    <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} } } } }'

  3. Machine Config Operator는 각 머신 구성 풀에서 머신을 업데이트하므로 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다. 

    $ oc get machineconfigpools

    업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

    참고

    기본적으로 Machine Config Operator는 풀당 한 번에 하나의 머신을 업데이트하여 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간을 늘립니다.

  4. 호스트의 새 머신 구성 상태를 확인합니다.

    1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다. 

      $ 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

    2. 다음 구문이 올바른지 확인합니다.

      • machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
      • machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.

    3. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다. 

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart

      여기서 <config_name>은 machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

      머신 구성은 다음 업데이트를 systemd 구성에 포함해야 합니다. 

      ExecStart=/usr/local/bin/mtu-migration.sh

  5. MTU 마이그레이션을 완료하려면 OVN-Kubernetes 네트워크 플러그인에 대해 다음 명령을 입력합니다. 

    $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'

    다음과 같습니다.

    <mtu>
    < overlay_to>로 지정한 새 클러스터 네트워크 MTU를 지정합니다.

  6. MTU 마이그레이션을 완료한 후 각 머신 구성 풀 노드는 하나씩 재부팅됩니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다. 

    $ oc get machineconfigpools

    업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

검증

  • 다음 명령을 입력하여 클러스터의 노드에서 지정한 MTU를 사용하는지 확인합니다. 

    $ oc describe network.config cluster

8.2.2. AWS 로컬 영역 또는 Wavelength 영역 선택

AWS 로컬 영역 또는 Wavelength 영역에서 서브넷을 만들려면 각 영역 그룹을 별도로 선택해야 합니다.

사전 요구 사항

  • AWS CLI를 설치했습니다.
  • OpenShift Container Platform 클러스터를 배포할 AWS 리전을 확인했습니다.
  • 영역 그룹에 옵트인하는 사용자 또는 역할 계정에 허용 IAM 정책을 연결했습니다.

프로세스

  1. 다음 명령을 실행하여 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 리전에서 사용 가능한 AWS Wavelength 영역을 나열하는 명령의 예

    $ aws --region "<value_of_AWS_Region>" ec2 describe-availability-zones \
    --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \
    --filters Name=zone-type,Values=wavelength-zone \
    --all-availability-zones

    AWS 리전에 따라 사용 가능한 영역 목록이 길 수 있습니다. 이 명령은 다음 필드를 반환합니다.

    ZoneName
    로컬 영역 또는 Wavelength 영역의 이름입니다.
    GroupName
    영역으로 구성된 그룹입니다. 리전을 선택하려면 이름을 저장합니다.
    상태
    로컬 영역 또는 Wavelength Zones 그룹의 상태입니다. 상태가opted-in 인 경우 다음 단계에 설명된 대로 GroupName 을 선택해야 합니다.

  2. 다음 명령을 실행하여 AWS 계정의 영역 그룹을 선택합니다. 

    $ aws ec2 modify-availability-zone-group \
    --group-name "<value_of_GroupName>" \1
    --opt-in-status opted-in
    1
    & lt;value_of_GroupName >을 서브넷을 생성하려는 로컬 영역 또는 Wavelength 영역의 이름으로 바꿉니다.

8.2.3. AWS 로컬 영역 또는 Wavelength 영역을 사용하는 기존 VPC에서 네트워크 요구 사항을 생성합니다.

Machine API가 원격 영역 위치에 Amazon EC2 인스턴스를 생성하려면 로컬 영역 또는 Wavelength Zones 위치에 서브넷을 생성해야 합니다. Ansible 또는 Terraform과 같은 프로비저닝 툴을 사용하여 기존 VPC(Virtual Private Cloud)에서 서브넷을 만들 수 있습니다.

요구 사항을 충족하도록 CloudFormation 템플릿을 구성할 수 있습니다. 다음 하위 섹션에는 CloudFormation 템플릿을 사용하여 AWS 로컬 영역 또는 Wavelength 영역을 사용하도록 기존 VPC를 확장하는 네트워크 요구 사항을 생성하는 단계가 포함되어 있습니다.

노드를 로컬 영역으로 확장하려면 다음 리소스를 생성해야 합니다.

  • 2 VPC 서브넷: 공용 및 개인. 공용 서브넷은 리전의 일반 가용성 영역의 공용 경로 테이블에 연결됩니다. 프라이빗 서브넷은 제공된 경로 테이블 ID에 연결됩니다.

노드를 Wavelength 영역으로 확장하려면 다음 리소스를 생성해야 합니다.

  • 제공된 VPC ID에 연결된 1개의 VPC 캐리어 게이트웨이.
  • VPC 카리더 게이트웨이에 기본 경로 항목이 있는 1개의 VPC Route Table for Wavelength Zones
  • 2 VPC 서브넷: 공용 및 개인. 공용 서브넷은 AWS Wavelength 영역의 공용 경로 테이블에 연결됩니다. 프라이빗 서브넷은 제공된 경로 테이블 ID에 연결됩니다.
중요

Wavelength 영역에 있는 NAT 게이트웨이의 제한을 고려할 때 제공된 CloudFormation 템플릿은 제공된 경로 테이블 ID와 프라이빗 서브넷만 연결할 수 있습니다. 경로 테이블 ID가 AWS 리전의 유효한 NAT 게이트웨이에 연결되어 있습니다.

8.2.4. 파장 영역만 해당: VPC 캐리어 게이트웨이 생성

Wavelength 영역에서 실행되는 OpenShift Container Platform 클러스터의 퍼블릭 서브넷을 사용하려면 캐리어 게이트웨이를 생성하고 캐리어 게이트웨이를 VPC에 연결해야 합니다. 서브넷은 로드 밸런서 또는 엣지 컴퓨팅 노드를 배포하는 데 유용합니다.

OpenShift Container Platform 클러스터의 Wavelength Zones 위치에서 에지 노드 또는 인터넷 대 로드 밸런서를 생성하려면 다음과 같은 필수 네트워크 구성 요소를 생성해야 합니다.

  • 기존 VPC에 연결하는 캐리어 게이트웨이입니다.
  • 경로 항목을 나열하는 캐리어 경로 테이블입니다.
  • 캐리어 경로 테이블에 연결하는 서브넷입니다.

Wavelength 영역에 서브넷만 포함하는 VPC에는 캐리어 게이트웨이가 있습니다.

다음 목록은 AWS Wavelength Zones 위치의 컨텍스트에서 캐리어 게이트웨이의 기능을 설명합니다.

  • 캐리어 네트워크에서 사용 가능한 장치를 포함하는 Wavelength 영역과 이동 통신 네트워크 간의 연결을 제공합니다.
  • Wavelength 영역에서 캐리어 IP 주소로, 네트워크 테두리 그룹에 저장된 공용 IP 주소인 IP 주소를 변환하는 등 NAT(네트워크 주소 변환) 기능을 수행합니다. 이러한 변환 기능은 인바운드 및 아웃바운드 트래픽에 적용됩니다.
  • 특정 위치에 있는 캐리어 네트워크에서 인바운드 트래픽을 승인합니다.
  • 캐리어 네트워크 및 인터넷에 대한 아웃바운드 트래픽을 인증합니다.
참고

이동 통신 게이트웨이를 통해 인터넷에서 Wavelength 영역으로의 인바운드 연결 구성이 없습니다.

제공된 CloudFormation 템플릿을 사용하여 다음 AWS 리소스의 스택을 생성할 수 있습니다.

  • 템플릿의 VPC ID에 연결하는 하나의 캐리어 게이트웨이입니다.
  • < ClusterName>-public-carrier라는 이름의 Wavelength 영역에 대한 하나의 공용 경로 테이블입니다.
  • 이동 통신 게이트웨이를 대상으로 하는 새 경로 테이블의 기본 IPv4 경로 항목입니다.
  • AWS S3(Simple Storage Service)용 VPC 게이트웨이 끝점.
참고

AWS 인프라를 생성하는 데 제공된 CloudFormation 템플릿을 사용하지 않는 경우, 제공된 정보를 검토하고 수동으로 인프라를 생성해야 합니다. 클러스터가 올바르게 초기화되지 않은 경우, Red Hat 지원팀에 설치 로그를 제시하여 문의해야 할 수도 있습니다.

사전 요구 사항

  • AWS 계정을 구성했습니다.
  • aws 구성을 실행하여 AWS 키와 리전을 로컬 AWS 프로필에 추가하셨습니다.

프로세스

  1. "CloudFormation template for the VPC carrier Gateway"라는 문서의 다음 섹션으로 이동한 다음 VPC 카리더 게이트웨이 템플릿의 CloudFormation 템플릿에서 구문을 복사합니다. 복사한 템플릿 구문을 로컬 시스템에 YAML 파일로 저장합니다. 이 템플릿은 클러스터에 필요한 VPC를 설명합니다.

  2. 다음 명령을 실행하여 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="${VpcId}" \3
    ParameterKey=ClusterName,ParameterValue="${ClusterName}" 4
    1
    <stack_name >은 CloudFormation 스택의 이름입니다(예: clusterName-vpc-carrier-gw ). 클러스터를 제거하는 경우 이 스택의 이름이 필요합니다.
    2
    <template >은 상대 경로이며 저장한 CloudFormation 템플릿 YAML 파일의 이름입니다.
    3
    <VpcId >는 "AWS에서 VPC 생성"이라는 섹션에 생성된 CloudFormation 스택 출력에서 추출된 VPC ID입니다.
    4
    <clustername >은 CloudFormation 스택에서 생성하는 리소스에 접두사를 지정하는 사용자 정의 값입니다. install-config.yaml 구성 파일의 metadata.name 섹션에 정의된 동일한 이름을 사용할 수 있습니다.

    출력 예

    arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-2fd3-11eb-820e-12a48460849f

검증

  • 다음 명령을 실행하여 CloudFormation 템플릿 구성 요소가 있는지 확인합니다. 

    $ aws cloudformation describe-stacks --stack-name <stack_name>

    StackStatus 에 CREATE_COMPLETE 가 표시되면 출력에 다음 매개변수의 값이 표시됩니다. 클러스터에 대해 생성하기 위해 실행하는 다른 CloudFormation 템플릿에 매개변수 값을 제공해야 합니다.

    PublicRouteTableId

    카리더 인프라에 있는 경로 테이블의 ID입니다.

8.2.5. 웨이브 길이 영역만 해당: VPC 카리더 게이트웨이용 CloudFormation 템플릿

다음 CloudFormation 템플릿을 사용하여 AWS Wavelength 인프라에 카리어 게이트웨이를 배포할 수 있습니다.

예 8.1. VPC 카리더 게이트웨이용 CloudFormation 템플릿

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Creating Wavelength Zone Gateway (Carrier Gateway).

Parameters:
  VpcId:
    Description: VPC ID to associate the Carrier Gateway.
    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 tag Name for each subnet.
    Type: String
    AllowedPattern: ".+"
    ConstraintDescription: ClusterName parameter must be specified.

Resources:
  CarrierGateway:
    Type: "AWS::EC2::CarrierGateway"
    Properties:
      VpcId: !Ref VpcId
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "cagw"]]

  PublicRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VpcId
      Tags:
      - Key: Name
        Value: !Join ['-', [!Ref ClusterName, "public-carrier"]]

  PublicRoute:
    Type: "AWS::EC2::Route"
    DependsOn: CarrierGateway
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      CarrierGatewayId: !Ref CarrierGateway

  S3Endpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
        - Effect: Allow
          Principal: '*'
          Action:
          - '*'
          Resource:
          - '*'
      RouteTableIds:
      - !Ref PublicRouteTable
      ServiceName: !Join
      - ''
      - - com.amazonaws.
        - !Ref 'AWS::Region'
        - .s3
      VpcId: !Ref VpcId

Outputs:
  PublicRouteTableId:
    Description: Public Route table ID
    Value: !Ref PublicRouteTable

8.2.6. AWS 엣지 컴퓨팅 서비스의 서브넷 생성

OpenShift Container Platform 클러스터에서 에지 컴퓨팅 노드에 대한 머신 세트를 구성하기 전에 로컬 영역 또는 Wavelength 영역에 서브넷을 생성해야 합니다. 컴퓨팅 노드를 배포할 각 Wavelength 영역에 대해 다음 절차를 완료합니다.

제공된 CloudFormation 템플릿을 사용하고 CloudFormation 스택을 생성할 수 있습니다. 그런 다음 이 스택을 사용하여 서브넷을 사용자 지정 프로비저닝할 수 있습니다.

참고

AWS 인프라를 생성하는 데 제공된 CloudFormation 템플릿을 사용하지 않는 경우, 제공된 정보를 검토하고 수동으로 인프라를 생성해야 합니다. 클러스터가 올바르게 초기화되지 않은 경우, Red Hat 지원팀에 설치 로그를 제시하여 문의해야 할 수도 있습니다.

사전 요구 사항

  • AWS 계정을 구성했습니다.
  • aws 구성을 실행하여 AWS 키와 리전을 로컬 AWS 프로필에 추가하셨습니다.
  • 로컬 영역 또는 Wavelength Zones 그룹을 선택했습니다.

프로세스

  1. "CloudFormation template for the VPC subnet"이라는 문서의 섹션으로 이동하여 템플릿에서 구문을 복사합니다. 복사한 템플릿 구문을 로컬 시스템에 YAML 파일로 저장합니다. 이 템플릿은 클러스터에 필요한 VPC를 설명합니다.

  2. 다음 명령을 실행하여 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 >은 로컬 영역의 cluster-wl-<local_zone_shortname > 및 Wavelength 영역의 경우 cluster-wl-<undercloudlength_zone_shortname >과 같은 CloudFormation 스택의 이름입니다. 클러스터를 제거하는 경우 이 스택의 이름이 필요합니다.
    2
    <template >은 상대 경로이며 저장한 CloudFormation 템플릿 YAML 파일의 이름입니다.
    3
    ${VPC_ID} 는 VPC의 CloudFormation 템플릿 출력에 있는 VpcID 값인 VPC ID입니다.
    4
    ${CLUSTER_NAME} 은 새 AWS 리소스 이름의 접두사로 사용할 ClusterName 의 값입니다.
    5
    ${ZONE_NAME} 은 서브넷을 생성할 로컬 영역 또는 Wavelength 영역 이름 값입니다.
    6
    ${ROUTE_ Cryostat_PUB} 는 CloudFormation 템플릿에서 추출한 공개 경로 테이블 ID입니다. 로컬 영역의 경우 공용 경로 테이블이 VPC CloudFormation Stack에서 추출됩니다. Wavelength Zones의 경우 VPC 통신 게이트웨이 CloudFormation 스택의 출력에서 값을 추출해야 합니다.
    7
    ${SUBNET_CIDR_PUB} 는 공용 서브넷을 생성하는 데 사용되는 유효한 CIDR 블록입니다. 이 블록은 VPC CIDR 블록 VpcCidr 의 일부여야 합니다.
    8
    ${ROUTE_ Cryostat_PVT} 는 VPC의 CloudFormation 스택 출력에서 추출된 PrivateRouteTableId 입니다.
    9
    ${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 가 표시되면 출력에 다음 매개변수의 값이 표시됩니다.

    PublicSubnetId

    CloudFormation 스택에서 생성한 공용 서브넷의 ID입니다.

    PrivateSubnetId

    CloudFormation 스택에서 생성한 프라이빗 서브넷의 ID입니다.

    이러한 매개변수 값을 클러스터에 생성하기 위해 실행하는 다른 CloudFormation 템플릿에 제공해야 합니다.

8.2.7. VPC 서브넷용 CloudFormation 템플릿

다음 CloudFormation 템플릿을 사용하여 로컬 영역 또는 Wavelength 영역 인프라에 프라이빗 및 퍼블릭 서브넷을 배포할 수 있습니다.

예 8.2. 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]]

8.2.8. AWS Local Zones 또는 Wavelength Zones 노드의 머신 세트 매니페스트 생성

AWS 로컬 영역 또는 Wavelength 영역에서 서브넷을 생성한 후 머신 세트 매니페스트를 생성할 수 있습니다.

설치 프로그램은 클러스터 설치 시 에지 머신 풀에 대해 다음 레이블을 설정합니다.

  • 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 로컬 영역 또는 Wavelength 영역에 서브넷을 생성했습니다.

프로세스

  • 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
    1
    & lt;value_of_Region >의 경우 영역의 리전 이름을 지정합니다.
    2
    & lt;value_of_ZoneName >의 경우 로컬 영역 또는 Wavelength 영역의 이름을 지정합니다.

    로컬 영역 us-east-1-nyc-1a의 출력 예

    [
    {
        "ZoneName": "us-east-1-nyc-1a",
        "ParentZoneName": "us-east-1f",
        "GroupName": "us-east-1-nyc-1",
        "ZoneType": "local-zone"
    }
]

    Wavelength Zone us-east-1-wl1출력 예

    [
    {
        "ZoneName": "us-east-1-wl1-bos-wlz-1",
        "ParentZoneName": "us-east-1a",
        "GroupName": "us-east-1-wl1",
        "ZoneType": "wavelength-zone"
    }
]

8.2.8.1. AWS에서 컴퓨팅 머신 세트 사용자 정의 리소스의 샘플 YAML

이 샘플 YAML은 us-east-1-nyc-1a AWS (Amazon Web Services) 영역에서 실행되는 컴퓨팅 머신 세트를 정의하고 node-role.kubernetes.io/edge: "" 로 레이블이 지정된 노드를 생성합니다.

참고

Wavelength Zones 컨텍스트에서 샘플 YAML 파일을 참조하려면 AWS 리전 및 영역 정보를 지원되는 Wavelength Zone 값으로 교체해야 합니다.

이 샘플에서 < 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
선택 사항: 클러스터의 사용자 지정 태그 데이터를 지정합니다. 예를 들어 Email:admin-email@example.com의 name:value 쌍을 지정하여 관리자 연락처 이메일 주소를 추가할 수 있습니다.
참고

install-config.yml 파일에서 설치 중에 사용자 지정 태그를 지정할 수도 있습니다. install-config.yml 파일과 머신 세트에 동일한 name 데이터가 있는 태그가 포함된 경우 머신 세트의 태그 값이 install-config.yml 파일의 태그 값보다 우선합니다.

11
영역 이름을 지정합니다(예: us-east-1-nyc-1a ).
12
리전을 지정합니다(예: us-east-1 ).
14
AWS 로컬 영역 또는 Wavelength 영역에서 생성한 공용 서브넷의 ID입니다. "AWS 영역에서 서브넷 생성" 절차를 완료하면 이 공용 서브넷 ID를 생성했습니다.
18
사용자 워크로드가 에지 노드에서 예약되지 않도록 테인트를 지정합니다.
참고

인프라 노드에 NoSchedule 테인트를 추가하면 해당 노드에서 실행 중인 기존 DNS Pod가 misscheduled로 표시됩니다. misscheduled DNS Pod에서 허용 오차를 삭제하거나 추가해야 합니다.

8.2.8.2. 컴퓨팅 머신 세트 생성

설치 프로그램에서 생성한 컴퓨팅 머신 세트 외에도 고유한 머신 세트를 생성하여 선택한 특정 워크로드의 머신 컴퓨팅 리소스를 동적으로 관리할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터를 배포합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 oc에 로그인합니다.

프로세스

  1. 컴퓨팅 머신 세트 CR(사용자 정의 리소스) 샘플이 포함된 새 YAML 파일을 만들고 <file_name>.yaml이라는 이름을 지정합니다.

    <clusterID> 및 <role> 매개 변수 값을 설정해야 합니다.

  2. 선택 사항: 특정 필드에 설정할 값이 확실하지 않은 경우 클러스터에서 기존 컴퓨팅 머신 세트를 확인할 수 있습니다.

    1. 클러스터의 컴퓨팅 머신 세트를 나열하려면 다음 명령을 실행합니다. 

      $ 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

    2. 특정 컴퓨팅 머신 세트 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
        ...

      1
      클러스터 인프라 ID입니다.
      2
      기본 노드 레이블입니다.
      참고

      사용자 프로비저닝 인프라가 있는 클러스터의 경우 컴퓨팅 머신 세트는 worker 및 infra 유형 머신만 생성할 수 있습니다.

      3
      컴퓨팅 머신 세트 CR의 <providerSpec> 섹션에 있는 값은 플랫폼에 따라 다릅니다. CR의 <providerSpec> 매개변수에 대한 자세한 내용은 공급자의 샘플 컴퓨팅 머신 세트 CR 구성을 참조하십시오.

  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

추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.