단일 서버에 경량 쿠버네티스 k3s 싱글 노드 배포와 운영 시 고려사항

k8s(Upstream Kubernetes) vs k3s

1. 목적/무게감
   • Kubernetes(이하 k8s)는 엔터프라이즈급 분산 오케스트레이션(완전한 control plane 구성, etcd 등).
   • k3s는 경량화된 배포판으로 단일 바이너리, 의존성 축소, 엣지/IoT/로컬 개발·테스트 목적에 최적화.
2. 구성 요소
   • k8s: API Server, Controller, Scheduler, etcd 등 여러 프로세스/컴포넌트.
   • k3s: control-plane 구성 요소를 단일 바이너리에 패키징, 기본 데이터스토어로 SQLite(경량), 필요시 etcd / 외부 DB(MySQL/Postgres)도 사용 가능.
3. 설치·운영 편의성
   • k8s: kubeadm/관리 툴로 구성, 운영·보안·확장 설계가 더 복잡.
   • k3s: curl https://get.k3s.io | sh - 스크립트로 간편 설치, 운영자 부담 적음.
4. 확장성·운용성
   • k8s는 대규모(수십~수천 노드) 운영에 맞춤.
   • k3s는 경량·중소형 클러스터에 적합. 단일 호스트(싱글 노드)는 빠르게 배포·테스트·소규모 서비스에 효율적이나 단일 장애점(SPOF) 존재 — 프로덕션에서는 HA 설계 권장.
5. 보안·하드닝
   • k3s는 기본 보안 설정/완화가 일부 적용되어 있어 쉽게 시작 가능하지만, 프로덕션급 하드닝(CIS 등)은 별도 적용 필요. k3s 공식 문서에서 하드닝 가이드 제공.

단일 호스트(k3s 싱글 노드) 설치 설계 결정 포인트 (운영 상 고려사항)

• 장점: 빠른 설치, 낮은 리소스(메모리·디스크) 요구, 개발/테스트·작은 서비스 적합.
• 단점: control plane과 워커가 같은 호스트 → SPOF, 호스트 장애 시 클러스터 전체 불가용. 따라서 비교적 중요도가 낮거나 장애 복구(백업/복원)가 확실히 준비된 서비스에 적합.
• 권장: 중요한 프로덕션 서비스라면 외부 DB(etcd/External DB)·다중 노드 HA 또는 관리형 k8s를 고려.

300x250

사전 준비 (OS/커널/네트워크/보안)

• 운영체제: Ubuntu/CentOS 등 최신 패치 적용된 Linux (커널 보안 패치 적용).
• 커널 설정
  • swap 비활성화: sudo swapoff -a 및 /etc/fstab에서 swap 항목 주석 처리.
  • sysctl: IP 포워딩 및 브리지 네트워크 패킷 허용

    sudo tee /etc/sysctl.d/99-k8s.conf <<'EOF'
    net.bridge.bridge-nf-call-iptables = 1
    net.ipv4.ip_forward = 1
    EOF
    sudo sysctl --system

• 방화벽: API 서버(기본 6443), 노드 포트(노드 IP/노드 포트 범위), kubelet(10250), 서비스용 포트(예: 80/443) 등 필요 포트만 허용.
• 컨테이너 런타임: k3s는 내장 컨테이너런타임(containerd 포함)을 기본 사용. 별도 CRI가 필요하면 설정 가능.

설치 (싱글 노드) — 실전 명령 예시

• 기본 설치 (가장 단순)

  # 기본 설치 (root 권한)
  curl -sfL https://get.k3s.io | sh -
  # kubeconfig 경로
  sudo cat /etc/rancher/k3s/k3s.yaml

• 운영용으로 일부 컴포넌트 비활성화(예: 내장 서비스LB, 내장 Traefik 비활성) 및 kubeconfig 권한 설정

  # 예시: servicelb, traefik 비활성화, kubeconfig 권한을 644로
  curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable servicelb --disable traefik" K3S_KUBECONFIG_MODE="644" sh -

• 설치 후 확인

  # 노드 확인
  kubectl get nodes
  # 시스템 네임스페이스 리소스 확인
  kubectl get pods -A

데이터스토어(디폴트 및 권장) — 백업·복구 포인트

• 기본: SQLite(/var/lib/rancher/k3s/server/db/) — 가볍고 단일노드에 적합. 복구 시 token이 필요(토큰으로 기밀 데이터 암호화되므로 동일 토큰으로 복원해야 함). 백업은 해당 디렉터리 복사로 가능.
• 권장(프로덕션/중요 서비스): 외부 데이터스토어 사용 (etcd, MySQL/MariaDB, Postgres) — 외부 DB는 DB 자체 백업 전략 사용 권장(스냅샷, PITR 등).

SQLite 백업(간단)

# 예: 정지 후 복사(단일 노드)
sudo systemctl stop k3s
sudo tar czf /backup/k3s-sqlite-$(date +%F-%T).tgz /var/lib/rancher/k3s/server/db /etc/rancher/k3s/k3s.yaml /var/lib/rancher/k3s/server/node-token
sudo systemctl start k3s

• 자동화 방안: Litestream 같은 도구로 SQLite WAL 리플리케이션을 S3에 복제 → 무중단 백업 가능

복원 시나리오(핵심)

• SQLite: /var/lib/rancher/k3s/server/db와 node-token(또는 설치 시 사용한 token)을 복원 → k3s 재시작. 토큰 불일치 시 시크릿/기밀 데이터 사용 불가.
• 외부 DB: DB 자체 복구(스냅샷/덤프/restore) → k3s 재기동.

운영(운영·모니터링·로깅) — 권장 스택 및 예시

1. 모니터링
   • Prometheus + node-exporter + kube-state-metrics + grafana: k3s에서 Helm으로 배포.
   • 예: helm repo add prometheus-community https://prometheus-community.github.io/helm-charts 등으로 설치.
2. 로그 수집
   • Fluent Bit (경량) → 중앙 ELK/Opensearch로 전송.
3. 스토리지
   • 싱글 노드: local-path-provisioner(k3s에서 기본 제공) 사용 가능.
   • 프로덕션 저장소: Longhorn(분산 블록 스토리지)을 여러 노드로 운영 권장(싱글 노드에서는 분산성 부족).
4. 알림
   • Alertmanager → Slack/Email 연동.

보안 관점 — 실무 하드닝 체크리스트

아래 항목은 정책·감사·운영 체크리스트로 활용하세요. (CIS 기준과 k3s 하드닝 가이드 참고 권장)

1. Kubeconfig 및 토큰 관리
   • /etc/rancher/k3s/k3s.yaml 접근 권한 최소화(root 전용). K3S_KUBECONFIG_MODE로 권한 조정 시 최소 허용 필요.
   • node-token(설치 토큰) 안전 저장(백업 시 암호화).
2. RBAC / 네임스페이스 정책
   • 최소 권한 원칙 적용(ClusterRoleBinding 최소화).
   • 사용자/서비스 계정 권한 주기 전 반드시 리뷰.
3. API 접근 제어
   • 불필요한 익명 인증/인증 미허용 설정 확인, kube-apiserver 접근 제어(방화벽/IP 화이트리스트).
4. 네트워크 분리·NetworkPolicy
   • Pod간 통신 제어를 위해 NetworkPolicy 적용(기본 허용이면 차단형 정책으로 전환).
5. Secret 관리
   • 외부 KMS(예: Vault) 연동 권장. SQLite 토큰으로 암호화되는 부분은 복원 시 유의.
6. 패키지/이미지 관리
   • 이미지 서명/검증, 내부 레지스트리 사용, 불필요한 컨테이너 권한 제거(루트 실행 금지), 이미지 스캐닝 도입.
7. 로그·감사
   • kube-apiserver 감사로깅(audit) 활성화(감사 로그 중앙 수집).
   • 이벤트·시스템 로그의 중앙화 및 무결성 확보(로그 적재 전 해시 체인 등 고려).
8. 업데이트/패치 전략
   • k3s는 자동 업데이트 기능도 있으나(옵션), 운영 정책에 맞춘 테스트·롤아웃 계획 필요. 자동화 전 사전 검증 환경에서 점검.

업그레이드·유지보수 절차(예시)

1. 사전: kubectl get pods -A로 상태 확인, 리소스 백업(설정·PVC·DB 스냅샷).
2. 워크로드 드레인(유휴 또는 대체 호스트 있을 때)

   kubectl drain <노드명> --ignore-daemonsets --delete-local-data
   # 업그레이드 작업 (예: k3s binary 교체/패키지 업그레이드)
   sudo systemctl restart k3s
   kubectl uncordon <노드명>

3. 싱글 노드 환경에서는 다운타임 발생 가능 → 배포 시점/유지보수 창 관리 필요.

장애 대응 & 복구(실전 절차 요약)

• 장애 유형별 우선순위
  1. 호스트 OS/하드웨어 장애 → DR 복구(백업된 /var/lib/rancher/k3s/server/db + token 복원 또는 외부 DB 복원)
  2. 데이터 손상 → DB 스냅샷에서 복원(외부 DB면 DB 도구로 복구, SQLite면 백업 파일 복원)
• 복원 테스트는 정기적으로 시행(복원 시나리오 문서화 및 체크리스트화).

구체적 예제: 프로덕션 준비 체크리스트

1. OS 패치 완료, swap off, sysctl 적용.
2. k3s 설치 (옵션으로 --disable servicelb --disable traefik 등 필요한 구성 비활성화).
3. kubeconfig, node-token 안전 보관(암호화 백업).
4. 외부 모니터링/로깅 연동(Prometheus / Fluent Bit).
5. 네트워크/방화벽 정책·NetworkPolicy 적용.
6. 정기 백업 스케줄(Litestream or cron backup for sqlite / DB snapshot for external DB).
7. 정기 복원 테스트(분기별 또는 릴리스 전).
8. RBAC 및 감사 로깅 활성화(CIS 체크리스트 기반 점검).

참고 자료(공식·실무 문서)

• k3s Cluster Datastore(데이터스토어 옵션: sqlite, etcd, MySQL, Postgres). (docs.k3s.io)
• k3s Backup & Restore (SQLite 백업/복원, 외부 DB 백업 권고). (docs.k3s.io)
• k3s 설치 문서(설치 옵션, 구성파일, 패키지 컴포넌트 관리). (docs.k3s.io)
• k3s Security / CIS Hardening Guide (프로덕션 보안 지침). (docs.k3s.io)
• Litestream을 이용한 SQLite 실시간 백업 방법(싱글 노드 k3s 백업 사례). (inovex GmbH)

권장 아키텍처

• 개발/테스트/엣지·작은 서비스: k3s 싱글 노드 빠르게 도입 가능 — 리소스 효율적이고 관리가 쉬움.
• 중요한 프로덕션(무중단, 고가용성 요구): 싱글 노드는 SPOF이므로 외부 DB(etcd/DB) 기반 HA 또는 다중 노드 k3s(또는 풀 k8s) 구성 권장. 백업/복구·보안·모니터링 계획을 반드시 마련해야 함.