obsidian/infra/k3s-migration.md at ffb3d80f2a26823ec1a0850e46312e1aac0e6f41

kaffa/obsidian

Fork 0

Files

kaffa ffb3d80f2a k3s: 현재 노드 구성 반영 (kr1+kr2 server, hp2 agent)

2026-03-25 09:16:42 -07:00

5.0 KiB

Raw Blame History

title, updated, status, tags

title

updated

status

개요

기존 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)를 수용할 수 없으므로 점진적 이전 필요.

경량 서비스부터 kr2에 배포 (nocodb, searxng, openmemory 등)
PV 데이터 백업 → kr2 Longhorn에 복원
APISIX 라우트를 서비스별로 새 클러스터로 전환
DNS 전환

Phase 2: kr1 합류 ⬜

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

Phase 3: hp2 합류 ⬜

기존 클러스터 완전 종료
hp2에서 기존 K3s 중지
hp2를 새 클러스터에 server로 합류
기존 etcd Incus 컨테이너 폐기

Phase 4: 정리 ⬜

기존 etcd Incus 컨테이너 폐기 (kr1, kr2, hp2)
기존 K3s server.bak 삭제
모니터링/백업 체계 재구성

5.0 KiB Raw Blame History

개요