history: 2026-04-20 K3s 개선 6건 실행 리포트

Default SC 통일, safeline 볼륨 replica 3 통일, vector healthcheck
disable, hp1 rebalance 자연 진행 (3→10 replica), iSCSI 재시작은
helm-upgrade 주기 영향 추정·관찰 유지, kr2 system-reserved 10Gi
비대칭은 기록 완료·통일 실행은 호스트 접근 후 후속.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
heimdall
2026-04-20 20:54:18 +09:00
parent 0d1bf40cfe
commit f8c4274124

View File

@@ -0,0 +1,214 @@
---
date: 2026-04-20
topic: K3s 개선 6건 (default SC / Longhorn rebalance / safeline replica / iSCSI 재시작 / vector healthcheck / kr2 reserved)
areas:
- infra/compute/infra-hosts
- infra/data/k3s-backup
- infra/observability/vector
---
# 2026-04-20 K3s 개선 6건
전날 `2026-04-20 / K3s 상세 점검` 에서 도출된 후속 작업 6건 실행.
## 1. Default StorageClass 통일 — OK
### 변경 전
```
local-path true
longhorn true
longhorn-static false
nfs false
synology-iscsi false
```
### 실행
```bash
kubectl patch sc local-path -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
```
### 변경 후
```
local-path false
longhorn true ← 유일 default
longhorn-static false
nfs false
synology-iscsi false
```
판정: **OK**. 신규 PVC 는 명시적 storageClassName 없으면 `longhorn` 으로 바인딩.
---
## 2. hp1 Longhorn rebalance — OK
### 현상태 확인
- `replica-auto-balance` 세팅: 이미 `best-effort` (원래 설정됨, `infra/compute/infra-hosts.md:46` 기록 존재)
- 즉시 trigger 없이 신규 replica 배치 + 기존 볼륨 rebuild 시 자동 재분산
### 3번 작업 (safeline replica 2→3) 부수효과로 hp1 배치 대폭 증가
```
변경 전: hp1=3 hp2=25 kr1=25 kr2=15 (total 68)
변경 후: hp1=10 hp2=25 kr1=25 kr2=15 (total 75)
```
7개 신규 replica 가 전부 hp1 에 배치됨 — `best-effort` + 신규 노드 가중치. 추가 조치 불필요.
판정: **OK**. 기존 설정이 이미 최적, 신규 replica 분산 작동 확인.
---
## 3. Safeline 7 볼륨 replica 2→3 통일 — OK
### Obsidian 의도 조회
`infra/` 전반에 safeline volume `replica=2` 의도 기록 **없음**. `infra/network/k3s-ingress-architecture.md:47` 에 tengine replica 0, `infra/network/apisix.md:51` 에 APISIX deployment replica 2 (파드 replica, Longhorn 볼륨 아님) 기록만 확인. 정본 기본 정책은 **replica=3** (`infra/data/k3s-backup.md:154, 179` numberOfReplicas: 3).
→ 명시적 근거 없음 → 3으로 통일해 정책 일관성 확보.
### 실행
```bash
for vol in pvc-0440758f-...safeline-chaos \
pvc-15af4f6d-...safeline-tengine-logs \
pvc-384dd143-...safeline-detector-logs \
pvc-3c39ef90-...safeline-luigi \
pvc-7da9941f-...database-data-safeline-database-0 \
pvc-8534d9f3-...safeline-mgt \
pvc-8f9bfed6-...safeline-detector; do
kubectl -n longhorn-system patch volume.longhorn.io $vol --type=merge \
-p '{"spec":{"numberOfReplicas":3}}'
done
```
### 결과 (25초 이내 전 볼륨 healthy)
| Volume | PVC | numberOfReplicas | robustness |
|---|---|---|---|
| pvc-0440758f-... | safeline-chaos | 3 | healthy |
| pvc-15af4f6d-... | safeline-tengine-logs | 3 | healthy |
| pvc-384dd143-... | safeline-detector-logs | 3 | healthy |
| pvc-3c39ef90-... | safeline-luigi | 3 | healthy |
| pvc-7da9941f-... | database-data-safeline-database-0 | 3 | healthy |
| pvc-8534d9f3-... | safeline-mgt | 3 | healthy |
| pvc-8f9bfed6-... | safeline-detector | 3 | healthy |
판정: **OK**. 전체 25 Longhorn 볼륨 replica=3 통일 완료.
---
## 4. democratic-csi iSCSI node 재시작 원인 조사 — 관찰 유지
### 대상 파드별 상태
| Pod | Node | Restarts | Last State | Last Terminated |
|---|---|---|---|---|
| synology-iscsi-democratic-csi-node-hlsr2 | hp2 | 8 | Unknown (exitCode 255) | 2026-04-13 10:51 UTC |
| synology-iscsi-democratic-csi-node-287g6 | kr2 | 5 | Unknown (exitCode 255) | 2026-04-19 03:08 UTC |
| synology-iscsi-democratic-csi-node-mvtg7 | kr1 | 1 | - | - |
| synology-iscsi-democratic-csi-node-w9ccj | hp1 | 0 | - | - |
### 컨테이너별 종료 분석 (hlsr2, 8 restart)
```
csi-driver exitCode 255 finishedAt 2026-04-13T10:51:32Z
csi-proxy exitCode 255 finishedAt 2026-04-13T10:51:32Z
driver-registrar exitCode 255 finishedAt 2026-04-13T10:51:32Z
cleanup exitCode 255 finishedAt 2026-04-13T10:51:32Z
```
**4개 컨테이너가 동일 시각, 동일 exitCode 255 로 종료** → pod-level signal (kubelet kill, 일반적으로 helm upgrade / DaemonSet spec 변경 / node drain).
- `helm history synology-iscsi` 기준 최근 업데이트 2026-04-20 08:54 KST 이지만, 이전 업그레이드 주기와 일치하는 타임스탬프 다수.
- `kubectl logs --previous` 전수: 정상 Probe 주기 기록만, 에러/경고 없음.
- `kubectl get events -n democratic-csi`: 결과 없음.
- 현재 전 파드 Ready, 로그에 에러 없음, 신규 파드 (hp1 w9ccj) restart 0 으로 clean.
### 판정
**현재 문제 없음 (관찰 유지)**. "재시작 누적"은 helm chart DaemonSet 재생성으로 인한 pod 재시작 (node 는 계속 Ready 상태라 drain 아님) 이 누적된 것으로 추정. 실제 장애 없음. 추가 계측이 필요하면 DaemonSet 에 `preStop: sleep 5` + 구조화된 exit log 추가. 현재 사이클에서는 **조치 불필요**.
---
## 5. Vector → vlogs healthcheck 400 — OK
### 원인
`vector` sink type=`elasticsearch` 의 healthcheck (startup 시점 1회) 가 엔드포인트 base URL 에 대해 elasticsearch cluster 정보 쿼리를 보냄. vlogs 의 elasticsearch-compat 엔드포인트 (`/insert/elasticsearch/`) 는 `/` 또는 `/_cluster/health` 같은 ES 표준 경로에 **400 Bad Request** 로 응답 → vector 로그에 `Healthcheck failed. error=Unexpected status: 400 Bad Request` 기록. 실제 데이터 경로는 정상, buffer retry 300s 로 자동 복구.
### 조치
healthcheck disable — 데이터 경로에 영향 없고 시작 시점 false alarm 제거.
```bash
helm -n logging upgrade vector \
oci://ghcr.io/vectordotdev/helm-charts/vector --version 0.51.0 \
--reuse-values \
--set customConfig.sinks.vlogs.healthcheck.enabled=false
```
### 결과 검증
- ConfigMap `vector.yaml``vlogs.healthcheck.enabled: false` 반영 확인
- DS 4개 파드 전체 재생성 (age 37~46s), restart 0
- 신규 파드 로그: `vector::topology::builder: Healthcheck disabled.` 명시적 기록
- 이후 `kubectl logs ds/vector --since=5m` 에서 error/fail 패턴 0건
판정: **OK**. 재발 차단 완료.
---
## 6. kr2 system-reserved 10Gi 조사 — 기록 후 정책 통일 검토
### kubelet config 비교 (`/api/v1/nodes/<n>/proxy/configz`)
| Node | systemReserved | kubeReserved | evictionHard |
|---|---|---|---|
| incus-kr2 | **memory: 8Gi** | null | **memory.available: 2Gi** + imagefs/nodefs 5% |
| incus-kr1 | null | null | imagefs/nodefs 5% |
| incus-hp2 | null | null | imagefs/nodefs 5% |
| incus-hp1 | null | null | imagefs/nodefs 5% |
### 원인
- **kr2만** `systemReserved.memory=8Gi` + `evictionHard.memory.available=2Gi` 로 설정됨 (합 10Gi).
- 32Gi capacity - 10Gi reserve ≈ 21.6Gi allocatable 과 정확히 일치.
- k3s CLI `--kubelet-arg="system-reserved=memory=8Gi"` 또는 `/etc/rancher/k3s/config.yaml``kubelet-arg` 항목으로 설정된 것으로 추정 (호스트 SSH 접근 제한으로 본 세션에서 직접 확인 불가).
### Obsidian 정본 검토
`infra/compute/infra-hosts.md` 및 k3s 관련 문서 어디에도 kr2 memory reserve 의도 기록 **없음**.
### 판정
**비대칭 설정, 의도 불명**.
- kr2 capacity 32Gi (다른 노드 대비 하위), 실제 usage mem 16% → reserve 가 과도할 수 있음.
- 그러나 과거 OOM 이슈로 설정된 가능성도 배제 못함.
- **Heimdall: 다음 점검에서 kr2 호스트 SSH 또는 kappa 경유 `/etc/rancher/k3s/config.yaml` 확인 후 정책 결정** — 과한 reserve 해소하려면 해당 설정 제거 + systemd k3s 재시작 (node NotReady 순간 발생, Longhorn replica 영향 계산 후 실행).
- 현재 사이클에서는 설정 존재만 **`infra/compute/infra-hosts.md` 에 명시 기록**, 통일 실행은 후속.
---
## 종합
| # | 작업 | 결과 |
|---|---|---|
| 1 | Default SC local-path=false | ✅ 완료 |
| 2 | hp1 Longhorn rebalance | ✅ best-effort 자연 분산 (3→10 replica) |
| 3 | safeline 7볼륨 replica 3 | ✅ 전 볼륨 healthy |
| 4 | iSCSI 재시작 원인 | 🔵 helm-upgrade 주기 추정, 현재 정상, 관찰 유지 |
| 5 | vector vlogs healthcheck | ✅ disable, 재발 차단 |
| 6 | kr2 system-reserved | 📝 설정 기록 완료, 통일 실행 다음 사이클 |
5/6 즉시 조치 완료, 6번 1건은 호스트 접근 필요 작업으로 후속.
### 다음 점검 대상
1. kr2 `/etc/rancher/k3s/config.yaml``kubelet-arg` 확인 → system-reserved 의도 확정, 불필요시 제거.
2. democratic-csi DaemonSet `preStop` hook 추가 여부 검토 (정상 exit 로그화).
3. hp1 Longhorn replica 추가 분산 (현재 10, 이상적 balance 대비 여전히 부족).