[Infra] Kubernetes 기초

About this offer

Kubernetes 기초 개념과 핵심 리소스 총정리 도커를 접하게 되며 생각했다. *"도커로 컨테이너 띄우는 거 엄청 편한데, 굳이 왜 쿠버네티스(k8s)까지 배워서 써야 하지?"* 하지만 서비스 규모가 커져서 컨테이너가 10개, 50개, 100개로 늘어나고 서버가 여러 대로 쪼개지는 순간 현실적인 지옥이 시작된다. 어느 서버에 여유 공간(CPU/메모리)이 있는지 일일이 확인해서 띄워야 하고, 새벽에 특정 서버의 컨테이너가 죽으면 자다 깨서 수동으로 재기동해야 하며, 트래픽이 몰릴 때마다 수동으로 컨테이너를 늘리고 로드밸런서에 붙여줘야 한다. 이 모든 반복적이고 귀찮은 운영 작업을 "자동화된 시스템" 에 맡기기 위해 탄생한 것이 바로 쿠버네티스(Kubernetes) 다. 쿠버네티스의 기본 아키텍처와 실무에서 다루는 핵심 리소스들을 정리해 본다. 1. 클러스터 아키텍처: 두뇌와 일꾼 쿠버네티스는 여러 대의 물리/가상 서버를 묶어 마치 "하나의 거대한 컴퓨터" 처럼 동작하게 만든다. 컨트롤 플레인 : 클러스터의 관리자이자 두뇌. 직접 앱을 실행하지 않고, 명령을 받고 워커 노드들을 감시하고 스케줄링한다. (AWS EKS를 쓰면 이 부분을 AWS가 돈 받고 완전 관리해 준다.) 워커 노드 : 실제 컨테이너들이 배포되어 사용자 트래픽을 처리하는 일꾼 서버. (AWS EC2 인스턴스) 2. 쿠버네티스의 핵심 : "선언적 상태" 쿠버네티스를 이해하는 가장 중요한 핵심은 "선언적" 이라는 말이다. 명령형 (과거 방식) : *"지금 당장 컨테이너 1개 더 띄워라."* 선언형 (쿠버네티스 방식) : *"내가 원하는 상태는 웹 서버 파드가 항상 3개 유지되는 것이다."* YAML 파일로 "원하는 상태"를 선언해 두면, 쿠버네티스는 24시간 루프를 돌며 "현재 상태"가 "원하는 상태"와 일치하는지 감시 한다. 서버가 다운되거나 컨테이너가 에러로 꺼져서 파드가 2개로 줄어들면, 관리자가 개입하지 않아도 쿠버네티스가 즉시 빈 서버를 찾아 새 파드를 띄워 3개로 맞춘다. 이것이 바로 셀프 힐링 이다. 3. 실무 쿠버네티스 핵심 리소스 맵 (5대 분류) 쿠버네티스는 모든 대상을 리소스 라는 단위로 다룬다. 자주 사용하는 리소스들은 목적에 따라 크게 5가지로 나뉜다. [쿠버네티스 리소스 생태계] ├── 1. 워크로드 (Workload) : 컨테이너를 어떤 형태로 띄울 건지? ├── 2. 설정 & 보안 (Config) : 환경변수와 비밀번호 분리 ├── 3. 스토리지 (Storage) : 영구 데이터 보존 ├── 4. 네트워크 (Network) : 내부 통신 및 외부 노출 └── 5. 운영 & 격리 (Governance) : 구획 분리 및 권한 1 워크로드 (Workload) 리소스 설명 주요 사용처 Pod 쿠버네티스의 가장 작은 배포 단위 . 1개 이상의 컨테이너를 감싼 캡슐. 직접 띄우기보다는 상위 리소스에 의해 관리됨 Deployment 파드의 수량 유지와 무중단 롤링 업데이트 를 보장하는 관리자. 일반적인 백엔드 API, 프론트엔드 웹 서버 (Stateless) StatefulSet 파드의 고유 이름(순번)과 고유 디스크 를 영구 보장하는 관리자. DB(MySQL, PostgreSQL), Kafka, Redis (Stateful) DaemonSet "모든 노드에 무조건 1개씩 띄워라!" Fluent Bit(로그 수집), Prometheus Node Exporter Job / CronJob 계속 켜두는 게 아니라 "한 번 실행되고 끝나면 종료" 되는 작업. DB 마이그레이션, 일일 정산 배치 스크립트 2 설정 및 보안 (Config & Secret) 도커 이미지 안에 DB 비밀번호나 설정값을 하드코딩하지 않고 외부에 주입하기 위해 사용한다. ConfigMap : 일반 텍스트 설정값을 저장하는 상자 (포트 번호, 프로필 dev / prd , 로그 레벨 등) Secret : Base64로 인코딩된 민감한 값을 저장하는 상자 (DB 접속 비밀번호, JWT 시크릿 키, 인증서 등) 3 스토리지 (Storage) 파드는 기본적으로 일회성이라 파드가 죽으면 내부 파일이 모두 증발한다. 데이터를 영구 저장하려면 외부 스토리지를 붙여야 한다. PV (Persistent Volume) : 실제 연결할 물리/클라우드 디스크 (e.g. AWS EBS 100GB 볼륨) PVC (Persistent Volume Claim) : 개발자가 파드에 디스크를 달기 위해 제출하는 "스토리지 신청서" (*"나 20GB SSD 볼륨 줘"*) StorageClass : 개발자가 PVC를 제출했을 때, 백그라운드에서 클라우드(AWS EBS 등)에 가서 디스크를 동적으로 자동 생성해 주는 공장 4 네트워크 (Network) Service : 파드는 죽었다 살아나면 IP가 매번 바뀐다. 서비스는 파드들 앞단에 고정 가상 IP(단일 진입점) 를 제공하고 로드밸런싱을 수행한다. (ClusterIP, NodePort, LoadBalancer) Ingress : 클러스터 외부(인터넷)에서 들어오는 HTTP/HTTPS 트래픽을 도메인이나 URL 경로에 따라 적절한 서비스로 연결해 주는 L7 관문. NetworkPolicy : 쿠버네티스 내부 방화벽. 특정 파드 간의 트래픽만 허용하고 나머지는 차단. 5 운영 및 격리 (Governance) Namespace : 거대한 클러스터를 논리적인 '가상의 방' 으로 나누는 단위 ( dev , prod , monitoring , kube-system ) HPA (Horizontal Pod Autoscaler) : CPU나 메모리 부하에 따라 파드 개수를 자동으로 늘리고 줄이는 오토스케일러. RBAC (Role, RoleBinding, ServiceAccount) : 누가 어떤 리소스에 접근할 수 있는지 제어하는 권한 체계. 4. 확장 리소스: CRD (Custom Resource Definition) 쿠버네티스의 진정한 강력함은 확장성 에 있다. 기본 제공되는 Deployment나 Service 외에도, 개발자가 새로운 리소스 문법을 직접 정의해서 클러스터에 추가할 수 있는데 이를 CRD 라고 부른다. 실무에서 자주 쓰는 KEDA의 ScaledObject 나 Karpenter의 NodePool , Cert-Manager의 Certificate 등이 모두 이 CRD를 통해 쿠버네티스 생태계에 플러그인처럼 붙여서 사용하는 확장 리소스들이다. 5. 마치며 정리하자면: 쿠버네티스는 수많은 컨테이너의 배치, 확장, 장애 복구를 사람 대신 24시간 수행해 주는 컨테이너 오케스트레이션 시스템 이다. 시스템은 두뇌(Control Plane) 와 일꾼(Worker Node) 으로 나뉘며, EKS는 두뇌 영역을 완전 관리형으로 제공한다. 명령이 아니라 원하는 상태(Desired State) 를 선언하면 시스템이 스스로 상태를 맞추는 선언적 방식 으로 동작한다. 실무에서는 워크로드(Deployment/StatefulSet), 설정(ConfigMap/Secret), 스토리지(PVC), 네트워크(Service/Ingress) 리소스를 조합하여 완전한 애플리케이션 플랫폼을 구축한다. 이상.