이 페이지 개선에 도움 주기
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 GitHub에서 이 페이지 편집 링크를 선택합니다.
하이브리드 노드용 네트워킹 준비
이 주제에서는 Amazon EKS 클러스터를 생성하고 하이브리드 노드를 연결하기 전에 구성해야 하는 네트워킹 설정에 대한 개요를 제공합니다. 이 안내서에서는 AWS Site-to-Site VPN, AWS Direct Connect 또는 자체 VPN 솔루션을 사용하여 하이브리드 네트워크 연결에 대한 사전 요구 사항을 충족했다고 가정합니다.

온프레미스 네트워킹 구성
최소 네트워크 요구 사항
최적의 경험을 위해 AWS 리전의 하이브리드 노드 연결에 최소 100Mbps 및 최대 200ms의 왕복 지연 시간을 제공하는 안정적인 네트워크 연결을 권장합니다. 이는 대부분의 사용 사례에 적용되는 일반적인 지침이지만 엄격한 요구 사항은 아닙니다. 대역폭 및 지연 시간 요구 사항은 하이브리드 노드 수와 애플리케이션 이미지 크기, 애플리케이션 탄력성, 모니터링 및 로깅 구성, 다른 AWS 서비스에 저장된 데이터에 대한 애플리케이션 종속성과 같은 워크로드 특성에 따라 달라질 수 있습니다. 네트워킹 설정이 워크로드의 요구 사항을 충족하는지 확인하려면 프로덕션에 배포하기 전에 자체 애플리케이션 및 환경을 사용하여 테스트하는 것이 좋습니다.
온프레미스 노드 및 포드 CIDR
하이브리드 노드에 사용할 노드 및 포드 CIDR과 해당 노드에서 실행되는 워크로드를 식별합니다. 노드 CIDR은 온프레미스 네트워크에서 할당되고 포드 CIDR은 CNI에 오버레이 네트워크를 사용하는 경우 컨테이너 네트워크 인터페이스(CNI)에서 할당됩니다. RemoteNodeNetwork
및 RemotePodNetwork
필드를 사용하여 EKS 클러스터를 생성할 때 온프레미스 노드 CIDR과 포드 CIDR을 입력으로 전달합니다. 온프레미스 노드 CIDR은 온프레미스 네트워크에서 라우팅 가능해야 합니다. 온프레미스 포드 CIDR 라우팅 가능성에 대한 자세한 내용은 다음 섹션을 참조하세요.
온프레미스 노드 및 포드 CIDR 블록은 다음 요구 사항을 충족해야 합니다.
-
다음
IPv4
RFC-1918 범위10.0.0.0/8
,172.16.0.0/12
또는192.168.0.0/16
중 하나에 있어야 합니다. -
서로, EKS 클러스터의 VPC CIDR 또는 Kubernetes 서비스
IPv4
CIDR과 중첩되지 않습니다.
온프레미스 포드 네트워크 라우팅
EKS Hybrid Nodes를 사용할 때 일반적으로 클라우드와 온프레미스 환경 간에 완전한 클러스터 통신 및 기능을 사용할 수 있도록 온프레미스 네트워크에서 온프레미스 포드 CIDR을 라우팅할 수 있게 만드는 것이 좋습니다.
라우팅 가능한 포드 네트워크
온프레미스 네트워크에서 포드 네트워크를 라우팅할 수 있게 만들 수 있는 경우 아래 지침을 따르세요.
-
온프레미스 포드 CIDR을 사용하여 EKS 클러스터의
RemotePodNetwork
필드를 구성하고, 온프레미스 포드 CIDR을 사용하여 VPC 라우팅 테이블을 구성하고, 온프레미스 포드 CIDR을 사용하여 EKS 클러스터 보안 그룹을 구성합니다. -
Border Gateway Protocol(BGP), 정적 경로 또는 기타 사용자 지정 라우팅 솔루션을 포함하여 온프레미스 네트워크에서 온프레미스 포드 CIDR을 라우팅 가능하도록 하는 데 몇 가지 기법을 사용할 수 있습니다. BGP는 사용자 지정 또는 수동 라우팅 구성이 필요한 대체 솔루션보다 더 확장성이 뛰어나고 관리하기 쉽기 때문에 권장되는 솔루션입니다. AWS는 포드 CIDR을 알리는 데 Cilium 및 Calico의 BGP 기능을 지원합니다. 자세한 내용은 하이브리드 노드에 대한 CNI 구성 및 라우팅 가능한 원격 포드 CIDR 섹션을 참조하세요.
-
EKS 컨트롤 플레인이 웹후크에 할당된 포드 IP 주소와 통신할 수 있으므로 웹후크가 하이브리드 노드에서 실행될 수 있습니다.
-
클라우드 노드에서 실행되는 워크로드는 동일한 EKS 클러스터의 하이브리드 노드에서 실행되는 워크로드와 직접 통신할 수 있습니다.
-
AWS Application Load Balancer, Amazon Managed Service for Prometheus 등의 다른 AWS 서비스는 하이브리드 노드에서 실행되는 워크로드와 통신하여 네트워크 트래픽의 균형을 맞추고 포드 지표를 스크래핑할 수 있습니다.
라우팅 불가능한 포드 네트워크
온프레미스 네트워크에서 포드 네트워크를 라우팅할 수 있게 만들 수 없는 경우 아래 지침을 따르세요.
-
웹후크는 EKS 컨트롤 플레인에서 웹후크에 할당된 포드 IP 주소로 연결해야 하므로 하이브리드 노드에서 웹후크를 실행할 수 없습니다. 이 경우 하이브리드 노드와 동일한 EKS 클러스터의 클라우드 노드에서 웹후크를 실행하는 것이 좋습니다. 자세한 내용은 하이브리드 노드용 웹후크 구성을 참조하세요.
-
클라우드 노드에서 실행되는 워크로드는 클라우드 노드에 VPC CNI를 사용하고 하이브리드 노드에 Cilium이나 Calico를 사용할 때 하이브리드 노드에서 실행되는 워크로드와 직접 통신할 수 없습니다.
-
서비스 트래픽 분산을 사용하여 트래픽이 시작되는 영역에 트래픽을 로컬로 유지합니다. 서비스 트래픽 분산에 대한 자세한 내용은 서비스 트래픽 분산 구성을 참조하세요.
-
온프레미스 호스트를 떠나는 포드 트래픽에 대해 송신 매스커레이드 또는 네트워크 주소 변환(NAT)을 사용하도록 CNI를 구성합니다. 이 기능은 Cilium에서 기본적으로 활성화되어 있습니다. Calico에서는
natOutgoing
을true
로 설정해야 합니다. -
AWS Application Load Balancer, 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 | 프로토콜 | Port |
---|---|---|---|
EKS 노드 아티팩트(S3) |
https://hybrid-assets.eks.amazonaws.com |
HTTPS |
443 |
https://eks. |
HTTPS |
443 |
|
https://api.ecr. |
HTTPS |
443 |
|
EKS ECR 엔드포인트 |
리전별 엔드포인트는 Amazon EKS 추가 기능에 대한 Amazon 컨테이너 이미지 레지스트리 보기 섹션을 참조하세요. |
HTTPS |
443 |
SSM 바이너리 엔드포인트 1 |
https://amazon-ssm- |
HTTPS |
443 |
https://ssm. |
HTTPS |
443 |
|
IAM Anywhere 바이너리 엔드포인트 2 |
https://rolesanywhere.amazonaws.com |
HTTPS |
443 |
https://rolesanywhere. |
HTTPS |
443 |
|
운영 체제 패키지 관리자 엔드포인트 |
패키지 리포지토리 엔드포인트는 OS별로 다르며 지리적 리전에 따라 다를 수 있습니다. |
HTTPS |
443 |
참고
1 AWS SSM 엔드포인트에 대한 액세스는 온프레미스 IAM 자격 증명 공급자에 AWS SSM 하이브리드 활성화를 사용하는 경우에만 필요합니다.
2 AWS IAM 엔드포인트에 대한 액세스는 온프레미스 IAM 자격 증명 공급자에 AWS IAM Roles Anywhere를 사용하는 경우에만 필요합니다.
지속적인 클러스터 작업에 필요한 액세스
지속적인 클러스터 작업을 위해서는 온프레미스 방화벽에 대한 다음 네트워크 액세스가 필요합니다.
중요
CNI 선택에 따라 CNI 포트에 대한 추가 네트워크 액세스 규칙을 구성해야 합니다. 자세한 내용은 Cilium documentation
유형 | 프로토콜 | Direction | Port | 소스 | 대상 | 사용법 |
---|---|---|---|---|---|---|
HTTPS |
TCP |
아웃바운드 |
443 |
원격 노드 CIDR |
EKS 클러스터 IP 1 |
kubelet에서 Kubernetes API 서버로 |
HTTPS |
TCP |
아웃바운드 |
443 |
원격 포드 CIDR |
EKS 클러스터 IP 1 |
포드에서 Kubernetes API 서버로 |
HTTPS |
TCP |
아웃바운드 |
443 |
원격 노드 CIDR |
5분마다 SSM 하이브리드 활성화 자격 증명 새로 고침 및 SSM 하트비트 |
|
HTTPS |
TCP |
아웃바운드 |
443 |
원격 노드 CIDR |
IAM Roles Anywhere 자격 증명 새로 고침 |
|
HTTPS |
TCP |
아웃바운드 |
443 |
원격 포드 CIDR |
포드에서 STS 엔드포인트로, IRSA에만 필요 |
|
HTTPS |
TCP |
아웃바운드 |
443 |
원격 노드 CIDR |
노드에서 Amazon EKS 인증 엔드포인트로, Amazon EKS Pod Identity에만 필요 |
|
HTTPS |
TCP |
인바운드 |
10250 |
EKS 클러스터 IP 1 |
원격 노드 CIDR |
Kubernetes API 서버에서 kubelet으로 |
HTTPS |
TCP |
인바운드 |
웹후크 포트 |
EKS 클러스터 IP 1 |
원격 포드 CIDR |
Kubernetes API 서버에서 웹후크로 |
HTTPS |
TCP, UDP |
인바운드, 아웃바운드 |
53 |
원격 포드 CIDR |
원격 포드 CIDR |
포드와 CoreDNS 간. 클라우드에서 CoreDNS 복제본을 1개 이상 실행하는 경우 CoreDNS가 실행 중인 VPC에 대한 DNS 트래픽을 허용해야 합니다. |
사용자 정의 |
사용자 정의 |
인바운드, 아웃바운드 |
앱 포트 |
원격 포드 CIDR |
원격 포드 CIDR |
포드 간 |
참고
1 EKS 클러스터의 IP입니다. Amazon EKS 탄력적 네트워크 인터페이스에 대한 다음 섹션을 참조하세요.
Amazon EKS 네트워크 인터페이스
Amazon EKS는 클러스터 생성 중에 전달하는 VPC의 서브넷에 네트워크 인터페이스를 연결하여 EKS 컨트롤 플레인과 VPC 간의 통신을 활성화합니다. Amazon EKS가 생성하는 네트워크 인터페이스는 Amazon EC2 콘솔에서 또는 AWS CLI를 사용하여 클러스터를 생성한 후에 찾을 수 있습니다. Kubernetes 버전 업그레이드와 같이 EKS 클러스터에 변경 사항이 적용되면 원래 네트워크 인터페이스가 삭제되고 새 네트워크 인터페이스가 생성됩니다. 클러스터 생성 중에 전달하는 서브넷에 대해 제한된 서브넷 크기를 사용하여 Amazon EKS 네트워크 인터페이스의 IP 범위를 제한할 수 있습니다. 이렇게 하면 알려진 제한된 IP 세트에 대한 인바운드/아웃바운드 연결을 허용하도록 온프레미스 방화벽을 쉽게 구성할 수 있습니다. 네트워크 인터페이스가 생성되는 서브넷을 제어하려면 클러스터를 생성하거나 클러스터를 생성한 후 서브넷을 업데이트할 때 지정하는 서브넷 수를 제한할 수 있습니다.
Amazon EKS에서 프로비저닝한 네트워크 인터페이스에는 Amazon EKS
형식에 대한 설명이 있습니다. Amazon EKS가 프로비저닝하는 네트워크 인터페이스의 IP 주소를 찾는 데 사용할 수 있는 AWS CLI 명령은 아래 예제를 참조하세요. your-cluster-name
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은 온프레미스 노드 및 포드 CIDR과 중첩될 수 없습니다. 온프레미스 노드와 선택적으로 포드 CIDR에 대해 VPC 라우팅 테이블에서 경로를 구성해야 합니다. 이 경로는 일반적으로 가상 프라이빗 게이트웨이(VGW) 또는 전송 게이트웨이(TGW)인 하이브리드 네트워크 연결에 사용 중인 게이트웨이로 트래픽을 라우팅하도록 설정되어야 합니다. TGW 또는 VGW를 사용하여 VPC를 온프레미스 환경에 연결하는 경우 VPC에 대한 TGW 또는 VGW 연결을 생성해야 합니다. VPC는 DNS 호스트 이름과 DNS 확인을 모두 지원해야 합니다.
다음 단계에서는 AWS CLI를 사용합니다. AWS Management Console에서 또는 AWS CloudFormation, AWS CDK, Terraform과 같은 다른 인터페이스를 사용하여 이러한 리소스를 생성할 수도 있습니다.
1단계: VPC 생성
-
다음 명령을 실행하여 VPC를 생성합니다.
VPC_CIDR
를IPv4
RFC-1918(프라이빗) 또는 non-RFC-1918(퍼블릭) 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
2단계: 서브넷 생성
서브넷을 2개 이상 생성합니다. Amazon EKS는 클러스터 네트워크 인터페이스에 이러한 서브넷을 사용합니다. 자세한 내용은 Subnets requirements and considerations을 참조하세요.
-
다음 명령을 사용하여 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-blockSUBNET_CIDR
\ --availability-zoneAZ
(선택 사항) 3단계: Amazon VPC Transit Gateway(TGW) 또는 AWS Direct Connect 가상 프라이빗 게이트웨이(VGW)에 VPC 연결
TGW 또는 VGW를 사용하는 경우 VPC를 TGW 또는 VGW에 연결합니다. 자세한 내용은 Amazon VPC attachments in Amazon VPC Transit Gateways 또는 AWS Direct Connect virtual private gateway associations.를 참조하세요.
전송 게이트웨이
다음 명령을 실행하여 전송 게이웨이를 연결합니다. 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-idsSUBNET_ID1 SUBNET_ID2
\ --transit-gateway-idTGW_ID
가상 프라이빗 게이트웨이
다음 명령을 실행하여 전송 게이웨이를 연결합니다. VPN_ID
를 VGW의 ID로 바꿉니다. VPC_ID
를 VPC의 ID로 바꿉니다.
aws ec2 attach-vpn-gateway \ --vpn-gateway-id
VPN_ID
\ --vpc-idVPC_ID
(선택 사항) 4단계: 라우팅 테이블 생성
VPC의 기본 라우팅 테이블을 수정하거나 사용자 지정 라우팅 테이블을 생성할 수 있습니다. 다음 단계에서는 온프레미스 노드 및 포드 CIDR에 대한 경로가 포함된 사용자 지정 라우팅 테이블을 생성합니다. 자세한 내용은 Subnet route tables을 참조하세요. VPC_ID
를 VPC의 ID로 바꿉니다.
aws ec2 create-route-table --vpc-id
VPC_ID
5단계: 온프레미스 노드 및 포드에 대한 경로 생성
각 온프레미스 원격 노드의 라우팅 테이블에서 경로를 생성합니다. VPC의 기본 라우팅 테이블을 수정하거나 이전 단계에서 생성한 사용자 지정 라우팅 테이블을 사용할 수 있습니다.
아래 예제에서는 온프레미스 노드 및 포드 CIDR에 대한 경로를 생성하는 방법을 보여줍니다. 이 예제에서는 전송 게이트웨이(TGW)를 사용하여 VPC를 온프레미스 환경에 연결합니다. 온프레미스 노드와 포드 CIDR이 여러 개인 경우 각 CIDR에 대해 단계를 반복합니다.
-
인터넷 게이트웨이 또는 가상 프라이빗 게이트웨이(VGW)를 사용하는 경우
--transit-gateway-id
를--gateway-id
로 바꿉니다. -
RT_ID
를 이전 단계에서 생성한 라우팅 테이블의 ID로 바꿉니다. -
REMOTE_NODE_CIDR
을 하이브리드 노드에 사용할 CIDR 범위로 바꿉니다. -
REMOTE_POD_CIDR
을 하이브리드 노드에서 실행되는 포드에 사용할 CIDR 범위로 바꿉니다. 포드 CIDR 범위는 온프레미스 오버레이 네트워크를 가장 일반적으로 사용하는 컨테이너 네트워킹 인터페이스(CNI) 구성에 해당합니다. 자세한 내용은 하이브리드 노드에 대한 CNI 구성 섹션을 참조하세요. -
TGW_ID
를 TGW의 ID로 바꿉니다.
원격 노드 네트워크
aws ec2 create-route \ --route-table-id
RT_ID
\ --destination-cidr-blockREMOTE_NODE_CIDR
\ --transit-gateway-idTGW_ID
원격 포드 네트워크
aws ec2 create-route \ --route-table-id
RT_ID
\ --destination-cidr-blockREMOTE_POD_CIDR
\ --transit-gateway-idTGW_ID
(선택 사항) 6단계: 서브넷을 라우팅 테이블에 연결
이전 단계에서 사용자 지정 라우팅 테이블을 생성한 경우 이전 단계에서 생성한 각 서브넷을 사용자 지정 라우팅 테이블과 연결합니다. VPC 기본 라우팅 테이블을 수정하는 경우 서브넷이 VPC의 기본 라우팅 테이블과 자동으로 연결되며 이 단계를 건너뛸 수 있습니다.
이전 단계에서 생성한 각 서브넷에 대해 다음 명령을 실행합니다. RT_ID
를 이전 단계에서 생성한 라우팅 테이블로 바꿉니다. SUBNET_ID
를 서브넷의 ID로 바꿉니다.
aws ec2 associate-route-table --route-table-id
RT_ID
--subnet-idSUBNET_ID
클러스터 보안 그룹 고려 사항
지속적인 클러스터 작업을 위해서는 EKS 클러스터 보안 그룹에 대한 다음 액세스 권한이 필요합니다. Amazon EKS는 원격 노드 및 포드 네트워크가 구성된 클러스터를 생성하거나 업데이트할 때 하이브리드 노드에 필요한 인바운드 보안 그룹 규칙을 자동으로 생성합니다. 보안 그룹은 기본적으로 모든 아웃바운드 트래픽을 허용하므로 Amazon EKS는 하이브리드 노드에 대한 클러스터 보안 그룹의 아웃바운드 규칙을 자동으로 수정하지 않습니다. 클러스터 보안 그룹을 사용자 지정하려면 다음 표의 규칙으로 트래픽을 제한할 수 있습니다.
유형 | 프로토콜 | Direction | Port | 소스 | 대상 | 사용법 |
---|---|---|---|---|---|---|
HTTPS |
TCP |
인바운드 |
443 |
원격 노드 CIDR |
N/A |
Kubelet에서 Kubernetes API 서버로 |
HTTPS |
TCP |
인바운드 |
443 |
원격 포드 CIDR |
N/A |
CNI가 포드 트래픽에 NAT를 사용하지 않을 때 K8s API 서버에 대한 액세스가 필요한 포드입니다. |
HTTPS |
TCP |
아웃바운드 |
10250 |
N/A |
원격 노드 CIDR |
Kubernetes API 서버에서 Kubelet으로 |
HTTPS |
TCP |
아웃바운드 |
웹후크 포트 |
N/A |
원격 포드 CIDR |
Kubernetes API 서버에서 웹후크로(하이브리드 노드에서 웹후크를 실행하는 경우) |
중요
보안 그룹 규칙 제한: Amazon EC2 보안 그룹에는 기본적으로 최대 60개의 인바운드 규칙이 있습니다. 클러스터 보안 그룹이 이 제한에 근접하면 보안 그룹 인바운드 규칙이 적용되지 않을 수 있습니다. 이 경우 누락된 인바운드 규칙에 수동으로 추가해야 할 수 있습니다.
CIDR 정리 책임: EKS 클러스터에서 원격 노드 또는 포드 네트워크를 제거하는 경우 EKS는 해당 보안 그룹 규칙을 자동으로 제거하지 않습니다. 사용자가 직접 보안 그룹 규칙에서 사용하지 않은 원격 노드 또는 포드 네트워크를 수동으로 제거해야 합니다.
Amazon EKS에서 생성하는 클러스터 보안 그룹에 대한 자세한 내용을 알아보려면 클러스터에 대한 Amazon EKS 보안 그룹 요구 사항 보기 부분을 참조하세요.
(선택 사항) 수동 보안 그룹 구성
추가 보안 그룹을 생성하거나 자동으로 생성된 규칙을 수정해야 하는 경우 다음 명령을 참조로 사용할 수 있습니다. 기본적으로 아래 명령은 모든 아웃바운드 액세스를 허용하는 보안 그룹을 생성합니다. 위의 규칙만 포함하도록 아웃바운드 액세스를 제한할 수 있습니다. 아웃바운드 규칙을 제한하려는 경우 변경된 규칙을 프로덕션 클러스터에 적용하기 전에 모든 애플리케이션 및 포드 연결을 철저히 테스트하는 것이 좋습니다.
-
첫 번째 명령에서
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-idVPC_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"}]}]'