[에스넷시스템 부트캠프] TIL Day 72~75 - 프로젝트 6주차
Day 72 - 추가 학습
혹시 설정 과정에서 내가 놓친 부분이 있을까 싶어, 교육 과정 중 받았던 책을 다시 펼쳐보았다. 앞부분의 이론 위주로 읽으며 헷갈리는 부분은 따로 Notion에 정리했고, EKS Cluster 구성에서 수정할 만한 부분이 있는지도 고민해보았다. 책을 보기 전에 Ingress 부분이 조금 헷갈렸는데 개념을 정리할 수 있는 좋은 기회였다.
Day 73 - 문서화
Outputs 파일 수정하기
Terraform의 outputs.tf 파일을 보완했다.
기존에는 단순히 VPC 정보 정도만 출력했지만, Terraform을 사용하는 만큼 리소스의 ARN, 이름, ID 같은 필수 정보를 바로 확인할 수 있도록 output을 추가했다.
- terraform output으로 전체 정보를 확인 가능
- 특정 리소스만 지정해서 볼 수도 있음
- 단, 지정하려면 outputs.tf에 정의된 리소스명을 알아야 하지만 → Ctrl+F나 VS Code 개요 기능으로 쉽게 찾을 수 있
EKS 구성 문서화
팀원들과 공유하기 위해 EKS Cluster 내부에 생성한 리소스에 대한 문서를 작성했다.
ServiceAccount와 연결된 IAM Role, Deployment 구성 방식 등을 다시 점검하면서, 동시에 전체 구조를 다시 한 번 정리할 수 있었다.
Day 74 - 네트워킹 및 외부 노출 설정하기
External-DNS 설치
데이터 조회용 서비스의 Pod를 외부에 노출하기 위해 External-DNS를 설치했다.
External-DNS는 Route53 같은 Public DNS 서비스에 자동으로 레코드를 생성·관리해주어, 내부 클러스터 리소스와 외부 도메인을 연결하는 작업을 단순화한다.
설치 과정
- External-DNS 파드가 Route53에 접근할 수 있도록 IAM 역할 생성
- Route53 호스팅 존에 대한 읽기/쓰기 권한 부여
- ServiceAccount를 통해 권한 연결
- helm을 이용해 External-DNS 설치 및 환경 변수 설정
AWS Load Balancer Controller 설치
Ingress와 Service 리소스를 AWS ALB로 프로비저닝하기 위해 AWS Load Balancer Controller도 함께 설치했다.
이 컨트롤러가 데이터 조회용 서비스들을 위한 ALB를 생성하고, ALB DNS Name을 발급하여 내부 Pod로 트래픽을 로드밸런싱한다.
ALB의 DNS Name은 동적으로 변경될 수 있기 때문에, External-DNS가 이를 감지해 Route53 레코드를 자동 업데이트하도록 했다. 이제 외부 사용자는 고정된 도메인 주소를 통해 안정적으로 내부 서비스를 이용할 수 있다.
Day 75 - 모니터링 환경 구성
이번 목표는 Prometheus + Grafana 기반의 모니터링 환경 구축이었다. 여기에 더해 Prometheus 메트릭 데이터를 장기 저장하기 위해 EBS를 붙이고, EBS 생성을 위한 CSI Driver를 설치하려고 했다.
진행 내용
- EBS 생성 → 실패
CSI Driver 설치까지 시도했지만 EBS 생성 단계에서 막혀버렸다. 원인은 아직 명확히 못 잡았고, 다음주에 다시 시도할 예정이다. - Prometheus + Grafana 설치 → 성공
Helm 차트 덕분에 repo 추가 후 비교적 간단히 설치할 수 있었다.
다만 마지막 Pod가 Pending 상태로 남아 있어, 이 부분은 추후 확인이 필요하다. - 결과
EBS 추가는 포기했지만, Prometheus와 Grafana만으로도 기본적인 리소스 메트릭이 잘 수집되는 것을 확인했다.
휴일 추가 진행 사항
모니터링 환경을 구성하지 못했다는 점이 너무 아쉬워서 교육 과정일이 아니었음에도 프로젝트를 진행했다.
문제 : Grafana에서 Prometheus 데이터소스 연결 실패
prometheus로 시작하는 도메인명으로 연결되지 않고, IP 주소로만 연결이 되는 문제점을 발견했다.
External-DNS가 작동하기에 도메인으로 접근이 가능해야 하는데, 도메인 해석이 되지 않았던 것이다.
원인
- External-DNS 로그 확인 결과: sts.amazonaws.com 접속 실패.
- IRSA 인증 과정에서 STS 접근을 통해 임시 토큰을 발급받아야 하는데 이 단계에서 막힘.
- 즉, Private Subnet에 위치한 노드들이 인터넷에 접근하지 못하는 문제.
- NAT Instance를 이용한 인터넷 연결 구조였으나, Pod ↔ NAT Instance 간의 연결이 불안정해 정상적으로 작동하지 않았음.
- 이전에는 정상 동작했으나 하루아침에 문제가 발생 → 불안정한 NAT Instance 기반 설계임을 확인.
해결
- 팀원들이 이미 EIP를 최대치로 사용 중이라 NAT Gateway 대신 NAT Instance를 사용했던 상황.
- 불필요한 EIP 삭제를 팀원들에게 부탁했고, 팀원들이 협조해주어 삭제 완료.
- 이를 통해 NAT Gateway 생성 가능 상태 확보.
- 이후 월요일부터 NAT Gateway를 새로 생성하고 모니터링 환경을 다시 구성할 예정.
쉬는 날임에도 팀원들이 메시지를 확인해주어 리소스 삭제를 해주어서 다행이었다.
다음주에 있을 자격증 시험 준비로 주말에는 프로젝트를 진행하지 못하겠지만 다음주 월요일부터 바로 NAT Gateway를 생성해 다시 모니터링 환경을 구성해볼 수 있어 다행이었다.
✍️ 주간 회고
이번 주는 정말 삽질의 연속이었다. Grafana에서 Prometheus 데이터소스 연결 실패 문제는 상황 파악과 원인 분석이 비교적 명확해서 "곧 해결할 수 있겠다"는 자신감이 들었지만, EBS 추가 문제는 정확히 어디에서 막히는지 원인을 잡지 못해 답답한 마음이 컸다. 다음주 월요일까지만 다시 시도해보고, 그래도 안되면 강사님께 도움을 요청해야 할 것 같다.
비록 원하는 만큼 결과를 내진 못했지만, 이번 주는 Kubernetes를 한층 더 깊이 이해하게 된 시간이었다. 단순히 이론으로 "아 그렇구나" 하고 넘어가는 게 아니라, 직접 구성해보고 문제를 마주하면서 내부 동작 원리를 더 확실히 알 수 있었다. 문제 상황 속에서 배우는 게 많았고, 이 과정이 결국 내 실력이 될 거라 믿는다.