컨테이너
- 컨테이너는 COW 파일 시스템을 사용합니다.
COW를 활용하면 컨테이너 여러 개가 같은 데이터를 공유할 수 있고, 운영체제는 컨테이너가 데이터를 수정하거나 새로 쓸 수 있게 데이터의 복제본을 제공할 수 있습니다.- 따라서 컨테이너의 메모리나 디스크 공간 사용량이 매우 가벼워지므로, 컨테이너를 빠르게 실행할 수 있습니다.
- 환경, 격리, 높은 응집도 간의 이동이 가능하도록 배포할 수 있습니다.
컨테이너 격리 수준
- 컨테이너는 운영체제 가상화에 기반을 두고 있어서 같은 호스트에서 실행한다면 같은 커널을 공유합니다.
- VM은 확장이 어렵습니다. VM에 더 많은 자원을 추가하는
스케일업을 하려면 기존 CPU, 메모리, 스토리지보다 더 큰 VM을 준비하고 부팅해야 합니다.스케일아웃은 필요한 만큼 빠르게 동작하지 못합니다.
컨테이너 오케스트레이션
1) 컨테이너 오케스트레이터가 수행하는 작업
- 클러스터의 노드에 컨테이너를 프로비저닝하고 배포
- 컨테이너 자원 관리, 자원히 충분한 노드에 컨테이너를 배치하고 노드 자원이 부족해지면 다른 노드로 컨테이너 이동
- 컨테이너의 노드 상태 모니터링, 컨테이너나 노드에 장애가 발생했을 때, 컨테이너를 재배치 및 재시작
- 클러스터 내 컨테이너를 스케일인 또는 스케일아웃
- 네트워크 연결을 위해 컨테이너 매핑
- 컨테이너 간의 내부 로드 밸런싱
2) 쿠버네티스
kube-proxy: 노드의 네트워크 규칙을 관리하고 커넥션 포워딩을 수행합니다.Pod: 컨테이너 생명 주기를 관리하기 위해 하나 이상의 컨테이너와 스토리지 자원, 네트워크 IP 등을 한꺼번에 묶은 단위 / 파드 하나에 컨테이너 여러 개를 지원하지만 대부분은 파드 한 개에 애플리케이션 한 개만 사용함 / 애플리케이션 컨테이너의 기능을 확장하고 추가하기 위해 사이드카 컨테이너의 패턴을 사용함Service: 클러스터에서 실행 중인 파드들의 그룹에 대한 안정적인 엔드포인트를 제공합니다.
게이트웨이
1) API 게이트웨이
- 하나 이상의 API 게이트웨이를 클라이언트와 서비스 사이에 둘 수 있습니다.
- 요청을 담당 서비스 쪽으로 보내는 것부터 공통 엔드포인트를 통해 비즈니스 API를 노출시키거나 SSL 처리같은 작업을 수행하거나 인증처리를 할 수 있습니다.
- 계층을 만들 수 있어서 하나의 계층으로 SSL 오프로딩을 담당하고, 또다른 계층으로 인증과 권한 관리를 할 수 있습니다.
2) 애플리케이션 게이트웨이
- API 관련된 건 아무것도 필요하지 않습니다.
- 주로 SSL, 오프로딩, 정적자원(HTML, CSS 파일 등) 라우팅, 오브젝트 스토리지로 라우팅하는 데 사용됩니다.
서비스 메시
각 서비스의 공통 기능들을 서비스 메시쪽으로 옮겨서 개발자 생산성을 향상하는 것입니다.
서비스 기능과 서비스 메시의 일반적인 기능 사이의 관심사를 분리할 수 있습니다.
1) 프록시 : 서비스로 들어오고 나가는 모든 요청을 가로채는 역할을 합니다.
쿠버네티스의 경우, 프록시는 서비스처럼 같은 파드 내에 사이드카로 실행하고 네트워크를 공유합니다.- 사이드카 프록시를 사용하는 것은 간단하지만 파드마다 추가 컨테이너를 실행해야 하므로 자원 비용이 추가로 발생합니다.
- 서비스 메시 내 모든 프록시들은 데이터 플레인이라고 합니다.
- 서비스 메시의 일부는 데이터 플레인을 제외하고 컨트롤 플레인이라고 합니다.
- 서비스 메시 사용자는 데이터 플레인에 있는 프록시를 직접 관리하지 않음 / 컨트롤 플레인의 역할은 데이터 플레인이 사용자가 의도한 대로 설정되도록 보장하는 것
DevOps, 코딩 기록