Kubernetes 1. Container 한방정리 (Kubelet, Container runtime)

Container와 Container Orchestration의 차이

기존 Container는 새로운 버전으로 릴리즈 되면 매번 운영자가 수정해주어야 하지만, Container Orchestration은 업그레이드만 설정하면 알아서 Container Orchestration이 해결해 준다. 이것이 우리가 쿠버네티스를 배워야 하는 이유다.
쿠버네티스는 구글 주도하에 어려 기업들의 배포 운영의 노하우가 담긴 집합체이다.
쿠버네티스를 학습하기 전에, Linux OS의 흐름에 대해 짚고 넘어간다면, 앞으로 쿠버네티스 공식 문서를 볼 때 좀 더 이해가 빠를 것이다.

Linux 진화 과정

1. 1960년에 UNIX가 탄생했다.
2. 하지만 UNIX는 유료이기에, 이를 무료로 사용할 수 있게 만든(취미로 만들었다고 한다...) Linux가 등장한다.
3. Linux를 무료로 쓸 수 있는 debian, Redhat으로 나뉜다.
debian은 커뮤니티용이여서 무료이고, Redhat linux는 Redhat 회사에서 만들었으며 유료이다.
OS는 버그가 생길 수 있으니 꾸준히 업데이트를 해주어야 하는데, 이를 Redhat에서 직접 해준다고 생각하면 된다.
그래서 Linux는 크게 debian 계열, Redhat 계열로 나뉜다.
 
4. 그 후 ubuntu가 등장했다. 1999년 debian 을 기반으로 만들었으며, 사용자 편의 기능이 추가됐다. 기존과 다르게 UI가 생겼다는 것이 가장 큰 차이이다.
 
5. Redhat linux의 과정을 알아야 그 후 내용을 이해할 수 있다.
Redhat linux는 개발버전인 fedora를 사용하여 개발하고, 이를 안정화한 것이 RedHat EnterpriseLinux이다. 줄여서 RHEL이라고 불린다.
하지만 이는 유료이기에, 무료로 복제한 버전인 CentOS가 존재한다. 실제로 유지보수를 직접 할 수 있는 회사에서 사용한다.
하지만 이는 2021, 2024에 종료된다.
 
6. 2019년 IBM이 RedHat을 인수한다. 
인수를 하면서 배포판을 바뀌는 순서가 바뀌었다.
테스트할 때는 마찬가지로 fedora를 사용하여 개발하고, CentOS stream이라는 것이 등장하였고, 이를 사용하여 테스트하며 이를 안정화한 버전이 RedHat Enterprise Linux이다.
CentOS stream는 바이너리 호환성이 보장 안 될 수 있다는 얘기를 한다. (그럼 쓰면 안 되겠지?)
그렇게 해서 나온 것이 RedHat Enterprise Linux을 복제한 Rocky Linux, AlmaLinux가 있다.
현재 더 많이 쓰이고 있는 것이 Rocky Linux이다.
 
위를 정리하면 아래와 같다.
1. 주로 사용하는 Linux는 Debian, Redhat 계열이 있다.
2. 쿠버네티스도 크게 이 두 가지 계열을 지원한다.
3. Redhat 계열인 CentOS는 종료됐다.
4. Rocky Linux는 CentOS의 대체제 중 하나이다.
결론. Rocky Linux는 쿠버네티스를 설치할 때 Redhat 계열을 보면 된다.
 
위를 이해했다면 이제 컨테이너의 진화과정을 학습하면 쿠버네티스를 이해하는데 크게 영향을 준다.

Container 진화 과정

컨테이너 진화과정을 학습한다면 쿠버네티스를 이해하는데 순조로울 것이다.

 
컨테이너에 대해 이야기하기 전에, SW는 꾸준히 격리기술에 대해 발전했다.
1. chroot 1979년 유저, 파일, 네트워크 격리 기술이 등장했다.
 
2.  2006년 각각의 app 마다 자원(cpu, memory)을 격리하는 cgroup기술이 등장했다.
 
3. 각 앱마다 하나의 프로세스를 격리시켜 주는, "독립적인 환경"에서 실행할 수 있게 된다.
이러한 기술들을 정리한 게 LXC, Linux Container이다.
 
4. 2013년 LXC를 기반으로 만들어진 것이 docker이다. 이전까지는 개발자들이 쓰기 어려웠다면 docker는 이를 쉽게 사용할 수 있게 해 주었다.
docker는 항상 root 권한으로 실행했어야 했는데, 이의 보안을 지적하고, 성능을 개선한 Rocker container가 등장했다. 그 이후에 docker도 root 권한으로 실행하지 않는 rootless 모드가 등장했다.
컨테이너 제일 위 Linux 사진에 보이는 CoreOS가 있는데, 이것이 컨테이너 전용 OS이고, rkt가 대표적인 런타임이다.
그런데 이 OS가 Rethat으로 인수가 됐고, fedora CoreOS로 이름이 바뀌었다.
하지만 Rethat이 밀고 있는 컨테이너가 cri-o 이기 때문에 rkt의 입지가 줄어들고 있다.
 
5. docker의 위세가 줄고 있다는 이유가, 쿠버네티스에서 docker가 빠질 수 있다는 이야기 때문이다.
이유는 docker가 쿠버네티스의 인터페이스와 잘 맞지 않아서 나온다. docker가 만들어지고 쿠버네티스가 만들어졌지만 쿠버네티스가 표준화될 수록 docker가 걸림돌이 되는 아이러니한 상황.
앞으로 쿠버네티스를 사용할 때 쿠버네티스랑 누가 더 호환성이 좋은지가 컨테이너를 선택하는 결정요소가 됐다.
 
6. 그 이후로 나온 것이 condaier-d와 cri-o 컨테이너이다.
condadier-d는 docker에서 컨테이너를 만들어주는 기능이 분리된 것이다. 
 
7. 2019년 MIRANTIS 회사가 docker를 인수하여 쿠버네티스 인터페이스를 잘 맞추게 되어 쿠버네티스에서 빠지지 않게 된다.

Container Orchestration 진화과정

Docker가 나온 이후 쿠버네티스가 등장했다.
container-d와 cri-o는 모두 CloudNative Computing Foundation(CNCF)에 기부가 됐다.
그렇기 때문에 CNCF를 졸업했다면 믿고 쓰면 된다.
마찬가지로 쿠버네티스 또한 CNCF에 가장 먼저 기부가 됐다. 
그 이후로 다른 기업들은 쿠버네티스를 활용해서 자신들의 제품을 만들기 시작한다.
기업 관리형이라고 해서 기업들이 쿠버네티스를 관리하는데 좀 더 편한 기능들을 제공해 주는 제품들이다.
위 제품들을 설치하면 쿠버네티스 외에 모니터링이나 로깅 배포 툴까지 한 패키지로 다 설치를 해준다.
이 제품들은 회사에서 private 하게 관리하고 싶을 때 사용하는 것이고, 이를 public으로 사용하는 것이 우리가 아닌 cloud service, Google Cloud Platform Amazon Web Service, Azure, Naver Cloud Platform 등 다양한 환경에서 쿠버네티스를 지원한다.

결론

1. Kubernetes는 현재 표준을 넘어 여러 분야에서 활용되고 있다.
2. Kubernetes는 컨테이너를 더 쉽게 사용할 수 있게 해 준다.
3. 컨테이너는 Kubernetes와의 인터페이스가 중요하다.

Container Runtime와 Kubelet의 진화 과정

 
1. Container runtime은 High Level과 Low Level로 나뉜다.
사용자에게 친화적인 것이 High Level, 기계에 친화적인 것이 Low Level이다.
최초의 컨테이너인 LXC는 LowLevel 컨테이너 런타임이다.
 
2. 가 LXC를 기반으로 libcontainer 런타임을 만들었다. 이를 그대로 존재한다면 사용자에게 인기가 없었을 것이다.
이를 사용자 친화적으로 만든 HighLevel이 docker이다.
docker 엔진은 아래와 같이 부가기능이 많은 컨테이너 외에도 많은 기능을 제공한다. 
정작 컨테이너를 만들어 주는 것은 containerd이다.
containerd가 Low Level인 libcontainer을 만든다.

3. LXC는 OS를 위한 컨테이너이고, docker는 APP을 위한 컨테이너이다.
LXC는 우분투같은 것을 컨테이너로 띄운다면 docker는 jar 같은 애플리케이션을 띄운다.
 
4. 쿠버네티스에는 kube-apiserver와 kublet이라는 컴포넌트가 있다.
쿠버네티스에 컨테이너 하나를 생성하는 명령어는 존재하지 않으며 pod를 생성하여 그 안에 컨테이너를 생성할 수 있게 한다.
만약 pod 생성 api가 호출이 된다면, Kube-apiserver가 pod 생성해 달라는 요청을 kubelet으로 요청하게 되며 kubelet이 컨테이너 생성 요청을 container runtime에 요청하게 된다.
container runtime은 컨테이너를 생성한다.
 
5. kubelet은 container runtime이 받을 수 있는 형태의 API를 호출한다. (쿠버네티스 1.0 버전)
실제 kublet 소스에는 docker와 rkt 를 구분한다.
 
6. 그러다 시간이 점차 지나면서 docker에서 containerd 가 따로 분리되어 나왔다. (현재 쿠버네티스를 설치할 때 containerd를 가장 많이 씀)
kubelet은 이렇게 컨테이너가 생성될 때 마다 소스를 docker와 rkt를 구분하는 것처럼 매번 업데이트를 해야 할까?
쿠버네티스는 1.5 버전부터 interface를 추가한다. 
그리고 구현부를 따로 빼는데, 이를 CRI라고 해서, 컨테이너 런타임 인터페이스라고 불린다.
kubelet에 인터페이스 규격을 정하고, 이 규격에 맞게 구현부를 만들었다.
이 구현부에서 각각의 컨테이너 런타임을 호출한다.
구현부는 쿠버네티스 프로젝트에 존재하며 오픈소스이므로, 각각의 컨테이너 런타임 측에서(docker, rkt 측) 쿠버네티스 프로젝트의 소스를 contribution 하는 형태이다.
docker가 앞으로 지원이 안 되는 것은 아니다. kubelet의 오픈소스인 dockershim이 제대로 관리가 안되고 버그가 많아서 kubelet에서 dockershim을 빼려고 한 것이다.
참고) docker가 유료화된다는 얘기가 있는데, container runtime의 docker가 유료화되는 것이 아니라 docker desktop이 유료 된다는 것임
 
7. 위에서 docker가 MIRANTIS 회사에 인수되었다 했는데 수정을 하며 미란티스 컨테이너 런타임으로 이름이 바뀌었다. 또 dockershim을 뺀다고 하니 이를 수정하여 다시 사용할 수 있게 한 것이 cri-dockerd이다. 
OCI라는 단체가 생겼는데, 컨테이너를 생성할 때 규약을 만든 단체이다. 그래서 런타임들끼리 서로 공유해서 사용할 수 있다.
이때 docker는 이 규약에 맞추기 위해 runC를 만들었고 containerd도 runC를 쓰도록 변경한다.
기존의 LXC의 libcaontainer와 runC의 차이점은, libcaontainer는 Low Level의 LXC를 사용하지만, runC는 kernel 레벨의 가상화 기술을 사용한다. 
 
8. 하지만 컨테이너에서 기술 개발이 될 때마다 kubelet에서의 인터페이스도 추가되어야 하므로 패치가 되어야 한다.
이를 해결하기 위해서 kubelet에서 컨테이너 런타임으로 바로 받을 수 있도록 구조를 변경한다. 
이러한 규칙을 만들기 위해 containerd에서는 CRI-Plugin을 만들었다.
rethat의 cri-o는 태생부터 인터페이스 규격을 맞춰서 만든 런타임이다.
그리고 미란티스 컨테이너 런타임도 아까 언급했던 것과 같이 cri-docker-d를 만들었다.
 
출처
위 사진들은 일프로님 강의에 나온 화면이며 강의를 수강하며 학습했습니다.
https://www.inflearn.com/course/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%96%B4%EB%82%98%EB%8D%94-%ED%81%B4%EB%9E%98%EC%8A%A4-%EC%A7%80%EC%83%81%ED%8E%B8-sprint1/dashboard

쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의 | 일프로 - 인프런