---
title: K3s PostgreSQL 백엔드 이전
updated: 2026-03-25
status: Phase 0 완료, Phase 1 대기
tags: [k3s, migration, postgresql, supabase]
---

## 개요

기존 K3s 클러스터(외부 etcd)에서 Supabase PostgreSQL 백엔드로 전환하는 프로젝트.

## 기존 클러스터

| 항목 | 값 |
|------|-----|
| 노드 | hp2(server), kr1(server), kr2(분리됨) |
| 데이터스토어 | 외부 etcd (Incus 컨테이너 3개) |
| etcd 엔드포인트 | http://192.168.9.214:2379, http://192.168.9.135:2379, http://192.168.9.134:2379 |
| 네트워크 | LAN 192.168.9.x, flannel vxlan |
| Pod CIDR | 10.42.0.0/16 |
| Service CIDR | 10.43.0.0/16 |
| tls-san | k3s.inouter.com |
| 리소스 사용 | CPU ~3코어, 메모리 ~45GB |

## 새 클러스터 (진행 중)

| 항목 | 값 |
|------|-----|
| 컨트롤 플레인 | kr1 (192.168.9.214), kr2 (192.168.9.135) |
| 워커 (agent) | hp2 (192.168.9.134) |
| 데이터스토어 | Supabase PostgreSQL (싱가포르) |
| Pooler | Session mode, port 5432 |
| DB 호스트 | aws-1-ap-southeast-1.pooler.supabase.com |
| DB 유저 | postgres.bahmyfgldxmtgvsufmwf |
| 시크릿 | Vault `secret/cloud/supabase` |
| 커넥션 제한 | pool_max_conns=5&pool_min_conns=1 |
| max_connections | 60 (무료 티어) |
| 현재 사용 | ~18 커넥션 |
| 네트워크 | LAN 192.168.9.x, flannel vxlan (기존과 동일) |
| Pod CIDR | 10.42.0.0/16 |
| Service CIDR | 10.43.0.0/16 |
| tls-san | k3s.inouter.com, 192.168.9.135, 100.119.109.41 |

## 목표 구성

```
kr2: k3s server  (컨트롤 플레인 + 워커)  192.168.9.135
kr1: k3s server  (컨트롤 플레인 + 워커)  192.168.9.214
hp2: k3s server  (컨트롤 플레인 + 워커)  192.168.9.134
```

- server 3대 → 완전 HA (어떤 노드가 죽어도 나머지가 API 서버 유지)
- 노드당 커넥션: ~14개 (실측, 안정적)
- 예상 총 커넥션: ~42/60 (70%)

## 장애 시나리오

| 장애 | 영향 | 복구 |
|------|------|------|
| server 1대 죽음 | 서비스 무중단, 나머지 server가 API 유지 | 자동 |
| agent 죽음 | Pod 재스케줄 | 자동 |
| server 2대 동시 | 기존 Pod 유지, 변경 불가 | 아무 노드에서 k3s server 시작 |
| Supabase DB 장애 | 기존 Pod 유지, 변경 불가 | Supabase 복구 시 자동 |

## Supabase 제약사항

- **Transaction mode pooler(6543) 사용 불가** — K3s Kine이 prepared statements 사용, transaction pooler와 충돌
- **Session mode pooler(5432) 필수** — pool_max_conns로 커넥션 수 제한
- 무료 티어 max_connections=60, Pro($25/월)도 Micro는 동일
- Small($65/월 총)로 올리면 90개
- 싱가포르 리전 → 서울에서 ~70ms 레이턴시 (허용 범위)

## 마이그레이션 순서

### Phase 0: 새 클러스터 인프라 구성 ✅ 완료 (2026-03-24~25)
- cert-manager v1.20.0 + Google Trust ClusterIssuer ✅
- 와일드카드 인증서 6개 (inouter/anvil/actions/ironclad/keepanker/servidor) ✅
- Reflector ✅
- **Traefik DaemonSet (hostPort 80/443) + Gateway API → 메인 라우팅** ✅ (2026-03-25)
  - TLSStore CRD로 와일드카드 인증서 기본 로드
  - 전 서비스 정상 확인 (NocoDB, Gitea, n8n, ArgoCD, Grafana, SearXNG, SafeLine 등)
  - Gitea Runner: Tailscale 직접 접속 + 와일드카드 인증서 정상
  - CoreDNS hairpin: traefik.kube-system.svc.cluster.local
- APISIX replica 1 (SafeLine WAF 전용으로 축소) ✅
  - APISIX Ingress Controller 제거 (GatewayProxy 모드 플러그인 제한 문제)
- HAProxy 80/443 → Traefik hostPort로 복원 ✅
- Longhorn v1.8.2 ✅
- HAProxy/nftables에서 kr2 제거 완료 ✅

### Vault jp1 이전 ✅ 완료 (2026-03-24)
- jp1 Incus default 프로젝트, `vault` 컨테이너 (Debian 13)
- Vault v1.21.4 (raft 스토리지, 스냅샷 복원)
- vault-mcp-server v0.2.0 (Go 바이너리, systemd, port 8080)
- auto-unseal (리트라이 루프, vault-unseal.service)
- `~/.mcp.json` URL: `http://10.253.101.58:8080/mcp` (Tailscale 서브넷 라우팅)
- 기존 K3s Vault 제거 대기

### Phase 1: 서비스 점진적 이전 ⬜
kr2(30GB)가 단독으로 전체 워크로드(45GB)를 수용할 수 없으므로 점진적 이전 필요.
1. 경량 서비스부터 kr2에 배포 (nocodb, searxng, openmemory 등)
2. PV 데이터 백업 → kr2 Longhorn에 복원
3. APISIX 라우트를 서비스별로 새 클러스터로 전환
4. DNS 전환

### Phase 2: kr1 합류 ⬜
1. kr2에서 경량 서비스 안정 확인
2. kr1을 기존 클러스터에서 drain
3. kr1을 새 클러스터에 **server**로 합류 (kr2+kr1 = 92GB, 전체 수용 가능)
4. 나머지 서비스 이전

### Phase 3: hp2 합류 ⬜
1. 기존 클러스터 완전 종료
2. hp2에서 기존 K3s 중지
3. hp2를 새 클러스터에 **server**로 합류
4. 기존 etcd Incus 컨테이너 폐기

### Phase 4: 정리 ⬜
1. 기존 etcd Incus 컨테이너 폐기 (kr1, kr2, hp2)
2. 기존 K3s server.bak 삭제
3. 모니터링/백업 체계 재구성

## 관련 문서

- [[infra-hosts]] — 서버 목록
- [[backup]] — 백업 체계 (etcd → PostgreSQL 전환 후 변경 필요)