안녕하세요, 정보보호 전문 업체 보안클라우드입니다.

이번 게시글에서는​ DevOps 직군에서 중요시하는 스킬인 도커(Docker)와 쿠버네티스(Kubernetes)에 대해서 이야기하려 합니다.

​

시작하기 앞서 도커와 쿠버네티스를 이해하기 위해서는 컨테이너(container)에 대하여 이야기하겠습니다. 컨테이너는 구동하고자 하는 애플리케이션의 환경, 코드, 시스템 라이브러리, 시스템 도구 등 모든 요소를 감싸서 어떤 환경에서도 실행할 수 있도록 해주는 기술입니다. 컨테이너 이전에 많이 사용하던 VM(Virtual Machines)과 어떻게 다른지 다음 그림을 통해 알아보겠습니다.

Virtual Machines, Containers

해당 그림을 보면 VM에서는 가상화 기능을 이용하여 Guest OS를 생성하고 애플리케이션이 실행됩니다. 이러한 구조는 Host OS와 Guest OS는 별개로 존재하여 의존적이지 않지만, Guest OS에서 I/O 기능 등 실행하기 위해서는 Host OS를 거쳐서 이루어지기 때문에 속도가 느리며, 또한 Guest OS을 실행 및 유지하기 위해 자원을 소모하게 됩니다. 반면에 컨테이너는 가상화 기능을 사용하지 않고 엔진을 이용하여 동작하게 되는데요. 이는 Guest OS를 생성·유지를 하지 않아 VM 대비하여 자원을 절약할 수 있습니다.

​

도커(Doker)

도커(docker)

앞서 컨테이너에 대해 이야기하였는데 컨테이너를 실행하고 관리하는 도구를 컨테이너 런타임(Docker Runtime)이라 말합니다. 도커는 이 컨테이너 런타임 중 가장 유명한 도구입니다. 도커에서는 서비스 운영에 필요한 서버 프로그램, 소스코드 및 라이브러리, 컴파일된 실행 파일을 묶는 형태를 도커 이미지(Docker Image)라 합니다.

도커 이미지는 컨테이너 실행에 필요한 모든 파일과 설정을 지닌것으로 더 이상의 의존성 파일을 컴파일하거나 추가 설치할 필요 없는 상태의 파일을 의미하는데 응용프로그램 자체를 패키징 또는 캡슐화하여 격리된 공간에서 프로세스를 동작시키는 기술인 도커 컨테이너(Doker Container)의 인스턴스가 됩니다. 이러한 도커를 이용하면 개발한 애플리케이션을 쉽게 배포하고 어떤 환경에서 구동할 수 있는 장점이 있습니다.

​

쿠버네티스(Kubernetes)

​

쿠버네티스(Kubernetes)

서비스를 개발 또는 운영하는 환경에서 적용한다면 데이터베이스와 프론트엔드, 백엔드 등 여러 컨테이너를 배치

하고 관리하는 작업이 필요하게 될 것입니다. 이 여러 컨테이너를 다수의 호스트에 배치하고 다수의 컨테이너를 실행하고 관리하는 것을 오케스트레이션(Orchestration)이라 합니다.

쿠버네티스를 이야기하기 위해 앞에서 컨테이너 런타임, 오케스트레이션에 대하여 이야기했는데요, 쿠버네티스는 컨테이너 런타임을 통해 컨테이너를 오케스트레이션 하는 도구라 할 수 있습니다. 즉, 쿠버네티스는 컨테이너 런타임 중 유명한 도커 이외에 다양한 컨테이너 런타임 소프트웨어를 사용하는 할 수 있습니다. 이러한 쿠버네티스를 사용하면 애플리케이션 배포가 단순화되고 개발 환경과 운영 환경이 동일한 환경에서 구동이 되므로 개발 측면에서 환경 차이로 인한 고민을 덜 수 있습니다. 또한, 쿠버네티스 사용으로 인해 컴퓨터 자원을 효율적으로 활용할 수 있을 뿐만 아니라 오토스케일링(Auto Scaling) 기능을 통하여 예상치 못한 서비스의 부하에 대응할 수 있습니다.

​

* 오토스케일링(Auto Scaling) : 사용자가 정의한 스케줄링이나 이벤트에 따라 서버를 자동으로 생성하거나 삭제

​

​

앞서 다룬 내용으로 도커와 쿠버네티스가 다르다는 것을 알 수 있습니다. 쿠버네티스에서 사용하는 컨테이너 런타임으로 도커가 많이 사용되었는데, 쿠버네티스에서는 CRI (Container Runtime Interface)라는 표준 인터페이스 API를 사용하는데, 도커에서 이를 지원하지 않아 호환성 문제가 발생하여 쿠버네티스 v1.20 버전 이후 도커 지원을 중단을 하였습니다. 이 때문에 도커와 쿠버네티스를 잇는 도구인 도커심(Dockershim)을 사용하였지만 배포 속도가 느려지고 유지 관리자에게 큰 부담으로 쿠버네티스 v1.24 버전 이후 도커심 기본 지원을 중단하였습니다. 그렇다고 해서 컨테이너 런타임 도구을 사용 못 하는 것이 아닙니다. 쿠버네티스와 호환이 되는 컨테이너 런타임인 containerd, CRI-O가 있습니다.

​

쿠버네티스에서 지원하지 않는 도커 이젠 쓸모가 없어진 걸까요? 그렇지 않습니다. 도커가 CRI를 사용하는 컨테이너 런타임으로 더 이상 사용되지 않지만, 더 이상 개발 도구로 사용할 수 없다는 뜻은 아닙니다. 무슨 뜻인가 하면 쿠버네티스 런타임에서 도커를 제거하더라도 도커에서 만든 컨테이너 이미지를 등록하고 실행하는 것은 가능한데, 도커가 생성하는 이미지는 OCI(Open Container Initiative)와 호환되는 이미지이기 때문입니다. 이는 containerd나 CRI-O 등의 컨테이너 런타임에서도 도커 이미지를 가져와 실행할 수 있다는 것입니다.

개발은 도커로 진행하되, 실행하는 컨테이너 런타임만 다른 것으로 변경하면 큰 불편함 없이 쿠버네티스를 사용할 수 있습니다.

​

* OCI(Open Container Initiative) : Container라는 개념이 생긴 초반에 많은 IT 회사들이 Container 기반의 제품을 출시하지만 Container 기술에 대한 특정한 규격이 없어 개념 자체가 혼란스러워졌으나 이 문제를 해결하기 위해 구글, 마이크로소프트, 도커, IBM 등 Container 포맷과 런타임에 대한 개방형 업계 표준을 만들기 위해 OCI(Open Container Initiative)를 구성.

이후 OCI는 Container 개발의 기준이 되며, OCI는 표준 요구 사항, 구성 요소 및 특징을 가짐

​

​

오늘은 도커와 쿠버네티스에 대하여 알아보았습니다. 도커와 쿠버테니스는 상황마다 다르게 사용되는데요, 하나의 컨테이너만을 사용한다면 도커를, 많은 컨테이너를 사용한다면 쿠버네티스를 사용하여 컨테이너를 관리해 보는 건 어떨까요?

컨테이너를 도입하고 있는 기업에서는 효율적인 컨테이너 관리를 위해 운영하고 있는 컨테이너 수 앱의 복잡성을 파악하여 도커를 사용할지 쿠버네티스를 사용할지 다시 확인해 보고, 컨테이너 도입을 하려는 기업의 경우 도입 전에 도커 또는 쿠버네티스 중 어느 환경이 적합한지 결정하여 도입해 보시는 건 어떨까요? 지금 당장 컨테이너 도입을 생각하지 않는 기업들은 도커와 쿠버네티스가 무엇인지만 알고 있다가 도입 시 이를 참고하시면 도움이 될 거 같습니다.

​

이상 도커와 쿠버네티스에 간략한 지식을 공유해 보았는데요, 이미 한참 전에 관련한 블로그나 게시글 자료들이 많아 도움이 되셨을지 모르겠습니다. 그럼 다음엔 다른 주제로 찾아뵙겠습니다.