[Kubernetes] 쿠버네티스와 컨테이너에 대한 한방 정리

해당 포스팅은 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의 내용을 기반으로 작성했습니다.

---

 

Linux의 흐름

• 최초의 OS인 유닉스는 유료 버전으로, 이후 무료버전은 Linux가 탄생한다
• 이 Linux를 기반으로 많은 배포판들이 만들어지는데, 대표적으로 debian linux와 rehat linux이다.
  debian linux는 커뮤니티용으로 무료이며, rehat linux는 redhat 기업에서 개발한 유료 배포판이며 유지보수 측면에서 많은 기업에서 사용하고 있다. 쿠버네티스 설치 시에 두 배포판에 대한 설치 가이드를 제공한다.
• debian linux를 기반으로 전 세계에서 가장 많이 쓰는 ubuntu가 탄생한다. Ubuntu는 UI를 지원해서 사용자가 많이 넘어가게 되고 현재는 개인 학습용이나 클라우드에서 많이 사용한다.
• redhat linux의 경우 linux가 만들어지는 순서가 있다.
  
  • fedora linux: 개발 버전, 무료.
  • RHEL: redhat enterprise linux를 의미하며 fedora linux가 안정화된 버전이다. 유지 보수 비용을 내야 한다
  • CentOS: rhel을 복제해서 만든 무료 버전.
    기업에서는 비용절감을 위해 개발 환경은 CentOS, 운영 환경은 rhel을 쓰기도 한다.
    다만 현재 centOS는 지원이 종료되었다.
• 2019년 IBM에서 redhat을 인수하고, CentOS 유저들을 rhel로 이주시키려고 한다.
  여전히 개발 버전은 fedora linux를 쓰고, 테스트 환겨에서 CentOS stream을 사용한다. 이후 안정화 버전이 rhel이다.
  이때 centOS 유저들에게는 다음과 같은 선택지가 주어진다.
  1. redhat linux로 전환하여 유료로 사용하는 방식. CentOS는 어차피 rhel의 복사본이라 IBM에서도 마이그레이션 하는 것이 기존 APP에 안전하다고 권고하는 방식이다.
  2. CentOS가 많이 사용되어 이를 그대로 기술지원해 주는 기업들이 존재한다. 이 기업에 유지보수 비용을 내면서 그대로 CentOS를 사용할 수 있다.
  3. 타 Linux에서 CentOS의 App이 자기들 OS에서 잘 돌아갈 수 있도록 마이그레이션 스크립트를 제공해 준다. 하지만 약간의 위험도가 존재.
  4. rhel을 복제해서 CentOS를 만들었듯이, 기존 CentOS와 같은 무료 배포판이 있으며, 대표적으로 Rocky Linux와 Alma Linux가 있다.

컨테이너의 흐름

 

Container

• 리눅스가 개발되며 내부적으로도 많은 코어 기술들이 발전되는데 그중 하나는 격리 기술이다.
  • chroot는 사용자 격리를 시작으로 파일, 네트워크 격리를 해준다
  • cgroup은 각 App마다 cpu, memory를 할당할 수 있게 해준다.
  • namespace는 보통 App하나가 하나의 프로세스를 차지하게 되는데, 프로세스 격리 기술이 만들어지며
    각 App을 독립적인 환경에서 실행할 수 있게 해준다.
• 이 기술들을 집약해 만들어진게 최초의 컨테이너인 LXC(Linux container)이며 LXC 기반으로 컨테이너의 대명사인 도커(docker)가 만들어진다. 도커는 컨테이너 기술을 누구나 쓰기 쉬운 형태로 만들어 누구나 쉽게 OS에 컨테이너를 띄울 수 있게 해준다. 이후 도커는 root 권한으로 설치하고 실행해야 하기 때문에 보안 취약점이 발생되었고, 이 취약점을 노리고 나온 것이 rkt이다. 현재는 docker에도 rootless 기능이 생겨서 보안이 강화되었다.

Container Orchestration

• 먼저 컨테이너와 컨테이너 오케스트레이션의 차이이다. 기존 컨테이너 환경인 Docker에서는 App V1을 생성하고 해당 App을 V2로 업데이트하기 위해서는 차례대로 1) App V2 컨테이너를 생성하고 2) App V2가 정상적으로 작동되는지 확인 후에 3) 네트워크를 수정하여 기존에 V1으로 인입되는 트래픽을 V2로 전환해주고 4) 기존의 V1 App을 삭제하는 과정이 필요하다.
• 반면 쿠버네티스를 이용하면 App V2로 업데이트할 때 관리자가 하나하나 수행해야 했던 기존의 과정을 쿠버네티스에서 모두 자동으로 처리해주기 때문에 굉장히 편리하다.
• 쿠버네티스는 처음에 도커를 메인으로 만들어졌지만, 쿠버네티스 인터페이스와의 호환성 때문에 입지가 줄어들었다. 쿠버네티스가 표준화될수록 호환성이 컨테이너를 선택하는 중요한 결정요소가 되었고, 그 이후에 나온 컨테이너가 containerd와 cri-o이다. containerd는 거대한 도커엔진에서 분리된 프로젝트이고, cri-o는 redhat에서 만들었으며 두 프로젝트 모두 CNCF에 기부되었다.
• CNCF(Clound Native Computing Foundation)는 크라우드 분야의 표준을 관장하는 협회이다. containerd는 CNCF의 graduated project인데, 이는 CNCF에 기부된 프로젝트의 기술 성숙도를 의미하며 graduated된 기술들은 믿고 사용해도 무방하다. 참고로 도커는 mirantis에 인수된 이후로 쿠버네티스 인터페이스를 맞추려고 하고 있기 때문에 쿠버네티스에서 빠지지 않게 되었다.
• 컨테이너와 컨테이너 오케스트레이션이 갈수록 한 몸처럼 움직이면서 컨테이너를 직접 다룰 일이 줄어들게 된다. 그 이유는 쿠버네티스가 컨테이너 런타임을 알아서 조작해주기 때문이다. 따라서 컨테이너는 쿠버네티스와 인터페이스가 잘 맞는지 중요해진다. 참고로 쿠버네티스는 CNCF의 1st graduated project이다.
• 이 쿠버네티스를 기반으로 기업 관리형 쿠버네티스 상품들이 생겨나며 이 제품들은 모니터링, 로깅, 배포 툴까지 한 패키지로 설치해주고 기술지원도 해준다. 이런 제품들은 기업 자체 서버에서 private하게 쿠버네티스를 쓰고 싶을 때 사용한다. 쿠버네티스를 public하게 사용하는 일반적인 형태는 클라우드 서비스이며, 각 클라우드 회사마다 각자의 쿠버네티스 서비스가 존재한다.

• 최초의 컨테이너라고 불리는 LXC는 커널 레벨의 기술을 가지고 만든 low level 컨테이너 런타임이다. 이후 Docker가 lxc를 기반으로 libcontainer라는 low level 컨테이너 런타임을 만들고, 사용자 친화적인 high level 컨테이너 Docker를 탄생시킨다. 도커는 dockerd라고 컨테이너 생성 기능 외에도 CLI, Log 관리, storage driver, network 등 부가 기능이 많아 사용자 편의가 좋다. 실질적인 컨테이너 생성은 containerd가 libcontainer를 호출하는 방식으로 동작한다.

• Docker는 app들을 독립적인 환경에서 띄우려고 사용하고, lxc는 기존 VM 기술을 컨테이너 기술로 하는 목적으로 운영체제를 컨테이너 가상화로 나누기 위한 목적이다. rkt는 docker보다 보안에는 좋지만 low level이라 점점 외면당한다.
• 쿠버네티스는 컨테이너 생성이 아닌 pod 생성 명령어가 존재하고, 이 pod에서 컨테이너 생성 개수를 명시할 수 있다. 쿠버네티스는 pod를 생성할 때 kube-apiserver를 호출하여 파드 생성 API를 호출하고, kube-apiserver는 kubelet에 명령을 전달하여 kubelet이 생성해야할 컨테이너 개수를 체크한다. 만약 pod에서 2개의 컨테이너 생성을 지정했으면 kubelet이 컨테이너 런타임에 컨테이너 생성 명령어를 2번 보내고 컨테이너 런타임이 컨테이너를 2개 생성하게 된다.
• 쿠버네티스 초기 버전 1.0에서는 kubelet이 컨테이너 런타임의 API를 호출하였다. 예를 들어 docker와 rkt에 대한 api 호출 분기가 존재했다. 이후 containerd가 docker에서 분리되며 컨테이너 런타임이 점점 늘어나게 되었는데, 이 때마다 kubelet 소스를 수정해야 하는 구조여서 쿠버네티스는 1.5버전에서 interface를 추가한다. 이 인터페이스의 구현부는 CRI(Container Runtime Interface)로 분리하였다. kubelet에 인터페이스 규격을 정하고 규격에 대한 구현부에서 각각의 컨테이너 런타임을 호출한다. 이 CRI는 쿠버네티스 프로젝트에 존재하고, 각 컨테이너 런타임 측에서 해당 프로젝트 소스를 contribution 하는 형태가 이루어진다.
• 이러한 과정속에서 기존 dockershim이 관리가 잘 안됐고 버그가 많아서 1.24버전 부터 지원이 종료된다. 이후 mirantis가 도커를 인수하고 cri-dockerd를 만들어서 다시 쿠버네티스에서 도커가 지원된다. 이 시기에 많은 사람들이 docker에서 containerd로 컨테이너 런타임을 변경한다. 이러한 이슈가 있을 때마다 컨테이너 런타임을 변경할 때 컨테이너 이미지 호환에 대한 고민이 생기게 된다. 이런 고민을 해소하기 위해 컨테이너 표준의 필요성이 느껴지게 되고, 이를 위해 OCI(Open Container Initiative)가 만들어진다. OCI에서는 컨테이너 런타임이 컨테이너를 만들 때 지켜야하는 표준 규약들을 관리하며 이 규약을 지켜서 컨테이너를 생성하면 서로 다른 런타임끼리 컨테이너를 공유해서 사용할 수 있다.
• kubelet과 CRI의 내부 통신은 grpc로 이루어진다. 하지만 컨테이너 런타임의 기술 개발과 쿠버네티스의 기능 개발이 별개로 이루어지기 때문에 만약 도커에 새로운 기능이 생기면 쿠버네티스도 패치를 해주어야 했다. 여전히 구조상으로 컨테이너 런타임의 변경에 대해 CRI 구현체도 수정해야하기 때문이었다. 따라서 kubelet에서 컨테이너 런타임으로 바로 통신할 수 있게 구조가 변경되고 이 구조를 지원하기 위해 containerd에서 CRI-Plugin이라는 기능을 추가한다. cri-o와 cri-dockerd 또한 이러한 규격에 맞춰 만든 런타임이다. 1.27버전 부터는 pod 생성 시 해당 구조를 기본 동작으로 실행한다.