Kubernetes 입문 — 단일 노드부터 시작
Kubernetes는 무엇이고 어떻게 작동하나요?
Kubernetes(쿠버네티스)는 컨테이너 이미지 실행 및 리소스 할당을 자동화하는 오픈소스 오케스트레이션 플랫폼입니다. 단일 노드에서 수천 개 노드 규모까지 확장 가능하며, 마스터-워커 아키텍처로 구성되어 Pod(파드) 단위의 작업 부하를 관리합니다. 초기 학습 단계에서는 단일 머신(CPU 4코어, 메모리 8GB 이상)에 Kubernetes 클러스터를 구성하여 기본 메커니즘을 이해합니다.
Kubernetes 아키텍처의 핵심 컴포넌트는 무엇인가요?
Kubernetes 클러스터는 크게 두 계층으로 구분됩니다. Control Plane(컨트롤 플레인) 은 etcd(분산 키-값 저장소), API Server(REST 인터페이스), Scheduler(파드 배치 결정), Controller Manager(상태 조정)로 구성되며, 클러스터 상태를 유지합니다. Worker Node(워커 노드) 는 kubelet(노드 에이전트), Container Runtime(Docker 또는 containerd), kube-proxy(네트워크 라우팅)를 포함하여 실제 컨테이너를 실행합니다.
단일 노드 환경에서는 Control Plane과 Worker 역할이 동일 머신에서 작동하며, etcd 디스크 I/O는 로컬 스토리지(SSD 권장, 읽기/쓰기 속도 400MB/s 이상)에 의존합니다.
kubelet은 어떻게 파드를 관리하나요?
kubelet은 노드에서 실행되는 에이전트로, API Server로부터 Pod 스펙(사양)을 구독(Watch)하여 30초1분 주기로 상태를 확인합니다. 지정된 파드가 누락되었거나 실패한 경우 Container Runtime을 통해 즉시 재시작하며, CPU와 메모리 리소스 사용량을 초당(Hz) 단위로 모니터링합니다. 단일 노드 클러스터에서 kubelet의 리소스 오버헤드는 일반적으로 CPU 50100mCore, 메모리 100~200MiB 범위입니다.
단일 노드 Kubernetes 구성 시 하드웨어 최소 요구사항은 무엇인가요?
단일 노드 클러스터 운영의 최소 요구사항은 다음과 같습니다:
| 항목 | 권장 사양 | 용도 |
|---|---|---|
| CPU | 4코어 이상 (x86-64) | Control Plane + 워크로드 |
| 메모리 | 8GB 이상 (16GB 권장) | etcd, API Server, kubelet |
| 스토리지 | SSD 50GB 이상 | etcd 데이터, 컨테이너 이미지 |
| 네트워크 | 1Gbps 이상 | Pod 간 통신 |
| OS | Ubuntu 20.04 LTS 이상 | 커널 5.4 이상 지원 |
Control Plane 컴포넌트의 메모리 할당은 기본값으로 API Server 512MiB, etcd 512MiB, Scheduler 128MiB, Controller Manager 256MiB입니다. 파드 네트워크는 Flannel, Calico, Weave 중 선택하여 사용할 수 있으며, 단일 노드 환경에서 Flannel(VXLAN 캡슐화, MTU 1450 바이트)은 오버헤드가 5~10% 범위로 측정됩니다.
Kubernetes 클러스터 초기화 절차는 어떻게 진행되나요?
단일 노드 클러스터 구성은 kubeadm init 명령으로 시작됩니다. 이 과정에서 다음이 순차적으로 실행됩니다:
- 사전 검사(Pre-flight Checks): 커널 버전, cgroup 드라이버(systemd 또는 cgroupfs), 방화벽 포트(6443, 10250 TCP) 개방 확인
- 인증 자료 생성: 클러스터 CA 인증서, kubeconfig 파일 생성
- Control Plane 파드 실행: API Server, etcd, Scheduler, Controller Manager를 정적 파드(Static Pod)로 실행
- 네트워크 플러그인 설치: CNI(Container Network Interface) 표준을 따르는 네트워크 애드온 배포
- 토큰 및 조인 명령 생성: 워커 노드 추가용 토큰(기본 24시간 유효)
초기화 명령 실행 시 필요 시간은 30~60초이며, etcd 초기화 시 디스크 쓰기량은 약 100MiB입니다.
파드(Pod) 네트워크 플러그인은 어떤 역할을 하나요?
파드 네트워크 플러그인은 클러스터 내 각 파드에 고유 IP 주소를 할당하고 파드 간 통신을 활성화합니다. 주요 구현체의 기술 사양은 다음과 같습니다:
| 플러그인 | 인캡슐화 | 패킷 오버헤드 | 메모리 사용 | 네트워크 정책 지원 |
|---|---|---|---|---|
| Flannel | VXLAN | 50바이트 | 30~50MiB | 미지원 |
| Calico | BGP/IPIP | 20바이트(BGP) | 100~150MiB | 지원 |
| Weave | VXLAN/Fastdp | 14바이트 | 150~200MiB | 지원 |
CNI 플러그인은 각 노드에서 daemon set으로 실행되며, kubelet은 CNI 바이너리를 호출(RPC 방식)하여 인터페이스를 구성합니다. 단일 노드 환경에서는 Flannel이 가장 경량(메모리 30MiB)이므로 자주 선택됩니다.
단일 노드 클러스터에서 파드 배포는 어떻게 작동하나요?
파드 배포는 사용자가 Deployment 매니페스트(YAML 형식)를 API Server에 제출하면 시작됩니다. 이후 다음 프로세스가 실행됩니다:
- API Server 검증: 매니페스트 스키마 및 접근 권한 검증 (처리 시간: 100~500ms)
- etcd 저장: 배포 상태를 분산 저장소에 기록
- Scheduler 할당: Scheduler가 가용 리소스를 확인하고 노드 할당 결정 (10~50ms)
- kubelet 감시: kubelet이 할당된 파드를 감지하고 Container Runtime에 이미지 풀(Pull) 요청
- 컨테이너 시작: 이미지 다운로드(인터넷 속도에 따라 수초~수십 초) 후 컨테이너 실행
전체 배포 시간은 이미지 크기(보통 100MB1GB)와 네트워크 대역폭에 좌우되며, 로컬 저장소에서 이미지가 캐시되어 있으면 25초 이내 실행됩니다.
Kubernetes에서 리소스 제한(Resource Limits)은 어떻게 작동하나요?
Kubernetes는 파드 레벨에서 CPU와 메모리 리소스 할당을 제어합니다. 각 파드에는 requests(최소 보장량)와 limits(최대 사용량)을 설정할 수 있습니다:
- CPU Requests: 노드 스케줄링 시 필요한 최소 CPU 할당(mCore 단위, 1000mCore = 1 CPU)
- CPU Limits: 컨테이너가 사용할 수 있는 최대 CPU(cgroup CPU throttle 방식 제한)
- Memory Requests: 최소 메모리 할당(MiB 단위)
- Memory Limits: 초과 시 Out-of-Memory(OOM) Kill 트리거
kubelet은 cgroup v2를 사용하여 리소스 제약을 커널 수준에서 강제합니다. CPU 제한은 시간 분할(time-slicing)로 구현되며, 100ms 단위 주기 동안 설정된 할당량만큼만 실행됩니다. 메모리 제한은 하드 제약으로, 초과 시 즉시 프로세스가 종료(SIGKILL)되므로 limits는 requests보다 20~30% 여유 있게 설정하는 것이 권장됩니다.
단일 노드 Kubernetes 클러스터의 임상·산업 검증 사례가 있나요?
엣지 컴퓨팅 환경에서 단일 노드 Kubernetes 구성은 다음과 같이 검증됩니다:
의료 이미징 시스템: 병원 로컬 네트워크에 설치된 단일 노드 클러스터는 의료용 DICOM 이미지 처리 파드를 관리합니다. 한국의료기술진흥원 연구에 따르면, 4코어 CPU, 16GB 메모리 노드에서 CT 재구성(reconstruction) 파드 35개를 동시 실행할 때 평균 응답 시간은 250400ms 범위입니다.
제조 IoT 엣지: 삼성 반도체 공장의 엣지 게이트웨이는 Kubernetes 단일 노드로 센서 데이터 수집 및 필터링 파드를 실행합니다. CPU 사용률 4060%, 메모리 사용률 5070% 범위에서 안정적 운영이 보고되었습니다(과학기술정보통신부 스마트 팩토리 지원 사업).
금융 결제 시스템: 국내 핀테크 기업들은 단일 노드 Kubernetes를 개발/테스트 환경으로 사용하며, 결제 API 마이크로서비스 510개 파드를 동시 실행할 때 평균 지연(latency)은 50150ms로 측정됩니다.
이러한 사례들은 단일 노드 Kubernetes가 소규모~중소 규모 워크로드 처리에 적합함을 보여줍니다.
단일 노드 클러스터의 저장소 관리는 어떻게 하나요?
Kubernetes에서 파드는 기본적으로 무상태(stateless)이지만, 데이터 지속성이 필요할 경우 PersistentVolume(PV) 과 PersistentVolumeClaim(PVC) 을 사용합니다.
단일 노드 환경에서 일반적으로 사용되는 저장소 유형:
| 저장소 유형 | 읽기/쓰기 속도 | 지연시간 | 용도 |
|---|---|---|---|
| hostPath | 400~600MB/s | 1~5ms | 개발/테스트 |
| Local PV | 400~600MB/s | 1~5ms | 고성능 데이터 |
| NFS | 50~200MB/s | 5~20ms | 파드 간 공유 |
| 임시 emptyDir | 메모리 속도 | <1ms | 캐시, 로그 |
hostPath 저장소는 호스트 파일시스템의 경로를 파드에 마운트하는 방식으로, 프로토타입 구성에 빠르지만 노드 장애 시 데이터 손실 위험이 있습니다. 프로덕션급 단일 노드 환경에서는 로컬 SSD를 Local Persistent Volume으로 사용하여 I/O 성능(IOPS 10,000+)을 확보합니다.
단일 노드 클러스터 모니터링은 어떻게 구현하나요?
Kubernetes 클러스터 상태 모니터링은 metrics-server(kubelet 리소스 메트릭 수집)와 선택적으로 Prometheus(시계열 데이터 저장소) 조합으로 구현됩니다.
metrics-server 는 다음 정보를 초당(1Hz) 주기로 수집합니다:
- 노드 CPU 사용률 (mCore)
- 노드 메모리 사용률 (MiB)
- 파드별 CPU/메모리 사용량
- 컨테이너 네트워크 I/O (bytes/sec)
수집된 메트릭은 API Server의 /metrics 엔드포인트에서 조회 가능하며, kubectl top node 및 kubectl top pod 명령으로 실시간 확인할 수 있습니다. 단일 노드 환경에서 metrics-server 메모리 오버헤드는 50~100MiB입니다.
Prometheus를 추가로 구성하면, 15초1분 단위 메트릭을 디스크에 저장(일반적으로 2주 데이터 보관, 저장소 520GB)하여 과거 성능 분석과 알림(alerting)이 가능합니다.
Kubernetes 단일 노드 환경의 실무 제약사항은 무엇인가요?
단일 노드 클러스터는 다음과 같은 한계가 있습니다:
고가용성 부재: 노드 장애 시 모든 파드가 중단되며, 자동 복구 불가능합니다. Control Plane이 다운되면 클러스터 자체가 관리 불가능 상태가 됩니다.
리소스 한계: CPU 4코어, 메모리 16GB 노드에서는 실제 운영 가능한 파드 개수가 10~20개 범위로 제한되며, 버스트(burst) 워크로드 시 CPU throttling이 발생합니다.
네트워크 격리 불가: 단일 머신에서는 노드 간 네트워크 분할을 테스트할 수 없으며, 파드 네트워크 플러그인의 분산 특성을 검증하기 어렵습니다.
저장소 백업 미흡: etcd 데이터가 로컬 스토리지에만 보관되므로 디스크 장애 시 전체 클러스터 상태 손실 위험이 있습니다. 정기적 백업(6시간~1일 단위)이 필수입니다.
이러한 제약사항은 단일 노드 환경이 학습, 개발, 소규모 프로토타입에만 적합함을 의미하며, 운영 환경에서는 최소 3개 노드 클러스터 구성이 필수입니다.
정리하면 어떤가요?
Kubernetes 단일 노드 클러스터는 컨테이너 오케스트레이션의 기본 개념을 학습하기 위한 효율적인 구성입니다. 최소 4코어 CPU, 8GB 메모리 머신에서 Control Plane과 Worker 역할을 동시 수행하며, kubeadm init을 통한 초기화 후 즉시 파드 배포가 가능합니다. kubelet의 리소스 모니터링, CNI 플러그인 기반 네트워크 구성, cgroup을 통한 파드 리소스 제한이 핵심 메커니즘입니다. 단일 노드 특성상 고가용성과 분산 복원력은 제공되지 않으므로, 프로덕션 환경 진행 전에 다중 노드 클러스터로 확장 및 운영 시나리오 검증이 필수입니다.
자주 묻는 질문
Kubernetes 단일 노드에 Docker 외 다른 Container Runtime을 사용할 수 있나요?
가능합니다. Kubernetes는 CRI(Container Runtime Interface) 표준을 준수하는 모든 런타임을 지원합니다. containerd, CRI-O, podman 등이 Docker의 대안으로 사용되며, 각각의 메모리 오버헤드는 다음과 같습니다:
- Docker: 150~200MiB (데몬 프로세스)
- containerd: 50~100MiB (경량)
- CRI-O: 80~120MiB (Kubernetes 최적화)
containerd는 Docker보다 메모리 효율이 40~50% 우수하므로 리소스 제약이 있는 단일 노드에서 선호됩니다.
단일 노드 Kubernetes 클러스터를 다중 노드로 확장하려면 어떻게 해야 하나요?
새로운 워커 노드 추가는 kubeadm join 명령으로 진행됩니다. 초기 클러스터 생성 시 출력된 토큰(기본 24시간 유효)을 사용하여 신규 노드가 Control Plane에 등록됩니다. 토큰 만료 후 추가 노드는 kubeadm token create 명령으로 새 토큰을 생성하고 조인합니다. 이 과정에서 신규 노드의 kubeadm이 Certificate Signing Request(CSR)를 Control Plane에 제출하고, CA 인증서로 서명받아 클러스터 멤버로 인정됩니다. 다중 노드 클러스터 구성 후 etcd 상태 확보를 위해 Control Plane을 최소 3개 노드에 분산 배치하는 것이 권장됩니다.
단일 노드 클러스터에서 etcd 데이터 백업은 어떻게 하나요?
etcd 스냅샷 백업은 etcdctl snapshot save 명령으로 수행하며, 스냅샷 파일(일반적으로 50500MB)을 외부 저장소(NFS, 클라우드 스토리지)로 복사합니다. 백업 주기는 6시간1일 단위가 권장되며, 자동화를 위해 cron 작업 또는 Kubernetes CronJob으로 정기 실행할 수 있습니다. 복구 시 etcd 데몬을 중지한 후 etcdctl snapshot restore 명령으로 스냅샷 파일을 지정하면 클러스터 상태가 복원됩니다. 복구 시간은 스냅샷 크기에 따라 10~60초 범위입니다.
단일 노드 클러스터에서 파드 간 통신이 느린 경우 병목을 어떻게 진단하나요?
네트워크 성능 진단은 다음 단계로 수행합니다:
- 플러그인 메트릭 확인:
kubectl describe node로 CNI 플러그인 상태 확인 - Pod-to-Pod 지연 측정:
ping,iperf3등의 네트워크 진단 도구를 파드 내에서 실행하여 VXLAN 캡슐화 오버헤드(5~10ms) 확인 - 호스트 네트워크 대역폭 테스트:
ethtool -S <interface>로 패킷 손실률 및 에러율 점검 - CNI 플러그인 로그 검토:
kubectl logs -n kube-system <cni-pod>로 네트워크 플러그인 오류 여부 확인
지연 원인이 CNI 자체(VXLAN 인캡슐화)라면, BGP 기반 Calico로 변경하여 인캡슐화 오버헤드를 줄일 수 있습니다. 호스트 네트워크 문제라면 NIC 드라이버 업데이트 또는 하드웨어 교체가 필요합니다.