하이브리드 노드용 네트워킹 준비

Amazon EKS 클러스터를 만들고 하이브리드 노드를 연결하기 전에 구성해야 하는 네트워킹 설정의 개요를 설명합니다.

출처: 문서

본문

이 주제는 Amazon EKS 클러스터를 만들고 하이브리드 노드를 연결하기 전에 구성해야 하는 네트워킹 설정의 개요를 제공합니다. 이 가이드는 AWS Site-to-Site VPN, AWS Direct Connect 또는 자체 VPN 솔루션을 사용한 하이브리드 네트워크 연결의 사전 요구 사항을 충족했다고 가정합니다.

온프레미스 네트워킹 구성

최소 네트워크 요구 사항

최적의 경험을 위해 AWS 리전에 대한 하이브리드 노드 연결에 최소 100 Mbps의 안정적인 네트워크 연결과 최대 200ms 왕복 지연 시간을 권장합니다. 이는 대부분의 사용 사례를 수용하는 일반 지침이며 엄격한 요구 사항은 아닙니다. 대역폭과 지연 시간 요구 사항은 하이브리드 노드 수와 애플리케이션 이미지 크기, 애플리케이션 탄력성, 모니터링 및 로깅 구성, 다른 AWS 서비스에 저장된 데이터 접근에 대한 애플리케이션 의존성 같은 워크로드 특성에 따라 달라질 수 있습니다. 프로덕션에 배포하기 전에 자체 애플리케이션과 환경으로 테스트하여 네트워킹 설정이 워크로드 요구 사항을 충족하는지 검증할 것을 권장합니다.

온프레미스 노드 및 Pod CIDR

하이브리드 노드와 그 위에서 실행되는 워크로드에 사용할 노드 및 Pod CIDR을 식별합니다. 노드 CIDR은 온프레미스 네트워크에서 할당되고, Pod CIDR은 CNI에 오버레이 네트워크를 사용하는 경우 CNI(Container Network Interface)에서 할당됩니다. RemoteNodeNetwork 및 RemotePodNetwork 필드로 EKS 클러스터를 만들 때 온프레미스 노드 CIDR과 Pod CIDR을 입력으로 전달합니다. 온프레미스 노드 CIDR은 온프레미스 네트워크에서 라우팅 가능해야 합니다. 온프레미스 Pod CIDR 라우팅 가능성에 대한 정보는 다음 섹션을 참조하세요.

온프레미스 노드 및 Pod CIDR 블록은 다음 요구 사항을 충족해야 합니다.

IPv4 RFC-1918 범위 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 중 하나 또는 RFC 6598로 정의된 CGNAT 범위 100.64.0.0/10 내에 있어야 합니다.
서로, EKS 클러스터의 VPC CIDR, Kubernetes 서비스 IPv4 CIDR과 겹치면 안 됩니다.

중요

클러스터 생성 중 Kubernetes 서비스 IPv4 CIDR을 명시적으로 지정하지 않으면 Amazon EKS가 구성된 원격 노드 및 Pod 네트워크와 충돌하지 않는 서비스 CIDR을 자동으로 선택합니다. 즉 할당된 서비스 CIDR이 표준 기본값(10.100.0.0/16 또는 172.20.0.0/16)과 다를 수 있습니다. 예를 들어 원격 네트워크가 172.20.0.0/16과 겹치면 Amazon EKS가 대신 172.16.0.0/16을 할당할 수 있습니다. 예기치 않은 서비스 CIDR 할당을 피하려면 클러스터를 만들 때 서비스 IPv4 CIDR을 명시적으로 지정할 것을 권장합니다. 클러스터에 할당된 서비스 CIDR을 찾아야 한다면 aws eks describe-cluster --name CLUSTER_NAME --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr"를 실행하세요.

온프레미스 Pod 네트워크 라우팅

EKS Hybrid Nodes를 사용할 때 클라우드와 온프레미스 환경 간의 완전한 클러스터 통신과 기능을 활성화하려면 온프레미스 네트워크에서 온프레미스 Pod CIDR을 라우팅 가능하게 만들 것을 일반적으로 권장합니다.

라우팅 가능한 Pod 네트워크

온프레미스 네트워크에서 Pod 네트워크를 라우팅 가능하게 만들 수 있다면 아래 지침을 따르세요.

온프레미스 Pod CIDR로 EKS 클러스터의 RemotePodNetwork 필드를, 온프레미스 Pod CIDR로 VPC 라우팅 테이블을, 온프레미스 Pod CIDR로 EKS 클러스터 보안 그룹을 구성합니다.
온프레미스 네트워크에서 온프레미스 Pod CIDR을 라우팅 가능하게 만드는 데는 BGP(Border Gateway Protocol), 정적 경로, 기타 사용자 지정 라우팅 솔루션 등 여러 기술이 있습니다. BGP는 사용자 지정 또는 수동 경로 구성이 필요한 대안보다 확장성이 높고 관리하기 쉬우므로 권장 솔루션입니다. AWS는 Pod CIDR 광고를 위해 Cilium과 Calico의 BGP 기능을 지원합니다. 자세한 내용은 하이브리드 노드용 CNI 구성 및 라우팅 가능한 원격 Pod CIDR을 참조하세요.
EKS 컨트롤 플레인이 웹훅에 할당된 Pod IP 주소와 통신할 수 있으므로 하이브리드 노드에서 웹훅을 실행할 수 있습니다.
클라우드 노드에서 실행되는 워크로드는 같은 EKS 클러스터의 하이브리드 노드에서 실행되는 워크로드와 직접 통신할 수 있습니다.
AWS Application Load Balancers, Amazon Managed Service for Prometheus 같은 다른 AWS 서비스는 하이브리드 노드에서 실행되는 워크로드와 통신하여 네트워크 트래픽을 분산하고 Pod 지표를 스크레이프할 수 있습니다.

라우팅 불가능한 Pod 네트워크

온프레미스 네트워크에서 Pod 네트워크를 라우팅 가능하게 만들 수 없다면 아래 지침을 따르세요.

웹훅은 EKS 컨트롤 플레인에서 웹훅에 할당된 Pod IP 주소로의 연결이 필요하므로 하이브리드 노드에서 웹훅을 실행할 수 없습니다. 이 경우 하이브리드 노드와 같은 EKS 클러스터의 클라우드 노드에서 웹훅을 실행할 것을 권장합니다. 자세한 내용은 하이브리드 노드용 웹훅 구성을 참조하세요.
클라우드 노드에 VPC CNI를, 하이브리드 노드에 Cilium 또는 Calico를 사용하면 클라우드 노드에서 실행되는 워크로드가 하이브리드 노드에서 실행되는 워크로드와 직접 통신할 수 없습니다.
Service Traffic Distribution을 사용하여 트래픽을 발생한 존(zone)에 로컬로 유지하세요. Service Traffic Distribution에 대한 자세한 내용은 Service Traffic Distribution 구성을 참조하세요.
Pod 트래픽이 온프레미스 호스트를 떠날 때 이그레스 마스커레이드(egress masquerade) 또는 NAT(network address translation)를 사용하도록 CNI를 구성합니다. 이는 Cilium에서 기본적으로 활성화됩니다. Calico는 natOutgoing을 true로 설정해야 합니다.
AWS Application Load Balancers, Amazon Managed Service for Prometheus 같은 다른 AWS 서비스는 하이브리드 노드에서 실행되는 워크로드와 통신할 수 없습니다.

하이브리드 노드 설치 및 업그레이드 중 필요한 액세스

호스트에 하이브리드 노드 의존성을 설치하는 설치 과정에서 다음 도메인에 접근할 수 있어야 합니다. 이 과정은 운영 체제 이미지를 빌드할 때 한 번 수행하거나 각 호스트에서 런타임에 수행할 수 있습니다. 여기에는 초기 설치와 하이브리드 노드의 Kubernetes 버전 업그레이드가 포함됩니다.

일부 패키지는 OS의 기본 패키지 관리자로 설치됩니다. AL2023과 RHEL의 경우 yum 명령으로 containerd, ca-certificates, iptables, amazon-ssm-agent를 설치합니다. Ubuntu의 경우 apt로 containerd, ca-certificates, iptables를, snap으로 amazon-ssm-agent를 설치합니다.

구성 요소	URL	프로토콜	포트
EKS 노드 아티팩트(S3)	https://hybrid-assets.eks.amazonaws.com	HTTPS	443
EKS 서비스 엔드포인트	https://eks.`region`.amazonaws.com	HTTPS	443
ECR 서비스 엔드포인트	https://api.ecr.`region`.amazonaws.com	HTTPS	443
EKS ECR 엔드포인트	리전 엔드포인트는 Amazon EKS 애드온용 Amazon 컨테이너 이미지 레지스트리 보기 참조	HTTPS	443
SSM 바이너리 엔드포인트¹	https://amazon-ssm-`region`.s3.`region`.amazonaws.com	HTTPS	443
SSM 서비스 엔드포인트¹	https://ssm.`region`.amazonaws.com	HTTPS	443
IAM Anywhere 바이너리 엔드포인트²	https://rolesanywhere.amazonaws.com	HTTPS	443
IAM Anywhere 서비스 엔드포인트²	https://rolesanywhere.`region`.amazonaws.com	HTTPS	443
운영 체제 패키지 관리자 엔드포인트	패키지 저장소 엔드포인트는 OS별이며 지리적 리전에 따라 다를 수 있음	HTTPS	443

참고

¹ 온프레미스 IAM 자격 증명 공급자에 AWS SSM 하이브리드 활성화를 사용하는 경우에만 AWS SSM 엔드포인트에 대한 액세스가 필요합니다.

² 온프레미스 IAM 자격 증명 공급자에 AWS IAM Roles Anywhere를 사용하는 경우에만 AWS IAM 엔드포인트에 대한 액세스가 필요합니다.

지속적인 클러스터 운영에 필요한 액세스

지속적인 클러스터 운영을 위해 온프레미스 방화벽에 다음 네트워크 액세스가 필요합니다.

중요

CNI 선택에 따라 CNI 포트에 대한 추가 네트워크 액세스 규칙을 구성해야 할 수 있습니다. 자세한 내용은 Cilium 문서와 Calico 문서를 참조하세요.

유형	프로토콜	방향	포트	소스	목적지	용도
HTTPS	TCP	아웃바운드	443	원격 노드 CIDR	EKS 클러스터 IP¹	kubelet에서 Kubernetes API 서버로
HTTPS	TCP	아웃바운드	443	원격 Pod CIDR	EKS 클러스터 IP¹	Pod에서 Kubernetes API 서버로
HTTPS	TCP	아웃바운드	443	원격 노드 CIDR	SSM 서비스 엔드포인트	SSM 하이브리드 활성화 자격 증명 갱신 및 5분마다 SSM 하트비트
HTTPS	TCP	아웃바운드	443	원격 노드 CIDR	IAM Anywhere 서비스 엔드포인트	IAM Roles Anywhere 자격 증명 갱신
HTTPS	TCP	아웃바운드	443	원격 Pod CIDR	STS 리전 엔드포인트	Pod에서 STS 엔드포인트로, IRSA에만 필요
HTTPS	TCP	아웃바운드	443	원격 노드 CIDR	Amazon EKS Auth 서비스 엔드포인트	노드에서 Amazon EKS Auth 엔드포인트로, Amazon EKS Pod Identity에만 필요
HTTPS	TCP	인바운드	10250	EKS 클러스터 IP¹	원격 노드 CIDR	Kubernetes API 서버에서 kubelet으로
HTTPS	TCP	인바운드	웹훅 포트	EKS 클러스터 IP¹	원격 Pod CIDR	Kubernetes API 서버에서 웹훅으로
HTTPS	TCP, UDP	인바운드, 아웃바운드	53	원격 Pod CIDR	원격 Pod CIDR	Pod에서 CoreDNS로. 클라우드에서 CoreDNS 복제본을 최소 1개 실행한다면 CoreDNS가 실행되는 VPC로 DNS 트래픽을 허용해야 함
사용자 정의	사용자 정의	인바운드, 아웃바운드	앱 포트	원격 Pod CIDR	원격 Pod CIDR	Pod와 Pod 사이

참고

¹ EKS 클러스터의 IP입니다. 다음 Amazon EKS 네트워크 인터페이스 섹션을 참조하세요.

Amazon EKS 네트워크 인터페이스

Amazon EKS는 EKS 컨트롤 플레인과 VPC 간의 통신을 위해 클러스터 생성 중 전달한 VPC의 서브넷에 네트워크 인터페이스를 연결합니다. Amazon EKS가 생성한 네트워크 인터페이스는 클러스터 생성 후 Amazon EC2 콘솔이나 AWS CLI에서 확인할 수 있습니다. Kubernetes 버전 업그레이드처럼 EKS 클러스터에 변경 사항이 적용되면 원래 네트워크 인터페이스가 삭제되고 새 네트워크 인터페이스가 생성됩니다. 클러스터 생성 중 전달하는 서브넷에 제약된 서브넷 크기(constrained subnet sizes)를 사용하여 Amazon EKS 네트워크 인터페이스의 IP 범위를 제한할 수 있으며, 이렇게 하면 이 알려진 제약된 IP 세트에 대한 인바운드/아웃바운드 연결을 허용하도록 온프레미스 방화벽을 구성하기가 쉬워집니다. 네트워크 인터페이스가 생성될 서브넷을 제어하려면 클러스터 생성 시 지정하는 서브넷 수를 제한하거나 클러스터 생성 후 서브넷을 업데이트할 수 있습니다.

Amazon EKS가 프로비저닝한 네트워크 인터페이스의 설명은 Amazon EKS your-cluster-name 형식입니다. 아래 예시는 Amazon EKS가 프로비저닝한 네트워크 인터페이스의 IP 주소를 찾는 데 사용할 수 있는 AWS CLI 명령입니다. VPC_ID를 클러스터 생성 중 전달한 VPC의 ID로 바꾸세요.

aws ec2 describe-network-interfaces \
--query 'NetworkInterfaces[?(VpcId == VPC_ID && contains(Description,Amazon EKS))].PrivateIpAddress'

AWS VPC 및 서브넷 설정

하이브리드 노드가 있는 클러스터에는 Amazon EKS의 기존 VPC 및 서브넷 요구 사항이 적용됩니다. 또한 VPC CIDR은 온프레미스 노드 및 Pod CIDR과 겹칠 수 없습니다. 온프레미스 노드 및 선택적으로 Pod CIDR에 대한 경로를 VPC 라우팅 테이블에 구성해야 합니다. 이러한 경로는 일반적으로 가상 프라이빗 게이트웨이(VGW) 또는 트랜짓 게이트웨이(TGW)인 하이브리드 네트워크 연결에 사용하는 게이트웨이로 트래픽을 라우팅하도록 설정해야 합니다. TGW 또는 VGW를 사용하여 VPC를 온프레미스 환경과 연결한다면 VPC에 대한 TGW 또는 VGW 어태치먼트를 만들어야 합니다. VPC는 DNS 호스트 이름과 DNS 해석 지원이 있어야 합니다.

다음 단계는 AWS CLI를 사용합니다. AWS Management Console이나 AWS CloudFormation, AWS CDK, Terraform 같은 다른 인터페이스로도 이러한 자원을 만들 수 있습니다.

Step 1: VPC 생성

다음 명령을 실행하여 VPC를 생성합니다. VPC_CIDR을 RFC 1918(개인), CGNAT(RFC 6598), 또는 비-RFC 1918/비-CGNAT(공용)인 IPv4 CIDR 범위(예: 10.0.0.0/16)로 바꾸세요. 참고: EKS 요구 사항인 DNS 해석은 VPC에서 기본적으로 활성화됩니다.

aws ec2 create-vpc --cidr-block VPC_CIDR

VPC의 DNS 호스트 이름을 활성화합니다. 참고: DNS 해석은 VPC에서 기본적으로 활성화됩니다. VPC_ID를 이전 단계에서 만든 VPC의 ID로 바꾸세요.

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

Step 2: 서브넷 생성

최소 2개의 서브넷을 생성합니다. Amazon EKS는 클러스터 네트워크 인터페이스에 이 서브넷을 사용합니다. 자세한 내용은 서브넷 요구 사항 및 고려 사항을 참조하세요.

다음 명령으로 AWS 리전의 가용 영역을 찾을 수 있습니다. us-west-2를 자신의 리전으로 바꾸세요.

aws ec2 describe-availability-zones \
     --query 'AvailabilityZones[?(RegionName == us-west-2)].ZoneName'

서브넷을 생성합니다. VPC_ID를 VPC의 ID로 바꾸세요. SUBNET_CIDR을 서브넷의 CIDR 블록(예: 10.0.1.0/24)으로 바꾸세요. AZ를 서브넷이 생성될 가용 영역(예: us-west-2a)으로 바꾸세요. 만드는 서브넷은 최소 2개의 서로 다른 가용 영역에 있어야 합니다.

aws ec2 create-subnet \
    --vpc-id VPC_ID \
    --cidr-block SUBNET_CIDR \
    --availability-zone AZ

(선택 사항) Step 3: Amazon VPC Transit Gateway(TGW) 또는 AWS Direct Connect 가상 프라이빗 게이트웨이(VGW)로 VPC 연결

TGW 또는 VGW를 사용한다면 VPC를 TGW 또는 VGW에 연결합니다. 자세한 내용은 Amazon VPC Transit Gateways의 Amazon VPC attachments 또는 AWS Direct Connect virtual private gateway associations를 참조하세요.

트랜짓 게이트웨이

다음 명령을 실행하여 Transit Gateway를 연결합니다. VPC_ID를 VPC의 ID로 바꾸세요. SUBNET_ID1과 SUBNET_ID2를 이전 단계에서 만든 서브넷의 ID로 바꾸세요. TGW_ID를 TGW의 ID로 바꾸세요.

aws ec2 create-transit-gateway-vpc-attachment \
    --vpc-id VPC_ID \
    --subnet-ids SUBNET_ID1 SUBNET_ID2 \
    --transit-gateway-id TGW_ID

가상 프라이빗 게이트웨이

다음 명령을 실행하여 Transit Gateway를 연결합니다. VPN_ID를 VGW의 ID로 바꾸세요. VPC_ID를 VPC의 ID로 바꾸세요.

aws ec2 attach-vpn-gateway \
    --vpn-gateway-id VPN_ID \
    --vpc-id VPC_ID

(선택 사항) Step 4: 라우팅 테이블 생성

VPC의 기본 라우팅 테이블을 수정하거나 사용자 지정 라우팅 테이블을 만들 수 있습니다. 다음 단계는 온프레미스 노드 및 Pod CIDR로의 경로가 있는 사용자 지정 라우팅 테이블을 만듭니다. 자세한 내용은 서브넷 라우팅 테이블을 참조하세요. VPC_ID를 VPC의 ID로 바꾸세요.

aws ec2 create-route-table --vpc-id VPC_ID

Step 5: 온프레미스 노드 및 Pod에 대한 경로 생성

각 온프레미스 원격 노드에 대해 라우팅 테이블에 경로를 만듭니다. VPC의 기본 라우팅 테이블을 수정하거나 이전 단계에서 만든 사용자 지정 라우팅 테이블을 사용할 수 있습니다.

아래 예시는 온프레미스 노드 및 Pod CIDR에 대한 경로를 만드는 방법을 보여줍니다. 예시에서 트랜짓 게이트웨이(TGW)를 사용하여 VPC를 온프레미스 환경과 연결합니다. 온프레미스 노드 및 Pod CIDR이 여러 개라면 각 CIDR에 대해 단계를 반복하세요.

인터넷 게이트웨이나 가상 프라이빗 게이트웨이(VGW)를 사용한다면 --transit-gateway-id를 --gateway-id로 바꾸세요.

RT_ID를 이전 단계에서 만든 라우팅 테이블의 ID로 바꾸세요.
REMOTE_NODE_CIDR을 하이브리드 노드에 사용할 CIDR 범위로 바꾸세요.
REMOTE_POD_CIDR을 하이브리드 노드에서 실행되는 Pod에 사용할 CIDR 범위로 바꾸세요. Pod CIDR 범위는 CNI(Container Networking Interface) 구성에 해당하며, 가장 일반적으로 온프레미스에서 오버레이 네트워크를 사용합니다. 자세한 내용은 하이브리드 노드용 CNI 구성을 참조하세요.
TGW_ID를 TGW의 ID로 바꾸세요.

원격 노드 네트워크

aws ec2 create-route \
    --route-table-id RT_ID \
    --destination-cidr-block REMOTE_NODE_CIDR \
    --transit-gateway-id TGW_ID

원격 Pod 네트워크

aws ec2 create-route \
    --route-table-id RT_ID \
    --destination-cidr-block REMOTE_POD_CIDR \
    --transit-gateway-id TGW_ID

(선택 사항) Step 6: 라우팅 테이블에 서브넷 연결

이전 단계에서 사용자 지정 라우팅 테이블을 만들었다면 이전 단계에서 만든 각 서브넷을 사용자 지정 라우팅 테이블에 연결합니다. VPC의 기본 라우팅 테이블을 수정한다면 서브넷이 VPC의 기본 라우팅 테이블과 자동으로 연결되므로 이 단계를 건너뛸 수 있습니다.

이전 단계에서 만든 각 서브넷에 대해 다음 명령을 실행합니다. RT_ID를 이전 단계에서 만든 라우팅 테이블로 바꾸세요. SUBNET_ID를 서브넷의 ID로 바꾸세요.

aws ec2 associate-route-table --route-table-id RT_ID --subnet-id SUBNET_ID

클러스터 보안 그룹 구성

지속적인 클러스터 운영을 위해 EKS 클러스터 보안 그룹에 다음 액세스가 필요합니다. Amazon EKS는 원격 노드 및 Pod 네트워크를 구성하여 클러스터를 만들거나 업데이트할 때 하이브리드 노드에 필요한 인바운드 보안 그룹 규칙을 자동으로 생성합니다. 보안 그룹은 기본적으로 모든 아웃바운드 트래픽을 허용하므로 Amazon EKS는 하이브리드 노드에 대한 클러스터 보안 그룹의 아웃바운드 규칙을 자동으로 수정하지 않습니다. 클러스터 보안 그룹을 사용자 지정하려면 아래 표의 규칙으로 트래픽을 제한할 수 있습니다.

유형	프로토콜	방향	포트	소스	목적지	용도
HTTPS	TCP	인바운드	443	원격 노드 CIDR	해당 없음	kubelet에서 Kubernetes API 서버로
HTTPS	TCP	인바운드	443	원격 Pod CIDR	해당 없음	CNI가 Pod 트래픽에 NAT를 사용하지 않을 때 K8s API 서버에 접근해야 하는 Pod
HTTPS	TCP	아웃바운드	10250	해당 없음	원격 노드 CIDR	Kubernetes API 서버에서 kubelet으로
HTTPS	TCP	아웃바운드	웹훅 포트	해당 없음	원격 Pod CIDR	Kubernetes API 서버에서 웹훅으로(하이브리드 노드에서 웹훅 실행 시)

중요

보안 그룹 규칙 한도 — Amazon EC2 보안 그룹은 기본적으로 최대 60개의 인바운드 규칙을 가집니다. 클러스터 보안 그룹이 이 한도에 근접하면 보안 그룹 인바운드 규칙이 적용되지 않을 수 있습니다. 이 경우 누락된 인바운드 규칙을 수동으로 추가해야 할 수 있습니다.

CIDR 정리 책임 — EKS 클러스터에서 원격 노드 또는 Pod 네트워크를 제거하면 EKS가 해당 보안 그룹 규칙을 자동으로 제거하지 않습니다. 사용하지 않는 원격 노드 또는 Pod 네트워크를 보안 그룹 규칙에서 수동으로 제거할 책임은 사용자에게 있습니다.

Amazon EKS가 생성하는 클러스터 보안 그룹에 대한 자세한 내용은 클러스터용 Amazon EKS 보안 그룹 요구 사항 보기를 참조하세요.

(선택 사항) 수동 보안 그룹 구성

추가 보안 그룹을 만들거나 자동 생성된 규칙을 수정해야 한다면 다음 명령을 참조로 사용할 수 있습니다. 기본적으로 아래 명령은 모든 아웃바운드 액세스를 허용하는 보안 그룹을 만듭니다. 아웃바운드 액세스를 위 규칙만 포함하도록 제한할 수 있습니다. 아웃바운드 규칙을 제한할 계획이라면 변경된 규칙을 프로덕션 클러스터에 적용하기 전에 모든 애플리케이션과 Pod 연결을 철저히 테스트할 것을 권장합니다.

첫 번째 명령에서 SG_NAME을 보안 그룹 이름으로 바꾸세요.
첫 번째 명령에서 VPC_ID를 이전 단계에서 만든 VPC의 ID로 바꾸세요.
두 번째 명령에서 SG_ID를 첫 번째 명령에서 만든 보안 그룹의 ID로 바꾸세요.
두 번째 명령에서 REMOTE_NODE_CIDR과 REMOTE_POD_CIDR을 하이브리드 노드 및 온프레미스 네트워크의 값으로 바꾸세요.

aws ec2 create-security-group \
    --group-name SG_NAME \
    --description "security group for hybrid nodes" \
    --vpc-id VPC_ID

aws ec2 authorize-security-group-ingress \
    --group-id SG_ID \
    --ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "REMOTE_NODE_CIDR"}, {"CidrIp": "REMOTE_POD_CIDR"}]}]'

더 알아보기 (Learn more)

공식 문서