251 lines
17 KiB
Markdown
251 lines
17 KiB
Markdown
---
|
|
title: K3s → Incus 이전 플랜
|
|
updated:
|
|
- 2026-06-01 초안 작성 (kappa 결정 — K3s 운영부담 감축 위해 Incus 전환)
|
|
- 2026-06-01 미결정 사항 확정 — APISIX 서울 유지 / 프로비저닝 OpenTofu+Ansible / kr1 GTX 1080 Ti 유지
|
|
tags: [infra, compute, k3s, incus, migration, plan]
|
|
status: draft
|
|
---
|
|
|
|
## 배경
|
|
|
|
K3s 운영 부담이 누적되어 Incus 전환 결정. 주요 통증:
|
|
|
|
- Longhorn 리밸런싱·drain hang·VolumeAttachment 수동 정리
|
|
- kine → HAProxy → Patroni 다단 의존, 장애 cascade ([[../../history/2026-05-23-kr1-k3s-stuck-cascade]])
|
|
- kr2 RAM 30GiB에서 K3s + Incus 동시 호스팅 → OOM freeze ([[../../history/2026-05-04-amd-iommu-freeze]] 포함)
|
|
- multus·MetalLB·descheduler 튜닝, kube-system CRD/operator 다수 (cert-manager, ArgoCD 등) 유지비
|
|
- helm/ArgoCD GitOps 학습·디버깅 비용
|
|
|
|
반대로 Incus는 이미 정착(Vault, Patroni, ops 에이전트 모두 incus), OpenTofu 모듈 보유, OCI 이미지 1급 지원.
|
|
|
|
## 목표
|
|
|
|
- 서울 K3s 클러스터(kr1·kr2·hp1·hp2) 워크로드를 incus 컨테이너/VM으로 이전
|
|
- K3s 자체 폐기 (kine·Patroni 의존 종료, Longhorn 폐기)
|
|
- 운영 면적 축소: GitOps·CRD·CNI·CSI·CRDS 레이어 제거
|
|
|
|
## 비목표
|
|
|
|
- jp1 Incus 호스트 그대로 유지 (도쿄, Vault·agents 정본)
|
|
- 서울 4대 Incus 클러스터링은 별도 결정 ([[infra-hosts]] 참조). 이전은 호스트 분리 상태로 진행
|
|
- Outline/Slack 등 외부 SaaS 이전 (해당 없음)
|
|
|
|
## 디폴트 결정 — 대체 패턴
|
|
|
|
플랜 단계에서 확정. 변경 시 본 문서 history에 명시.
|
|
|
|
| 레이어 | K3s 현행 | Incus 대체 | 근거 |
|
|
|--------|---------|-----------|------|
|
|
| 진입점/라우팅 | MetalLB + Traefik + APISIX | OpenWrt HAProxy → APISIX 서울 (incus 컨테이너) → 컨테이너 IP | APISIX 서울은 유지 (정책·플러그인·SafeLine 통합 가치). MetalLB·Traefik만 폐기. APISIX는 K3s StatefulSet에서 incus 단일 컨테이너 + sqlite/etcd 백엔드로 축소 |
|
|
| TLS 인증서 | cert-manager + Let's Encrypt | acme.sh + Cloudflare DNS-01, HAProxy/APISIX/SafeLine reload | CF global key 이미 운영. cert-manager CRD 학습 비용 회피 |
|
|
| 스토리지 | Longhorn (분산 블록) | Synology NAS NFS/iSCSI 직접 마운트 + 호스트 btrfs 로컬 | 분산 복제는 앱 레벨 HA(Patroni)로 한정. NAS는 democratic-csi 없이 직접 |
|
|
| 프로비저닝 | ArgoCD + Helm (Gitea) | **OpenTofu + Ansible** (ops-agents-tofu 패턴 확장 + playbook 표준화) | Tofu = 인프라(컨테이너 생성·디스크·네트워크 device), Ansible = 컨테이너 안 OS/앱 설정. 기존 헤임달/씬 Tofu 패턴 위에 Ansible 추가. ArgoCD GitOps는 Gitea 저장소 + Tofu Cloud 또는 atlantis로 PR 기반 plan/apply |
|
|
| 시크릿 | K8s Secret + Vault Agent | Vault API 직접 (envconsul/sidecar/init) | Vault는 이전 없음 |
|
|
| 로깅 | VictoriaLogs + vector daemonset | VictoriaLogs 컨테이너 + vector systemd unit on host | 컨테이너 수집은 console.log tail |
|
|
| 메트릭 | VictoriaMetrics + node-exporter daemonset | VictoriaMetrics 컨테이너 + node-exporter systemd on host | 동일 패턴 |
|
|
| 메시지 큐 | RabbitMQ operator + cluster | RabbitMQ 단일 incus 컨테이너 (현 사용량 단일로 충분) | operator 폐기, 필요 시 페어 |
|
|
| WAF | SafeLine in K3s (6 컴포넌트) | SafeLine docker-compose → incus 단일 컨테이너 묶음 | 공식 docker-compose 그대로, K3s 분산 가치 적음 |
|
|
| HA 정책 | Pod 자동 재스케줄 | 디폴트 active-passive (호스트 다운 시 분 단위 다운타임 수용) | Patroni·Vault만 자체 HA. 나머지는 분 단위 다운 허용 |
|
|
|
|
확정 사항 (2026-06-01):
|
|
- **APISIX 서울 유지**: K3s StatefulSet → incus 단일 컨테이너로 축소 이전. etcd 3-replica 폐기, sqlite 또는 단일 etcd. ApisixRoute CRD는 Admin API + Tofu provider 또는 dashboard로 대체
|
|
- **OpenTofu + Ansible 조합**: Tofu가 incus 컨테이너·디스크·네트워크 device 생성, Ansible이 컨테이너 안 OS 설정·앱 배포. 시범 단계부터 두 도구 동시 적용
|
|
- **kr1 GTX 1080 Ti 유지**: Incus GPU 컨테이너로 GPU 워크로드 계속. K3s 종료 후에도 docker-gpu/podman-gpu 이미지 활용
|
|
|
|
## 배치 정책
|
|
|
|
| 호스트 | 권장 워크로드 | 사유 |
|
|
|--------|-------------|------|
|
|
| kr1 (62GiB + GTX 1080 Ti) | GPU 워크로드 (docker-gpu/podman-gpu 이미지 기반), brokkr(현행), postgres-2 replica | GPU 자원 유지. control-plane 부담 제거 후 GPU 활용도 확대 가능 |
|
|
| kr2 (30GiB) | inbest 7컨테이너 유지, mariadb-3/postgres-3 유지, **신규 무거운 워크로드 금지** | RAM 작음. K3s 폐기 후에도 OOM 위험 |
|
|
| hp1 (188GiB) | 메인 호스트 — Gitea, Outline, OpenMemory, SafeLine, VictoriaLogs/Metrics | RAM 여유, 베어메탈 |
|
|
| hp2 (188GiB) | hp1 짝꿍 — jarvis, trader 유지 + 분산 부담 분배, mariadb-1/postgres-1 유지 | RAM 여유, Tailscale 가입 |
|
|
|
|
## Phase 0 — 대체 패턴 인프라 셋업
|
|
|
|
K3s 워크로드 이전 전 인프라 토대 구축. 약 1~2주.
|
|
|
|
- [ ] **OpenTofu 컨테이너 모듈** 작성 (`kaffa/ops-agents-tofu`에 `modules/incus-service/` 추가): Incus 컨테이너 + 디스크 device + proxy device + cloud-init 표준화
|
|
- [ ] **Ansible 표준 playbook 셋업**: `kaffa/ansible-services` 신규 저장소 — inventory를 Tofu output으로 자동 생성, 공통 role(`base`, `vector-agent`, `node-exporter`, `tailscale`, `app-runtime` 등) 작성. Vault lookup plugin으로 시크릿 주입
|
|
- [ ] **Tofu ↔ Ansible 연결 패턴 확정**: Tofu apply → Ansible playbook 자동 실행 (`null_resource` + `local-exec` 또는 별도 CI 단계). 적용 순서·재실행 멱등성 검증
|
|
- [ ] **공통 베이스 이미지** (Debian 13 + vector + node-exporter + tailscale 선택적): incus image build, 캐시 push. Ansible playbook으로 이미지 빌드 자체도 코드화
|
|
- [ ] **acme.sh 인증서 발급기**: hp1에 incus 컨테이너 `acme` 신설, Cloudflare DNS-01 + Vault에서 CF global key 조회. hook으로 HAProxy / APISIX / SafeLine reload
|
|
- [ ] **HAProxy 확장**: OpenWrt의 `/etc/haproxy/haproxy.cfg`에 신규 backend 추가 검증 (현재 Traefik VIP 192.168.9.53 백엔드 → APISIX 서울 incus 컨테이너 IP 또는 직접 컨테이너 IP로 점진 전환)
|
|
- [ ] **APISIX 서울 incus 컨테이너 준비**: hp1 또는 hp2에 신규 APISIX 컨테이너 생성, sqlite/etcd 백엔드 결정, 현행 K3s APISIX config·플러그인·SafeLine 통합 설정 export → 신규 컨테이너로 import. dual-run으로 검증 (Phase 4까지 K3s APISIX 병행)
|
|
- [ ] **NAS 마운트 표준**: Synology NFS export 디렉터리 구조 결정 (`/volume1/incus-data/<service>/`), btrfs subvol 옵션, idmap 정책
|
|
- [ ] **VictoriaLogs/Metrics incus 이전 사전 작업**: jp1 monitoring 프로젝트 또는 hp1에 신규 컨테이너 — K3s VictoriaMetrics 데이터 마이그레이션 dry-run
|
|
- [ ] **롤백 스냅샷 정책**: `incus snapshot` 자동화 — 이전 후 일정 기간 보관
|
|
|
|
성공 기준: Phase 1 시범 서비스를 Tofu apply → 컨테이너 RUN → HAProxy 라우팅 → 인증서 발급까지 무인 실행
|
|
|
|
## Phase 1 — 시범 이전 (1~2주)
|
|
|
|
패턴 검증용. 다운타임 영향 작은 서비스만.
|
|
|
|
| 순서 | 서비스 | 출처 ns | 목표 호스트 | 메모 |
|
|
|------|--------|--------|-----------|------|
|
|
| 1 | kroki | kroki | hp1 | stateless, 다이어그램 렌더링. 의존성 없음 |
|
|
| 2 | searxng | searxng | hp1 | stateless 검색 프록시 |
|
|
| 3 | juice-shop | juiceshop | hp2 | 테스트용, jp1 default에도 컨테이너 존재 → 통합 검토 |
|
|
|
|
검증 항목:
|
|
- OpenTofu 모듈로 컨테이너 생성·재생성 멱등성
|
|
- **Ansible playbook으로 컨테이너 안 설정·앱 배포 멱등성** (재실행 시 변경 없음)
|
|
- **Tofu output → Ansible inventory 자동 연결 동작**
|
|
- OCI 이미지 자동 업데이트 패턴 (blue-green vs in-place restart)
|
|
- HAProxy → APISIX 서울 (또는 컨테이너 IP 직접) 라우팅 + SafeLine 통과 (필요 시)
|
|
- acme.sh 인증서 발급·갱신
|
|
- vector → VictoriaLogs 수집 (K3s 잔존 + 신규 incus 동시 수집)
|
|
|
|
성공 기준: 3 서비스 정상 가동 + DNS 전환 후 1주 무이슈
|
|
|
|
## Phase 2 — Stateless·단일 컨테이너 이전 (2~3주)
|
|
|
|
| 순서 | 서비스 | 출처 ns | 목표 호스트 | 메모 |
|
|
|------|--------|--------|-----------|------|
|
|
| 1 | smtp-relay | mail | hp1 | ArgoCD App, 단순 |
|
|
| 2 | BunnyCDN MCP | mcp | hp1 | ArgoCD App |
|
|
| 3 | cfb-manager | tools | hp1 | ArgoCD `cf-bouncer-manager` |
|
|
| 4 | Namecheap API | api | hp1 | ArgoCD |
|
|
| 5 | Vultr API | api | hp1 | ArgoCD |
|
|
| 6 | NocoDB | tools | hp1 | Patroni 사용 — DB 연결만 유지 |
|
|
| 7 | n8n | n8n | hp1 | Helm. Postgres 연결만 유지. workflow 데이터 백업 후 마이그레이션 |
|
|
| 8 | sftpgo | sftpgo | hp2 | SFTP 22 노출 — HAProxy TCP 라우팅 |
|
|
| 9 | sshpiper | sshpiper | hp2 | jp1에 sshpiper 컨테이너도 있음 — 역할 분리 확인 후 |
|
|
| 10 | teleport | teleport | hp1 | auth + proxy 2 컴포넌트, 단일 incus 컨테이너로 통합 가능 |
|
|
|
|
각 항목 작업:
|
|
1. OpenTofu apply로 컨테이너 생성
|
|
2. 데이터 이전 (PVC → NAS 또는 컨테이너 disk)
|
|
3. K3s 측에서 동일 DNS로 dual-run, healthcheck
|
|
4. HAProxy backend 전환 (K3s VIP → incus 컨테이너 IP)
|
|
5. 1주 모니터 후 K3s 측 helm uninstall / kubectl delete ns
|
|
6. ArgoCD Application 삭제
|
|
|
|
## Phase 3 — 멀티 컴포넌트 이전 (2~3주)
|
|
|
|
| 순서 | 서비스 | 출처 ns | 목표 호스트 | 구성 |
|
|
|------|--------|--------|-----------|------|
|
|
| 1 | Gitea | gitea | hp1 | gitea + valkey 두 컨테이너. PostgreSQL은 Patroni 그대로. valkey는 컨테이너 동거 또는 별도 |
|
|
| 2 | Outline | outline | hp1 | outline + redis 두 컨테이너. PostgreSQL은 Patroni |
|
|
| 3 | OpenMemory | openmemory | hp1 | mcp + ui + qdrant 세 컨테이너. qdrant 데이터는 NAS NFS |
|
|
| 4 | SafeLine WAF | safeline | hp1 | 공식 docker-compose 기반, 단일 incus 컨테이너 안에서 compose 실행 (예외적 사용) 또는 multi-container profile |
|
|
| 5 | RabbitMQ | mq | hp1 | 단일 컨테이너로 충분. operator·cluster 폐기 |
|
|
| 6 | PgCat/ProxySQL | db | hp1 또는 jp1 db 프로젝트 | Patroni pooler 위치 재검토 |
|
|
|
|
작업 패턴 (Phase 2와 동일하나 데이터 마이그레이션 비중 큼):
|
|
- Postgres 의존: 이전 중 connection string만 incus 컨테이너 IP로 전환
|
|
- Redis/valkey/qdrant: 데이터 export → import 또는 NAS 볼륨 통째로 이동
|
|
- Gitea: LFS 데이터 NAS 이전 + clone/push 무중단 테스트
|
|
|
|
## Phase 4 — 게이트웨이 정리 (1~2주)
|
|
|
|
- [ ] **APISIX 서울 incus 컨테이너 전면 전환**: Phase 0에서 준비한 incus APISIX 컨테이너로 트래픽 전환. HAProxy backend를 K3s APISIX VIP(192.168.9.50) → incus APISIX 컨테이너 IP로 변경. DNS TTL + 1주 모니터 후 K3s apisix ns 삭제
|
|
- [ ] **Traefik 폐기**: 모든 HTTPRoute/IngressRoute → HAProxy backend(또는 APISIX 라우트)로 이전 완료 확인. K3s Traefik helm uninstall
|
|
- [ ] **MetalLB 폐기**: LoadBalancer Service 없음 확인 후 helm uninstall
|
|
- [ ] **cert-manager 폐기**: 모든 Certificate CR 무사용 확인 (APISIX·HAProxy·SafeLine 인증서 모두 acme.sh로 대체됨) 후 helm uninstall
|
|
|
|
## Phase 5 — K3s 인프라 폐기 (1~2주)
|
|
|
|
- [ ] **Longhorn 데이터 마이그레이션 완료 확인**: 모든 PVC가 NAS NFS 또는 호스트 디스크로 이전됨. `kubectl get pv` 비어있음
|
|
- [ ] **Longhorn helm uninstall + longhorn-system ns 삭제**
|
|
- [ ] **ArgoCD helm uninstall + argocd ns 삭제**: GitOps 저장소(`kaffa/k3s-charts` 등) 아카이브
|
|
- [ ] **VictoriaLogs/Metrics 데이터 incus로 이전**: jp1 monitoring 또는 hp1 신규 컨테이너에서 단일 인스턴스 운영
|
|
- [ ] **kube-system 잔여 정리**: descheduler, multus, nfs-provisioner 등
|
|
- [ ] **Patroni → kine 의존 제거**: K3s 자체 종료 직전 단계. Patroni는 그대로 유지 (다른 워크로드가 사용)
|
|
|
|
## Phase 6 — K3s 종료 (1주)
|
|
|
|
- [ ] kr1·kr2 control-plane drain + `k3s-uninstall.sh`
|
|
- [ ] hp1·hp2 agent drain + `k3s-agent-uninstall.sh`
|
|
- [ ] OpenWrt HAProxy에서 K3s 관련 backend 전체 삭제
|
|
- [ ] DNS — `k3s.inouter.com`, `*.inouter.com` 매핑 정리
|
|
- [ ] [[infra-hosts]] 업데이트: K3s 섹션 → history로 이동, 호스트 역할 재정의
|
|
- [ ] Obsidian K3s 관련 정본 문서 → `history/2026-XX-XX-k3s-decommission.md`로 이전
|
|
|
|
## 서비스 매핑 요약
|
|
|
|
| 서비스 | 현재 (K3s) | 이전 후 (Incus) | Phase |
|
|
|--------|-----------|----------------|-------|
|
|
| kroki | kroki ns | hp1 컨테이너 `kroki` | 1 |
|
|
| searxng | searxng ns | hp1 컨테이너 `searxng` | 1 |
|
|
| juice-shop | juiceshop ns | hp2 컨테이너 (jp1과 통합 검토) | 1 |
|
|
| smtp-relay | mail ns | hp1 컨테이너 `smtp-relay` | 2 |
|
|
| BunnyCDN MCP | mcp ns | hp1 컨테이너 `bunny-mcp` | 2 |
|
|
| cfb-manager | tools ns | hp1 컨테이너 `cfb-manager` | 2 |
|
|
| Namecheap/Vultr API | api ns | hp1 컨테이너 `dns-api` (통합 또는 분리) | 2 |
|
|
| NocoDB | tools ns | hp1 컨테이너 `nocodb` | 2 |
|
|
| n8n | n8n ns | hp1 컨테이너 `n8n` | 2 |
|
|
| sftpgo | sftpgo ns | hp2 컨테이너 `sftpgo` | 2 |
|
|
| sshpiper | sshpiper ns | hp2 컨테이너 `sshpiper-seoul` (jp1과 역할 분리) | 2 |
|
|
| Teleport | teleport ns | hp1 컨테이너 `teleport` (auth+proxy 통합) | 2 |
|
|
| Gitea | gitea ns | hp1 컨테이너 `gitea` + `gitea-valkey` | 3 |
|
|
| Outline | outline ns | hp1 컨테이너 `outline` + `outline-redis` | 3 |
|
|
| OpenMemory | openmemory ns | hp1 컨테이너 `openmemory-mcp` + `openmemory-ui` + `openmemory-qdrant` | 3 |
|
|
| SafeLine WAF | safeline ns | hp1 컨테이너 `safeline` (compose 내부) | 3 |
|
|
| RabbitMQ | mq ns | hp1 컨테이너 `rabbitmq` | 3 |
|
|
| PgCat/ProxySQL | db ns | hp1 또는 jp1 db 프로젝트 | 3 |
|
|
| VictoriaLogs/Metrics | logging/monitoring ns | hp1 컨테이너 또는 jp1 monitoring | 5 |
|
|
| APISIX 서울 | apisix ns (Deployment x2 + ingress-controller + etcd 3/3) | hp1 또는 hp2 단일 컨테이너 `apisix-seoul` (sqlite/단일 etcd 백엔드) | 0 준비 / 4 전환 |
|
|
| Traefik | kube-system | **폐기** | 4 |
|
|
| MetalLB | metallb-system | **폐기** | 4 |
|
|
| cert-manager | cert-manager | **폐기** (acme.sh로 대체) | 4 |
|
|
| Longhorn | longhorn-system | **폐기** (NAS NFS로 대체) | 5 |
|
|
| ArgoCD | argocd | **폐기** (OpenTofu로 대체) | 5 |
|
|
|
|
## 롤백 절차
|
|
|
|
Phase별 롤백 가능. 단 Phase 5 (Longhorn 폐기) 이후 K3s 복귀는 비현실적 — 그 이전 단계는 데이터 손실 없이 복귀 가능.
|
|
|
|
각 서비스 단위 롤백:
|
|
1. HAProxy backend를 K3s VIP로 되돌림
|
|
2. Incus 컨테이너 stop (삭제 금지 — `incus snapshot`으로 백업 보존)
|
|
3. K3s 측 Deployment/StatefulSet replica 복원
|
|
4. DNS TTL 안에 트래픽 복귀
|
|
|
|
전체 롤백 트리거:
|
|
- 이전 후 1주 내 다운타임 > 1시간 누적
|
|
- 데이터 무결성 사고
|
|
- 운영 부담이 예상보다 큼 (incus 자체 OOM, idmap 깨짐 반복 등)
|
|
|
|
## 위험요소 / 트레이드오프
|
|
|
|
| 위험 | 완화 |
|
|
|------|------|
|
|
| HA 손실 (호스트 다운 = 서비스 다운) | 디폴트 수용. Patroni·Vault·DNS만 자체 HA. 핵심 외 분 단위 다운타임 허용 |
|
|
| 이전 중 K3s + Incus 이중 운영 부담 | Phase 시간 단축, 시범에서 패턴 확립 후 가속 |
|
|
| ArgoCD GitOps 시각화 손실 | OpenTofu state + Tofu Cloud 또는 atlantis로 PR 기반 plan/apply. Ansible은 별도 CI 실행 로그 |
|
|
| APISIX 서울 단일 컨테이너 — etcd 3-replica 폐기 후 가용성 저하 | sqlite 백엔드 시 단일 컨테이너 다운 = 라우팅 중단. NAS 백업 + 빠른 재기동 패턴. 필요 시 hp1·hp2 active-passive 페어 |
|
|
| Tofu + Ansible 이중 도구 학습·운영 부담 | Phase 0에서 패턴 표준화·문서화. Phase 1 시범으로 마찰 조기 발견 |
|
|
| OCI 이미지 자동 업데이트 부재 | blue-green 패턴 표준화, renovate-bot으로 tag PR 자동 생성 |
|
|
| Longhorn 폐기 후 백업 전략 | NAS snapshot + R2 sync 기존 파이프라인 ([[backup]]) 활용 |
|
|
| kr2 OOM 재발 (Incus 단독에서도) | inbest 7컨테이너 + DB 2 + 신규 워크로드 금지. 가벼운 것만 |
|
|
| SafeLine WAF Phase 3 단일 컨테이너 통합 — chaitin-waf 트래픽 처리 성능 | 시범에서 부하 테스트, 필요 시 hp1·hp2 페어 active-passive |
|
|
|
|
## 일정 추정 (의지적, 실제는 더 길어질 수 있음)
|
|
|
|
| Phase | 기간 | 누적 |
|
|
|-------|------|------|
|
|
| Phase 0 (인프라 토대) | 2주 | 2주 |
|
|
| Phase 1 (시범) | 2주 | 4주 |
|
|
| Phase 2 (단일 컨테이너) | 3주 | 7주 |
|
|
| Phase 3 (멀티 컴포넌트) | 3주 | 10주 |
|
|
| Phase 4 (게이트웨이) | 1주 | 11주 |
|
|
| Phase 5 (인프라 폐기) | 2주 | 13주 |
|
|
| Phase 6 (K3s 종료) | 1주 | 14주 |
|
|
|
|
전체 약 3.5개월. 실제 진행은 다른 작업·인시던트로 6개월~1년 범위 예상.
|
|
|
|
## 관련 문서
|
|
|
|
- [[infra-hosts]] — 현재 K3s/Incus 호스트 및 워크로드 정본
|
|
- [[../platform/longhorn]] — Longhorn 현행 운영
|
|
- [[../network/apisix]] — APISIX 서울/오사카 라우팅
|
|
- [[../network/metallb]] — MetalLB IP 풀
|
|
- [[../data/postgresql-ha]] — Patroni HA (그대로 유지)
|
|
- [[../security/vault]] — Vault (그대로 유지, jp1)
|
|
- [[../data/k3s-backup]] — 현행 백업 파이프라인
|
|
- [[../../history/2026-05-23-kr1-k3s-stuck-cascade]] — 이전 결정 동기 중 하나
|
|
- [[../../history/2026-05-04-amd-iommu-freeze]] — kr2 freeze 이력
|