기술의 흐름으로 이해하는 컨테이너
쿠버네티스는 컨테이너, 가상화, DevOps 환경에 깊숙히 자리잡고 있습니다. 쿠버네티스를 잘 이해하기 위해서 OS 와 더불어 컨테이너, 가상화, DevOps 환경에 대한 전반적인 배경을 이해하는 것이 중요하다.
1. Linux OS 흐름
메인프레임을 시작으로 1960년대 UNIX 가 등장하였고 이후 높은 안정성과 고성능으로 시장을 장악하였으나, 고가의 장비와 OS 로 인하여 일반적인 엔지니어의 접근이 어려웠다. 1990대 들어 리누스 토발즈에 의해 Linux ( 리누스 + 유닉스 ) 가 무료로 공개된 이후 언제든지 누구나 쉽게 접근하고 배울 수 있는 범용적인 OS로 자리 매김 하였다.
리눅스는 수많은 배포판이 존재하지만, debian 과 redhat 두가지 계열만 인지하고 있어도 충분하다.
- debian : 커뮤니티용으로 만들어진 배포판으로 무료이다.
- redhat : redhat 에서 만든 배포판으로 배포는 무료, 기술지원은 유료형태로 운영되다 유료화로 전환되면서 RHEL(RedHat Enterprise Linux) 이 되었다. 레드햇은 배포판이 만들어지는 순서가 존재하는데, 1) fed마이ora, 2) Red Hat, 3) CentOS 이다.
1) fedora : 새로운 기능이 개발되었을때 배포판으로 무료.
2) Red Hat : 페도라에 들어간 기능이 안정화 되었을때 이름을 바꿔 릴리즈하는 기업용 배포판으로 유료.
3) CentOS : 레드햇 배포판을 복사해서 만든 무료 배포판
CentOS 는 2014년 레드햇에 인수되었고, 이후 레드햇은 2019년에 IBM 에 인수되었다. 이후 배포판을 만드는 순서가 다음과 같이 변경되었다.
- 새로운 기능을 포함하는 배포판인 fedora
- 기능들을 테스트 하는 배포판(바이너리 호환성 보장이 안 될 수 있음)인 CentOS Stream (무료)
- 안정화 된 버전인 Red Hat 배포판
이후 안정화 배포판이었던 CentOS 가 사라질 예정으로, CentOS 를 사용하던 사용자가 선택할 수 있는 옵션은 4가지로 나누어 볼 수 있다.
- Red Hat 으로 전환
- 3rd party 의 기술지원을 받아 CentOS 를 사용
- 마이그레이션 스크립트등을 통해 다른 배포판으로 전환
- Rocky, Alma 등 새롭게 출시된 레드햇 복제 리눅스로 전환
많은 사용자들이 Rocky Linux 나 Alma Linux 로 전환을 고려하고 있으며 구글 트랜드와 깃헙 포크수를 살펴볼 때 Rocky 리눅스쪽이 더 인기가 많음을 알 수 있다. 이에 따라, 향후 환경구성은 Rocky Linux 를 기반으로 진행토록 한다.
2. 컨테이너 런타임
리눅스는 지금까지 꾸준히 발전해 왔고, 내부적으로도 많은 코어 기술들이 개발이 되었으며, 핵심 코어 기술중 하나가 격리 기술이다.
- chroot : 사용자 격리를 시작으로 파일이나 네트워크를 분리하는 기술
- cgroup : App 마다 cpu나 메모리를 별도로 할당하는 기술
- namespace : 프로세스를 격리하는 기술 (App 을 독립환경에서 실행 할 수 있음)
- LXC : 위의 3가지 기술을 집약하여 정리한 (LinuX Container)로 OS 레벨의 가상화 기술.
이를 기반으로 어플리케이션 레벨의 가상화 기술인 Docker 가 탄생하게 됨.
Docker 가 탄생한 이후 누구나 쉽게 컨테이너 환경을 구성할 수 있게 되었다. 초기 Docker 는 root 권한으로 설치, 실행되어야 하기 때문에 보안에 안 좋다는 단점이 존재하였고, 이를 개선한 rkt ( 로켓 ) 이라는 컨테이너가 나왔으나 사용성 측면에서 불편한 점이 존재한다. 현재 Docker 는 rootless 설치 모드가 생겨 보안이 강화된 상태이다.
Docker 에서 분리되어 나온 containerd 와 래드햇의 cri-o 라는 컨테이너가 출시되면서, 점점 표준화가 되어가는 쿠버네티스에서 어떤 컨테이너를 사용하는지에 대한 경쟁이 시작되었다.
3. 컨테이너 오케스트레이션과 컨테이너 흐름
쿠버네티스는 kube-apiserver 와 kubelet 을 포함하고 있다. kube-apiserver 는 API 를 외부에 노출하는 서비스이고, kubelet 은 api-server와 통신하며, 노드에서 실행되는 컨테이너 런타임을 관리하는 에이전트 이다.
초창기 쿠버네티스에서의 kubelet 은 컨테이너 런타의 종류에 따라 맞춤형 API 를 호출하게 만들어져 있었다.
이후, 새로운 컨테이너 런타임이 등장할 때마다 새로운 구현체를 만들고 배포해야 하는 불편함이 생겼고, 이를 해결하기 위하여 v1.5부터 kubelet 에서 컨터이너 런타임을 호출하는 부분을 CRI (Container Runtime Interface) 라 불리우는 인터페이스를 분리하여 별도 정의하였다. 그런데, CRI 내부에서 Docker 와 연결을 담당하던 dockershim이 관리가 잘 안 이루어지고, 버그가 많다보니 v1.23까지 유지되던 dockershim 이 빠지게 되었다. 이후, 많은 사용자들이 docker 에서 이탈하여 containerd 로 갈아타게 되었다.
쿠버네티스와 CRI 는 별도의 기능인데 k8s 에 같이 존재하다 보니 CRI 구현체가 수정될 때 마다 패치가 이루어지는 상황이 생겨, v1.24 부터는 kubelet 에서 컨테이너 런타임을 바로 호출할 수 있는 형태로 구조가 변경되었다.
이 표준을 따르기 위하여, containerd 에서는 CRI-Plugin 이라는 기능이 추가되었고, cri-o 는 처음부터 규격에 맞추어 런타임을 구성하였고, docker 는 cri-dockerd 를 만들었다.
v1.27 부터는 이 구조를 기본으로 따르도록 변경되었다
'k8s' 카테고리의 다른 글
| 쿠버네티스 빠른 설치 (Mac - m시리즈 ) (0) | 2024.01.02 |
|---|