Part 1. 쿠버네티스 (Kubernetes)
01. 왜 쿠버네티스인가? (Computing Evolution)
컴퓨팅 환경은 효율성을 높이는 방향으로 3단계를 거쳐 발전함.
- Traditional (물리 서버): 한 애플리케이션이 자원을 독점하거나, 유휴 자원이 낭비되는 문제가 발생함.
- VM (가상 머신): 하나의 서버를 쪼개 사용하나, 각 VM마다 OS가 포함되어 무겁고 느림.
- Container (컨테이너): OS를 공유하며 애플리케이션만 격리함. 가볍고 빠르며 효율적임.
쿠버네티스의 필요성 (Orchestration)
수많은 컨테이너를 사람이 직접 관리하는 것은 불가능함. 쿠버네티스는 이를 자동화하는 도구임.
- 자동 배포 & 스케일링: 트래픽 증가 시 컨테이너 수를 자동 확장함.
- 자동 복구 (Self-healing): 장애 발생 시 자동으로 재시작함.
- 무중단 업데이트: 서비스 중단 없이 버전을 교체함.
02. 쿠버네티스 아키텍처 (Architecture)
크게 두뇌 역할의 Control Plane과 실제 작업을 수행하는 Worker Node로 구분됨.
A. Control Plane (마스터 영역)
클러스터 전체의 상태를 관리하고 명령을 내림.
- kube-apiserver: 모든 요청이 통과하는 유일한 관문(문지기).
- etcd: 클러스터의 모든 데이터와 상태를 저장하는 저장소(DB).
- kube-scheduler: 새로 생성된 파드(Pod)를 배치할 노드를 결정함.
- kube-controller-manager: 현재 상태를 감시하며 의도한 상태를 유지하려 노력함.
B. Worker Node (일꾼 영역)
실제 애플리케이션(Pod)이 구동되는 서버임.
- kubelet: 마스터의 명령을 받아 노드 내 파드 상태를 관리하는 에이전트.
- kube-proxy: 파드 간의 네트워크 통신을 담당함.
- Container Runtime: 실제 컨테이너 실행 엔진(Docker, containerd 등).
03. 핵심 동작 원리
- Pod (파드): 배포의 최소 단위. 보통 1개의 컨테이너를 포함하나, 여러 개를 묶어 IP와 저장소를 공유할 수 있음. 일시적(Ephemeral)인 존재임.
- Controller & Desired State: 사용자가 의도한 상태(Desired State)를 선언(YAML)하면, 컨트롤러가 현재 상태를 감시하다가 자동으로 상태를 일치시킴. (예: 파드 3개 유지 선언 시, 1개가 죽으면 자동으로 생성)
04. 워크로드 리소스 (Workload Resources)
애플리케이션 성격에 따라 관리 방식이 다름.
| 종류 | 용도 | 특징 | 예시 |
|---|---|---|---|
| Deployment | Stateless 앱 | 가장 보편적. 롤링 업데이트 지원. | 웹서버, Web App |
| StatefulSet | Stateful 앱 | 순서(0, 1...)와 스토리지 유지가 중요함. | DB (MySQL, Redis) |
| DaemonSet | 노드 관리 | 모든 노드에 1개씩 자동 설치됨. | 로그 수집기, 모니터링 |
| Job / CronJob | 배치 작업 | 1회성 실행(Job) 또는 주기적 실행(CronJob). | 데이터 분석, 백업 |
05. 네트워크와 스토리지 설정
- Service (서비스): 유동적인 파드 IP 대신 고정된 IP를 제공하여 트래픽을 로드밸런싱함.
- PV / PVC (스토리지):
- PV: 관리자가 프로비저닝한 실제 저장소.
- PVC: 개발자가 요청하는 저장소 이용권. 파드 재생성 시에도 데이터가 유지됨.
- ConfigMap / Secret:
- ConfigMap: 환경변수 등 설정 파일을 이미지와 분리함.
- Secret: 비밀번호, 키 등 민감 정보를 암호화하여 저장함.
Part 2. CI/CD (지속적 통합 및 배포)
01. 문제 상황과 해결책
- 문제: 수동 배포 시 발생하는 내 로컬에선 되는데 현상, 머지 충돌, 배포 공포 등.
- 해결 (CI/CD): 자동화를 통한 안정성 확보.
- CI (지속적 통합): 빌드/테스트 자동화. 하루에 여러 번 머지해도 안정성 유지.
- CD (지속적 제공/배포): 사람의 승인 후 배포(Delivery) 혹은 즉시 자동 배포(Deployment).
02. DevOps 문화와 측정
DevOps는 개발(Dev)과 운영(Ops)이 무한 루프처럼 피드백을 주고받는 문화임.
DORA 4대 지표 (측정 기준)
- 배포 빈도: 얼마나 자주 배포하는가?
- 변경 리드 타임: 커밋부터 배포까지 소요 시간.
- 서비스 복구 시간: 장애 발생 시 복구 속도.
- 변경 실패율: 배포 시 실패할 확률.
03. CI Deep Dive: 파이프라인
- Git 전략:
- Git Flow: 복잡하고 긴 주기(Main, Develop, Release 등)에 적합.
- GitHub Flow: 단순하고 빠른 배포(Main + Feature)에 적합.
- 테스트 피라미드:
- Unit Test (70%): 함수 단위, 빠르고 비용 저렴.
- Integration Test (20%): 모듈 간 연결 확인.
- E2E Test (10%): 사용자 관점 시나리오, 느리고 비용 높음.
- 정적 코드 분석: 코드 실행 없이 버그나 보안 취약점을 사전 탐지(Linting, SAST).
04. GitHub Actions 실전
GitHub 저장소에서 직접 사용하는 CI/CD 도구임.
- 구조: Workflow (전체) > Job (병렬 실행 단위) > Step (개별 명령)
- 최적화: Cache를 사용하여 의존성 설치 시간을 단축함.
- 보안: API Key 등은 코드에 포함하지 않고 GitHub Secrets에 저장하여 활용함.
05. CD 전략과 트렌드
배포 전략
- Blue/Green: 구버전(Blue)과 신버전(Green)을 동시에 운영하며 트래픽만 전환. 즉시 롤백 가능하나 리소스 비용이 2배임.
- Canary: 소수 사용자(예: 5%)에게만 먼저 배포하여 리스크를 최소화함.
- Rolling Update: 파드를 하나씩 순차적으로 교체함 (K8s 기본 방식).
2025 최신 트렌드
- GitOps: ArgoCD 등의 에이전트가 Git 변경사항을 감지해 클러스터 상태를 동기화함(Pull 방식). 보안성과 복구 능력이 우수함.
- DevSecOps: 보안 검사를 파이프라인 초기 단계(Left)에서 수행함.
- Platform Engineering (IDP): 개발자가 인프라 지식 없이도 환경을 구성할 수 있는 포털 제공.
- AI & GreenOps: AI 기반 파이프라인 작성 및 탄소 배출을 고려한 효율적 빌드 관리.
제 별명이 감자입니다