k8s 3-Tier

1.Web ----> Deployment(Nginx,React) 사용자의 요청을 직접 받는 프론트엔트
2.WAS ----> Deployment(Spring Boot,Node.js) 비즈니스 로직을 처리하는 백엔드
3.DB  ----> StatefulSet(MySQL,PostgreSQL) 데이터를 저장하는 영역




핵심 구조 및 전략 
1.외부노출: Ingress & Service 

Ingress
클러스터 외부의 HTTP/HTTPS 트래픽을 내부 서비스로 연결하는 관문 
호스트 기반의 라우팅 , SSL/TLS 종단 처리

Service(ClusterIP)
Web-App, App-DB 간의 통신은 외부로 노출될 필요가 없다.
반드시 Cluster IP 타입을 통해 클러스터 내부 IP로만 통신하도록 설정하기
[Web,App : Deployment로 관리]

2.데이터 무결성:StatefulSet & PVC 
StatefulSet을 사용하여 파드에 고유한 식별자 부여 
PersistentVolumeClaim[PVC]
파드가 재시작 되어도 데이터 유지

3.보안: Network Policy
·Web Tier : 외부 트래픽 허용
·App Tier : Web Tier로부터 오는 트래픽만 허용 
·Data Tier: App Tier로부터 오는 트래픽만 허용


가용성전략 (HPA & Anti-Affinity)
· HPA
트래픽이 몰릴 때 Web과 App파드가 자동으로 늘어나도록 설정 
· Pod Anti-Affinity
동일한 서비스의 파드들이 서로 다른 노드에 배치되도록함.
특정 노드가 다운되어도 서버 전체가 내려가지 않게 구성 


---------------------------------------------------------------------------
구축환경 선택 
1.AWS(EKS)
2.On-premise(Bare-metal)


Bare-metal 3-Tier 아키텍처 설계
1.네트워크: 서비스 노출(MetalLB)
★Bare-metal에는 type:LoadBalancer를 처리해줄 클라우드 컨트롤러가 존재 X ★
이 문제를 해결하기 위해 MetalLB 필수 

L2모드  : ARP를 이용해 특정 노드에 가상 IP 할당.(간단)
BGP모드 : 모든 스위치와 연동하여 부하 분산 구현

정석: MetalLB로 외부 IP 받는다.
외부 IP를 Ingress Controller에 연결한다.
Ingress Controller에서 각 Tier(Web,App)으로 트래픽을 뿌려준다.


2.스토리지:동적 프로비저닝(StorageClass)
DB를 위해 StatefulSet을 쓸 때, 매번 수동으로 PV 만들지 않기!!!!

· Rook-Ceph: Bare-metal에서 가장 선호되는 분산 스토리지. (난이도 높음)

· NFS Subdir External Provisioner: 기존 NFS 서버가 있다면 가장 빠르게 구축 가능.
[이걸로 만들었던 걸로 기억.]
· Longhorn: 설정이 쉽고 GUI를 제공해서 추천하는 편이야.


3.CNI(Container Network Interface)
노드간 통신을 담당
· Calico: BGP 지원 및 강력한 Network Policy 기능 제공,★3-Tier 보안(계층 간 차단) 구현에 최적 



계층별 구현 포인트
Web Tier(Nginx/Frontend)
· HPA 설정
Bare-metal은 리소스가 한정적, metrics-server 설치 -> CPU/Memory 기반 파드 자동 확장 세팅
· Node Affinity
특정 사양의 노드에만 웹서버 구성할 때 사용 


App Tier(WAS/Backend)
· Service Discovery
CoreDNS를 통해 http://backend-service 같은 이름으로 내부 통신
· ConfigMap/Secret
DB 접속 정보, API 키 를 매니페스트와 분리해서 관리 


Data Tier(Database)
· Local Path Provisioner
노드 장애 시 데이터 가용성 확보를 위해 복제(Replication)설정을 DB 레벨


---------------------------------------------------------------------------
HA(고가용성) 구성 
마스터 노드를 반드시 3대 이상 구축하는건 하드자원상불가능

타임존 설정
Bare-metal 설치 시 노드와 파드의 타임존 맞추기

리소스 제한(Limits/Requests)
클라우드보다 자원 관리 타이트하게 제한. 
특정 파드가 노드의 메모리를 다 먹어버린다.
노드가 NotReady 되는 상황을 방지하기 위해 resources 설정 

----------------------------------------------------------------------------
[Bare-metal 완주를 위한 최종 체크리스트]
1. 네트워킹: "내부에서 어떻게 찾을 것인가?"
CoreDNS: Web 파드가 App 파드에 접근할 때 IP가 아니라 http://app-service-name이라는 서비스 이름으로 통신하도록 설정해야 해. (Bare-metal에선 DNS 트러블슈팅이 잦으니 주의!)

Ingress Controller: 외부에서 들어오는 트래픽을 도메인에 따라 Web Tier로 보내주는 역할을 담당하게 될 거야.

2. 스토리지: "데이터가 사라지지 않게"
클라우드(AWS EBS 등)가 없으니, DB 파드가 죽었다 살아나도 데이터가 유지되도록 NFS나 Longhorn 같은 스토리지 솔루션을 클러스터에 꼭 붙여줘야 해. 이게 Bare-metal 프로젝트의 최대 고비야.

3. 모니터링: "문제가 터지면 어떻게 알 것인가?"
파드가 죽었는지, 메모리가 부족한지 보려면 Prometheus와 Grafana는 필수야. 3-Tier가 돌아가는 걸 대시보드로 시각화하는 것까지가 프로젝트의 완성

[YAML을 짜기보다는 아래 순서대로 진행하기]
환경 구축: Ubuntu 노드 준비 → kubeadm으로 클러스터 조인 → CNI(Calico 등) 설치.
인프라 세팅: MetalLB(IP 할당용) → StorageClass(DB용) 설치.

애플리케이션 배포:
Data Tier (DB) 먼저 배포하고 접속 확인.
App Tier (WAS) 배포해서 DB 연결 확인.
Web Tier (Nginx) 배포해서 App 연결 확인.
외부 노출: Ingress 설정해서 브라우저에서 접속 성공하기!