이 게시물은 인프런 -
쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2
강의에 대한 복습 및 정리용 게시물입니다.
그리고 여기에서 나오는 모든 이미지들은 해당 강의가 출처임을 미리 말씀드립니다.
기술의 흐름으로 이해하는 컨테이너
쿠버네티스를 잘 사용하기 위해서는 반드시 컨테이너 에 대한 이해가 있어야 합니다.
하지만 컨테이너라는 용어 자체가 정말 큰 개념이라서 단순 용어 설명으로는 이해하기 힘듭니다.
그래서 컨테이너 기술에 전반적인 배경을 이해하는 게 중요하다고 생각합니다.
이번 글은 쿠버네티스를 잘 이해하기 위해 컨테이너를 중심으로한
여러 배경 흐름 들을 이야기 합니다.
1. Linux OS 흐름
컨테이너를 잘 알기 위해서는 먼저 Linux 에 대해 알 필요가 있습니다.
- 최초에 OS로
unix가 생김. - 시간이 지나 unix 와 거의 똑같지만 무료인
linux가 나옴 - 이후
linux를 기반으로 수많은 배포판이 오늘날까지 생기고 있습니다.
수많은 배포판을 다 알 필요는 없으며 그중에서
debian 계열과 redhat 계열의 배포판만 알면 충분합니다.
참고:
debian linux는 커뮤니티용으로 무료이고
redhat linux는 redhat 이라는 기업에서 만들었고, 유료입니다.
리눅스 공부할 때 많이 사용하는 우분투가 debian 계열에 속하는 리눅스이며,
일하시는 분들이 자주 접한 RHEL, Centos, Rocky 리눅스가 바로
Redhat 계열 리눅스입니다.
다만 RedHat 계열에는 조금 더 세부적인 배포 프로세스가 있는데,
이를 짧게 요약하자면 다음과 같습니다.
초창기 RedHat 에서 리눅스 배포판이 만들어지는 순서가 있었습니다.
Fedora: 개발버전, 무료RHEL (redhat enterprise linux): 안정화 버전, 유료Centos:RHEL복제판, 무료
이렇게 하는 이유는 무료 버전인 Centos 로 최대한 사용자를 늘리고,
그 사용자들이 자연스럽게 RHEL 리눅스로 편입시키려던 것으로 추측됩니다.
참고로 2024 년 이후 Centos 는 최종적으로 지원이 종료되었습니다!
신규 프로젝트에서는 사용하면 안되겠죠?
하지만 RedHat 이 IBM 에 인수되면서 이 순서가 바뀌게 됩니다.
Fedora: 개발 버전, 무료Centos Stream: 테스트 버전, 무료. 바이너리 호환성 보장 XRHEL: 안정화 버전, 유료
아마 여기까지 보면 기존 CentOS 사용자들은 이제 가망이 없다고 생각할 수도 있지만,
저희에게는 Rocky Linux 가 있습니다.
Redhat 이 IBM 에 인수되기 이전에 CentOS 가 RHEL 의 복제판이였듯,
Rocky Linux 가 오늘날 RHEL 의 복제판이며 마찬가지로 무료입니다.
Rocky Linux 에 대해 더 알고 싶다면 https://namu.wiki/w/Rocky%20Linux 를 참고하세요.
2. Container 흐름
이제 컨테이너에 대해서 알아봅시다.
오랜 시간 linux는 지속적인 발전이 이루어졌고,
이와 마찬가지로 내부적으로도 코어 기술들이 개발이 됐는데
컨테이너와 관련해서 가장 중요한 발전은 바로 격리 기술 입니다.
격리 기술에는 다음과 같은 것들이 있습니다.
chroot: 유저격리/파일격리/네트워크 격리cgroup: 각각의 앱마다 자원(cpu, memory) 격리namespace: 프로세스(=사실상 App) 격리
이를 다 종합하면 결과적으로 프로세스와 그 프로세스가 실행되는 환경에 대한
독립적인 환경 구성이 가능하게 되었습니다.
그리고 이런 기술들을 집약해서 정리한 게 바로
LXC (= linux container 의 줄임말) 입니다.
LXC 는 최초의 컨테이너이기도 합니다.
그런데 이 LXC 를 직접 사용하는 건 꽤나 어려웠다고 합니다.
그래서 나온 게 여러분들이 잘 아는 Docker 입니다.
참고로 Docker 처럼 컨테이너를 띄울 수 있는 프로그램을
Container runtim
이라고 하는데, 이런 런타임이 Docker 만 있는 게 아닙니다!!
그런데 한가지 알아야 될점이 있습니다.
요즘은 컨테이너 런타임 자체 기술보다는,
(사실상 표준인) 쿠버네티스와 컨테이너 런타임 간의 호환성이 핵심입니다.
그렇기 때문에 대부분의 컨테이너 런타임이 쿠버네티스에서 제공하는
인터페이스 규격에 맞게 설계/개발되고 있습니다.
이는 다음 3. Container Orchestration과 Container 흐름 목차에서
더 자세히 알아보겠습니다.
3. Container Orchestration과 Container 흐름
위 그림 뭔가 많지만 Container Orchestration 영역에서
kubelet 이라고 적혀있는 부분이 이번 목차의 핵심입니다.
kubelet 은 쿠버네티스 사용 시, 실제로 컨테이너를 생성하는
Container Runtime 에게 컨테이너 생성 API 요청을 하게 됩니다.
그런데 초창기 (kubelet v1.0 ~ v1.20) 에는 이러한 API 요청에 대한
kubelet 코드가 모두 Container Runtime 마다 다르게 요청되도록
많은 case 문을 사용했다고 합니다.
이런 비효율적인 개발방식을 멈추기 위해서 kubelet v1.5~1.23 에서는
인터페이스 규격을 하나 정하고
이런 인터페이스에 대한 구현부, 즉 CRI 를 만들게 됩니다.
CRI 에는 각각의 Container Runtime 에 맞는 인터페이스 구현체가 존재했고,
컨테이너 런타임에 맞게 각 구현체를 사용하도록 했죠.
그리고 시간이 더 지나 오늘날에는 (kubelet 1.24 이후)로는
CRI 에 대한 개발 부분을 완전히 Container Runtime 개발자들에게 넘기게 되었습니다.
보충: 추가로 알면 좋은점
-
기존에 사용하던 이미지를 다른 컨테이너 런타임에서 사용 가능할까요?
가능합니다! 이는OCI 컨테이너 표준덕분입니다! -
containerd는docker에서 컨테이너 생성과 관련된 기능만 쏙 빼온겁니다! -
cri-o도 컨테이너 런타임이지만 태생 자체가 kubelet 인터페이스와 호환되기 위해 만들어진 겁니다.
