작업일: 2026-07-22
대상: self-hosting k3s 클러스터 (oldbear 컨트롤플레인)
관리 작업 내역을 계속 마크다운으로 기록해나가기로 했는데, GitHub(private repo)에서 직접 보는 건 탐색/검색이 불편하고 모바일에서 보기도 번거로웠음. 공개 저장소로 바꾸는 건 호스팅 정보(도메인, 내부 구조 등)가 노출돼서 원하지 않음 → private 저장소는 그대로 유지하고, 그 위에 셀프호스팅 위키를 얹어 읽기 경험만 개선하기로 결정.
검토한 대안:
deploy/wikijs/wikijs.yaml에 아래 리소스를 정의:
wikiwiki-data 2Gi (longhorn)wiki (ghcr.io/requarks/wiki:2, SQLite 백엔드 — 별도 Postgres 없이 단일 파일로 운영, LiteLLM 때처럼 불필요한 스토어를 늘리지 않기 위함)wiki.igotoo.club, 기존 nginx-ingress + cert-manager letsencrypt-prod 패턴 그대로 사용)Longhorn 볼륨 스토리지 노드는 oldbear 하나뿐이고, borilikebook은 longhorn-csi-plugin 자체가 배제되어 있어(2026-07-21 조치) 그 노드에 스케줄되면 볼륨 마운트가 원천적으로 불가능. 첫 배포 시 파드가 borilikebook에 스케줄되어 AttachVolume 실패가 발생해서, nodeSelector: kubernetes.io/hostname: oldbear를 추가해 고정.
새 PVC를 만들 때마다 mke2fs가 "apparently in use by the system" 에러로 포맷을 거부하는 문제 발생.
oldbear에서 multipathd가 활성 상태였고, Longhorn이 새로 만든 블록 디바이스(iSCSI 기반)를 자동으로 device-mapper 멀티패스 맵(/dev/mapper/mpatha)으로 감싸버림. 이 클러스터는 멀티패스 스토리지를 쓰지 않으므로 완전히 불필요한 개입이었음.sudo systemctl stop/disable/mask multipathd multipathd.socket 실행mpatha 매핑은 서비스를 껐다고 자동으로 없어지지 않아서, 특권 kubectl debug node 파드로 dmsetup remove mpatha를 수동 실행해 제거multipathd는 이번에 완전히 비활성화해뒀으니 당장은 안전하지만, 필요하면 /etc/multipath.conf에 blacklist 설정을 추가하는 게 더 근본적인 조치.cert-manager HTTP-01 challenge로 wiki.igotoo.club 인증서 자동 발급 성공 (기존 서비스들과 동일한 letsencrypt-prod ClusterIssuer 사용). DNS는 기존 *.igotoo.club 와일드카드(Cloudflare)가 이미 커버하고 있어 별도 설정 불필요.
Wiki.js Admin → Storage → Git 모듈로 이 저장소(igotoo/k3s-maintenance, private)를 연결.
gh repo deploy-key add로 등록wiki-git-ssh-key)으로 생성fix-ssh-key-perms)로 emptyDir에 복사 + chown 1000:1000 + chmod 600 처리 후 본 컨테이너에 /wiki/ssh/id_ed25519로 마운트 (SSH가 요구하는 엄격한 파일 권한을 k8s Secret 볼륨 기본 마운트만으로는 맞추기 어려워서 추가한 단계)/wiki/ssh/id_ed25519main → pull rebase → push까지 로그로 정상 확인. 5분 간격 자동 sync(schedule: PT5M) 동작 중.README.md, cluster-maintenance-2026-07-21.md를 페이지로 가져옴.기본 랜딩 경로(home)에 페이지가 없어서 "Create home page" 안내만 뜨는 문제 발생 — 버그가 아니라 import된 두 문서가 각각 README, cluster-maintenance-2026-07-21 경로로 들어갔을 뿐 home 경로엔 아무것도 없어서 생기는 정상 동작.
사용자가 홈페이지를 만들었는데 README 내용을 그대로 복사해 제목도 "README"로 설정하는 바람에 사이드바에 "README"가 두 개로 보이는 것처럼 됨. 다음과 같이 직접 정리:
home 페이지(page id 4) 제목을 Home으로, 본문을 두 문서로 가는 링크만 있는 간단한 인덱스로 교체pages 테이블)와 git 저장소(home.md) 양쪽을 동시에 맞추고, pod 안에서 직접 git add && commit && push로 정합성 유지kubectl rollout restart deployment/wiki로 캐시 초기화| 항목 | 상태 |
|---|---|
| 접속 | https://wiki.igotoo.club (private, 자체 로그인) |
| DB | SQLite, wiki-data PVC(longhorn, 2Gi) |
| 스케줄 | oldbear 고정 |
| Git 동기화 | SSH deploy key, 5분 간격 자동 sync, 정상 동작 |
| 페이지 | Home(인덱스), README, cluster-maintenance-2026-07-21 — 3개 |
| 매니페스트 | deploy/wikijs/wikijs.yaml에 기록 (이 저장소 자체가 git storage 소스이기도 함) |
/etc/multipath.conf에 blacklist를 추가해두면 더 안전. 우선순위 낮음(현재는 문제 없음).docs: create home, page: home 등), 앞으로 로컬에서 이 저장소를 pull 없이 오래 작업하면 히스토리가 갈라질 수 있음 — 로컬에서 커밋하기 전에 git fetch && git rebase origin/main 습관화 권장.