쿠버네티스를 잘 이해하기 위해서는 컨테이너를 잘 알아야 하고 그러기 위해선 Linux를 먼저 알면 좋다.
심지어 쿠버네티스 클러스터 기술을 사용하기 위해서는 아래 그림처럼, 리눅스 배포판을 알아야 한다.
리눅스는 크게 무료인 Debian 계열과 유료인 RedHat 계열로 나누어 진다.
RedHat의 경우 IBM의 인수전과 인수후의 배포판 만드는 순서가 달라진다. 그러면서 기존의 사용자들은 1,2,3,4 선택지중 고민을 해야하는 상황에 직면하게 됨.
리눅스는 꾸준히 발전하면서 chroot , cgroup, namesapce 기술이 만들어졌고 그 기술로 각각의 APP을 독립적인 환경에서 실행 시킬수 있게 된다.
그 이후에 이 기술들을 집약해서 만든것이 Linux Container(LXC) 최초의 컨테이너이다. LXC 기술로 만들어진것이 유명한 Docker이다.
쿠버네티스가 점점 표준화가 되면서 초반에 docker가 걸림돌이 되고 있다. 쿠버네티스와 도커의 인터페이스가 잘 안 맞기 시작하고 그러면서 점점 더 나은 컨테이너가 나오기 시작한다.
그 이후에 나온것이 containerd와 cri-o 프로젝트이고 containerd는 docker에서 컨테이너 만들어주는 기능인 부분이 빠져나온것이다.
쿠버네티스에서 POD를 만들어 달라는 명령을 하면 kubelet에서 Container로 요청이 들어오고 컨테이너를 생성이 된다.
정확하게 말하면 Container Runtime에서 Container를 만들어낸다.
Container Runtime은 크게 High Level , Low Level로 구성되어 있다.
- Low Level Container Runtime
: 기계 친화적이며 컨테이너 실행 및 생성에만 초첨을 맞춘 기술이다.
: 간단한 CLI 형태의 실행파일 또는 라이브러리로 존재하고 대부분은 High Level Container Runtime에 의해 호출되는것이 일반적이다.
- High Level Container Runtime
: 사용자 친화적이며 이미지 전송, 관리, 압축&해제 및 API를 포함하는 기술을 가졌다.
쿠버네티스가 점점 표준화로 정착되면서 기존 docker가 걸림돌이 되고 있는 상황이다.
이렇게 Docker와 Kubernetes가 나란히 성공신화를 써내려가고 있는 가운데 Docker 측에서는 기존 Docker Engine의 Monolithic한 구조를 나누는 작업을 시작했다. Docker를 개발하면서 하나의 완성된 컨테이너 사용자경험을 만드는 것에 집중하다보니 Docker Engine이라는 하나의 패키지에 API, CLI, 네트워크, 스토리지 등 여러 기능들을 모두 담게 되었고, Docker에 의존하고 있던 Kubernetes에서는 Docker 버전이 새로 나올때마다 Kubernetes가 크게 영향을 받는 일들이 생겨났기 때문이다.
그러면서 쿠버네티스와 컨테이너간의 인터페이스를 통해 유연한 연동을 시작하게 된다. 그것이 CRI ( Container Runtime Interface ) 이다. CRI를 통해 쿠버네티스와 Container들 간에 연동이 유연해졌고 또한 OCI에서 표준 컨테이너를 위한 스펙을 정한다. 그래서 많은 컨테이너들이 OCI 표준에 맞춘 컨테이너를 개발하기 시작함. OCI의 표준을 기준 Low Level Container Runtime중 대표중 하나는 runC가 있다. 그래서 OCI의 표준을 맞춘 컨테이너는 다른 컨테이너에서도 동작을 한다.
쿠버네티스] Object를 이해해보자 (0) | 2024.03.30 |
---|