Developers Haven

스토리지-컴퓨팅 분리 아키텍처에 대하여

DH’s Blog — Thu, 18 Apr 2024 14:33:59 +0900

기존 Hadoop 빅데이터 클러스터 아키텍처에서 스토리지-컴퓨팅 분리 아키텍처로 바뀌게 된 이유에 대해서 알아보자.

기존 Hadoop 빅데이터 클러스터 아키텍처 구조

Cnode(컴퓨팅 노드), Snode(스토리지 노드)가 하나로 구성된 구조
Hadoop의 데이터 지역성 활용 가능 → 최대한 데이터가 저장된 노드에서 데이터를 처리하게 함으로써 데이터의 이동(move)을 줄이고, 네트워크를 통해 전달하지 않게 하여 처리 성능 향상
하지만 시스템 확장에 비용이 많이 들며 비효율적이라는 문제가 존재 → Why? 컴퓨팅 파워와 스토리지 용량을 함께 늘려야하므로

스토리지-컴퓨팅 분리 아키텍처 구조

스토리지와 컴퓨팅의 독립적 확장이 가능하여 비교적 저렴
마이크로 서비스(s/w 기능을 작고 독립적으로 쪼개서 서비스를 제공) 아키텍처에 적합
Spark의 경우, 메모리에 데이터를 올려서 처리하는 방식으로 스토리지-컴퓨팅 분리 아키텍처에 적합
하지만 데이터를 읽기 위해서 네트워크 대역폭을 소모하는 것을 피할 수 없음

Q. 스토리지 종류(DAS, NAS, SAN)의 차이점은?

1. DAS(Direct Attached Storage)

스토리지가 개별 호스트(ex. 컴퓨터, 서버)에 다이렉트로 연결되는 방식 → 네트워크 연결 없음
각 호스트에서 스토리지까지 물리적으로 근접한 곳에서 접근 가능
하지만 호스트에 장애가 발생할 경우 스토리지에도 같이 접근이 제한되는 문제 존재

2. NAS(Network Attached Storage)

스토리지와 호스트 사이에 네트워크를 두는 방식
스토리지는 직접 네트워크에 연결하여 데이터 공유 가능
블록의 상위 개념인 파일(file)을 저장 단위로 사용
하지만 네트워크 병목 현상에 취약하며 대역폭에 제한이 있는 문제 존재

3. SAN(Storage Area Network)

여러 스토리지의 단일 네트워크에 연결시켜서 스토리지 전용 네트워크(SAN)를 구성하는 방식
호스트는 SAN 전용 네트워크를 통해 접근 가능
블록을 저장 단위로 사용
하지만 네트워크 복잡도가 높아지면서 상대적으로 비용이 높다는 문제 존재

참고 페이지
https://www.stevenjlee.net/2020/05/24/%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%EC%8A%A4%ED%86%A0%EB%A6%AC%EC%A7%80storyage-%EC%9D%98-%EC%A2%85%EB%A5%98das-nas-san-%EC%99%80-%EA%B0%9C%EB%85%90/

[k8s] 쿠버네티스 오브젝트 - service(서비스)에 대하여

DH’s Blog — Sat, 13 Apr 2024 21:38:11 +0900

pod는 클러스터 내부에서만 접근이 가능하기 때문에 클러스터 외부에서 pod에 요청이 불가능하다. 또한, pod는 일회성으로 뜨고 지면서 IP가 계속 바뀌게 되고 클러스터 내/외부와의 통신을 유지하는 것이 불가능하다. 그래서 Service를 통해 클러스터 내부에서 고정 IP를 갖게 해서, pod 그룹에 대한 단일 진입점으로 외부와 통신할 수 있게 만들어준다.

쉽게 생각하면 Service는 클러스터 외부에서 트래픽이 들어오면 해당 Service와 연결된 pod에게 트래픽을 전달해주는 역할을 하는 것이다.

Service에는 4가지 유형이 있으며 일반적으로는 아래와 같은 구성으로 이루어진다.

Service의 일반적인 구성 (예시)

Service	특징
ClusterIP	클러스터 내부에서 pod들이 다른 리소스들과 통신할 수 있는 클러스터 전용 IP 클러스터 내부 통신만 가능하며 외부 트래픽은 받을 수 없다
NodePort	노드(host)에 노출되어 클러스터 내외부 통신이 모두 가능한 서비스 외부에서 <노드IP>:<노드Port>로 서비스 접근 가능
LoadBalancer	NodePort 방식은 외부 사용자에게 워커 노드의 정보가 노출되어야 하는 불편함이 존재 1개의 노드 IP만을 외부로 노출하여 해당 IP로 모든 트래픽을 부하 분산 가능
ExternalName	클러스터 내부에서 외부의 특정 주소로 접근할 때 사용

1. ClusterIP

클러스터 내부에서만 접근할 수 있는 서비스 생성
label이 동일한 pod 그룹의 단일 진입점인 Virtual IP를 생성
작업 요청이 서비스의 ClusterIP 주소로 전달되면, 해당 서비스는 pod 중 하나로 요청을 전달하여 처리(for 작업 부하 분산)

ClusterIP 서비스는 클러스터 내부에서만 접근이 가능하기 때문에, 클러스터 외부로 서비스를 노출 시키기 위해서 NodePort, LoadBalancer를 사용한다.

2. NodePort

(ClusterIP 위에)클러스터 모든 노드에서 지정된 포트를 열어 서비스에 접근 가능
쉽게 생각하면 ClusterIP가 생성되고, 워커 노드의 Port를 사용하여 접속하는 방식
외부에서 <NodeIP>:<Port>로 들어오는 요청을 감지하여, 서비스는 자신과 연결된 pod에 트래픽 전달

3. LoadBalancer

클러스터 외부에서 로드 밸런서를 사용하여 서비스 노출
로드 밸런서는 네트워크 트래픽을 분산하여 전달

4. ExternalName

서비스를 DNS 이름에 매핑하여 서비스 노출
클러스터 안에서 도메인을 등록하여 사용하는 방식

처음 서비스에 대한 개념을 접했을 때는, 알듯말듯 이해가 조금 어려운 부분이 있다. 쿠버네티스 오브젝트 중 특히 서비스의 경우, 단순 개념에 대해서만 찾아보는 것보다 직접 실습해보는 것이 이해가 훨씬 더 쉬울 것이다. 그래서 다음 시간에는 실제 쿠버네티스 안에서 서비스를 적용해보는 부분을 진행해보려고 한다.

[k8s] 쿠버네티스 오브젝트 - pod에 대하여

DH’s Blog — Sat, 13 Apr 2024 21:33:41 +0900

k8s에서 파드(pod)는 1개 이상의 컨테이너가 캡슐화 되어 클러스터 안에서 배포되는 가장 작은 단위의 객체를 의미한다. 실제 Docker 로고는 고래 이미지를 따와서 만들어졌고, 고래의(컨테이너) 떼를 일컫는 파드(pod)라는 명칭으로 불리게 되었다.

(참고) Docker 로고

< Pod에 대하여 >

(참고) k8s objects

1. pod의 기본적인 특징

하나의 pod에는 하나 이상의 컨테이너가 포함된다. (1 Pod = N Containers)
pod는 워커 노드 IP와 별개로 고유 IP를 할당 받으며, pod 내의 컨테이너들은 자신이 속한 pod IP를 공유한다.
동일 pod내의 컨테이너들은 해당 pod가 가진 스토리지(volume)을 공유한다.
pod는 반영속적인 속성을 가지고 있다.

2. pod의 생명주기

Pending : 클러스터 내 pod 생성이 승인되었지만 아직 워커 노드에 배치되지 않은 상태
Running : 파드가 워커 노드에 배치되었고 내부 컨테이너도 모두 생성 완료된 상태
Succeeded : 파드 내의 모든 컨테이너가 작업을 정상적으로 마치고 종료된 상태
Failed : 파드 내의 컨테이너 중 하나 이상의 컨테이너가 비정상 종료된 상태
Unknown/Terminating : Unknown은 파드 상태 확인이 불가능한 경우를 의미하며, Terminating은 파드를 삭제시킨 경우 나타남

(참고) Pending 상태가 지속되는 여러가지 상황

1. 배치 가능한 노드가 없어 스케줄링을 할 수 없는 경우
2. 이미지를 잘못 지정하여 이미지를 받지 못하는 경우
3. 컨테이너가 시작되었지만 아직 실행할 준비가 안된 경우
4. 볼륨에 문제가 있는 경우

3. pod 내부 컨테이너의 재시작 정책

pod 내부 컨테이너가 오류 생겼을 때, 재시작하는 방법은 대표적으로 아래 3가지가 있다.

Always : 컨테이너가 정상/비정상 종료 시 항상 재시작 → 컨테이너가 항상 구동 중이여야 하는 옵션
Onfailure : 컨테이너가 비정상 종료되었을 때만 재시작
Never : 오류와 상관 없이 재시작을 하지 않음

4. pod 내부 컨테이너의 상태를 진단해주는 프로브(Probe)

프로브(Probe)는 kubelet에 의해 주기적으로 수행되는 진단을 의미하며, pod 안의 컨테이너 상태를 진단하여 컨테이너의 재시작 or 종료 필요 여부를 확인할 수 있도록 알려준다.

(1) 프로브 종류 3가지

아래 여러 방식을 함께 조합하여 사용 가능하며, 모든 프로브(Probe) 진단 결과가 Success이어야 한다.

Liveness Probe : 컨테이너가 제대로 작동하고 있는지 확인 → 문제 발생 시 컨테이너 재기동
Readiness Probe : 컨테이너가 트래픽을 받을 준비가 되었는지 확인
Startup Probe : 컨테이너가 제대로 시작되었는지 확인

(2) 프로브의 컨테이너 진단 방식

컨테이너 진단을 통해 Success/Failure/Unknown 결과를 도출하고 Failure 반환 시 조치를 취하게 된다.

HTTP 방식(HttpGet) : 컨테이너 IP에 대한 Http Get 요청으로 응답 상태 코드 확인 (200 ≤ 상태코드 < 400이면 정상)
TCP 방식(TcpSocket) : 컨테이너 IP에 대한 Tcp 검사를 수행해서 포트가 활성화되어 있는지 확인
Exec 방식 : 컨테이너 내부에서 지정된 명령어를 수행하여 종료 코드가 0인지 확인

참고 페이지
https://seongjin.me/kubernetes-pods/

[k8s] 쿠버네티스 오브젝트란?

DH’s Blog — Sat, 13 Apr 2024 20:34:41 +0900

지금까지 쿠버네티스에 대한 개념과 전체적인 아키텍처에 대해서 알아보는 시간을 가졌다. 쿠버네티스에 대한 얘기에서 '오브젝트(object)'가 빠질 수 없는데 이번 시간에는 오브젝트가 무엇을 의미하는지에 대해서 알아보도록 하자.

[지난 시간 내용 - 쿠버네티스의 아키텍처]

2024.04.13 - [[기술공부]/Kubernetes] - [k8s] 쿠버네티스란? with 쿠버네티스 아키텍처 - (1)

[k8s] 쿠버네티스란? with 쿠버네티스 아키텍처 - (1)

지금까지 가상화 배포에서 컨테이너 배포로 바뀌게 된 배경과, 쿠버네티스가 등장하게 된 배경에 대해 알아보았다. 이번 시간에는 쿠버네티스의 개념과 아키텍처에 대해 알아보도록 하자. [지

developers-haven.tistory.com

< k8s 오브젝트 >

k8s는 클러스터 상태를 계속 체크하면서 선언된 상태가 되도록 조치를 취해주게 된다. 이때, 다양한 오브젝트(object)를 이용하여 클러스터 상태를 나타내게 된다. 쉽게 생각하면 시스템에서 배포하고 관리되는 기본 단위를 오브젝트라고 이해하면 된다.

< 대표적인 k8s 오프젝트 6가지 >

(1) Pod

k8s에서 실행되는 가장 작은 배포 단위
pod 안에는 1개 이상의 컨테이너 생성 가능 (1 Pod = N Containers)
pod는 스토리지, 네트워크 속성을 가지며 pod 내의 컨테이너는 해당 pod의 스토리지와 네트워크 공유
Why? 여러 컨테이너를 pod 단위로 묶어서 배포할까?
- pod 내의 컨테이너들은 동일 IP를 기준으로 서로 다른 port를 가지고 있는데 → 컨테이너 끼리 데이터를 교환할 때 IP 호출 없이 localhost를 통해서 통신 가능 (컨테이너들간의 통신이 쉽고 효율적)

(2) Deployment

여러 개의 pod를 생성하고 관리하는 역할 → pod 배포 자동화를 위한 오브젝트 (with ReplicaSet & 배포 전략)
ReplicaSet : 지정된 수만큼 pod 복제본을 유지하도록 보장
배포 전략 : k8s 서비스의 무중단 업데이트를 위한 배포 전략

Deployment 대표적인 배포 전략 3가지

1. Recreate 전략
: 새로운 App을 배포하기 위해 이전 pod를 모두 삭제하고 새로운 pod를 생성하는 방식

2. Rolling update 전략
: 이전 pod를 일정 갯수만큼 점진적으로 새로운 pod로 교체하는 방식

3. Blue-Green 전략
: 현재 환경(Blue)과 동일한 새로운 환경(Green)을 구성하여 Green 환경에서 App 배포 후 테스트되면 트래픽을 Blue → Green 환경으로 전환하는 방식 (만약 문제가 발생하면 롤백 가능)

(3) Service

pod는 클러스터 내부에서만 접근이 가능하기 때문에 → 클러스터 외부에서 pod에 요청이 불가능하다
이때 Service 오브젝트를 통해 클러스터 외부로부터 요청을 받을 수 있게 IP를 노출하게 된다 → 쉽게 이해하자면 pod를 통해 실행되고 있는 App을 네트워크에 노출시켜주는 가상의 컴포넌트

(4) Volume

pod 내의 컨테이너에 데이터를 저장하거나 공유하기 위한 저장 공간 → pod가 접근하여 read/write 할 수 있는 곳
pod는 일시적으로 뜨고 사라지기 때문에 → pod가 종료되어도 데이터를 보존하기 위해 볼륨 사용

대표적인 Volume 방식
1. emptyDir : pod의 라이프사이클 동안만 존재하는 임시 볼륨으로 pod가 종료되면 함께 사라짐
2. hostPath : pod가 올라간 Node의 path에 마운트하여 사용하는 방식

(5) Namespace

k8s 클러스터 내에 생성된 가상 클러스터로, 리소스들을 그룹화하여 사용할 수 있게 해주는 역할
팀/환경/서비스 단위 처럼 목적에 맞게 네임스페이스 구성 가능

(6) Secret

암호화 데이터를 저장하는데 사용되며 비밀번호, ssh key 같은 민감 정보를 저장

실제 쿠버네티스에는 이 외에도 더 다양한 오브젝트들이 있다. 이번 시간에는 가장 기본적인 오브젝트가 무엇이고, 어떤 기능을 하는지에 대해서 배워보고자 했다. 앞으로 계속 쿠버네티스를 공부하면서 이러한 오브젝트들에 대해 더 깊은 내용을 하나씩 배워볼 예정이다.

참고 페이지
https://www.msaschool.io/operation/operation/operation-two/

[k8s] 쿠버네티스란? with 쿠버네티스 아키텍처 - (2)

DH’s Blog — Sat, 13 Apr 2024 16:40:55 +0900

지난 시간에는 쿠버네티스에 대한 개념과 아키텍처에 대해 알아보았다. 쿠버네티스는 크게 마스터/워커 노드로 구성되어 있으며 지난 시간에는 마스터 노드의 구성과 역할에 대해서 알아보았다. 이번 시간에는 워커 노드에 대해서 자세히 알아보도록 하자.

[지난 시간 내용]

2024.04.13 - [[기술공부]/Kubernetes] - [k8s] 쿠버네티스란? with 쿠버네티스 아키텍처 - (1)

[k8s] 쿠버네티스란? with 쿠버네티스 아키텍처 - (1)

developers-haven.tistory.com

1. k8s(쿠버네티스)란?

k8s는 컨테이너 런타임(Container Runtime, 컨테이너 실행 엔진)을 통해 컨테이너를 다루는 도구 중 하나이다. 노드에 컨테이너를 분산 배치하거나, 오류가 생긴 컨테이너를 교체하는 것 같은 일을 통해 컨테이너를 관리해준다. 그리고 k8s는 선언형 인터페이스를 사용하여 클러스터 상태를 계속 체크하면서 선언된 상태가 되도록 조치를 취하게 된다.

(참고) 명령형 인터페이스와 선언형 인터페이스의 차이
1. 명령형 인터페이스(CLI, Command-Line Interface) - 사용자가 직접 명령을 내리고 실행하며, 각 단계 및 세부사항을 명시해줘야 한다.
2. 선언형 인터페이스(Declarative Interface) - 사용자는 원하는 최종 상태만을 선언하고, 시스템은 해당 상태를 달성하기 위해 작업을 자동으로 처리해준다.

2. k8s 아키텍처

Worker Node 구성도

(1) Kube-proxy

각 워커 노드에서 구동되는 네트워크 proxy 서버로 k8s 내부 네트워크 트래픽 관리
워커 노드의 네트워크 규칙을 유지 및 관리하며 클러스터 내외부 통신을 가능하게 만듦

구조: 1개의 워커 노드 → 1개 이상의 pod → 각 pod 안에는 1개 이상의 컨테이너

워커 노드마다 Kube-proxy를 가지고 있고, 해당 워커 노드 내에는 1개 이상의 pod가 배치될 수 있다. 그리고 각 pod는 저마다 고유한 IP 주소를 가지게 되고 동일 pod 내의 컨테이너들은 해당 pod의 IP를 같이 공유한다. 이때, Kube-proxy를 통해 서로 다른 워커 노드에 있는 pod간의 통신이 이루어진다.

+----------------------------------------------------------------------------+
|                              워커 노드 (Worker Node)                         |
|                              (IP: 192.168.0.10)                            |
|                              +------------------+                          |
|                              |    kube-proxy    |                          |
|                              +------------------+                          |
|                                       |                                    |
|                                       v                                    |
|                                                                            |
|       +---------------------------+      +---------------------------+     |
|       |            파드            |      |            파드            |     |
|       |    (Pod - IP: 10.1.0.2)   |      |    (Pod - IP: 10.1.0.3)   |     |
|       |     +-----------------+   |      |     +-----------------+   |     |
|       |     | 컨테이너 1        |   |      |     | 컨테이너 1        |   |      |
|       |     | (IP: 10.1.0.2)  |   |      |     | (IP: 10.1.0.3)  |   |     |
|       |     | Port: 8080      |   |      |     | Port: 8080      |   |     |
|       |     +-----------------+   |      |     +-----------------+   |     |
|       |     | 컨테이너 2        |   |      |     | 컨테이너 2        |   |      |
|       |     | (IP: 10.1.0.2)  |   |      |     | (IP: 10.1.0.3)  |   |     |
|       |     | Port: 8081      |   |      |     | Port: 8081      |   |     |
|       |     +-----------------+   |      |     +-----------------+   |     |
|       +---------------------------+      +---------------------------+     |
+----------------------------------------------------------------------------+

(2) Kubelet

마스터 노드의 Kube-API-Server와 통신하며 서버를 통해 들어오는 신호 모니터링
pod 상태를 유지 및 관리(생명주기 관리)하여 pod에서 컨테이너가 정상 동작하도록 관리
쉽게 생각하면 노드의 심장처럼 모니터링하고 관리하는 역할과 같음

Kubelet 기능

(1) pod 관리
: 마스터 노드로 부터 할당된 pod를 워커 노드에 배치하고 실행하는 역할 → pod 상태를 주기적으로 모니터링하고 관리하며 안정성을 유지

(2) Container 실행
: pod에 정의된 컨테이너를 실행하고 관리하는 역할 → 컨테이너 런타임(ex. Docker, Containerd)을 사용하여 컨테이너를 시작하고 중지시킴

(3) 리소스 모니터링
: 워커 노드의 리소스 사용량을 모니터링하며 클러스터 상태 파악 → 이러한 정보가 마스터 노드의 Kube-API-Server에 전달되어 ‘스케줄링’에 사용됨

(4) 상태(이벤트) 보고
: 마스터 노드의 Kube-API-Server에 주기적으로 노드와 파드 상태 보고

(5) 노드 자동 복구
: 워커 노드가 비정상적으로 종료되면 자동으로 복구 시도 → 노드 장애 시 클러스터 안정성 보장 가능

(3) Container Runtime Engine

워커 노드에서 컨테이너 실행을 담당하는 S/W (ex. Docker)
컨테이너 이미지를 가져오고 구동시키는 엔진 역할

두 번의 시간에 걸쳐, 쿠버네티스의 전체적인 아키텍처와 마스터/워커 노드의 구성과 역할에 대해서 알아보았다. 쿠버네티스를 처음 접한다면 아키텍처를 먼저 이해하는 것이 가장 중요하다고 할 수 있다. 이제 아키텍처를 이해했다면 그 다음으로 쿠버네티스의 오브젝트에 대해서 알아보도록 하자. 오늘도 이 내용이 많은 사람들에게 도움이 되었으면 좋겠다:)

[k8s] 쿠버네티스란? with 쿠버네티스 아키텍처 - (1)

DH’s Blog — Sat, 13 Apr 2024 16:23:50 +0900

지금까지 가상화 배포에서 컨테이너 배포로 바뀌게 된 배경과, 쿠버네티스가 등장하게 된 배경에 대해 알아보았다.

이번 시간에는 쿠버네티스의 개념과 아키텍처에 대해 알아보도록 하자.

[지난 시간 내용]

2024.04.13 - [[기술공부]/Kubernetes] - [k8s] 도커와 쿠버네티스의 관계

[k8s] 도커와 쿠버네티스의 관계

지난 시간에는 가상화 배포 환경에서 컨테이너 배포 환경으로 바뀌게 된 이유와 컨테이너가 무엇인지에 대해서 알아보았다. 컨테이너 기술과 관련된 내용 중에 우리가 가장 많이 들어본 것이

developers-haven.tistory.com

1. k8s(쿠버네티스)란?

(참고) 명령형 인터페이스와 선언형 인터페이스의 차이
1. 명령형 인터페이스(CLI, Command-Line Interface) - 사용자가 직접 명령을 내리고 실행하며, 각 단계 및 세부사항을 명시해줘야 한다.
2. 선언형 인터페이스(Declarative Interface) - 사용자는 원하는 최종 상태만을 선언하고, 시스템은 해당 상태를 달성하기 위해 작업을 자동으로 처리해준다.

2. k8s 아키텍처

k8s 마스터와 워커 노드 구성도

쿠버네티스는 마스터 노드와 워커 노드로 구성된다. 쉽게 생각하면 마스터 노드는 클러스터 상태를 관리 및 조정하는 역할, 워커 노드는 클러스터 내에서 응용 프로그램을 실행하기 위한 컴포넌트 역할이다. 이번 시간에는 마스터 노드를 구성하는 기능들과 각 역할에 대해서 알아보도록 하자.

Master Node (= Control Plane) 구성도

(1) Kube-API-Server

워커 노드와 통신하는 주체로 클러스터 내의 모든 명령과 통신은 Kube-API-Server를 통해서 이루어진다.
Etcd 저장소와 직접 상호 작용하는 유일한 구성 요소이다. (Etcd는 아래에 설명)
kubectl command는 API Sever로 전송되고 해당 서버는 명령을 처리할 수 있는 다른 컴포넌트에게 요청을 전달한다.

(2) Kube-Scheduler

새로운 pod가 생성되면 이를 감지하여 어떤 워커 노드로 배치할지 결정하는 작업을 ‘스케줄링’이라고 하며 → 이러한 스케줄링을 담당하는 것이 Kube-Scheduler이다.
pod의 리소스 요구사항, 노드의 가용성 등을 모두 고려하여 어떤 워커 노드로 배치될지 결정된다. (참고로, pod는 k8s에서 실행되는 기본 작업 단위)

kube-scheduler 스케줄링 알고리즘

(1) 가중치 기반(Weighted) 알고리즘
: 노드의 리소스 용량 및 부하 상태 등을 고려하여 노드에 가중치를 부여하고, 이를 기반으로 스케줄링을 결정 → 가중치가 높은 워커 노드에 우선적으로 pod가 할당되는 방식

(2) 라운드 로빈(Round Robin) 알고리즘
: 워커 노드의 순서대로 pod가 할당되는 방식 → 모든 워커 노드에 균등하게 pod를 배치할 수는 있지만 노드의 상태 같은 부분은 고려하지 않음

(3) 랜덤(Random) 알고리즘
: 워커 노드를 랜덤으로 선택하여 pod가 할당되는 방식 → 가장 간단하고 빠르게 동작하지만 노드 상태나 부하 등을 역시 고려하지 않음

각 스케줄링 알고리즘은 클러스터의 요구사항과 운영 환경에 따라 저마다 적합한 방식이 있다. 예를 들어,

리소스 부족 상황 → Weighted 알고리즘

균형잡힌 부하 분산이 요구되는 상황 → Round Robin 알고리즘

pod 간의 우선순위가 없는 상황 → Random 알고리즘

처럼 각 클러스터 상황에 적절한 스케줄링 알고리즘을 정할 수 있다. (하지만 반드시 A상황에는 B알고리즘이 적합하다는 식으로 일반화하는 것은 No)

(3) Kube-Controller-Manager

클러스터 내에서 실행되는 Controller를 통합 관리하는 프로세스
워커 노드를 관리하는 주체로, API Server를 통해 클러스터의 상태를 감시하고 조치하는 역할이다.
(참고) Controller는 시스템 내의 컴포넌트들의 상태를 지속적으로 모니터링하여 선언된 상태(desired state)가 유지될 수 있도록 하는 역할

(4) Etcd

클러스터 상태와 설정 정보를 key-value로 보관하는 DB(Store) → ex. 클러스터 및 리소스 정보, 상태정보 등
API Server가 현재 가지고 있는 선언된 상태에 대한 값을 백업해두는 곳으로 안전을 위해 분산 저장한다.
참고로 $kubectl get pods 명령과 같은 command는 Etcd 서버로부터 정보를 가져오는 것이다.

이번 시간에는 쿠버네티스가 무엇인지와 아키텍처 중 마스터 노드에 대해서 알아봤다. 새로운 기술을 배우기 위해서는 그 기술의 아키텍처를 먼저 이해하는 것이 중요하다고 말할 수 있다. 아키텍처를 익히면 내부 동작이 어떻게 이뤄지는지 더 이해하기 쉽기 때문이다. 이번에는 쿠버네티스 마스터 노드에 대해서 알아보았고, 다음에는 워커 노드의 구성에 대해서 알아볼 예정이다.

[k8s] 도커와 쿠버네티스의 관계

DH’s Blog — Sat, 13 Apr 2024 15:19:59 +0900

지난 시간에는 가상화 배포 환경에서 컨테이너 배포 환경으로 바뀌게 된 이유와 컨테이너가 무엇인지에 대해서 알아보았다. 컨테이너 기술과 관련된 내용 중에 우리가 가장 많이 들어본 것이 도커(Docker)와 쿠버네티스(kubernetes, k8s)이다. 처음 공부를 하는 경우 도커랑 쿠버네티스를 많이 헷갈려하는데 이번에는 그 둘의 관계성에 대해서 자세히 알아보는 시간을 가져보도록 하자.

참고로, 쿠버네티스를 Kubernetes 혹은 k8s (k~s 중간에 8개의 글자가 있어서)라고도 부른다.

[지난 시간 내용]

2024.04.13 - [[기술공부]/Kubernetes] - [k8s] 컨테이너 등장 배경 with 가상화 배포 환경

[컨테이너 기술의 배경 with Docker & k8s]

시간이 지나면서 S/W 개발과 배포 과정은 복잡해졌고, 이러한 복잡성을 관리하기 위해 컨테이너화 기술이 등장하게 되었다. 이때 등장한 기술이 Docker(by. Docker.Inc)이고 컨테이너 생성, 배포, 관리를 쉽게 하는 것을 지원해주었다.

점차 컨테이너 사용이 일반화 되면서 어떻게 하면 많은 컨테이너들을 관리하고 조율할 수 있을지에 대해 고민을 하기 시작했고, 이러한 부분을 해결하기 위해 등장하게 된 기술이 Kubernetes(by. Google)이다.

다시 말하자면,

Docker → 컨테이너의 생성과 배포를 단순화 시켜주는 기술

Kubernetes → 컨테이너의 생명 주기를 관리하고 스케일링 및 장애 복구를 자동 처리해주는 기술

처음에는 도커와 쿠버네티스를 함께 사용할 때 시너지가 발생하면서 상호 보완적인 기술이었고, 쿠버네티스는 도커 외의 다른 런타임 엔진은 지원하지 않았다. 하지만 도커는 컨테이너를 사용하는 사용자 경험에 집중하면서 Monolithic(단일) 아키텍처를 나누는 작업을 하면서 도커 엔진 내에 API, CLI, Network, Storage와 같은 여러 기능이 추가 되었다.

결국, Docker 새로운 버전이 나올 때 마다 쿠버네티스도 함께 영향을 받게 되었고 또한 한편에서는 다른 컨테이너 런타임 엔진을 지원해달라는 요구도 나오게 되었다. 이러한 계기로 컨테이너 기술에 대한 표준을 정하는 OCI(Open Container Initiative) 오픈 소스 프로젝트가 시작되었다.

본 프로젝트(OCI)를 통해 도커와 쿠버네티스는

Docker → OCI 표준을 준수하는 컨테이너 런타임인 Containerd

Kubernetes → OCI 표준을 준수하는 Container Runtime Interface를 개발하게 되었다.

이를 통해 도커의 버전에 상관없이 모든 컨테이너 이미지를 쿠버네티스 환경에서 실행 가능하게 되었다. 그리고 Containerd는 컨테이너의 생명주기를 관리하기 위한 최소한의 필요 기능만 제공하여 가벼운 런타임 엔진이 될 수 있었다. 그래서 요즘 많은 회사에서 Containerd 런타임 엔진과 쿠버네티스를 함께 사용하고 있다.

이 내용을 알고 나면 도커와 쿠버네티스가 다시 헷갈리진 않을 것이다. 항상 새로운 기술을 배우기 전에는 그 기술이 등장하게 된 배경에 대해서 찾아보면 이해가 더 잘 될 수 있다. 오늘도 이 내용이 많은 사람들에게 도움이 되었으면 좋겠다:)

(참고 페이지)
https://www.linkedin.com/pulse/containerd%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B4%EA%B3%A0-%EC%99%9C-%EC%A4%91%EC%9A%94%ED%95%A0%EA%B9%8C-sean-lee/

[k8s] 컨테이너 등장 배경 with 가상화 배포 환경

DH’s Blog — Sat, 13 Apr 2024 14:56:18 +0900

요즘 많은 기업에서 클라우드에 관심을 가지고 있고,

현재 재직중인 회사에서도 클라우드 빅데이터 플랫폼을 출시하면서 쿠버네티스 환경을 많이 사용하고 있다.

이번 기회를 통해, 쿠버네티스가 무엇이며 어떠한 구성 원리로 이루어지는지 배워보려 한다.

새로운 기술을 처음 배울 때는, 그 기술이 왜 등장했는지를 먼저 알게되면 이후의 내용을 이해하는데 도움이 된다.

그래서 이번 시간에는 본격적인 쿠버네티스에 대한 내용에 들어가기 앞서,

가상화 환경이 무엇이고? 컨테이너 환경이 도입된 이유에 대해서 알아보도록 하자.

과거에는 한 컴퓨터에 하나의 OS를 설치하고 그 위에 여러 프로그램을 실행하는 방식으로, 한 두개의 프로그램 때문에 전체 컴퓨터의 성능이 떨어지는 문제가 있었다. (어릴적 컴퓨터에 게임을 몇 개 설치했다가 컴퓨터 성능이 저하되어 잔소리를 들은 경험이 있지 않은가? ) 이러한 문제를 해결하기 위해 한 컴퓨터에 가상 컴퓨터를 여러 개 구동되는 것처럼 구현하기 위해 가상화 배포(Virtualized Deployment) 방식이 등장하게 되었다.

[가상화의 종류]

1. Host OS 가상화

물리머신(H/W) 위에 OS를 설치하고, 그 위에 가상화 S/W(ex. VirtualBox)와 가상머신을 움직이는 방식
우리는 H/W 위에서 직접 동작하는 OS를 '호스트 OS(Host OS)'라고 부르고, 가상머신 위에 설치된 OS를 '게스트 OS(Guest OS)'라고 부른다.
ex) 본인 PC에 VM S/W를 설치하고 그 위에 게스트 OS를 설치하는 방식 → PC 리소스를 공유하는 방식

2. Hypervisor 가상화

호스트 OS 없이 H/W 위에 Hypervisor S/W를 설치하여 사용하는 가상화 방식 → Hypervisor는 H/W와 가상 머신 간의 중재자 역할을 하며, Hypervisor가 직접 H/W를 관리하기 때문에 호스트 OS가 필요하지 않다
호스트 OS가 없어서 가상 머신은 독립된 호스트 시스템처럼 행동할 수 있고 오버헤드가 적다.
ex) H/W 위에 Hypervisor S/W를 설치하고 그 위에 게스트 OS를 설치하는 방식 → 오버헤드가 적은 방식

[가상화 배포에서 컨테이너 배포로 바뀌게 된 이유]

(참고)
컨테이너 - S/W App 실행에 필요한 환경을 독립적으로 운용가능한 기술
Hypervisor - 단일 시스템 위에 가상 컴퓨터(VM)을 여러 개 구동할 수 있도록 만들어주는 계층

가상화 배포는 단일 물리 서버(H/W)에서 여러 가상머신(VM)을 실행할 수 있었지만, 가상머신마다 OS(게스트 OS) 설치가 필요하여 리소스를 너무 많이 사용하게 되면서 무거워졌다. 그래서 컨테이너를 도입하며 호스트 OS와 커널을 공유하면서 이전보다 가벼운 가상화 구현이 가능해지게 되었다.

[컨테이너 배포]

1. 컨테이너와 이미지의 관계

(1) Image

컨테이너 실행에 필요한 파일과 실행할 애플리케이션 설정을 포함한 file 패키지
ex. 웹 서버를 실행하기 위한 file, 환경설정 등

(2) Container

이미지를 기반으로 생성된 인스턴스(가상 환경)
이미지 내의 파일과 애플리케이션을 통해 구체화된 상태

2. 컨테이너 배포(Container Deployment)의 구성

App: 실행하려는 프로그램
Bin(바이너리)/Library: 프로그램이 실행하는데 필요한 환경과 관련된 file
Container: App이 구동되는 환경까지 감싸서 실행할 수 있는 격리 기술
Container Runtime: 컨테이너를 내려받거나 구동할 수 있도록 도와주는 컨테이너 실행 엔진(ex. Docker)

결국, 컨테이너는 게스트 OS 없이 가벼운 가상화 구현을 가능하게 해주었고 이러한 컨테이너를 생성하고 관리하기 위한 기술들이 등장하게 되는데 이것이 흔히 아는 도커(Docker), 쿠버네티스(Kubernetes)이다. 그럼 다음 시간에는 본격적으로 쿠버네티스가 등장한 배경과 개념에 대해서 배워보도록 하자.

(참고 페이지)
https://www.samsungsds.com/kr/insights/220222_kubernetes1.html

[Airflow] Connection 연결시 [Test] 버튼 비활성화된 경우 해결하는 방법

DH’s Blog — Sun, 4 Feb 2024 22:36:41 +0900

Airflow에서 Connection 연결하기 전, Connection 연결 정보가 올바르게 입력되었는지 확인하기 위해서 [Test] 버튼을 눌러 확인하고 이상이 없으면 [Save] 버튼을 눌러 커넥션을 저장하게 된다. 하지만 상황에 따라 아래와 같이 [Test] 버튼이 비활성화될 수 있는데, 이 문제를 해결하는 방법을 알아보도록하자.

여담으로 나도 처음에는 버튼이 비활성화되어 있어서, MySQL DB 연결시 커넥션 정보가 올바른지에 대해 확인이 어려웠다. 인터넷을 찾아보던 중 Airflow 내의 설정값 수정을 통해 해결할 수 있다는 것을 알아낼 수 있었다.

[Test] 비활성화된 상황

먼저, 해결 방법을 간단히 설명하자면

Airflow webserver 컨테이너 내에서의 airflow.cfg이란 설정 파일 내의 'test_connection = Disabled ' 값을 'test_connection = Enabled '로 수정해서 해결할 수 있으며, 한단계씩 설명해보도록 하겠다.

1. Airflow-webserver 컨테이너 접근 후 패키지 업데이트 하기

: container 내부를 root 권한으로 접속하여 vim을 사용하기 위해 패키지 업데이트를 진행한다.

# airflow webserver container명 확인
sudo docker ps

# airflow webserver container bash 접근
# -u root : container 내부에서의 사용자를 'root'로 지정
# sudo docker exec -it -u root ${airflow-webserver-container명} bash 
sudo docker exec -it -u root dhkim-airflow-webserver-1 bash

apt update
apt install vim

webserver 컨테이너 접근

2. Airflow-webserver 컨테이너 내부에서 airflow.cfg 파일을 vim 편집기로 수정하기

: airflow.cfg 파일에서 test_connection 설정값을 Disabled → Enabled로 수정한다.

# airflow webserver container에서 airflow.cfg 파일 vim으로 열기
ls -al
vim airflow.cfg


# ------------------- airflow.cfg vim 편집 ------------------- #
# 수정할 내용: test_connection = Disabled --> Enabled로 수정
# 편집방법: [i]눌러서 수정모드 --> Enabled로 수정 --> [Esc]로 수정모드 종료 --> [:wq!] 입력 후 Enter로 저장하고 빠져나오기

...
test_connection = Enabled
...

# ------------------- airflow.cfg vim 편집 ------------------- #

airflow.cfg 파일 편집 전(왼쪽), 후(오른쪽)

※ airflow.cfg 내부에서 test_connection 위치를 찾는 방법 2가지

(1) vim 편집기를 열고 :set number 입력 후 [Enter]하면 행 번호 확인 → 407번 row에서 확인 가능 (참고로, airflow 버전에 따라 row 행번호가 조금 다를 수 있다)

(2) vim 편집기를 열고 /test_connection 입력 후 [Enter]하면 해당 텍스트로 바로 접근 가능

3. Airflow-webserver 컨테이너에서 빠져나와서 컨테이너 재시작

: webserver 컨테이너를 재시작하면 Connection [Test] 버튼이 활성화된 것을 확인할 수 있다.

# container에서 나오기
exit

# container 재시작
# sudo docker restart ${airflow-webserver-container명}
sudo docker restart dhkim-airflow-webserver-1

위의 과정을 통해 Airflow 웹페이지에서의 Connection 진행시 [Test] 버튼이 비활성화된 것을 해결할 수 있었다. 처음에는 내 컴퓨터의 오류인가?라고 생각했었는데 알고보니 Airflow-webserver 컨테이너 내부 설정값이 원인이었다. 나와 같은 문제를 접한 사람들에게 이 글이 많은 도움이 되었으면 좋겠다:)

[Airflow] docker-compose.yaml로 Jupyter 컨테이너 올리기 - (2)

DH’s Blog — Tue, 23 Jan 2024 18:33:47 +0900

지난 시간에는 docker-compose.yaml 파일을 이용하여 Jupyter 컨테이너를 올려보는 과정을 알아보았다. 이번에는 Jupyter에서 Mariadb 컨테이너 데이터를 불러오는 과정을 진행해보고자 한다.

[지난 시간 내용 - Jupyter 컨테이너 올리기]

2024.01.23 - [[기술공부]/Apache Airflow] - [Airflow] docker-compose.yaml로 Jupyter 컨테이너 올리기 - (1)

[Airflow] docker-compose.yaml로 Jupyter 컨테이너 올리기 - (1)

지난 시간에 Mariadb 컨테이너를 올리고 테스트 데이터를 만들어보았다. 이번 시간에는 Jupyter 컨테이너를 올리는 과정을 알아보고, 다음 시간에는 Jupyter에서 Mariadb 컨테이너 데이터를 불러오는 방

developers-haven.tistory.com

(설명) 전체적으로 아래와 같은 아키텍처를 구축하려고 하며, 3번 과정에서 Mariadb 데이터를 Jupyter로 불러오는 과정을 진행해보고자 한다.

내용에 들어가기 앞서, docker-compose.yaml에 추가한 Jupyter 컨테이너 내용을 짚고 넘어가자.

# docker-compose.yaml
services:
  jupyter:
    image: jupyter/base-notebook:latest
    container_name: jupyter-container
    environment:
      # Jupyter notebook 접속시 사용할 패스워드
      - JUPYTER_TOKEN=${password}
    volumes:
      - ./notebooks:/home/jovyan/work
    restart: always
    ports:
      - 8888:8888
    networks:
      network_custom:
        ipv4_address: 172.28.0.2
        
networks:
  network_custom:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.28.0.0/16
          gateway: 172.28.0.1

※ 바인드 마운트 방식이란?

volumes:
      - ./notebooks:/home/jovyan/work

호스트 머신의 로컬 디렉터리(./notebooks)를 jupyter 컨테이너 내부 디렉터리(/home/jovyan/work)에 연결하는 바인드 마운트 방식
즉, 사용자가 호스트 머신의 특정 경로를 컨테이너에 직접 연결시키는 방식이며, 호스트 머신의 파일 시스템에 직접 액세스하여 데이터를 수정할 수 있게 된다. (해당 변경 사항은 실시간으로 양쪽에 반영된다)
DB 데이터와 달리 ipynb 파일에 직접 접근하고 수정해야하는 상황이 있을 수 있기에 직접 로컬 디렉터리 위치를 지정해주는 바인드 마운트 방식을 적용했다.

1. Jupyter notebook 접속

http://localhost:8888/
Password or Token → docker-compose.yaml에서 jupyter 컨테이너에서 설정한 토큰 or 패스워드 입력 후 [Log in] 클릭

토큰 or 패스워드 입력

Jupyter 브라우저 접속 완료

2. Jupyter notebook에서 Mariadb 컨테이너 데이터 불러오기

이전 시간에 Mariadb 컨테이너를 올리고 샘플 데이터를 적재하는 과정까지 완료했었다. 만약 이 내용을 아직 보지 못했다면 아래 페이지를 참고하도록 하자.

[참고 - Mariadb 컨테이너 올리고 데이터 적재하기]

2024.01.18 - [[기술공부]/Apache Airflow] - [Airflow] docker-compose.yaml로 mariaDB 컨테이너 올리기 & DBeaver 연결하기

[Airflow] docker-compose.yaml로 mariaDB 컨테이너 올리기 & DBeaver 연결하기

이번 시간에는 docker-compose.yaml 스크립트를 이용하여 mariaDB 컨테이너를 올리고 DBeaver 연결까지 하는 방법을 알아보도록 하자. [1단계 - mariaDB 컨테이너 올리기] 1. 컨테이너가 사용하고 있는 default n

developers-haven.tistory.com

Mariadb container - 샘플 데이터

(2-1) Jupyter 컨테이너 접속해서 필요한 라이브러리 설치

# jupyter 컨테이너 접근
# sudo docker exec -it ${container명} bash
sudo docker exec -it jupyter-container bash

# bash
pip install mysql-connector-python

라이브러리 설치 완료

(2-2) Jupyter 화면에서 work 폴더 더블 클릭 > python3 notebook 선택 > test.ipynb 생성

Jupyter notebook의 컨테이너 디렉터리를 /home/jovyan/work로 설정했으므로 work 디렉터리에 들어가서 코드를 생성해야한다.

work 폴더 내에서 ipynb 코드 생성

(2-3) test.ipynb에 아래 코드 작성 후 실행

import mysql.connector
from mysql.connector import Error

# mariadb container 접속정보
# docker-compose.yaml에 추가한 mariadb 컨테이너 정보
db_config = {
	'host': 'mariadb-container', # mariadb 컨테이너명
	'port': 3306, # mariadb 컨테이너접속포트
	'database': 'mariadb', # mariadb 데이터베이스명
	'user': '${DBeaver_Username}', # mariadb 접속정보 유저명
	'password': '${DBeaver_Password}' # mariadb 접속정보 패스워드
}

query = "SELECT * FROM test_table"

try:
	with mysql.connector.connect(**db_config) as connection:
		with connection.cursor() as cursor:
			cursor.execute(query)
			result = cursor.fetchall()
			print(result)
except Error as e:
	print(f"Error: {e}")

# 코드 설명
▶db_config 정보를 이용하여 mariadb 컨테이너를 연결하고, "SELECT * FROM test_table" 쿼리를 실행하여 결과를 가져오는 코드
▶try~except를 통해서 모든 과정이 올바르면 데이터를 가져오고, 만약 문제가 발생하면 에러 메세지 표시

# db_config 설명 (모든 내용은 아래 docker-compose.yaml에 추가한 내용 기반)
▶host: mariadb 컨테이너명
▶port: mariadb 컨테이너 접속 포트
▶database: mariadb 데이터베이스명 ${MYSQL_DATABASE}
▶user: mariadb 접속 유저명 ${MYSQL_USER}
▶password: mariadb 접속 패스워드 ${MYSQL_PASSWORD}

※ (참고) docker-compose.yaml의 Mariadb 컨테이너 정보

services:
  mariadb:
    image: mariadb:10
    container_name: mariadb-container
    environment:
      MYSQL_USER: ${user}
      MYSQL_PASSWORD: ${passwd}
      MYSQL_ROOT_PASSWORD: ${root_passwd}
      MYSQL_DATABASE: ${db_name}
      TZ: Asia/Seoul
    volumes:
      - mariadb-db-volume:/var/lib/mysql
    restart: always
    ports:
      - 3307:3306
    networks:
      network_custom:
        ipv4_address: 172.28.0.2

(2-4) Mariadb 컨테이너 내의 test_table 테이블 데이터 불러오기 완료

참고로, 이전 시간에 서비스들 간의 고정 IP를 지정해주었고 이 과정은 Mariadb, Jupyter 간에 같은 네트워크를 사용하고 있기에 통신이 가능한 것이다.

Mariadb 컨테이너 데이터 불러오기 완료

3. (선택사항) 바인드 마운트가 정상 작동하는지 확인

(3-1) 호스트 머신 local directory 확인 → test.ipynb 파일 존재 확인

로컬 디렉터리 내에서 test.ipynb 파일이 존재하는 것을 확인할 수 있다.

# 현재위치: docker-compose.yaml 스크립트가 있는 위치
pwd

cd notebooks/
ls

(3-2) container 내부 확인 → test.ipynb 파일 존재 확인

컨테이너 내부에서 test.ipynb 파일이 존재하는 것을 확인할 수 있다.

# jupyter 컨테이너 접근
# sudo docker exec -it ${container명} bash
sudo docker exec -it jupyter-container bash

# bash
cd work/
ls

→ Jupyter 컨테이너의 바인드 마운트 방식이 올바르게 적용되었음을 확인했고, 컨테이너 재기동 여부와 상관없이 ipynb 파일은 계속 남아있게 된다. 바인드 마운트 방식은 호스트, 컨테이너 디렉터리에 모두 접근할 수 있으며 서로 간의 데이터 변경이 발생하면 실시간으로 동기화된다.

※ (참고) 볼륨과 바인드 마운트 방식의 차이?

Mariadb, Jupyter 컨테이너를 올리기 위해서 각각 볼륨과 바인드 마운트 방식을 사용했는데 왜 서로 다르게 지정했을까?

# docker-compose.yaml

services:
  jupyter:
    volumes:
      # 바인드 마운트 방식
      - ./notebooks:/home/jovyan/work

  mariadb:
    volumes:
      # 볼륨 방식
      - mariadb-db-volume:/var/lib/mysql
      
...

volumes:
  mariadb-db-volume:

docker-compose.yaml에서 설정한 컨테이너 내용

◎ 볼륨(volume) - Mariadb

볼륨은 도커가 직접 호스트 파일 시스템(로컬) 일부에 데이터 저장 공간을 지정하여 관리하는 방식으로, 컨테이너 생명 주기와 상관없이 데이터를 독립적으로 유지할 수 있다. (컨테이너를 재기동해도 데이터가 남아있다)
위의 yaml 파일 기준으로 mariadb-db-volume 볼륨이 컨테이너 내부 디렉터리(/var/lib/mysql)에 마운트되는 방식이다.

◎ 바인드 마운트(bind mount) - Jupyter

사용자가 직접 호스트 머신(로컬)의 특정 디렉터리를 컨테이너와 연결시키는 방식으로, 호스트 머신의 파일 시스템에 직접 액세스하여 데이터를 수정할 수 있다. (변경 시 실시간으로 양쪽에 반영된다)
위의 yaml 파일 기준으로 호스트 머신의 로컬 디렉터리(./notebooks)를 컨테이너 내부 디렉터리(/home/jovyan/work)에 연결하는 방식이다.

→ 쉽게 생각하면 볼륨은 도커가 로컬 디렉터리 일부의 저장 공간을 관리할 수 있도록 하는 것이고, 바인드 마운트는 사용자가 직접 로컬 디렉터리를 지정하여 관리하게 되는 것이다. DB 데이터와 달리 분석용 노트북 ipynb 파일은 내가 직접 접근하고 수정하는 상황이 있을 수 있다고 생각하여 바인드 마운트 방식을 사용하게 되었다.

지금까지 Jupyter 컨테이너를 올리고 Mariadb 컨테이너의 데이터를 불러오는 과정까지 정리해보았다. 그리고 볼륨과 바인드 마운트 방식의 차이에 대해서도 알아볼 수 있었다. 오늘도 이 내용이 많은 사람들에게 도움이 되었으면 좋겠다:)