[쿠버네티스 어나더 클래스-지상편] 1. 컨테이너 한방 정리
기술의 흐름으로 이해하는 컨테이너
Container Orchestration, Container, Linux OS, Cloud Service, Virtualization, DevOps 6가지 꼭지가 최종적으로 쿠버네티스를 더 잘 이해하려면 알아야되는 큰 키워드이다
- 현재 가장 많이 사용하고 있는 제품을 중심으로 linux 흐름을 알아본다
- 컨테이너와 컨테이너 오케스트레이션에 대해서 기술 흐름을 알아본다
- 클라우드 서비스, 가상화, 데브옵스는 다음 강의로 자세히 설명한다
- 마지막으로 쿠버네티스가 컨테이너 런타임을 어떻게 쓰는지를 중심으로 흐름을 알아본다
1. Linux OS 흐름
최초의 OS로 유료인 Unix가 있었는데 무료인 Linux가 나왔고 Linux를 기반으로 엄청나게 많은 배포판들이 만들어지고 있음
현재는 기업에서도 주로 Linux를 사용하고 있으면 Unix는 점점 사용을 안하고 있는 추세
Debian Linux는 커뮤니티용이라고 해서 무료이고 Redhat Linux는 Redhat 이라는 기업에서 만들었고 유료이다
이 두가지 배포판이 OS설치에 주류이고 쿠버네티스를 설치할때도 두 가지 배포판에서 설치가이드를 제공한다
개인 학습용이나 클라우드에서는 Ubuntu가 정말 많이 사용되고 기업에서는 Redhat 계열의 리눅스가 많이 사용됨
시장점유율이 Ubuntu가 압도적(47%)이고 CentOS(19%), Debian(17%)가 2,3위이다
RedHat이 2019년에 IBM에 인수되고 CentOS의 지원이 종료될 예정
CentOS 리눅스를 복제해서 RockyLinux와 AlmaLinux 무료 배포판이 만들어졌고
현재는 CentOS 설립자중에 한명이 만든 RockyLinux가 둘중에 많이 사용이 되고 있음
2. Container 흐름
쿠버네티스는 구글에서 만든 컨테이너 오케스트레이션이고 많은 편의 기능들이 제공되어 정말 편하게 관리하고 운영하고 배포할 수있음
Docker는 많은 기능이 들어있는 엔진으로 docker 엔진에서 컨테이너를 만들어 주는 기능인 containerd 만 분리되서 나와서 CNCF에 기부됨
cri-o는 RedHat에서 만들어서 CNCF에 기부됨
쿠버네티스는 docker와 인터페이스가 잘 안맞아서 containerd를 사용
쿠버네티스가 컨테이너 런타임을 알아서 조작해주므로 컨테이너를 직접 다룰일이 점점 없어짐
그래서 쿠버네티스와 인터페이스가 잘 맞는지 중요함
docker는 mirantis에 인수된 이후부터 쿠버네티스의 인터페이스를 잘 맞추려고 하고 있기 때문에 쿠버네티스에서 빠지지는 않음
쿠버네티스가 점점 사용할 수록 관리하기가 어려워져서 기업들에서 좀 더 편하게 관리자하고자 하는 니즈 때문에 기업 관리형 쿠버네티스 상품(OPENSHIFT, RANCHER, VMware Tanzu)들이 계속 생기고 있음
각 클라우드 회사마다 쿠버네티스를 사용하게 해주는 서비스가 있음
3. Container Orchestration 과 Container 흐름
- docker는 App들을 독립적인 환경에서 띄울려고 사용
- LXC는 운영체제를 컨테이너 가상화로 나누기 위한 목적
컨테이너를 생성해주는 역할을 하는게 컨테이너 런타임이고 컨테이너는 생성물이다
지금은 쿠버네티스를 설치할 때 containerd를 제일 많이 쓴다
쿠버네티스는 지원해야하는 컨테이너 런타임이 점점 많아 지면서 CRI(Container Runtime Interface) 를 만듬
kubelet에 인터페이스 규격을 정하고 이 규격에 맞게 구현부를 만들었고 이 구현부에서 각각에 컨테이너 런타임을 호출한다
구현부는 쿠버네티스 프로젝트이 있는 것이고 이 프로젝트가 오픈소스니까 각각 런타임(docker, rkt) 측에서 쿠버네티스 프로젝트의 소스를 contribution하는 형태임
1.5 ~ 23버전까지 dockershim이 유지되면서 인터페이스가 잘 안맞았고 버그도 많았음 그래서 24버전 부터 dockershim이 제거된다는 말이 있었는데 mirantis가 docker를 인수하고 cri-dockerd라는 어댑터를 만들어 dockershim을 밖으로 빼내서 docker를 다시 지원할 수 있게 했음
이후 해당 명칭은 dockershim이 아니라 미란티스 컨테이너 런타임으로 부름
이런 이슈로 containerd와 cri-o에게 런타임 자리를 많이 내주게됨
표준의 필요성을 느껴 컨테이너 런타임이 컨테이너를 만들 때 지켜야되는 표준 규약들을 관리하는 OCI 단체가 만들어졌고 이 규약을 지켜서 컨테이너를 만들면 런타임끼리 서로 공유해서 쓸 수 있게 됨
docker를 비롯한 컨테이너 런타임들이 runC라는 OCI 규약을 지키는 LOW LEVEL 컨테이너 런타임을 사용
kubelet에서 CRI와 내부간 통신은 grpc로 하는데 이 구조상 컨테이너 런타임이 변경될 때 마다 CRI에 구현체도 수정을 해야되니까 결국 쿠버네티스 패치가 되야되는데 이부분이 때문에
kubelet에서 컨테이너 런타임으로 바로 받을 수 있게 구조를 바꿈
containerd에서는 CRI-Plugin이라는 기능이 추가되고 cri-o는 태생부터 RedHat이 이 규격을 맞춰서 만든 런타임, 미란티스 컨테이너 런타임도 이 규격을 따르려고 cri-dockerd를 만듬
쿠버네티스가 1.27 버전 부터는 이 구조를 기본으로 동작함