*해당 포스팅은 인프런 - 쿠버네티스 어나더 클래스(sprint1) 강의의 복습 내용 입니다.

쿠버네티스 컨테이너의 기술 흐름 이해하기

쿠버네티스를 처음 학습한다면, 세부적인 구성들을 학습하기 전에 현재의 쿠버네티스를 구성하고 있는 전체적인 주요 컴포넌트를 먼저 살펴보고 이러한 컴포넌트들이 어떤 변화를 거쳐서 오늘날의 모습을 하고 있는지 아는 것은 중요 한것 같습니다. 이런 과정을 통하게 되면 쿠버네티스 구성 하나 하나를 학습할 때 내가 어떤 부분을 학습하고 있는지 명확히 인지되기 때문에 기억에도 오래 남고 이해도 쉽게 됩니다. 마치 책의 목차를 먼저 읽고 책을 읽기 시작하거나, 목적지까지 가는 지도를 먼저 보고 길을 나서는 것과 유사할 것 같습니다. 지금부터 쿠버네티스에 관련된 전반적인 숲을 살펴보고 어떤 변화를 거쳐 지금의 모습을 하고 있는지 알아보도록 하겠습니다.

1. Linux OS 살펴보기

최초의 OS는 UNIX라는 유료 OS 입니다. 그리고 약 30년이 지나고 리누스 토발즈가 개발한 Linux가 세상에 나오게 됩니다. 잠시 곁길로 새자면 우리가 가장 많이 사용하는 버전관리서비스인 Git도 바로 이 리누스 토발즈가 개발하였습니다. 지금 우리가 Windows 서버를 제외한 대부분의 서버에서 사용되는 모든 Linux OS가 바로 이 OS를 기반으로 개발된 것입니다. 크게 보면 다음과 같이 나누어 집니다.

무료
- Debian --- 편의 기능 추가 ---> Ubuntu
유료
- RedHat Enterprise Linux(RHEL)(안정화 버전)
  - 무료
    - Fedora(RHEL의 개발버전)
    - CentOS(RHEL의 복제 OS)

아마 Linux OS 경험이 있으신 분들은 대부분 Ubuntu 또는 RHEL이나 CentOS를 사용해보셨을 것 입니다. 하지만 2019년 IBM이 RedHat을 인수하면서 다소 변화가 생기게 됩니다.

무료
- Fedora(RHEL의 개발 버전)
- CentOS Stream(RHEL의 테스트 버전)
유료
- RedHat Enterprise Linux(RHEL) (안정화 버전)

바로 기존에 RHEL 안정화 버전의 복제 버전이었던 CentOS가 더 이상 제공 되지 않고 CentOS Stream이라는 테스트 버전으로 변경된 것 입니다. CentOS Stream은 테스트 버전이기 때문에 바이너리 호환이 안되는 등의 이슈가 있을 수 있다고 발표했기 때문에 더 이상 프로덕트에서는 사용이 불가능하게 된 것 입니다. 그래서 나온 프로젝트가 Rocky Linux와 Alma Linux 입니다. 이 두개의 리눅스는 기존의 CentOS와 동일하게 RHEL을 복제하여 무료 배포판을 만드는 프로젝트 입니다. 그렇기 때문에 이름은 Rocky와 Alma이지만 RHEL과 거의 동일한 OS라고 보시면 됩니다.

자 여기까지 Linux OS에 대해 알아보았습니다. 사실 지금까지 내용은 그냥 그렇구나 넘어가시면 되고 제일 중요한 것은 이 것 입니다.

**쿠버네티스는 Debian과 Redhat 계열의 OS에 설치를 지원한다

2. Container 살펴보기

리눅스의 다양한 코어 기술들이 개발되었는데 그 중 하나가 격리 기술 입니다. 아래와 같이 chroot, cgroup, namespace가 있으며 각각 다음과 같은 역할을 담당 합니다.

chroot
- 유저 격리
- 파일 격리
- 네트워크 격리
cgroup
- 자원 격리(CPU / Memory)
namespace
- 프로세스 격리

그리고 이러한 격리 기술을 집약하여 나온 것이 최초의 컨테이너인 LXC(Lunux Container)이고 이를 기반으로 만들어진 것이 바로 Docker 입니다. 도커가 나오고 rkt라고 로켓이라는 컨테이너가 나오는데 도커보다 보안이 강화되어 더 안정적인 컨테이너를 강조했습니다. 다만 rkt는 Core OS의 대표 컨테이너 런타임인데 이 Core OS를 RedHat이 인수하게 됩니다. 그런데 RedHat은 Cri-O라는 컨테이너 런타임을 밀고 있기 때문에 자연스레 rkt는 점점 입지가 좁아지고 있습니다.

쿠버네티스가 처음 도커 기반으로 만들어졌음에도 쿠버네티스와 도커의 인터페이스가 잘 안맞으면서 쿠버네티스에서 도커가 빠진다는 얘기가 있으면서 도커의 위세가 꺾이기 시작했습니다. 즉, 호환성 이슈 때문에 도커의 위세가 흔들린 것 입니다. 그리고 이틈에 나온 것이 ContainderD와 Cri-O 입니다. 컨테이너D는 도커에서 컨테이너를 만들어주는 기능이 분리된 것이고 Cri-O는 앞서 언급되었던 것과 같이 레드햇이 만든 컨테이너 입니다. 컨테이너D가 도커에서 분리되어 나온 뒤 Cloud Native Computing Foundation(CNCF)라는 클라우드 분야의 표준을 관장하는 재단에 기부가 됩니다. 그리고 Cri-O도 역시 CNCF에 기부 됩니다. 컨테이너D는 CNCF에서 Graduated 된 프로젝트로 이미 기술 성숙도가 믿고 써도 될 정도로 검증된 것이며, Cri-O는 2023년까지는 Incubating 프로젝트이지만 곧 Graduated 될 예정이라고 합니다.물론 쿠버네티스도 CNCF에 기부되어 이미 Graduated 된 첫번째 프로젝트 입니다. 참고로 도커는 2019년에 MIRANTIS라는 기업에 인수되게 됩니다.

3.Container Orchestration

3-1. Container와 Container Orchestration의 차이

이번에는 Container Orchestration에 대해 알아보기 전에 빠른 이해를 위해 Container와 Container Orchestration의 차이를 먼저 알아보겠습니다. 컨테이너를 보면 사용자가 도커한테 앱을 생성해 달라고 명령을 날리면 도커는 앱(컨테이너)을 생성합니다. 컨테이너 오케스트레이션에서도 사용자가 쿠버네티스(컨테이너 오케스트레이션)에게 앱(컨테이너)을 생성해 달라고 명령을 날리면 쿠버네티스는 도커한테 명령을 전달하여 앱(컨테이너)을 생성합니다. 여기까지는 사용자가 도커에게 바로 커맨드를 날려서 컨테이너를 생성하나 쿠버네티스에게 명령어를 날려서 컨테이너를 생성하나 별 차이가 없어 보입니다.
이번에는 이렇게 만들었던 앱을 다른 버전으로 업그레이드 해보겠습니다. 도커에게 바로 명령을 날려야하는 경우 위의 그림과 같이 앱 V2를 생성하고, 확인하고, 전환하고, 삭제하고 총 네번의 작업을 직접 해주어야 합니다. 그러나 쿠버네티스를 이용하는 경우에는 쿠버네티스에게 업그레이드 명령만 날려주면 쿠버네티스가 알아서 도커에게서 업그레이들 위한 일련의 작업을 진행시키게 됩니다. 하지만 이와 같이 딱 봐도 너무나 편해보이는 해당 기능은 컨테이너 오케스트레이션이 가지고 있는 아주 작은 기능 중에 하나 입니다. 앞으로 쿠버네티스를 학습하며 컨테이너 운영에 필요한 더욱 편리한 기능들이 많으니 차차 배워보도록 하겠습니다.

3-2. Container Orchestration 살펴보기

도커가 출시된 이후에 쿠버네티스 뿐만 아니라 docker swarm, Nomad, Mesos 등 여러가지 오케스트레이션 서비스들이 출시 됩니다. 이렇게 여러 서비스가 출시되어 각 서비스 마다 컨테이너를 오케스트레이션하는데 필요한 개념과 용어들이 다른데 우리는 쿠버네티스에 대한 것만 기억하면 됩니다. 왜냐하면 쿠버네티스 >>넘사벽>> 그외 서비스 이기 때문입니다. 현재는 컨테이너 오케스트레이션이라고 하면 점점 쿠버네티스가 표준으로 정착되어가고 있습니다.

4. Container Orchestration과 Container Runtime의 변천사

컨테이너 오케스트레이션과 컨테이너 런타임의 변천사를 알아보기 전 컨테이너의 구조부터 좀 더 자세히 보겠습니다. 컨테이너는 Container Runtime과 Kernel로 구분이 되고 Kernel 레벨에는 chroot나 cgroup 그리고 namespace가 있습니다. 그리고 Container Runtime은 다시 High Level과 Low Level로 나누어지는데 개발 언어도 사용자 친화적인 고급어, 기계 친화적인 저급어로 나누듯 컨테이너 런타임도 유사하게 나누어져 있습니다.
LXC는 커널 레벨의 기술을 가지고 만든 최초의 컨테이너로 Low Level 컨테이너이며 이 LXC를 기반으로 도커가 libcontainer라는 Low Level 컨테이너 런타임을 만들었습니다. 그리고 이 libcontainer를 이용하여 만든 High Level 컨테이너 런타임이 바로 컨테이너D 입니다. 도커 엔진는 CLI/API/Logs/Network/Build/Image 등 다양한 기능이 합쳐져서 만들어진 것이며, 도커에서 실질적으로 컨테이너를 생성하는 기능은 컨테이너D가 하는 것 입니다.

이렇게 컨테이너 런타임에 대해 좀 더 알아보았으니 컨테이너 오케스트레이션인 쿠버네티스도 좀 더 자세히 보면 POD는 쿠버네티스에서 컨테이너를 생성하는 최소 단위로 각 POD에 최소 한개 이상의 컨테이너를 생성할 수 있습니다. 즉 사용자가 POD에 두개의 컨테이너를 만들어달라고 명령어를 쿠버네티스에 날리면 kube-apiserver가 POD 호출을 받아서 kubelet에 POD 생성 명령을 전달하고 kubelet이 컨테이너 런타임에 컨테이너를 두개 생성하도록 다시 명령을 전달하여 최종 결과물로 컨테이너 두개가 생성되는 것 입니다. 즉 용어를 정확히 정의하자면 컨테이너는 컨테이너 런타임이 만든 결과물 입니다.

초기 쿠버네티스인 1.0 버전에서는 kubelet이 도커 API를 호출하고 도커 API가 libcontainer에 명령을 전달하여 컨테이너를 생성하였습니다. 그런데 점차 도커 외에도 컨테이너D, Cri-O 같은 다양한 컨테이너 런타임이 나오면서 매번 새로운 컨테이너 런타임을 지원할때 마다 kubelet 소스를 수정해야하는 비효율적인 상황이 온 것 입니다. 이러한 비효율성을 해소하기 위해 쿠버네티스는 kubelet의 소스를 수정하는 것이 아닌 CRI(container Runtime Interface)라는 컨테이너 런타임을 호출하는 인터페이스 구현부를 추가하게 됩니다.즉 이제는 쿠버네티스가 컨테이너 런타임을 새롭게 지원할때 마다 소스를 변경하는 것이 아닌, 새롭게 추가될 컨테이너 런타임 측에서 쿠버네티스 프로젝트에 컨테이너 런타임을 호출 할 수 있는 인터페이스 코드를 컨트리뷰션 하는 형태로 변경된 것 입니다.

그리고 또한가지로 다양한 컨테이너 런타임이 출시되면서 이제는 컨테이너를 생성하는데 표준의 필요성이 대두되었고 이에 만들어진 단체가 OCI(Open Container Initiative) 입니다. 이 OCI에서 컨테이너 런타임이 컨테이너를 만들때 지켜야되는 표준 규약을 관리하기 시작하였고, 이때 도커는 이 OCI 표준 규격을 맞추기 위해 기존에 사용하던 LXC 기반의 libcontainer에서 커널 레벨의 가상화 기술을 사용하는 runC라는 새로운 Low Level 컨테이너 런타임을 개발하여 이것을 쓰도록 변경하게 됩니다. 이렇게 표준 규약이 정해졌기 때문에 도커에서 쓰던 이미지를 rkt나 Cri-O에서도 사용할 수 있습니다.

이렇게 kubelet의 새로운 인터페이스 구현부와 OCI의 표준규약에 맞춰 만들어진 새로운 컨테이너 런타임 어댑터가 도커는 dockershim, 컨테이너D는 CRI-ContainderD, rkt는 rktshim 입니다.

그리고 이와 유사한 이유로 쿠버네티스 서비스 내부간 통신에는 grpc 통신이 사용되는데 컨테이너 런타임에서 변경사항이 있으면 쿠버네티스 CRI 구현체도 패치를 해야하기 때문에 kubelet에서 grpc 통신도 컨테이너 런타임으로 바로 받을 수 있게 구조를 변경하였습니다. 이런 구조를 지원하기 위해 컨테이너D에서는 CRI-Plugin이라는 기능이 추가되었고 Cri-O는 태생이 grpc까지 통합된 CRI 규격을 맞췄기 때문에 별도 기능 추가는 필요하지 않았습니다. 그리고 미란티스가 인수한 도커도 이 인터페이스 구조를 따르기 위해서 cri-dockerd를 개발하였습니다.

5. 마무리

여기까지 쿠버네티스에 대해 알아보면서 Linux OS와 컨테이너, 컨테이너 오케스트레이션까지 알아 보았습니다. 그저 강의를 듣기만 했을 때보다 이렇게 정리를 하고 나니 이제야 비로소 어느정도 제 것으로 소화가 된 느낌 입니다. 혹 제가 잘 못 이해하고 서술한 부분이 있다면 댓글을 통해 가감 없이 말씀 부탁드리며, 다음 강의도 열심히 듣고 정리해보도록 하겠습니다.

린아저씨의 잡학사전

쿠버네티스(K8S) 컨테이너 한방 정리 - 쿠버네티스 이해하기