[Kubernetes] AI·빅데이터 직무를 위한 쿠버네티스 개념 이해 (1)

Kubernetes Cluster Architecture (출처. Kubernetes.io)

“로컬에서는 잘 되는데 서버에서만 안 돼요…”
“환경이 달라서 재현이 안 됩니다…”

 

AI/빅데이터 업무를 하다 보면 한 번쯤 들어봤거나, 겪어본 상황입니다.
이런 문제를 줄이기 위해 등장한 게 컨테이너이고, 그 컨테이너를 여러 서버에 알아서 잘 굴려주는 시스템이 바로 쿠버네티스(Kubernetes) 입니다.

이 글은 AI/빅데이터 직무를 하는 사람 관점에서,
쿠버네티스가 뭔지, 왜 쓰는지, 어떤 개념들만 알고 있으면 되는지 정리한 1탄(개념편)입니다.
(실습·구체적인 명령어는 2탄 이후에서 다룰 예정)

1. 왜 쿠버네티스를 쓸까?

클라우드가 보편화되면서 서비스 구조가 이렇게 바뀌었죠.

• 하나의 덩치 큰 서버 → 여러 개의 작은 서비스(마이크로서비스)
• 한두 대 서버 → 수십·수백 대 서버
• 수동 배포 → 자동 배포, 자동 복구, 자동 확장

이때 꼭 필요해진 게

• 환경을 통째로 묶어서 어디서나 똑같이 돌릴 수 있는 방식(컨테이너)
• 그 컨테이너들을 여러 서버에 자동으로 배치·관리해주는 시스템(쿠버네티스)

 

쿠버네티스 = 여러 대의 서버에 컨테이너를 알아서 배치·운영해주는 오케스트레이션 시스템

 

 

우리는 이 이미지를 이런 조건으로 몇 개 돌려줘만 선언적으로 써주고,
어디에 올릴지 / 죽으면 다시 살릴지 / 몇 개를 유지할지 같은 운영은
쿠버네티스가 맡는 구조입니다.

 

2. 컨테이너부터 짚고 가기: Docker vs 쿠버네티스

쿠버네티스를 이해하려면 먼저 컨테이너 개념이 필요합니다.

2-1. 컨테이너란?

• 애플리케이션 + 라이브러리 + 런타임 환경을 하나의 단위로 묶은 것
• 어디에 배포해도 동일한 환경에서 실행되도록 만들어주는 기술
• 가장 대표적인 도구가 Docker

AI/빅데이터 관점에서 보면

• 특정 버전의 Python, PyTorch, CUDA, 의존 라이브러리 등을
  하나의 이미지(Image) 로 만들어두면,
• 로컬·온프레미스·클라우드·쿠버네티스 어디서든 같은 환경으로 실행 가능

2-2. 그럼 Docker만 쓰면 안 되나?

Docker만으로도 컨테이너를 실행할 수는 있습니다.

1. 컨테이너가 많아지면
   • 어느 서버에서 뭐가 도는지 관리가 어렵고
   • 죽은 컨테이너를 다시 띄우는 것도 사람이 해야 하고
   • 배포/롤백/오토스케일링을 직접 구현해야 합니다.
2. 여러 서버(노드)를 하나의 자원 풀처럼 효율적으로 쓰기도 힘들어요.

그래서 등장한 게 쿠버네티스입니다.

 

Docker = 컨테이너를 만들고 실행하는 도구

Kubernetes = 컨테이너들을 여러 서버에 알아서 배치·관리하는 플랫폼

 

3. 쿠버네티스 기본 개념 한 번에 정리

쿠버네티스를 공부하다 보면 처음에 용어 폭탄을 맞는데,
AI/빅데이터 관점에서 우선 이 정도만 잡고 가면 충분합니다.

• Cluster / Node
• Pod
• Deployment
• Service
• Namespace, ConfigMap, Secret

하나씩 짧게 볼게요.

3-1. 클러스터(Cluster)와 노드(Node)

• 클러스터(Cluster)
  • 쿠버네티스가 관리하는 전체 서버 묶음
  • 보통 Control Plane(마스터 역할) + 여러 워커 노드로 구성
• 노드(Node)
  • 컨테이너가 실제로 실행되는 개별 서버
  • 물리 서버일 수도 있고, 가상 머신일 수도 있습니다.

“여러 대 서버를 하나의 큰 컴퓨팅 풀처럼 묶어놓은 게 클러스터,
그 안의 개별 서버가 노드” 라고 이해하면 편합니다.

3-2. 파드(Pod)

• 쿠버네티스에서 가장 작은 배포 단위
• 1개 이상의 컨테이너를 묶어놓은 것
• 같은 Pod 안의 컨테이너들은
  1. 같은 IP 주소
  2. 같은 저장공간(볼륨)
  3. 같은 네트워크 네임스페이스를 공유

실무에서는 대부분 컨테이너 1개 = Pod 1개로 구성하는 경우가 많습니다.

3-3. Deployment

Deployment는 이렇게 이해하면 됩니다.

“이 이미지를 항상 N개, 이런 설정으로 돌려줘.
죽으면 다시 살리고, 새 버전으로 부드럽게 업데이트해줘.”

 

예를 들어

replicas: 3

라고 적혀 있으면, 쿠버네티스는 항상 Pod 3개를 유지하려고 합니다.

• Pod 하나가 죽으면 자동으로 새 Pod를 띄움
• 이미지 태그를 새 버전으로 바꾸면 롤링 업데이트(조금씩 새로 띄우면서 교체)

AI/빅데이터 직무 예시로 보면

• model-serving:1.0.0 이미지를 서버 3개에서 돌리고 있다가
  1.1.0으로 올리고 싶을 때, 다운타임 없이 롤링 업데이트 가능

3-4. Service

Pod는 상태에 따라 쉽게 생기고 사라지기 때문에

• IP가 자주 바뀝니다.
• 특정 Pod의 IP를 직접 호출하는 방식은 위험합니다.

그래서 Service라는 개념이 있습니다.

• 여러 Pod 앞단에 있는 고정된 엔드포인트
• 뒤에 붙은 여러 Pod로 로드 밸런싱

예시:

• model-service라는 Service 뒤에 모델 서버 Pod 3개가 붙어 있다고 하면
  • 클라이언트는 항상 model-service만 바라보고 호출
  • 실제 트래픽 분산은 Service가 알아서 Pod들로 라우팅

3-5. Namespace, ConfigMap, Secret

• Namespace
  • 하나의 클러스터를 논리적으로 나누는 공간
  • 예) dev, stage, prod, 혹은 팀/프로젝트 단위로 나누기
  • 권한·리소스 제한·이름 충돌 방지에 활용
• ConfigMap
  • 환경변수, 설정 값 등을 이미지와 분리해서 관리
  • 코드/이미지를 바꾸지 않고도 설정만 바꿀 수 있음
• Secret
  • DB 비밀번호, API 토큰 등 민감 정보 관리용
  • ConfigMap과 비슷하지만 민감한 데이터용이라는 점이 다름

 

4. AI·빅데이터 업무에서 쿠버네티스를 쓰면 좋은 이유

웹 서비스 회사만의 도구 같지만,
실제로는 AI/데이터 쪽에서도 꽤 잘 맞는 플랫폼입니다.

4-1. 실험 환경 통일 & 재현성

• 모델 학습 코드, 피처 엔지니어링, ETL 파이프라인을
  전부 컨테이너 이미지로 만들어두면
• 팀원마다 로컬 환경이 달라도,
  동일한 컨테이너 이미지 기준으로 실험을 재현할 수 있습니다.
• 연구용 코드 → 서비스용 코드 전환 시에도
  환경 차이로 고생하는 시간이 확 줄어듭니다.

4-2. 배치 작업 & 파이프라인 구성

쿠버네티스에는 Job / CronJob 리소스가 있습니다.

• Job
  • 한 번 돌고 끝나는 작업(예: 하루치 데이터 전처리)
• CronJob
  • 특정 주기마다 실행되는 작업(예: 매일 새벽 3시 ETL, 주간 리포트 생성 등)

Airflow, Argo Workflows 같은 워크플로우 도구도
뒤에서 쿠버네티스를 활용해서 작업을 스케줄링하는 구조를 많이 사용합니다.

4-3. 확장성과 자원 관리

• 평소에는 모델 서버를 2개만 돌리다가,
  트래픽이 몰리면 자동으로 10개까지 늘리고,
• 밤에는 학습 Job을 많이 돌리고, 낮에는 API 서버 위주로 돌리는 식으로
  자원을 유연하게 할당할 수 있습니다.

쿠버네티스의 오토스케일링(HPA)과 GPU 노드 설정 등을 활용하면

• GPU 학습 Job들은 GPU 노드에서만 돌리게 하고,
• 경량 API 서버는 CPU 노드 위주로 돌리게 하는 식의 자원 최적화도 가능합니다.

 

5. 쿠버네티스 아키텍처: Control Plane과 워커 노드

조금만 더 깊게 보면, 쿠버네티스 클러스터는 크게 두 부분으로 나뉩니다.

• Control Plane (마스터 역할)
• 워커 노드(실제 컨테이너가 돌아가는 서버)

5-1. Control Plane(컨트롤 플레인)의 역할

주요 컴포넌트만 간단히 보면

• API Server
  • kubectl 명령이나, 다른 서비스에서 오는 요청을 받는 입구
  • 클러스터의 모든 요청이 이쪽으로 모입니다.
• etcd
  • 쿠버네티스의 상태 정보를 저장하는 키-값 저장소
  • 원하는 상태(Desired State)를 여기에 기록
• Scheduler
  • 새 Pod를 어느 노드에 올릴까? 결정
  • 노드의 자원 상태, 제약 조건 등을 고려해서 배치
• Controller Manager
  • 실제 상태 vs 원하는 상태를 계속 비교·감시
  • 예를 들어
    1. Deployment에 replicas: 3 이라고 적혀 있는데,
    2. 실제 Pod가 2개만 살아 있다면,
    3. Pod를 하나 더 만들어서 다시 3개로 맞춰줌

한 줄 요약

사용자가 선언한 상태와 실제 상태를 맞춰주기 위해
계속 상태를 감시하고 조정하는 두뇌 역할이 Control Plane이다.

 

5-2. 워커 노드에서 벌어지는 일

워커 노드에는 보통 이런 것들이 있습니다.

• kubelet
  • Control Plane으로부터 이 노드에 이런 Pod를 올려라라는 명령을 받고,
  • 컨테이너 런타임(Docker, containerd 등)에 실제 컨테이너 실행/정지를 요청
• kube-proxy
  • Service와 Pod 사이의 네트워크 트래픽을 라우팅
  • 로드 밸런싱, IP 테이블 설정 등에 관여

AI/빅데이터 입장에서 기억할 포인트는 단순합니다.

실제로 모델 서버, ETL Job, 배치 스크립트가
컨테이너 형태로 돌아가는 곳은 모두 워커 노드이다.

 

6. 한 번에 보는 쿠버네티스 워크플로우

이제 YAML 하나 적용했을 때, 내부에서 무슨 일이 일어나는지를 정리해보겠습니다.

1. 우리가 kubectl apply -f deployment.yaml을 실행한다.
2. API Server가 요청을 받고,
   Deployment라는 리소스 정의를 etcd에 저장한다.
   → “이 애플리케이션은 replicas=3으로 돌아야 한다”는 원하는 상태 기록
3. Scheduler가 “새로 만들어야 할 Pod들을 어느 노드에 올릴지”를 결정한다.
4. 선택된 각 노드의 kubelet이 컨테이너 런타임에
   • 해당 이미지 Pull
   • 컨테이너 실행 요청
5. Pod가 정상적으로 Running 상태가 되면,
   • 앞단에 선언된 Service가 해당 Pod들의 IP를 대상으로 로드 밸런싱을 수행한다.
6. 만약 Pod가 하나 죽으면?
   • Controller가 “replicas=3인데, 지금 2개만 있네?”라고 감지하고
   • 새 Pod를 하나 더 띄워서 다시 3개를 유지합니다.

AI/빅데이터 관점에서 요약하면

“나는 YAML에 모델 서버/배치 작업 스펙만 선언해두고,
나머지 인프라 운영은 쿠버네티스가 상태를 보면서 알아서 맞춘다.”

 

7. 로컬에서 연습해보기: Minikube / kind / k3s 간단 비교

실제 회사 클러스터에 바로 들어가서 실습하기 부담스럽다면,
로컬에 작은 클러스터 하나 올려서 연습하는 게 좋습니다.

대표적인 선택지는 아래 세가지입니다. Minikube를 추천합니다.

7-1. Minikube

• 가장 널리 알려진 로컬용 쿠버네티스
• 내 PC에 VM 또는 Docker 위에 클러스터를 하나 띄워줌
• 학습·테스트용으로 많이 사용

7-2. kind (Kubernetes in Docker)

• Docker 컨테이너 위에 쿠버네티스 클러스터를 올리는 방식
• CI 환경(예: GitHub Actions)에서 테스트용 클러스터 만들 때 자주 사용
• 로컬에서도 가볍게 여러 클러스터를 띄워볼 때 쓸 수 있음

7-3. k3s

• Rancher에서 만든 “경량 쿠버네티스 배포판”
• 리소스 적은 환경, 엣지/IoT, 집/연구실 작은 서버에 올리기 적합
• 실제 운영에 가까운 느낌으로 소규모 MLOps 환경을 구성해보고 싶을 때 좋음

 

8. 실제로 쓰면서 자주 겪는 삽질 포인트

실제로 쿠버네티스를 접하면, 개념보다 에러 처리로 고생할 때가 많습니다.
대표적인 것들만 몇 가지 짚어둘게요.

8-1. ImagePull 에러

• 에러 메시지 예
  • ImagePullBackOff
  • ErrImagePull
• 주 원인
  • 이미지 이름/태그 오타
  • Private Registry 인증/권한 문제
  • 이미지를 빌드만 하고 레지스트리에 Push 안 한 경우

간단 체크 포인트

• 로컬에서 docker pull <이미지> 가 되는지 먼저 확인
• Private Registry라면
  • Secret 생성 → imagePullSecrets 설정 여부 확인

8-2. Service / Ingress / 포트 문제

• Pod는 잘 떠 있는데 외부에서 접속이 안 되는 상황에서 자주 발생

확인할 것

• Service 타입(NodePort / LoadBalancer / ClusterIP) 설정
• Ingress 리소스의 host, path, backend Service 이름/포트
• Ingress Controller(nginx-ingress, traefik 등)가 실제로 설치되어 있는지

쿠버네티스를 처음 쓸 때 많이 헷갈리는 부분은

“Ingress 리소스만 만들었다고 끝이 아니라,
그걸 실제로 처리해줄 Ingress Controller가 클러스터에 설치되어 있어야 한다” 는 점.

 

8-3. 리소스 요청/제한 설정

resources.requests, resources.limits를 대충 두면

• 어떤 Pod는 CPU/메모리를 과도하게 먹고
• 어떤 Pod는 너무 적게 할당돼서 성능이 안 나오는 문제 발생

AI/빅데이터 작업에서는

• 학습 Job, 대용량 ETL Job은 메모리/CPU/GPU 리소스 요구량이 크기 때문에
• 각 Job/Pod별로 리소스 설정을 명시적으로 적어두는 게 좋습니다.

 

9. 앞으로 어떻게 공부를 이어가면 좋을까?

1탄에서는 개념 위주로만 정리했으니,
다음 단계로는 이런 키워드들을 자연스럽게 마주하게 되실 겁니다.

• Helm
  • 여러 YAML을 템플릿화해서 관리하는 “쿠버네티스용 패키지 매니저”
• Argo CD / Flux
  • GitOps 도구 (Git에 저장된 선언 상태를 기준으로 클러스터를 자동 관리)
• Argo Workflows / Airflow
  • 데이터/ML 파이프라인 오케스트레이션
• Kubeflow, KServe, Seldon, MLflow + K8s
  • 쿠버네티스 기반 MLOps 플랫폼

 

AI/빅데이터 직무에서 쿠버네티스를 어느 정도까지 알아야 할까?

개인적으로는 이렇게 3단계로 나눌 수 있습니다.

• Level 1 – 사용자 관점
  • Pod / Deployment / Service 개념 이해
  • kubectl로 배포, 로그 확인, 스케일 조절 가능
  • 간단한 모델 서버·ETL Job을 YAML 수정해서 배포할 수 있는 수준
• Level 2 – 실무 활용 관점
  • Namespace, ConfigMap, Secret, Ingress 활용
  • Helm Chart로 공통 템플릿 만들어서 팀과 공유
  • 오토스케일링, 리소스 최적화 개념 이해
• Level 3 – 플랫폼/인프라 관점
  • 클러스터 구성, 네트워크/스토리지, 모니터링/로그 수집까지
  • DevOps/플랫폼 엔지니어 역할에 가까운 영역이지만,
    아키텍트/리더라면 개념 정도는 알고 있으면 좋음