Kubernetes

컨테이너화된 애플리케이션을 자동으로 배포, 스케일링, 운영해주는 컨테이너 오케스트레이션 플랫폼

필요성

• 컨테이너가 많아지는 경우,
  - Docker 같은 기술로 컨테이너 하나는 쉽게 띄울 수 있지만,

  • 수십, 수백개의 컨테이너를 자동으로 배포하고 관리

  • 트래픽이 많아지면 자동으로 확장(scailing)

  • 장애가 생기면 자동 복구(restart, replace)
    이런 것들을 직접 하기는 매우 어려움

    -> 이런 것들은 운영(오케스트레이션) kubernetes가 해줌

주요 기능

기능	설명
배포 관리	원하는 수의 컨테이너(Pod)를 지정하고 자동으로 배포
자동 복구	컨테이너가 죽으면 다시 실행 (Self-healing)
서비스 디스커버리 & 로드 밸런싱	컨테이너 간 통신을 자동 관리 (ClusterIP, NodePort 등)
수평 확장	CPU/메모리 기준으로 컨테이너 수 자동 증가/감소
롤링 업데이트	다운타임 없이 애플리케이션 업데이트
비밀/설정 관리	환경변수, 비밀번호 등을 안전하게 저장하고 주입
리소스 관리	각 컨테이너에 대해 자원 제한 (CPU/메모리) 설정 가능

구성요소

1. Pod : Kubernetes의 최소 실행 단위(보통 하나의 컨테이너를 하나의 Pod라 봄)
2. Deployment: 어떤 Pod를 몇 개 띄울지 정의(버전 업데이트, 롤백 등도 담당)
3. Service: 여러 Pod에 고정된 접점을 제공(Load Balancer 역할)
4. Node: 실제 컨테이너가 실행되는 서버(가상/물리)
5. Master(Control Plane): 클러스터 상태를 관리하는 뇌 역할(스케줄링, 감시 등)

기본 아키텍처

구성 요소	설명
Control Plane	클러스터를 관리하는 중앙 제어 시스템 (마스터 노드에서 작동)
Node	실제로 컨테이너(Pod)가 동작하는 워커 노드
Pod	컨테이너가 배포되는 최소 단위 (보통 1 컨테이너 = 1 Pod)
Kubelet	각 Node에 설치되어 Control Plane과 통신하며 Pod 실행
kube-proxy	각 노드에서 네트워크 프록시 역할 (서비스 연결 처리)
etcd	클러스터 설정과 상태 정보를 저장하는 Key-Value 저장소

핵심 리소스 (Api Object)

리소스	역할
Deployment	원하는 수의 Pod를 관리하고, 롤링 업데이트/롤백 지원
Service	Pod에 고정된 네트워크 주소를 제공 (ClusterIP, NodePort, LoadBalancer)
Ingress	외부 HTTP(S) 요청을 내부 서비스로 라우팅하는 엔트리포인트
ConfigMap	환경변수, 설정파일 등의 비밀이 아닌 설정 데이터
Secret	비밀번호, 토큰 등 민감한 데이터를 암호화해 저장
PersistentVolume / Claim	디스크와 같은 저장공간을 컨테이너에 연결

쿠버네티스의 네트워킹

쿠버네티스는 내부적으로 다음을 가정함

• 모든 Pod는 서로 IP 기반으로 직접 통신 가능
• Pod->Service->Pod 간 트래픽은 kube-proxy가 관리
• 외부 트래픽은 Ingress Controller(Nginx, Traefik 등)로 수신

-> 서비스 간 호출, 로드밸런싱, 외부 접근은 K8s가 직접 관리함

쿠버네티스와 CI/CD

• Github Action/Gitlab CI -> Docker image build -> Registry push
• ArgoCD/FluxCD -> Kubernetes 자동 배포

Kubernetes와 Docker

• Docker는 더 이상 K8s의 공식 CRI(Container Runtime Interface)가 아님
• containered를 더 권장함. 더 가볍고 빠르며, Kubernetes에 최적화 되어 있음
• 그러나 실행할 이미지 포맷은 똑같이 Docker와 호환되므로 Docker로 빌드해도 문제는 없음

권장되는 배포 방법

항목	권장 방식
이미지 빌드	GitHub Actions에서 Docker 또는 BuildKit
이미지 저장소	DockerHub, GitHub CR, AWS ECR, 자체 Harbor 등
배포 방법 ①	GitHub Actions에서 kubectl로 직접 배포
배포 방법 ②	ArgoCD/FluxCD 같은 GitOps 도구를 통한 자동화 (더 확장성 있음)
런타임 환경	쿠버네티스에서 containerd 사용 (Ubuntu 24 LTS 환경 문제 없음)

Docker로 이미지 빌드하고, 실행은 containerd로.

장점

장점	설명
자동화	배포/복구/스케일링 자동
유연성	다양한 클라우드(AWS, GCP, Azure) 또는 온프레미스에서도 가능
마이크로서비스에 최적	서비스 간 통신, 분산 트래픽 처리에 강함
커뮤니티 & 생태계	Helm, Istio, ArgoCD 등 확장 도구 풍부

Helm

Kubernetes 환경에서 애플리케이션을 보다 쉽게 배포, 관리, 업그레이드 할 수 있도록 돕는 패키지 관리자

Linux의 apt, yum, Python의 pip와 유사한 역할을 수행한다고 보면 됨

• Kubernetes용 패키지 관리자
• Kubernetes 리소스를 묶어서 chart 라는 단위로 패키징
• chart를 통해 애플리케이션의 설치/업데이트/삭제 자동화 가능

핵심 개념

용어	설명
Chart	Helm에서 관리되는 하나의 패키지. Kubernetes 리소스 파일(yaml)들의 모음
Release	Chart를 실제 클러스터에 배포한 인스턴스
Values	Chart에서 사용하는 변수. values.yaml로 정의되어 있고 사용자 커스터마이징 가능

장점

장점	설명
재사용성	같은 Chart로 dev/staging/prod 모두 관리 가능
버전 관리	release마다 버전 기록 및 rollback 가능
변수화	환경에 따라 설정값 다르게 적용 가능 (values.yaml)
복잡도 감소	StatefulSet, PVC 등 복잡한 리소스를 간단히 설치 가능
커뮤니티	인기 있는 소프트웨어들은 Helm Chart가 이미 제공됨 (Kafka, Redis 등)

정리

쿠버네티스는 컨테이너 앱을 자동으로 띄우고, 트래픽에 따라 확장/축소하고, 장애시 자동 복구, 통신과 설정 및 배포도 자동 관리함