Kubernetes 개념 및 이론 가이드

Kubernetes 기본 개념

컨테이너 오케스트레이션의 필요성

• 수많은 컨테이너를 수동 관리하는 것은 불가능함
• Kubernetes는 컨테이너들을 자동으로 배치하고 관리하는 플랫폼임
• 마치 오케스트라 지휘자처럼 수백 개의 컨테이너를 조율함

리소스 계층 구조

Namespace (논리적 격리)
├── Pod (컨테이너 실행 단위)
├── 컨트롤러 (Pod 관리)
│   ├── Job (일회성)
│   ├── Deployment (무상태)
│   └── StatefulSet (상태유지)
├── Service (네트워크 추상화)
└── 설정 리소스 (Secret, ConfigMap, PVC)

핵심 구성 요소

리소스	역할	특징
Namespace	논리적 분리	개발/테스트/운영 환경 격리 리소스 할당량 관리
Pod	최소 배포 단위	1개 이상의 컨테이너 포함 동일한 네트워크와 스토리지 공유
Deployment	무상태 앱 관리	웹서버, API 서버 등 롤링 업데이트 지원
Job	일회성 작업	배치 처리, ETL 작업 완료 시 자동 종료
Service	네트워크 접근점	안정적인 IP와 DNS 제공 로드밸런싱 기능
Secret	민감정보 저장	패스워드, 인증서 관리 Base64 인코딩 저장

핵심 동작 원리

선언적 설정

• “이런 상태가 되어야 함”을 선언하면 Kubernetes가 실현함
• 명령형이 아닌 원하는 상태를 기술하는 방식임. ex) 자동차 크루즈 컨트롤과 유사한 개념

컨트롤러 패턴

• 현재 상태와 원하는 상태를 지속적으로 비교함
• 차이가 있으면 조정 작업을 수행함
• 이것이 Kubernetes의 자가 치유 능력의 근간임

라벨과 셀렉터

• 하드코딩된 참조 대신 유연한 쿼리 방식 사용함
• app=web 라벨을 가진 모든 Pod에 트래픽 전달함
• 새로운 Pod가 같은 라벨을 가지면 자동으로 포함됨

클러스터 아키텍처

구성 요소별 역할

컨트롤 플레인

구성 요소	역할
API Server	모든 통신의 중앙 허브 REST API 제공
etcd	클러스터 상태 정보 저장 분산 키-값 저장소
Scheduler	Pod 배치 결정 리소스 요구사항 고려
Controller Manager	컨트롤러 실행 관리 원하는 상태 유지

워커 노드

구성 요소	역할
kubelet	노드의 대리인 역할 Pod 생명주기 관리
kube-proxy	네트워크 트래픽 라우팅 서비스 추상화 구현
Container Runtime	실제 컨테이너 실행 CRI 인터페이스 구현

시스템 준비 요구사항

Swap 비활성화

• 메모리 관리의 예측 가능성을 위해 필수임
• Pod 메모리 사용량을 정확히 예측할 수 있음
• 성능 저하 방지를 위해서도 중요함

네트워크 설정

• br_netfilter: 브리지 트래픽이 iptables 규칙을 거치도록 함
• ip_forward: Pod 간 통신을 위한 패킷 포워딩 활성화함
• 이 설정들이 없으면 네트워크 정책과 서비스가 동작하지 않음

  kubeadm 1.30부터는 br_netfilter 모듈 확인을 하지 않으므로 수동 설정 필요함

Container Runtime 설정

• SystemdCgroup 활성화로 일관된 cgroup 관리함
• systemd와 호환되는 자원 제어 방식 사용함

Pod 네트워킹

CIDR과 IP 할당

• Pod 네트워크 CIDR은 클러스터 내 모든 Pod의 IP 주소 공간임
• 10.244.0.0/16은 65,536개의 IP 주소를 제공함
• 각 노드에 서브넷으로 분할되어 할당됨

CNI 플러그인 비교

플러그인	특징	장점	단점
Flannel	VXLAN 오버레이	간단한 설정 안정적인 동작	고급 정책 기능 없음 네트워크 오버헤드
Calico	BGP 라우팅	고성능 세밀한 정책	복잡한 설정 네트워크 지식 필요
Weave	자동 검색	암호화 지원 간편한 설치	성능 오버헤드 메모리 사용량 높음

Service와 네트워크 접근

Service 타입별 특징

타입	접근 범위	사용 시나리오	제한사항
ClusterIP	클러스터 내부만	마이크로서비스 간 통신 내부 API 호출	외부 접근 불가 포트포워딩 필요
NodePort	노드IP:포트	개발/테스트 환경 간단한 외부 노출	포트 관리 복잡 보안 고려 필요
LoadBalancer	외부 로드밸런서	운영 환경 서비스 노출 고가용성 필요	클라우드 환경 필요 비용 발생

ClusterIP 포트포워딩 활용: kubectl port-forward

• ClusterIP 타입의 서비스나 Pod에 로컬 포트를 통해 직접 접근할 수 있도록 포트 터널링을 설정하는 명령어
• 외부에 노출되지 않은 서비스도 API 서버를 통해 간접적으로 접근 가능
• Ingress나 NodePort 없이도 간단히 테스트 가능하며, 로컬 환경에서 유용
• 주로 개발·디버깅 용도로 사용하며, 운영 환경에서는 권장되지 않음

# ClusterIP 서비스에 포트포워딩 (예: MinIO 웹 콘솔 접근)
# http://localhost:9000 으로 MinIO 접근 가능
kubectl port-forward svc/minio 9000:9000 -n minio

# 특정 Pod에 직접 포트포워딩 (예: 내부 웹 서버 디버깅)
# http://localhost:8080 으로 Pod의 80번 포트에 접근
kubectl port-forward pod/my-pod 8080:80 -n default

라벨 셀렉터 동작

• Service는 라벨 쿼리로 대상 Pod를 동적 선택함
• Pod 생성/삭제 시 자동으로 트래픽 라우팅 업데이트됨
• 하드코딩된 IP 주소 대신 유연한 연결 방식 제공함

스토리지 관리

볼륨 생명주기

• Pod 파일시스템은 기본적으로 임시적임
• PV(PersistentVolume)는 추상화된 실제 스토리지 리소스
• PVC(PersistentVolumeClaim)는 스토리지 요청서
• 바인딩 과정을 통해 Pod가 영구 스토리지에 접근함

스토리지 타입 비교

타입	특징	사용 사례	성능
HostPath	노드 로컬 디렉토리 단일 노드 제한	개발/테스트 로깅 에이전트	빠름
NFS	네트워크 파일시스템 다중 노드 공유	공유 스토리지 레거시 시스템	보통
CSI	클라우드 스토리지 동적 프로비저닝	프로덕션 확장성 필요	클라우드 의존

StorageClass와 동적 프로비저닝

• StorageClass는 스토리지 등급을 정의함
• 동적 프로비저닝으로 PVC 생성 시 자동 PV 생성함
• StorageClass가 없으면 수동 PV 생성이 필요함

Secret과 보안

Secret 특징

• Base64 인코딩으로 저장됨 (암호화 아님)
• 실제 보안을 위해서는 etcd 암호화 필요함
• 환경변수와 볼륨 마운트 두 가지 사용 방식 존재함

Secret 사용 방식 비교

방식	설명	보안 수준	사용 사례
환경변수	Pod 환경변수로 주입 프로세스 목록에 노출 위험	낮음	간단한 설정 비중요 정보
볼륨 마운트	파일로 마운트 파일 권한 제어 가능	높음	민감한 데이터 인증서 파일
imagePullSecrets	이미지 pull 인증 Pod 수준에서 참조	중간	Private Registry 컨테이너 이미지

보안 모범 사례

• 최소 권한 원칙으로 네임스페이스별 Secret 생성함
• 강력한 패스워드와 정기 로테이션을 실시함
• RBAC으로 Secret 접근 권한을 제한함

리소스 정리 전략

안전한 정리 순서

1. 애플리케이션 레벨: Pod, Deployment, Job
2. 네트워크 레벨: Service, Ingress
3. 설정 레벨: ConfigMap, Secret
4. 스토리지 레벨: PVC, PV
5. 네임스페이스: 마지막에 전체 삭제

정리 시 고려사항

• 의존성 관계를 파악하여 순서대로 진행함
• 중요한 데이터는 반드시 백업 후 삭제함
• 단계적 삭제로 예상치 못한 문제를 방지함