기술블로그
클라우드 하모니 인프라를 직접 만들면서 배운 것들을 짧게 정리합니다.
- 그림으로 보는 클라우드 하모니 구성도
Kubernetes 클러스터, 애플리케이션 구조, 배포 파이프라인을 세 장의 그림으로 정리했습니다.
- self-hosted runner로 만든 dev / prd 배포 파이프라인
develop에 머지하면 dev 자동 배포, release 브랜치에서 수동 실행하면 prd. 배포 기록은 Git에 남깁니다.
- 도메인을 사서 Cloudflare Tunnel로 K8s에 연결하기
재시작마다 바뀌던 임시 주소를 claudharmony.io 고정 도메인으로 바꿨습니다. 포트포워딩 없이, HTTPS까지 자동입니다.
- 이중 NAT 사무실에서 서비스 공개하기
공유기가 두 단이라 포트포워딩이 막혔습니다. 바깥으로 연결하는 Cloudflare Tunnel로 해결했습니다.
- 트러블슈팅: localhost가 응답하지 않던 이유
노드 안에서는 200이 나오는데 밖에서는 응답이 없었습니다. 원인은 externalTrafficPolicy 기본값이었습니다.
- 홈페이지를 서버와 프론트로 나눈 이유
Spring Boot 4 API와 SvelteKit 웹으로 분리했습니다. 나중에 Tauri 관리자 앱이 같은 API를 쓰게 하려는 구조입니다.
- ingress-nginx 대신 Gateway API를 고른 이유
ingress-nginx는 2026년 3월에 지원이 종료됐습니다. 역할이 분리된 Gateway API와 Envoy Gateway로 갔습니다.
- Kubernetes에 PostgreSQL 올리기 — CloudNativePG + PostGIS
DB는 저장과 조회만, 규칙은 애플리케이션에. 그 원칙으로 PostgreSQL 18 + PostGIS를 Operator로 띄우고 앱에 연결했습니다.
- 맥북 한 대로 만든 사무실 Kubernetes
kind 클러스터, Envoy Gateway, dev/prd Namespace. 사무실 서버 전체 구조를 한 장으로 정리했습니다.
- Terraform 스택을 3단계로 나눈 이유
클러스터 · 게이트웨이 · 환경을 별도 state로 나눴습니다. 배포가 실수로 클러스터를 건드리지 못하게 하려는 구조입니다.