Kube Overview

쿠버네티스는 컨테이너로 실행되는 애플리케이션을 자동으로 배포/확장/복구/관리 해주는 플랫폼

1️⃣ 쿠버네티스(Kubernetes)는 왜 필요한가?

기존 Docker 만 사용할 때는 어떤 문제점이 있는가

  • 컨테이너가 죽으면 -> 직접 재시작

  • 트래픽 증가 -> 직접 컨테이너 늘림

  • 서버 여러 대면 -> 어디에 띄웠는지 기억해야 함

  • 장애 발생 시 -> 사람이 직접 조치

👉 운영이 힘들다

Kubenetes 가 해결하는 것

  • 컨테이너 자동 재시작(셀프 힐링)

  • 서버 여러 대에 자동 분산 배치(로드 벨런싱)

  • 트래픽에 따라 자동 스케일링(스케일링)

  • 선언만 하면 상태를 맞춰줌(Desired State)

2️⃣ 반드시 알아야 할 핵심 개념 & 용어 (⭐⭐⭐ 중요)

Pod (가장 중요한 개념)

| Pod = 쿠버네티스에서 실행되는 최소 단위

  • 하나 이상의 컨테이너 묶음

  • 같은 네트워크(IP), 같은 스토리지 볼륨 공유

  • 보통 1 Pod = 1 컨테이너가 일반적

핵심 포인트

  • 컨테이너를 직접 관리 ❌

  • Pod을 관리 ⭕

Node

| Node = Pod 가 실제로 실행되는 서버

  • 물리 서버 or VM

  • 하나의 Node 에는 여러 Pod 실행 가능

Cluster

| Cluster = 여러 Node 를 묶은 쿠버네티스 전체 환경

  • 최소 구성

  • Control Plane (관리)

  • Worker Node (실행)

Deployment ⭐⭐⭐

| Deployment = Pod 를 어떻게, 몇 개를, 어떤 이미지로 실행할지 정의

  • Pod 직접 만들지 않음

  • Deployment -> ReplicaSet -> Pod

| 의미

  • Pod 가 1개 죽어도 -> 자동으로 다시 실행

  • 이미지 버전 바꾸면 -> 롤릴 업데이트

Service ⭐⭐⭐

| Service = Pod 들의 고정된 접근 주소

Pod 문제:

  • Pod 는 죽고 다시 생기면 IP 가 바뀜

Service 해결:

  • 고정 IP / DNS 제공

  • 내부 로드벨런싱

Namespace

| Namespace = 쿠버네티스 리소스의 논리적 구분

  • 위와 같은 클러스터에서 환경 분리 가능

  • 리소스 충돌 방지

ConfigMap / Secret

| 설정과 비밀값을 코드와 분리

  • ConfigMap: 일반 설정값

  • Secret: 비밀번호, 토큰

Ingress

외부 트래픽을 클러스터 내부 Service로 라우팅

3️⃣ Kubernetes 전체 아키텍처 (한 눈에 보기)

kube_traffic_ingress_service_pod
kube_archi_diagram

4️⃣ Control Plane vs Worker Node

4.1 Control Plane (두뇌)

  • API Server

    • 모든 요청의 입구

  • Scheduler

    • Pod 를 어떤 Node 에 배치할지 결정

  • Controller Manager

    • 상태 유지(Pod 수 맞추기 등)

  • etcd

    • 모든 상태 정보 저장(DB)

👉 “지금 상태가 원하는 상태인가?” 계속 감시

4.2 Worker Node (몸)

  • kubelet

    • Pod 실행 관리자

  • container runtime

    • Docker / containerd

  • kube-proxy

    • 네트워크 & Service 처리

5️⃣ 실제 요청 흐름 (중요 ⭐⭐⭐)

6️⃣ 쿠버네티스를 이해하는 핵심 사고방식

❌ 이렇게 생각하면 헷갈림

  • “서버에 접속해서 뭐 실행하지?”

  • “컨테이너 직접 띄우면 되지 않나?”

⭕ 이렇게 생각해야 함

  • 상태를 선언한다

  • 쿠버네티스가 상태를 맞춘다

  • 나는 운영자가 아니라 설계자

7️⃣ 초보자 학습 로드맵 (추천)

  • Docker 컨테이너 이해

  • Pod / Deployment / Service

  • ConfigMap / Secret

  • Ingress

  • HPA / 리소스 제한

  • 실습 (minikube, kind)

🙋 질문 포인트

Q1. Node 가 실제 VM 이라면, 어떤 식으로 VM 이 생성되고 죽으며, 스펙등은 어디서 정의하는가

  • Node(VM, 대부분의 경우 VM)은 쿠버네티스가 직접 만들지 않고, 생성/삭제/스펙 관리는 클라우드 인프라 계층 책임

  • VM 생성/삭제: AWS / GCP / Azure

  • VM 스펙 (CPU, RAM, Disk): Auto Scaling Group / Node Pool

  • 쿠버네티스: 생성된 VM(Node) 위에서 Pod 관리

  • 예:

    • AWS EKS → EC2

    • GKE → Compute Engine VM

    • AKS → Azure VM

| 쿠버네티스 입장에서는 "Node = kubelet이 설치된 머신"

그래서 어떻게 생성? 핵심 개념: Node Group / Node Pool

  • 관리형 Kubernetes (EKS / GKE / AKS)

  • AWS EKS: Node Group

  • GCP GKE: Node Pool

  • Azure AKS: Node Pool

VM 스펙은 어디서 정의? (AWS 기준 (가장 명확))

  • CPU / RAM: EC2 Instance Type

  • 디스크: Launch Template

  • 최대 Node 수: Auto Scaling Group

  • OS: AMI

  • kubelet 옵션: User Data / Bootstrap Script

VM(Node)는 언제 생성되고 언제 죽는가

  • 생성되는 경우

    • 클러스터 생성 시

      • Node Pool / Node Group 설정된 만큼 생성

    • 오토 스케일링 (중요 ⭐️⭐️⭐️)

      • Pod 요청 증가

      • Node 공간 부족

      • Cluster AutoScaler 작동

      • 새 VM 생성

      • 새 Node 등록

  • 삭제되는 경우

    • 트래픽 감소

      • Pod 감소

      • Node 가 비어 있음

      • AutoScaler 판단

      • VM 종료

    • 장애 발생

      • VM 장애

      • ASG가 감지

      • 새 VM 생성

      • 쿠버네티스 Node 재등록

쿠버네티스는 Node를 어떻게 인식하는가

VM 생성

  • kubelet 실행

  • API Server에 등록

  • Node Ready

쿠버네티스 입장에서는:

  • kubectl get nodes 의 결과만 중요하다

  • VM 생성 방식에는 관여하지 않음

  • 등록된 Node 만 사용

Pod 리소스 vs Node 스펙 (아주 중요 ⭐⭐⭐)

Pod는 “요청”만 한다

Node는 “수용 능력”을 가진다

스케줄링 판단

정리하면

  • 쿠버네티스가 VM을 만든다: ❌

  • Pod 가 부족하면 쿠버네티스가 서버를 만든다: ❌

  • 쿠버네티스는 Node 위에서만 Pod 를 관리한다: ⭕

Q3. 운영에서 반드시 터지는 장애 포인트

ING

다음으로 이어나가기 좋은 주제

  • ❓ Docker → Kubernetes 사고 전환

  • ❓ FastAPI 앱을 쿠버네티스에 배포하기 (실습 YAML)

  • ❓ Ingress vs LoadBalancer vs NodePort 차이

  • ❓ 운영에서 반드시 터지는 장애 포인트

  • ❓ Cluster Autoscaler 는 정확히 언제 동작하는가?

  • ❓ Pod 스케일링(HPA) vs Node 스케일링 차이

  • ❓ Node 하나에 Pod는 최대 몇 개까지 가능한가?

  • ❓ Spot 인스턴스를 Node로 쓰면 어떻게 되나?

PreviousKubernetesNextKube HPA Overview

Last updated