AWS EKS·GitOps 파이프라인 시행착오 기록

#MSA #DevOps #AWSEKS #AWSGitops #GitOps #깃옵스 #AWSECR

​

오류 아키텍처

배포 파이프라인

1. Dev Team이 애플리케이션의 새로운 버전을 업로드합니다
2. GitHub Action를 사용하여 빌드/배포를 수행합니다.(자동/수동)
3. 새로운 애플리케이션 이미지는 AWS ECR로 저장합니다.
4. 빌드과정중에 변경된 Tag정보는 GitOps용 레포지토리에 업데이트합니다.

1. ArgoCD가 변경된 태그를 확인하고 새로운 Pod를 배포합니다 (자동/수동)

​

​

AWS EKS 클러스터 구축

사용자는 AWS EKS내에 배포된 프론트서버와 통신이 가능해야합니다.

1. 사용자는 프론트서버에 데이터를 요청합니다.

• VPC내의 모든 통신은 Internet Gateway를 통합니다.

1. VPC내의 ALB는 사용자의 요청을 분석하여 Pod와 라우팅합니다.

-

• 현재 프론트서버는 3개의 Pod로 밸런싱됩니다.(실습용)

1. 프론트 서버는 내부 MSA 서버들과 통신합니다.

-

• 대부분의 서버는 Private 서브넷에 연결되어있습니다.

1. 인증 서버의 경우 Cognito와 통신하기 때문에 Internet Gateway 비용이 발생합니다.

1. 이미지 서버는 VPC Endpoint를 통해 AWS S3와 직접 통신합니다.

​

​

비용 점검

비용이 발생하는 구간

1. Iternet GateWay는 인터넷을 경유하는 모든 트래픽을 담당합니다.

• 인바운드 트래픽은 무료이며, 아웃바운드 트래픽이 발생합니다.

1. ALB

• 시간당 요금
• LCU(처리량)기반 요금
• VPC 내부 트래픽은 무료

1. EKS

• 시간당 요금
• 워커노드 사용료: EC2/Fargate

1. ECR

-

• 이미지 저장 비용
• 같은 지역이라 ECR → EC2는 무료

​

무료

• VPC 리소스, Subnet, RouteTable, Security Group
• VPC Endpoint(S3, DynamoDB에 한함)
• ClusterIP Service(Pod간 내부 통신 비용)

​

문제점

현재 NAT Gateway를 생성하지 않아 Private 서브넷에 Pod를 띄우는 것이 불가능합니다. 이를 해결하기 위해 다음을 숙지했습니다.

​

1. EKS Cluster 구조

-

• EKS는 AWS가 관리하는 Controll Plane과 내부 사용자의 Pod들이 통신하도록 설계되어있습니다.
• EKS는 자동으로 등록된 Worker노드에 다음 Pod를 생성합니다.(kube-system namespace)
• aws-node: VPC CNI - Pod에 할당
• kube-proxy: Service → Pod 트래픽 라우팅
• coredns: 클러스터 내부 DNS 서버

​

1. NAT GateWay: Private Subnet에 위치한 리소스가 VPC 외부와 통신하기 위해 필요한 서비스

​

수정할 것

1. NAT Gateway 생성 및 설정
2. Private subnet에 인증(auth) 서버를 배치하고 Cognito와 NAT Gateway로 통신하도록 수정

​

​

최종 아키텍처 및 실습 정리

https://blog.naver.com/jword\_/224126305905

[AWS EKS 클러스터 구축 및 Gitops 파이프라인 최종안
#개발자의도구들 #AWSEKS #쿠버네티스 #AWS쿠버네티스 #gitops #깃옵스 아키텍처 VPC 설정 실...
blog.naver.com](https://blog.naver.com/jword_/224126305905)

​