컨테이너의 이해(3/3) - 도커와 쿠버네티스의 관계

레지스트리와 쿠버네티스의 관계

쿠버네티스에서도 레지스트리에 이미지를 다운받아 컨테이너를 실행한다.

쿠퍼네티스에서 컨테이너가 동작할 때까지의 흐름을 설명하면 다음과 같다.

도커와 쿠버네티스를 연결하는 레지스트리의 역활

1. docker build로 이미지를 빌드한다.
2. docker push로 이미지를 레지스트리에 등록한다.
3. kubectl 커맨드로 매니페스트에 기재한 오브젝트들의 생성을 요청한다.
4. 매니페스트에 기재된 리포지터리로부터 컨테이너의 이미지를 다운로드 한다.
5. 컨테이너를 파드 위에서 가동한다.

이처럼 레지스트리는 쿠버네티스를 사용할 때 반드시 필요한 서비스다.

---

도커와 쿠버네티스의 연동

쿠버네티스는 도커를 컨테이너의 런타임 환경으로 사용한다. 쿠버네티스를 설치할 때 제일 먼저 도커를 설치해야 하는 이유도 이 때문이다.

도커 데몬 프로세스인 dockerd와 연동하여 동작하는 containnerd 프로세스는 Docker CE 17.3에서 버전 0.2.3이 도입되었고, Docker CE 17.12에서는 1.1이 도입되었다.

이를 통해 이미지 보관 및 전송, 컨테이너 실행, 볼륨과 네트워크 연결과 같은 컨테이너의 라이프사이클을 호스트에서 완전히 관리할 수 있게 되었다.

containerd 버전 1.1부터는 CRI(Container Runtime Interface)에 대응하여 네이티브 kubelet도 연동할 수 있게 되었다.

도커와 쿠버네티스의 연동

containerd는 OCI(Open Container Initiative)의 표준 사양에 준하는 컨테이너 런타임 runC를 사용한다.

CRI를 통한 컨테이너 실행 요청을 받으면 contianerd는 containerd-shim을 만든다.

runC는 컨테이너를 띄운 후 바로 종료하며 이어서 containerd-shim이 프로세스로 남게 된다.

 

이와 같이 내부 표준화가 진행됨에 따라 향우 쿠버네티스의 컨테이너 실행 환경은 도커 설치를 필수도 하지 않게 되어, 보다 심플하고 경량으로 고속화 될 수 있는 방향으로 개발이 진행되고 있다.

퍼블릭 클라우드의 쿠버네티스 관리 서비스와 상용 제품에서도 containerd와 kubelet이 직접 연계하는 방향으로 진행되고 있다.

---

컨테이너를 위한 기술과 표준

리눅스 표준 규격과 리눅스 ABI(Application Binary Interface)

도커를 사용하면 다양한 리눅스 배포판을 기반으로 한 컨테이너 실행이 가능하다.

리눅스 배포판과 커널 버전이 달라도 동작이 가능한데, 그 이유는 먼저 LBS(Linux Base Standard)는 소스 코드를 컴파일한 시점에서 호환성 있는 머신 코드를 생성하도록 ISO 규격으로 표준화되어 있다.

또한, 리눅스 ABI(Application Binary Interface)로 인해 리눅스 커널의 버전이 올라가도 유저 공간에서 동작하는 바이너리(머신 코드) 레벨의 호환성은 유지된다.

 

리눅스 커널 기술

1. 네임스페이스(Namespace)

네임스페이스는 리눅스 커널에 사용된 기술로 컨테이너가 하나의 독립된 서버와 같이 동작할 수 있게 된다.

네임스페이스르르 사용하면 특정 프로세스를 다른 프로세스로부터 분리시켜 같은 네임스페이스 내에서만 접근할 수 있도록 제한할 수 있다.

 

2. 컨트롤 그룹(cgroup)

도커는 리눅스 커널의 cgroup을 사용한다.

cgroup은 프로세스별로 CPU 시간이나 메모리 사용량과 같은 자원을 감시하고 제한한다.

 

유니온 파일 시스템(UnionFS)

UnionFS는 다른 파일 시스템에서 파일이나 디렉터리를 투과적으로 겹쳐서, 하나의 일관적인 파일 시스템으로 사용할 수 있게 한다.

도커에서는 UnionFS의 여러 구현체(aufs, btrfs, overlay2) 중 하나를 선택할 수 있다.

예전에는 aufs가 사용되었으나, Docker CE 버전 17.12에서는 보다 빠르게 동작하고 구조가 간단한 overlay2가 사용된다.

 

OCI(Open Container Initiative)

컨테이너의 표준 사양을 책정하기 위해 만들어진 단체로, 처음에는 The Open Container Project라도 불렸다.

설립 초기에는 도커(Docker)가 사실상 컨테이너의 표준이었는데 CoreOS가 또 다른 표준화를 진행하고 있어 업계 표준이 필요한 상황이었다.

 

OCI의 설립에는 도커(Docker), CoreOS, 구글(Google), IBM, 레드햇(Red Hat), AWS, VMware, HP, EMC, Pivotal, 마이크로소프트(Microsoft), 리눅스 파운데이션(Linux Foundation) 등이 주요 멤버로 참가하였다.

 

이 단체가 2017년 7월에 발표한 OCI v1.0은 컨테이너 런타임의 표준 사양인 Runtime Specification v1.0과 이미지 포맷의 표준 사양인 Format Specification v1.0으로 구성된다.

이에 맞춰 도처가 구현한 것이 컨테이너 런타임 runC이다. 한편, CoreOS의 컨테이너 런타임 rkt도 내부적으로 표준에 맞추는 작업이 진행중이다.