

컨테이너 기술은 운영체제 수준 가상화(OS-level Virtualization)로,
하나의 물리 서버에서 여러 애플리케이션을 서로 격리된 공간에서 동시에 실행할 수 있게 하는 기술이다.
이 개념은 Docker가 나오기 훨씬 전부터 존재했다.
Docker로 컨테이너 기술을 처음 접하는 경우가 많은데, 실은 오랜 시간 동안 다양한 기술들을 거쳐 docker가 탄생되었다.
Solaris 운영체제에 들어있던 OS 수준 가상화 기술로
하나의 서버에서 여러 개 Zone을 만들어서 각 애플리케이션을 격리된 환경에서 실행 가능하다.
지금 리눅스 컨테이너와 격리 원리가 거의 동일하다.
Linux에서 제공하는 컨테이너 핵심 기술이다.
LXC(Linux Containers): cgroups와 namespace를 이용해 프로세스를 격리한다.
cgroups(Control Groups): CPU, 메모리 같은 리소스를 그룹 단위로 제한/분리
namespace: 프로세스 ID, 파일 시스템, 네트워크 스택 등 실행환경 분리**
컨테이너 실행/이미지 빌드/배포를 쉽게 만들어준 표준 도구이다.
복잡한 LXC 명령어 대신 간단한 CLI로 누구나 컨테이너를 쉽게 쓸 수 있게 해준다.
이미지 레지스트리(Docker Hub)까지 제공해 배포를 표준화하였다.
Google은 10년 넘게 Borg라는 내부 전용 container-oriented cluster-management system 으로 거의 모든 서비스를 컨테이너로 운영해왔다.
Borg 덕분에 구글은 수많은 컨테이너 워크로드를 자동으로 스케줄링하고 복구할 수 있었다.
이 운영 경험이 Kubernetes 오픈 소스로 공개되어 Borg는 대규모 컨테이너 운영 경험과 오케스트레이션의 원형 역할을 하게 되었다.
컨테이너는 리눅스 커널의 namespace, cgroups 같은 기능을 이용해
프로세스 실행 환경을 격리해 주는 운영체제 수준 가상화 기술이다.
여러 애플리케이션이 하나의 OS 커널을 공유하면서도
서로 독립적으로 실행될 수 있다.
커널 공유 → 가벼움·빠름·자원 효율 ↑ / 격리로 안정성은 그대로!
대표적인 예시: Solaris Zones, LXC, cgroups/namespace 등.
👉 즉, 컨테이너 기술 그 자체는 OS 기능에 가깝다.
Docker는 컨테이너를 쉽게 빌드하고 배포하고 실행할 수 있게 만든 “플랫폼” 이다.
컨테이너를 패키징하고 실행하는 표준 툴을 제공하여
이미지(Docker Image)로 애플리케이션과 의존성을 불변 상태로 묶어서 배포 가능하게 한다.
Docker Hub 같은 레지스트리를 통해 누구나 공유하고 가져다 쓸 수 있게 한다.
개발부터 배포까지 같은 이미지로 테스트/운영 환경을 표준화할 수 있다.
docker run 같은 간단한 CLI로 누구나 컨테이너를 띄울 수 있게 한다.
기존 LXC나 cgroups만 쓸 땐 커널 기능을 직접 만져야 해서 복잡하고 어려웠다.
Docker는 Daemon, CLI, Hub를 한데 묶어
컨테이너 빌드 → 배포 → 실행 → 공유를 표준화했다.
Dockerfile로 이미지를 관리하고 Docker Hub로 같은 이미지를 공유하면서
개발 중 “로컬 = 운영” 환경 일관성이 가능해졌다.
Docker는 몇 개의 컨테이너를 단일 서버에서 띄우는 데는 완벽하다.
하지만 실제 서비스는 수십~수천 개 컨테이너가 서로 통신하고,
서버 장애 시 자동 복구되어야 하며,
트래픽에 따라 컨테이너를 자동으로 늘리고 줄여야 한다.
초창기엔 스크립트를 직접 만들어서 관리했지만
이 방식은 유지보수도 어렵고 버전 충돌 위험도 컸다.
컨테이너 오케스트레이션은
컨테이너의 전체 라이프사이클(프로비저닝, 배포, 스케줄링, 삭제) 을 자동으로 관리해준다.
운영자가 원하는 상태만 선언(declarative) 하면
시스템이 알아서 아래 항목들을 처리한다.
이미지 가져오기
컨테이너 배포/스케줄링
상태 모니터링
자동 복구
✔ Google Borg → Kubernetes
Google은 내부에서 Borg라는 초대형 오케스트레이터를 10년 넘게 돌려왔다.
Borg 덕분에 Google은
전 세계 데이터센터에 걸쳐 수십만 개 컨테이너를 자동으로 배포하고,
죽으면 자동 복구하며, 자원을 최적화했다.
이 경험을 바탕으로 오픈 소스로 공개된 것이 Kubernetes(K8s) 이다.
k8s가 뭔가 했는데 k와 s의 중간에 8글자가 있는 것을 표현한 것이라고 한다.
Pod라는 최소 실행 단위로 컨테이너를 묶어 배치
Node, Cluster, Control Plane으로 대규모 인프라 운영
ReplicaSet과 Deployment로 원하는 개수를 선언하면 항상 유지
Service로 로드밸런싱과 DNS 제공
상태 모니터링, 롤링 업데이트, 롤백까지 자동화
1️⃣ 자동 확장 (Auto Scaling)
문제: 트래픽 변동에 따라 컨테이너 수를 수동으로 늘리고 줄이는 것은 한계가 있다.
해결: 오케스트레이터가 CPU/메모리/네트워크 지표를 모니터링해
수요에 따라 Replica 개수를 실시간으로 Auto Scale한다.
✅ 효과: 비용 최적화 + 무중단 스케일링
2️⃣ 자가 복구 (Self-Healing)
문제: 컨테이너나 노드에 장애 발생 시 수동으로 복구하면 다운타임이 발생한다.
해결: Kubernetes는 컨테이너 Health Probe로 상태를 지속 점검한다.
실패하면 자동으로 새로운 Pod를 띄우고, 노드 장애 시 다른 노드로 재배치한다.
✅ 효과: 서비스 연속성 확보 + 운영 부담 감소
3️⃣ 선언적 인프라
문제: 기존 스크립트 방식은 원하는 상태를 사람이 일일이 순서대로 명령해줘야 해서
버전 충돌이나 실수로 잘못된 배포가 자주 발생했다.
해결: 원하는 상태만 YAML이나 JSON으로 선언해두면
오케스트레이터가 현재 상태를 계속 감시하다가 다르면 자동으로 맞춰준다.
핵심: 운영자는 세부 동작을 하나하나 직접 제어하지 않고
원하는 상태만 정의하면 된다 → automated, safe, reproducible
✅ 효과: Infra as Code 실현 → 재현 가능하고 안전한 배포
Infra as Code(IaC)
서버, 네트워크, 데이터베이스, 로드밸런서 같은 인프라 구성을 코드(YAML, JSON, HCL 등) 로 정의하고
코드처럼 버전 관리하고 자동으로 배포/변경하는 것이다.
Kubernetes는 강력하지만 직접 설치·운영하면 마스터 노드(Control Plane) 유지, 버전 업그레이드, 보안 패치 같은 운영 부담이 상당하다.
✅ Amazon ECS (Elastic Container Service)
Kubernetes 없이도 컨테이너 클러스터를 관리할 수 있는 AWS의 독자적인 오케스트레이터이다.
인프라 프로비저닝, 컨테이너 스케줄링, 헬스체크, 로드밸런싱, IAM 연동까지 전부 AWS가 관리해 준다.
단일 AWS 환경에서 손쉽게 컨테이너 기반 서비스를 운영할 때 적합하다.
✅ Amazon EKS (Elastic Kubernetes Service)
Kubernetes의 모든 기능을 그대로 쓰면서도 Control Plane은 AWS가 관리해준다.
온프레미스, 멀티 클라우드 환경에서도 같은 Kubernetes API로 일관되게 배포·운영 가능하다.
AWS 인프라 자원(IAM, ELB, EBS)과 자연스럽게 연동돼 보안·네트워크 관리도 단순해진다.
Docker는 단일 노드에서 컨테이너를 쉽게 실행·빌드·배포할 수 있게 해준 도구다.
컨테이너 오케스트레이션은 수백~수천 개 컨테이너의 배포/스케일링/복구를 자동화해준다.
Kubernetes는 Google Borg 경험을 바탕으로 만들어진 대표 오케스트레이터로,
자동 확장, 자가 복구, 선언적 관리 같은 운영 자동화의 표준이다.
ECS/EKS 같은 Managed 서비스로 운영 복잡도를 줄이고 안정성과 재현 가능성을 확보할 수 있다.
docker
https://docs.docker.com/get-started/docker-overview/
aws
https://aws.amazon.com/what-is/container-orchestration/?nc1=h_ls
깔끔한 정리👍 잘 읽고 갑니당