쿠버네티스 자격증인 CKAD를 따기 위해 꼭 알고 가야하는 기초 개념 6가지를 정리해보았다.
컨테이너, 이미지, 런타임, pod, node, cluster!
1. Container
Kubernetes는 container를 관리하고 운영하는 컨테이너 오케스트레이션 플랫폼이다.
이때 container란 애플리케이션과 실행에 필요한 환경을 하나로 묶어서 실행하는 기술이다. 어디서 실행해도 동일하게 돌아가게 만드는 것이 제일 중요하다.
예를 들어, 파이썬, Flask, Redis가 깔려있는 내 컴퓨터에서는 A 프로그램이 돌아가지만,
다른 개발자 PC에서는 안 되는 경우가 있다.
이 개발 환경과 프로그램을 통째로 묶어놓은 것이 container다.
컨테이너 이미지
├ 애플리케이션
├ 라이브러리
├ 실행환경
└ 설정
이런 컨테이너는 어디서 만들까?
대표적인 컨테이너 기술은 Docker이다.
Docker로 컨테이너를 만들고 실행할 수 있고, Kubernetes로 컨테이너를 대규모 관리할 수 있다.
예를 들어, Kubernetes는 컨테이너를 대규모로 1000개 실행하고 자동확장, 복구, 로드밸런싱 해준다.
쿠버네티스가 하는 일
- container 관리
- 컨테이너 실행
- 컨테이너 중지
- 컨테이너 재시작
- 여러 서버에 배치
- 오퍼레이션(운영 자동화)
- 자동 배포
- 자동 확장
- 장애 복구
- 로드밸런싱
- 롤링 업데이트
2. Image
container를 실행하려면 먼저 Image가 필요하다.
Image는 컨테이너를 만들기 위한 설계도라고 생각하면 된다.
즉, 컨테이너가 실행될 때 필요한 앱, 라이브러리, 실행환경, 설정 정보가 모두 들어있는 패키지다.
Image는 exe 파일과 비슷하다고 생각하면 이해하기 쉽다.
exe 파일을 실행하면 프로그램이 실행되듯이, Image를 실행하면 Container가 생성된다.
Container는 Image를 기반으로 생성된다.
Image → 실행 → Container
예를 들어 어떤 웹 어플리케이션을 실행한다고 가정해보자.
이 앱이 실행되기 위해서 다음과 같은 환경이 필요하다.
Python
Flask
Redis
애플리케이션 코드
환경설정
이 모든 것을 하나의 패키지로 묶어놓은 것이 바로 Image다.
이 이미지를 실행하면 Container가 생성되고 프로그램이 실행된다.
Image
├ Python
├ Flask
├ Redis
├ 애플리케이션 코드
└ 환경설정
장점
같은 Image를 사용하면 어디서 실행하든 동일한 환경에서 동일한 앱이 실행된다는 점이 가장 큰 장점이다.
Image는 어디에 저장할까?
Image는 보통 Image Registry라는 저장소에 저장한다.
대표적인 Image 저장소
- Docker Hub
- Amazon Elastic Container Registry
- Google Container Registry
실행 구조
개발자 → Image 생성 → Registry 저장
서버 → Image 다운로드 → Container 실행
3. Container Runtime
Image가 컨테이너를 만들기 위한 설계도라면,
Container Runtime은 그 Image를 실제로 실행해서 Container를 만들어주는 프로그램이다.
즉, Image를 실행해 컨테이너를 생성하고 관리하는 소프트웨어이다.
실행 구조
Image → Container Runtime → Container
Container Runtime이 하는 일
- Image 다운로드
- Container 생성
- Container 실행
- Container 중지
- Container 삭제
예를 들어, 어떤 서버에서 컨테이너를 실행한다고 하면 다음과 같은 과정이 일어난다.
1. Kubernetes가 컨테이너 실행 요청
2. Node에서 Image 다운로드
3. Container Runtime이 Image 실행
4. Container 생성
5. 애플리케이션 실행
즉, Container Runtime은 실제로 컨테이너를 실행하는 역할을 한다.
대표적인 Container Runtime
- containerd
- CRI-O
이전에는 Docker도 쿠버네티스에서 많이 사용되었지만, 현재는 containerd가 가장 많이 사용되는 Runtime이다.
또 중요한 점은, Container Runtime은 Kubernetes가 컨테이너를 실행 요청할 때도 필요하다.
Kubernetes는 컨테이너 실행을 Container Runtime에게 요청한다.
요청/실행 구조
Kubernetes →요청→ Container Runtime → Container 실행
4. Pod
지금까지는 Container에 대해 설명했고, 컨테이너의 실행 흐름은 다음과 같다.
1. Kubernetes가 컨테이너 실행 요청
2. Image 준비
3. Container Runtime이 Image 실행
4. Container 생성
5. 애플리케이션 실행
즉, 지금까지 설명한 구조에서는 Container Runtime이 Image를 실행해 Container를 생성하는 방식이었다.
하지만 Kubernetes에서는 Container를 직접 실행하지 않는다.
Kubernetes에서 Container를 실행하는 최소 단위는 Pod이고,
Kubernetes는 Container가 아닌 Pod를 생성하고 관리한다.
Kubernetes → Pod 생성 → Container Runtime → Container 실행
Pod 안에는 여러 개의 Container가 들어갈 수 있다.
Pod가 필요한 이유는 뭘까?
그렇다면 Kubernetes는 왜 Container를 직접 실행하지 않고 Pod를 사용할까?
그 이유는 여러 Container를 하나의 실행환경으로 묶기 위해서다.
예를 들어, 어떤 웹 어플리케이션이 있다고 가정해보자.
웹 서버
로그 수집 프로그램
모니터링 프로그램
이 프로그램들이 항상 함께 실행되어야 한다면 이들을 하나의 Pod로 묶을 수 있다.
Pod
├ Container (Web Server) ← Image 1
├ Container (Log Collector) ← Image 2
└ Container (Monitoring) ← Image 3
이렇게 하면 같은 네트워크와 저장소를 공유하면서 함께 동작할 수 있다.
Pod의 특징
- 같은 네트워크 사용
Pod 안에 있는 Container들은 같은 IP 주소를 사용한다.
즉, 같은 Pod 안의 Container들은 localhost로 서로 통신할 수 있다. - 스토리지 공유 가능
Pod 안의 Container 들은 같은 저장소를 공유할 수 있다. - 항상 함께 생성되고 함께 삭제됨
Pod 안에 있는 Container들은 생명주기를 함께한다.
Container를 개별적으로 관리하는 것이 아니라 Pod 단위로 관리된다.
Kubernetes의 전체적인 실행 구조
Cluster
├ Node
│ ├ Pod
│ │ └ Container
│ │ ↑
│ │ Container Runtime
│ │ ↑
│ │ Image
- Cluster : Kubernetes 전체 환경 (바로 뒤뒤에 설명)
- Node : Pod가 실행되는 서버 (바로 뒤에 설명)
- Pod : Container 실행 단위
- Container : 실제 애플리케이션
5. Node
Pod가 Kubernetes에서 Container를 실행하는 최소 단위라면,
Node는 Pod가 실제로 실행되는 서버이다.
즉, Node는 컨테이너가 실행되는 물리 서버 또는 가상 서버라고 보면 된다.
Kubernetes Cluster에는 보통 여러 개의 Node가 존재한다.
Cluster
├ Node
│ └ Pod
│ └ Container
├ Node
│ └ Pod
│ └ Container
└ Node
└ Pod
└ ContainerKubernetes는 여러 Node에 Pod를 자동으로 배치하고 관리한다.
Node에서 컨테이너가 실행되는 과정
Pod가 생성되면 Kubernetes는 어떤 Node에서 실행할지 결정한다.
그리고 선택된 Node에서 다음과 같은 과정이 일어난다.
1. Kubernetes가 Pod 생성
2. Pod가 특정 Node에 배치됨
3. Node의 Container Runtime이 Image 다운로드
4. Container Runtime이 Container 실행
5. 애플리케이션 실행즉, 실제로 Container를 실행하는 것은 Node 안에 있는 Container Runtime이다.
Node의 구성 요소
Node에는 Pod를 실행하기 위해 몇 가지 중요한 구성 요소가 있다.
- Container Runtime
컨테이너를 실제로 실행하는 프로그램(containerd, CRI-O) - kubelet
Node에서 동작하는 Kubernetes 에이전트, Kubernetes와 Node를 연결하는 역할
역할
- Kubernetes로부터 Pod 실행 요청 받기
- Container Runtime에게 컨테이너 실행 요청
- Pod 상태를 Kubernetes에 보고 - kube-proxy
Pod 간 네트워크 통신을 관리하는 구성 요소
Node
├ kubelet
├ kube-proxy
├ Container Runtime
└ Pod
└ Container
구조를 정리하면 다음과 같다.
- Pod: Container 실행 단위
- Node: Pod가 실행되는 서버
6. Cluster
지금까지는 Container, Pod, Node에 대해 설명했다.
이제 Kubernetes의 전체 구조를 보면 다음과 같다.
Kubernetes
↓
Cluster
├ Node
│ └ Pod
│ └ Container
├ Node
│ └ Pod
│ └ Container
└ Node
└ Pod
└ Container
Cluster는 여러 Node를 묶어 하나의 Kubernetes 환경을 구성한 것이다.
Cluster가 필요한 이유
하나의 서버(Node)만으로도 컨테이너를 실행할 수 있다.
하지만 실제 서비스에서는 다음과 같은 문제가 발생한다.
- 서버 자원이 부족해질 수 있다.
- 트래픽이 증가한다.
- 서버 장애가 발생할 수 있다.
그래서 하나의 서버가 아닌 여러 서버를 하나의 Cluster로 묶어 관리한다.
Kubernetes가 하는 일
Cluster 안에서 Kubernetes는 다음과 같은 일을 한다.
- Pod 배치
Pod가 생성되면 어떤 Node에서 실행할지 자동으로 결정한다.
- Pod 생성 → Kubernetes Scheduler → Node 선택→Pod 실행 - 자동 확장
트래픽이 증가하면 Pod 개수를 자동으로 늘릴 수 있다. - 장애 복구
Pod가 죽으면 Kubernetes가 자동으로 새로운 Pod를 생성한다. - 로드 밸런싱
여러 Pod가 있을 때 트래픽을 자동으로 분산한다.
마무리
지금까지 설명한 구조를 정리하면 다음과 같다.
Cluster
├ Node
│ ├ Pod
│ │ └ Container
│ │ └ Container
│ ├ Pod
│ │ └ Container
│
├ Node
│ ├ Pod
│ │ └ Container
그리고 Container는 다음 과정을 통해 실행된다.
Image
↓
Container Runtime
↓
Container
마지막으로 구분해야 할 점
Pod 안의 Container들은 강하게 연관되어 있다.
항상 함께 스케줄링되고 함께 종료한다.
Pod
├ app container (웹 서버)
└ sidecar container (로그 수집)
Node(서버) 안에 있는 Pod들은 서로 연관이 없어도 된다.
그냥 Pod를 실행하는 물리/가상 서버로 보면 된다.
Node1
├ Pod (쇼핑몰 API)
├ Pod (추천 시스템)
├ Pod (배치 작업)
└ Pod (모니터링 agent)이 Pod들은 서로 독립적이지만 같은 Node에서 실행된다.