🧩 컨테이너 오케스트레이션
복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구
🧱 기존 방식의 한계
- 서버 환경을 아무리 문서화해도 환경/버전이 바뀌면 잘 안 돌아가는 경우 많음
- 설정 관리 도구 등장
대표 도구:CHEF,Puppet Labs,Ansible
하지만…- 배우기 어렵고
- 설정이 복잡해지면 도구 자체도 복잡해짐
- 가상머신(VM)의 등장
- 클라우드와 찰떡궁합은 아님
- 특정 벤더에 종속
- 부팅이 느려서 유연성 떨어짐
🐳 도커(Docker)의 등장
도커는 이 문제들을 상당히 해결해줬음.
- 실행 환경을 컨테이너로 추상화
- 도커만 설치되어 있으면 어디서든 동일하게 실행 가능
- 사용법이 상대적으로 쉬움 → 서버 운영 복잡성 ↓
📌 컨테이너의 특징
- VM보다 빠르고 효율적
- 이미지 기반 배포 및 롤백 가능
- 언어나 프레임워크에 상관없이 동일한 방식으로 앱 관리
- 개발/테스트/운영 환경 통일 가능
- 특정 클라우드 벤더에 종속되지 않음
📦 컨테이너화의 흐름
코드 작성 → Docker build → Ship → Run- DB, Redis, Jenkins 등도 컨테이너화하여 관리 가능
- "이미지화"된 애플리케이션을 어디서든 실행 가능하게 만들어 줌
🤯 컨테이너가 많아지면?
컨테이너가 10개, 100개, 1000개가 되면?
docker run만으로는 관리가 점점 어려워짐- 배포, 업데이트, 서비스 연결, 장애 대응까지 운영 자동화에 대한 요구 증가
🛠 도커 이후의 고민들
🚀 컨테이너 배포는 어떻게?
docker stop app && docker run ...- 수동 작업 많음
- 빈 서버 찾기도 힘듦
- 롤백/업데이트 불편
🧭 서비스 검색은 어떻게?
- 마이크로서비스 구조에서 컨테이너가 많아질수록 통신이 복잡
- 로드밸런서 설정도 번거롭고, 자동화 필요
🌐 서비스 노출은 어떻게?
- 가장 쉬운 방식: Nginx 같은 프록시 서버로 연결
- 하지만 프록시 설정을 컨테이너 증가에 맞춰 자동화해야 함
📊 모니터링과 확장
- 컨테이너 상태 이상 여부 체크
- CPU나 메모리 사용량에 따라 자동 확장/축소 필요
🧠 컨테이너 오케스트레이션의 필요성
컨테이너를 자동으로 배포, 관리, 확장, 모니터링해주는 시스템
주요 기능 요약
-
클러스터 단위 관리
- 개별 노드가 아닌 클러스터 단위로 컨테이너를 관리
- SSH로 접속하지 않고, 마스터 노드에 명령 전달
- 노드 간 통신이 원활해야 함
-
상태 관리(State Management)
- 예: Replica를 2 → 3으로 설정하면, 자동으로 컨테이너 3개 유지
- 시스템이 자동으로 상태를 유지해줌
-
스케줄링
- 리소스 상황에 따라 컨테이너 배치 자동 조정
-
버전 관리
- Rollout, Rollback 같은 배포 이력 관리 기능 제공
-
서비스 디스커버리
- 컨테이너가 DNS 이름 기반으로 자동으로 서비스에 접근 가능
- 예:
user-service→http://user-service
-
볼륨 스토리지
- 상태 유지가 필요한 서비스(DB 등)를 위한 Persistent Volume
- NFS, AWS EBS, Ceph 등 외부 스토리지 연동 가능
🤖 왜 쿠버네티스(Kubernetes)인가?
구글이 만든 오픈소스 오케스트레이션 플랫폼. 도커 이후의 실질적인 표준.
핵심 특징
Borg라는 구글 내부 컨테이너 시스템에서 출발- 가장 큰 커뮤니티와 생태계를 가진 오케스트레이션 도구
쿠버네티스를 선택하는 이유
-
자가 치유(Self-healing)
- 실패한 컨테이너를 자동으로 재시작
-
자동 확장(Auto-scaling)
- 부하에 따라 컨테이너 수 자동 조절
-
버전 관리와 롤백
- 이전 상태로 쉽게 복구 가능
-
멀티 클라우드 호환성
- GCP, AWS, Azure, 온프레미스 등 어디서든 실행 가능
-
강력한 생태계
- 다양한 오픈소스 프로젝트와 연동 가능
(예:Kubeflow,Tekton,Istio,KNative등)
- 다양한 오픈소스 프로젝트와 연동 가능
🏁 마무리
컨테이너는 Dev-Ops 전체 프로세스를 변화시켰고,
오케스트레이션은 이를 실전에서 쓸 수 있게 만들어 주는 핵심 기술
Frontend Developer