[AWS] EC2에 Kubernetes 구성을 위한 AWS Architecture

Joseph's Engineering Blog·2023년 11월 13일
0

AWS

목록 보기
1/1
post-thumbnail

포스팅 이유

금융권 DevOps 프로젝트를 진행하며 EC2 위에 Kubernetes를 설치하기 위해 Terraform을 이용해 AWS 인프라를 구성해보고 AWS의 Resource들과 Architecure에 대한 이해를 위함



1. AWS 인프라 구조

AWS 홈페이지에서 아이콘 PPT를 다운 받아 직접 전체적인 구조를 그려봤습니다.

사용되는 Resource는 크게 EC2, NLB(Network Load Balancer), Internet Gateway 세개라고 볼 수 있습니다.

Transit Gateway의 경우 모든 구축이 끝난 뒤 On-premise환경 및 다른 VPC와 연결을 위해 사용될 예정이라 아이콘만 간단히 넣어보았습니다.

먼저 위 구조도에 나오는 Resource들에 대해 알아보겠습니다.



2. AWS Resources

구조도 바깥쪽부터 하나씩 간단하게 알아보겠습니다.

2.1 Region과 Availability Zone(AZ)

전 세계에서 데이터 센터를 클러스터링하는 물리적 위치를 리전이라 합니다.
국내에는 서울 리전이 있고 가까운 위치에는 도쿄 리전이 있습니다.

그리고 이 Region안에는 물리적으로 분리된 최소 3개의 Availabilty Zone(AZ)라는 가용 영역으로 구성됩니다.

서울 리전의 경우 현재 총 4개의 AZ가 있습니다.


2.2 VPC와 Subnet

VPC

VPC(Virtual Private Cloud)는 간단히 논리적으로 격리된 가상 네트워크라고 생각하면 됩니다.

VPC 생성 시 CIDR 등록을 통해 VPC 내부에서 사용할 IP 대역을 미리 설정할 수 있습니다.


Subnet

서브넷은 VPC 생성 시 할당한 IP 대역을 VPC 내부에서 용도나 목적에 따라 쪼개여 사용하는 개념이라 생각하면 됩니다.

Subnet의 경우 크게 Public Subnet과 Private Subnet으로 구분할 수 있습니다.

Public의 경우 VPC외부 와 통신할 수 있는 Subnet이고, Private은 VPC 내부에서만 통신 가능한 Subnet이라고 생각하시면 됩니다.

VPC 리소스맵을 보면 이해하기 쉽습니다.

Public Subnet의 경우 Internet Gateway와 연결되어 외부 인터넷 대역으로 라우팅이 가능하지만 다른 Private Subnet은 내부 통신만 가능합니다.

그리고 Subnet을 어떤 AZ에 구성할것인지 선택할 수 있습니다.


2.3 NLB와 Internet Gateway

NLB(Network Load Balancer)

AWS LoadBalance중 하나인 NLB는 내부 통신만 가능한것과 외부 통신이 가능한것 두 가지가 있는데 여기서는 내부 통신용으로 사용할 예정입니다.

NLB는 VPC 내부에 위치하는데 어떤 AZ를 선택하여 IP는 어떻게 할당 할지 선택할 수 있습니다.

NLB에서 선택한 Subnet 별로 IP가 할당되어 동작합니다.

추가적으로 여기서는 NLB 속성 중 교차 영역 로드 밸런싱 기능을 사용합니다.


Internet Gateway

인터넷 게이트웨이는 VPC 내부에서 외부 인터넷망과 통신하기 위해 거쳐야하는 Gateway라고 생각하면 됩니다.


2.4 EC2와 Security Group

EC2

EC2는 VM이라고 생각하면 될 것 같습니다. EC2 인스턴스의 경우 AMI(Amazon Machine Image)을 이용해 생성할 수 있습니다. AMI의 경우 Redhat Linux, Oracle Linux 등등 Market에 올라와 있는 이미지를 사용할 수 있습니다.

Security Group

Security Group은 방화벽과 비슷한 역할을 한다고 생각하면 될 것 같습니다. 정확히는 방화벽은 특정 대역, 포트 등을 막는 역할을 한다면, Security Group에서는 특정 대역, 포트 등을 열어주는 역할을 합니다.



3. Architecture 설명

이제 다시 처음에 봤던 구성도를 보고 설명을 붙이면

  1. 서울 리전에 VPC를 구성
  2. 서울 리전 내 3개의 AZ에 Private Subnet을 하나씩 구성 (AZ를 3개로 나누어 특정 AZ 장애 시 가용성 확보)
  3. 각 Private Subnet에 EC2를 두 개씩 생성(AMI = RHEL 8)
  4. NLB를 생성하여 각 Subnet에 하나씩 맵핑 (가용성 확보 목적)
  5. AZ중 한 곳에 Public Subnet을 생성하고 EC2 한 대 생성 후 Internet Gateway를 생성하여 맵핑

이 정도가 될 것 같습니다.

추가 설명을 붙이면

4번에서 NLB를 두는 이유는 Master Node가 3개로 삼중화되는 구조라 Kubernetes APIServer의 Endpoint를 NLB를 통해 설정하고 했습니다.

그리고 NLB쪽의 Listener(리스너)와 Target Group(대상 그룹) 설정을 통해 80포트와 443포트를 NodePort 대역인 30080, 30443으로 포트 포워딩하여 내부에 들어오게 설정하여, K8s 내부에 NodePort 형식으로 Service를 생성한 Nginx가 해당 트래픽(30080, 30443)을 받아 내부 서비스(Gitlab Pod, Harbor Pod, Application Pod등..)와 연결하기 위함입니다.

5번에서 Bastion 서버를 두는 이유는 Private Subnet에 구성된 EC2들은 인터넷망과 통신이 되지 않는 폐쇄망 형태로 구성되어 있기 때문에 외부에서 SSH를 통해 접속할 수 없는 구조입니다.

따라서 Bastion 서버를 두어 pem키를 통해 bastion 서버에 SSH로 접속하고, 접속한 Bastion 서버에서 실제 K8s가 구성될 Private Subnet에 위치한 EC2에 SSH로 접속하여 작업할 수 있습니다. (해당 VPC를 On-Premise와 연결 시키기 전 VPC 내부 Security Group에서 0.0.0.0/0을 모두 허용하여 가능)



마무리

해당 구성은 직접 Terrafrom으로 짜서 구성하였습니다. (추후 Terraform 관련 별도 포스팅 예정)

생각보다 방대한 내용이라 여기에 빠진 내용도 많고 하나의 포스팅에서 모든 내용을 자세히 설명하기 어려워 시리즈로 이어서 계속 포스팅하겠습니다.

profile
Kubernetes / DevOps / Git / Network / AWS / Terraform / Opensource / Java / Springboot

0개의 댓글