위 아키텍처를 만드는 것을 목표로 합니다.
서론 - AWS Console vs CLI
AWS에서 자원을 생성 및 관리하는 방법은 크게 웹 콘솔과 명령어 인터페이스(CLI)가 있습니다(SDK, API도 있는데 아직 고려 X)
콘솔은 웹 GUI를 통해 생성이 가능하기 때문에 매우 직관적이어서 AWS가 익숙치 않은 사람도 쉽게 접근할 수 있습니다.
CLI는 여러 자원을 한번에 관리하거나, 자동화를 하는 등 매우 유연하고 자세하게 관리할 수 있지만 (초보자에게는) 접근이 어렵다고 생각합니다. 특히 CLI 특성상 delete와 같은 위험한 명령어도 조회 명령어와 비슷한 문법으로 동작을 해서 실수할 위험이 있습니다. 그리고 각 자원에 대한 식별 과정이 복잡할 수 밖에 없는 aws 특성상 명령어 하나에 여러줄이 필요한 경우가 많아서 번거롭고, 오타가 쉽게 나기도 하구요.
결론은 두 방법을 적절히 섞어 쓰는게 좋다고 생각합니다. 이 글에서는 초보자 입장에서 CLI 방식에 좀 익숙해지고자 CLI를 사용해보려고 합니다.
네트워크 구성
먼저 EKS 클러스터가 위치할 네트워크를 구성해야 합니다.
클라우드 아키텍처에서 소개하는 대부분의 경우는 2개 이상의 AZ(Availability Zone)에 다중 배포를 하여 고가용성을 보장하도록 합니다. 다만 이러면 비용이 많이 발생할 수 밖에 없어서, 정말 고가용성이 필요한 서비스가 아니라면 단일 AZ에 배포해도 된다고 생각합니다.
그래도 우선은 2개의 Multi-AZ로 배포하는 것으로 실습을 진행해보겠습니다.
참고자료: AWS 공식문서 - VPC 생성
1) VPC 구성
create-vpc 명령어를 통해 VPC를 생성할 수 있습니다.
VPC 생성
aws ec2 create-vpc \
--region ap-northeast-2 \
--cidr-block 10.0.0.0/16 \
--tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=my-project}]' \
--query Vpc.VpcId \
--output text- my-project가 VPC의 이름이 됩니다. 태그이기 때문에 추후 수정이 가능합니다.
query,output필드는 명령어 수행 결과로 생성된 VPC의 id를 얻기 위해 사용합니다.
VPC 설정 업데이트
EKS 클러스터 내에서 노드 간 통신 및 외부 AWS 서비스와의 통신은 DNS를 통해 이루어지기 때문에 DNS support DNS hostname을 모두 지원해야 합니다.
modify-vpc-attribute 명령어로 VPC 속성을 수정하여 지원하도록 바꿔줍니다.
aws ec2 modify-vpc-attribute \
--vpc-id vpc-1a2b3c4EXAMPLE \
--enable-dns-support "{\"Value\":true}"aws ec2 modify-vpc-attribute \
--vpc-id vpc-1a2b3c4EXAMPLE \
--enable-dns-hostnames "{\"Value\":true}"enable-dns-support, enable-dns-hostnames는 동시에 수정할 수 없기 때문에 별개 명령어로 따로 활성화해주어야 합니다.
아무 출력도 반환되지 않는다면 수정에 성공한 것입니다.
2) 서브넷 구성
create-subnet 명령어를 통해 생성 가능합니다.
aws ec2 create-subnet \
--vpc-id vpc-1a2b3cEXAMPLE \
--cidr-block 10.0.0.0/24 \
--availability-zone ap-northeast-2a \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-subnet-public-2a}]' \
--query Subnet.SubnetId \
--output text- 두 AZ에 각각 public, private 서브넷을 사용할 것이므로 총 4번 생성해야 합니다.
- /24 마스크를 사용했으므로,
10.0.0.0/24,10.0.1.0/24,10.0.2.0/24... 이런 방식으로 CIDR을 지정하면 됩니다. - 퍼블릭 서브넷과 프라이빗 서브넷을 구분하기 위해 Name 태그로 구분하는 것이 좋습니다. (예시.
my-subnet-{public/private}-{az})
3) 라우팅 구성
외부 인터넷으로부터 트래픽을 수신하는 퍼블릭 서브넷과 프라이빗 서브넷을 구분하는 것은 라우팅 구성 방법에 따라 결정됩니다.
인터넷 게이트웨이(igw) 구성
먼저 퍼블릭 서브넷은 인터넷 게이트웨이와 연결된 서브넷을 말합니다.
# igw 생성
aws ec2 create-internet-gateway \
--tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=my-project-igw}]' \
--query InternetGateway.InternetGatewayId \
--output text
>>> igw-1a2b3cEXAMPLE
# vpc에 igw 연결
aws ec2 attach-internet-gateway \
--vpc-id vpc-1a2b3c4EXAMPLE \
--internet-gateway-id igw-1a2b3cEXAMPLE
# 라우팅 테이블 생성
aws ec2 create-route-table \
--vpc-id vpc-1a2b3c4EXAMPLE \
--tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=my-project-public-rt}]' \
--query RouteTable.RouteTableId \
--output text
>>> rtb-publicEXAMPLE
# 인터넷 게이트웨이와 연결하는 라우팅 구성
aws ec2 create-route \
--route-table-id rtb-publicEXAMPLE \
--destination-cidr-block 0.0.0.0/0 \
--gateway-id igw-1a2b3cEXAMPLE
# 라우팅 테이블을 서브넷과 연결
aws ec2 associate-route-table \
--route-table-id rtb-publicEXAMPLE \
--subnet-id subnetpublic-1a2b3cEXAMPLENAT 게이트웨이
프라이빗 서브넷에서는 퍼블릭 NAT 게이트웨이를 통해 인터넷에 트래픽을 송신할 수 있습니다. NAT 게이트웨이는 인바운드 트래픽은 차단하면서, 송신 트래픽을 인터넷 게이트웨이에 전송합니다.
퍼블릭 NAT 게이트웨이는 퍼블릭 서브넷에서 생성되어야 하고, Elastic IP와 연결되어있어야 합니다.
NAT 게이트웨이는 EKS 자원들과는 별개이기 때문에 단일 AZ에 구성하고, 모든 자원이 하나의 NAT 게이트웨이를 바라보게 해도 됩니다. 다만 고가용성을 위해 각 서브넷마다 NAT 게이트웨이를 구성해 해당 서브넷의 자원과 연결하는 것을 AWS에서 권장하고 있습니다.
# NAT 게이트웨이가 사용할 Elastic IP 할당
aws ec2 allocate-address \
--domain vpc \
--query AllocationId \
--output text
>>> eipalloc-id
# NAT 게이트웨이 생성 및 Elastic IP 연결
aws ec2 create-nat-gateway \
--subnet-id subnet-public-az-id \
--allocation-id eipalloc-id \
--tag-specifications 'ResourceType=natgateway,Tags=[{Key=Name,Value=my-project-nat-gateway-az}]' \
--query NatGateway.NatGatewayId \
--output text
>>> nat-id
# NAT 게이트웨이에서 사용할 라우팅 테이블 구성
aws ec2 create-route-table \
--vpc-id vpc-1a2b3cEXAMPLE \
--tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=my-project-private-az-rt}]' \
--query RouteTable.RouteTableId \
--output text
>>> rtb-1a2b3cEXAMPLE
# NAT 게이트웨이 생성 확인(생성에 보통 몇 분 정도 걸립니다)
aws ec2 describe-nat-gateways \
--nat-gateway-ids nat-id \
--query 'NatGateways[0].State'
>>> "available" 출력 시 진행
# NAT 게이트웨이와 연결하는 라우팅 구성
aws ec2 create-route \
--route-table-id rtb-1a2b3cEXAMPLE \
--destination-cidr-block 0.0.0.0/0 \
--nat-gateway-id nat-id
# 라우팅 테이블을 서브넷과 연결
aws ec2 associate-route-table \
--route-table-id rtb-1a2b3cEXAMPLE \
--subnet-id subnet-private-az-id
구성이 완료되면 콘솔에서 위와 같이 resource map을 확인할 수 있습니다.
rtb-0d... 는 vpc를 생성할 때 자동으로 생성된 default 라우팅 테이블이니 지우셔도 무방합니다.
정리
여기까지 구성한 내용은 위와 같습니다.
이제 프라이빗 서브넷에 EKS 클러스터를 구성하고, EKS에서 AWS 자원을 생성 및 관리할 수 있도록 권한을 설정하는 것과, Application Load Balancer(ALB)를 통해 인터넷과 EKS 클러스터간 통신 설정을 진행하면 EKS 클러스터 설정이 완료됩니다.
일반적으로는 여기에 더해 외부에서 프라이빗 서브넷에 있는 자원에 접근하기 위해 배스천 호스트(bastion host)를 별도로 구성하는데, EKS 클러스터에서는 kubectl을 통해 권한이 있는 사람이 쿠버네티스 자원에 접근이 가능하기 때문에 별도로 구성하지 않았습니다.
