'VPC'에 해당하는 글 3건

EKS Cluster

Server/AWS 2021. 12. 8. 22:24

EKS(Elastic Kubernetes Service) 는 Kubernetes 를 실행해주는 프로덕션 환경의 관리형 서비스로, 사용자를 대신해 제어 플레인 또는 노드 설치, 작동 및 유지 관리를 한다. 오픈 소스 Kubernetes 소프트웨어의 최신 버전을 실행하므로 Kubernetes 커뮤니티의 모든 기존 플러그인과 도구도 사용할 수 있다. AWS 서비스들과의 통합이 쉽지만 기본적으로 IAM, VPC, ECR, ALB 등이 함께 사용되기 때문에 사전 숙지가 필요하다. 가장 중요한 쿠버네티스 사용법 역시 공식 사이트를 보면 자세하게 설명이 잘 되어 있지만, 분량도 많고, 테스트 환경 기반이다보니 막상 프로덕션 환경에서 사용하려고 하면 머릿속이 하얘지는... 사실 ECS/EKS 의 큰 차이는 모르겠다. ECS 를 잘 써왔는데 굳이 EKS 를 쓰려는 이유는 그냥 한번 써볼라꼬. 난 그저 컨테이너 자동 복구, 무중단 배포, 오토 스케일링만 잘되면 된다. 쿠버네티스를 모르더라도 EKS 를 잘 쓸 수 있는지 EKS 가이드를 참고하여 Fargate 위주로 제가 한번 먹어보겠습니다.

 

주의해야 할 것은 AWS 문서는 한글판에만 의존해서는 안된다. 영문판보다 버전도 낮고 번역이 정반대인 경우도 있고, 예제의 경우 시나리오 중간중간 버전이 혼용되는가 하면... 등의 이유로 영문판과 함께 보기를 권장한다. 덕분에 예상치 못한 에러들이 발생해서 도움이 많이 됐다...;

 

 

클러스터

 

EKS 를 시작할 때, 가장 먼저 해야할 일이 클러스터를 생성하는 것이다. 이 안에 제어영역(Control Plane) 과 해당 노드가 포함된다.

 

 

클러스터 생성 방법1)

 

클러스터 관리가 가능한 eksctl 명령 도구를 사용하는 방법이다. 

 

- eksctl 설치 : https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/install-kubectl.html

 

kubectl 설치 - Amazon EKS

Amazon EKS 클러스터 제어 영역과 마이너 버전이 하나 다른 kubectl 버전을 사용해야 합니다. 예를 들어, 1.20 kubectl 클라이언트는 Kubernetes 1.19, 1.20 및 1.21 클러스터로 작업해야 합니다.

docs.aws.amazon.com

 

$ eksctl create cluster \
--name my-cluster \
--region us-west-2

 

생략된 옵션이 매우 많다. eksctl 은 이런 식으로 줄줄줄 써 내려가거나 yaml 파일로 만들어서 관리할 때 유용한 툴이다. 위처럼 간단하게 명령해도 CloudFormation 을 이용한, 이미 준비된 완벽한 클러스터가 만들어진다.(약 20분 소요) 한번에 클러스터가 만들어진다는 장점은 있지만, 이 때 필요한 IAM 권한이나 VPC 등이 생성되고 연동되는 과정이 보이지 않으므로 잘 살펴보아야 한다. 오히려 초보자에게는 방법2) 가 더 유용할 수 있다. 

 

옵션을 나열하고 --dry-run 옵션까지 추가하면 지정한 옵션과 default 옵션으로 만들어질 항목들을 클러스터 생성없이 테스트 해볼 수 있고, yaml 파일로 만들어서 유지관리 할 수도 있다.

 

$ eksctl create cluster --dry-run > config.yaml

 

 

클러스터 생성 방법2)

 

AWS 관리콘솔로 클러스터를 생성하는 방법이다. 보기도 편하고 필수항목들이 준비되지 않으면 진행되지 않는다. IAM role(AmazonEKSClusterPolicy) / VPC / 보안그룹 등이 준비되어 있어야 한다. 보안그룹은 일단 공개, VPC 는 Fargate 의 경우 private 서브넷을 반드시 필요로 하므로 public/private 서브넷을 모두 구성한다.(약 10분 소요)

 

 

Fargate 프로파일

 

클러스터는 생성되었지만, 막상 클러스터를 선택해 세부정보를 보면 node 도 보이지 않고, DNS 서버인 CoreDNS 도 대기(pending) 상태임을 워크로드에서 확인할 수 있다. Fargate 에서 pod 를 실행시키려면 Fargate 프로파일을 생성해서 워크로드의 deployment 들과 매칭이 필요하다. CoreDNS 가 작동할 수 있도록 AWS 관리콘솔에서 Fargate 프로파일을 생성한다. 이 때도 AM 에서 pod 실행 역할(AmazonEKSFargatePodExecutionRolePolicy) 을 생성하고 연결해 주어야 한다. pod 를 생성할 서브넷도 선택하고, 워크로드의 coredns 에서 네임스페이스와 선택기(레이블) 을 확인하여 네임스페이스 또는 네임스페이스+선택기(레이블) 이 일치하도록 Fargate 프로파일을 생성한다.

 

이 단계에서는 Fargate 프로파일에 namespace: kube-system 만 생성해도 CoreDNS 와 매칭된다. 

 

그리고 eksctl 의 --fargate 옵션으로 클러스터를 설치하지 않으면 CoreDNS 의 기본값은 EC2 를 사용하도록 구성되기 때문에, CoreDNS deployment 의 해당 구성 부분을 삭제해 주어야 한다. 또한 그 전에 클러스터와의 통신을 위해 kubectl 툴을 사용할 수 있도록 kubeconfig(~/.kube/config) 를 구성한다.

 

- kubectl 설치 : https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/install-kubectl.html

 

kubectl 설치 - Amazon EKS

Amazon EKS 클러스터 제어 영역과 마이너 버전이 하나 다른 kubectl 버전을 사용해야 합니다. 예를 들어, 1.20 kubectl 클라이언트는 Kubernetes 1.19, 1.20 및 1.21 클러스터로 작업해야 합니다.

docs.aws.amazon.com

 

앞으로의 kubectl 명령이 클러스터와 통신하도록 kubeconfig 구성

$ aws eks update-kubeconfig --region <region> --name <cluster>

 

coredns 설정에서 ec2 구문 제거

$ kubectl patch deployment coredns \
-n kube-system \
--type json \
-p='[{"op": "remove", "path": "/spec/template/metadata/annotations/eks.amazonaws.com~1compute-type"}]'

 

기존 파드를 삭제하고 다시 생성

$ kubectl rollout restart -n kube-system deployment coredns
deployment.apps/coredns restarted

 

coredns 배포 확인

$ kubectl get -n kube-system deployment coredns 
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
coredns   2/2     2            2           6d23h

 

2개의 pod가 준비 완료되면 클러스터 생성부터 CoreDNS pods 띄우는 것까지 성공한 것이다. 만약 CoreDNS 가 정상적으로 생성되지 않았다면 IAM / VPC / Fargate 프로파일을 다시 살펴보아야 한다. Fargate 프로파일은 한번 생성하면 수정할 수 없으므로, 수정이 필요하다면 새로 생성하여 업데이트한 후에 원본을 삭제해야 한다.

 

workload-coredns

 

리소스 생성/삭제 시간이 생각보다 길어 테스트 과정이 상당히 지루했다. 앞으로 할일은 EKS 에서 nginx 화면을 브라우저에서 확인하기?

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

AWS VPC 시나리오

Server/AWS 2019. 5. 17. 11:54

AWS 에서 VPC 마법사로 생성할 수 있는 VPC 시나리오로 다음의 4가지를 제공한다.

public 서브넷만 있는 VPC

public 및 private 서브넷이 있는 VPC

public 및 private 서브넷이 있고 VPN 액세스를 제공하는 VPC

private 서브넷만 있고 VPN 액세스를 제공하는 VPC


이 4가지의 VPC 구성을 알고나면 어떤 커스텀 VPC 구성도 가능하다. 하나씩 살펴보자.



1. public 서브넷만 있는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

ec2 : 10.0.0.6 (EIP: 198.51.100.2)

router : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

internet gateway

ec2 가 인터넷에 오픈되어 있는 웹서비스 등에 알맞는 구성이다. 서브넷은 모두 private 형태이므로 외부와의 통신이 가능하려면 internet gateway 를 두어야 하며, 나가는 트래픽에 대하여 routing table 에 올바르게 설정해야 한다. 10.0.0.0/16(local) 은 해당 vpc 의 다른 서브넷으로의 통신을 가능하게 하며, 0.0.0.0/0(igw-id) 는 외부 모든 트래픽은 igw-id 로 보낸다는 설정이다. 외부에서 해당 서비스(EC2 등) 에 접근할 수 있도록 Public IP 주소도 연결해야 한다. Public IP 주소가 없다면 외부로부터 요청을 받을 수가 없을 것이고, router 에 igw 로의 설정이 없다면 외부로 응답이나 요청을 할 수 없을 것이다. 보안적인 측면에서 보안그룹(security group) 과 network acl 로도 ip/port 에 대하여 허용/거부를 설정할 수 있는데 network acl 은 보통 다 열어놓고 보안그룹만 이용한다. 모든 포트가 차단된 상태에서 웹서비스시 80, 443 포트로 들어오는 요청은 모두 열어주고, 22 포트는 개발자 ip 정도만 열어주는 형태를 추천한다. 이것이 일반적인 public 서브넷의 형태이다. 



2. public 및 private 서브넷이 있는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

private subnet : 10.0.1.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

ec2(db) : 10.0.1.5~7

router1 : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

router2 : 10.0.0.0/16(local), 0.0.0.0/0(nat-gw-id)

internet gateway

nat gateway

프론트엔드와 백엔드로 나누어 일반적으로 웹서버만 public 서브넷에 두고 DB 는 private 서브넷에 두어, 외부에서는 웹서버와 접근 가능하게 하고 DB 는 웹서버에서만 접근 가능하게 하는 구성이다. 굳이 노출할 필요없는 백엔드를 외부와 차단시키는 것에 중점을 둔 구성이다. public/private 구분을 위해 igw(인터넷 게이트웨이) 로 향하지 않도록 router 를 하나 더 추가해야 한다. 옵션이지만 private 서브넷에서 일방적으로 외부와 통신을 해야 한다면 nat 게이트웨이를 생성하고 router 에 nat 게이트웨이로 트래픽을 보내도록 routing 을 추가한다. igw 가 public 서브넷과 외부와의 양방향 통신이 가능하게 한다면, nat 게이트웨이는 public 서브넷에 위치하면서 private 서브넷에 대하여 외부로 단방향 통신(요청/응답) 이 가능하게 하며 응답을 받을 수 있도록 public IP 할당이 필요하다. 외부에서는 여전히 nat 게이트웨이로 서브넷과 통신할 수 없다. (nat 게이트웨이는 유료) 웹서버의 보안그룹 설정은 시나리오1과 동일, DB 보안그룹 설정은 웹서버 보안그룹ID 로부터 오는 해당 DB 전용포트만 열어주면 된다. 예로 mysql 의 경우 3306 포트.



3. public 및 private 서브넷이 있고 VPN 액세스를 제공하는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

private subnet : 10.0.1.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

ec2(db) : 10.0.1.5~7

router1 : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

router2 : 10.0.0.0/16(local), 0.0.0.0/0(vgw-id)

internet gateway

vpn (virtual private gateway, customer gateway)

시나리오2번과 비슷하지만 private subnet 을 외부는 여전히 차단하고 특정 네트워크(customer gateway)와만 통신할 수 있도록 하는 구성이다. vpn 이라고 하는 가상 비공개 네트워크를 구현하여 vpn 에 연결되어야만 private subnet 과의 통신이 가능하다. vpc 콘솔에서 private 서브넷과 연결할 네트워크(customer gateway) 를 ip 와 함께 지정하고 virtual private gateway 생성, 그리고 그 둘을 이어주는 Site-to-Site VPN 연결을 구성하면 된다. (vpn 도 역시 유료) 서브넷의 보안그룹 설정은 vpn 으로 연결되는 네트워크 ip 대역으로부터 필요한 포트만 열어주면 된다.



4. private 서브넷만 있고 VPN 액세스를 제공하는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

private subnet : 10.0.0.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

router : 10.0.0.0/16(local), 0.0.0.0/0(vgw-id)

vpn (virtual private gateway, customer gateway)

시나리오3번에서 public 서브넷만 제외한 구성이다. public 서브넷이 없으므로 igw 도 없다. vpn 과 연결된 특정 네트워크에서만 private 서브넷과 통신이 가능하며, 외부가 차단된 구성이다보니 서비스보다는 사내 인트라넷이나 개발 서버 등이 필요할 때 사용 가능한 구성이다.


이 중에 그나마 유용하게 쓸 수 있는 것이 2번이나 3번 시나리오 이다. 내가 선호하는 구성은 소규모 웹서비스의 경우 2번과 흡사하게. 더 큰규모의 웹서비스는 3번 시나리오에서 public subnet 에는 elb 만 두고 모든 자원을 private 서브넷으로, private 서브넷은 vpn 연결로 관리하는 것이 즐겨 사용하는 시나리오 이다. ^^


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

NAT gateway

Server/AWS 2017. 12. 9. 22:14



AWS Lambda 에서 외부에서 자료를 읽어와 VPC 의 RDS 에 저장하는 function 을 만들었다.

RDS 저장을 위해 Lambda 에 VPC 를 설정하면 외부 통신이 안되고, VPC 를 빼버리면 RDS 저장이 안되고.


기본적으로 Lambda 에 VPC 를 설정하면 선택된 서브넷으로만 접근을 할 수 있다.

Lambda 는 Public IP 가 없기 때문에 Internet Gateway 를 사용할 수 없고, 대신에 NAT Gateway 에 EIP 를 할당하여 사용할 수 있다.


Lambda 설정시 VPC 를 선택하면 아래와 같은 주의문을 볼 수 있다.


When you enable VPC, your Lambda function will lose default internet access. If you require external internet access for your function, ensure that your security group allows outbound connections and that your VPC has a NAT gateway.

-> 외부 인터넷 접근을 위해 시큐리티 그룹에 아웃바운드를 허용하고, NAT gateway 를 설정하라는...



NAT(Network Address Translation) gateway 은 자체 IP 를 할당하여 private 서브넷에 속한 인스턴스들을 외부망으로 보낼 수 있도록 한다.

NAT gateway 은 public 서브넷을 지정하여 IP 할당하면 생성 완료되며, private 서브넷과 연결된 라우팅 테이블에 nat-xxxxxxx 를 업데이트하면 설정 끝.

그리고 lambda 서블릿에 해당 private 서브넷을 설정하고, outbound 가능한 security group 을 선택하면 완료!


VPC 의 일반적인 EC2 와 Lambda 에서 외부망 통신하는 플로우는 다음과 같다.


VPC EC2(EIP) -> Public Subnet -> Routing Table(IGW) -> Internet Gateway -> Internet

VPC Lambda -> Private Subnet -> Routing Table(NAT) -> NAT Gateway(EIP) -> Public Subnet -> Routing Table(IGW) -> Internet Gateway -> Internet


Lambda 에서 간단히 inline Python 소스를 만들어 테스트 해 볼 수 있다.


from urllib import request
def lambda_handler(event, context):
 
response = request.urlopen('https://www.google.com/')
return response
cs


Timeout 걸리면 실패. 응답이 있으면 성공.


VPC 는 꽁짜지만, NAT gateway 가 유료라는 건 함정.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,