구축 & 운영/Docker

쿠버네티스의 도커 지원 중단 및 대응 방안

단칸이 2022. 4. 24. 19:19

컨테이너와 컨테이너 오케스트레이션 도구

'컨테이너'는 어플리케이션과 그 어플리케이션을 구동하기 위해 필요한 환경을 호스트로부터 격리한 공간을 의미합니다.  컨테이너를 사용하면 하나의 큰 어플리케이션을 서비스 단위로 구분하여 배포할 수 있으며, 각각이 격리된 공간이기 때문에 변경이 있더라도 상호간 영향을 미치지 않습니다. 

마이크로 서비스를 지향하는 현대 개발 환경에서 컨테이너는 N개 이상이 될 수 있으며, 다수의 컨테이너를 생성/소멸/스케줄링/로드 밸런싱/클러스터링 할 수 있도록 편의를 제공하는 도구를 '컨테이너 오케스트레이션 도구' 라고 합니다.

컨테이너 오케스트레이션 도구의 도입 목적

컨테이너화된 서비스는 배포에 상당한 편의를 가져옵니다. 그리고 이들을 관리하는 '컨테이너 오케스트레이션 도구'를 이용하면 물리적으로 구분된 다수의 호스트에서 서비스를 관리하는 것도 상당히 간편해집니다.

저희 팀에서는 다음과 같은 목적으로 컨테이너 오케스트레이션 도구의 도입을 고려하였습니다.

컨테이너의 Lifecycle 관리 간편화

부하 분산을 목적으로 동일한 컨테이너를 다수 복제할 수도 있으며, 이는 서비스의 장애 대응 또는 무중단 업데이트를 위한 기본 인프라가 됩니다. GUI를 통해 간편하게 컨테이너의 Lifecycle을 관리할 수 있으며, 명령어에 의한 실수가 개입되는 상황을 방지합니다.

서비스의 장애 복구

컨테이너에 문제가 발생하면 해당 컨테이너를 교체하거나 다시 실행하는 작업이 필요합니다. 그러나 관리자가 문제 발생을 인지하는 시점에서는은 이미 배포 중인 서비스에 문제가 있는 상황입니다.

컨테이너 오케스트레이션 도구를 이용하면 자동으로 컨테이너를 다시 생성함으로써, 장애 대응 시간을 최소화할 수 있습니다.

무중단 업데이트

컨테이너를 순차적으로 교체함으로써 서비스의 중단 없이 업데이트를 진행할 수 있습니다. 다만, 이 경우 구 버전과 신규 버전이 동시에 존재하는 순간은 일부 존재합니다. 

쿠버네티스가 도커 지원을 중단한 이유

도커는 쿠버네티스 이전에 개발되었으며, 쿠버네티스는 도커를 지원하기 위해 개발된 프로젝트 입니다. 

그러나 새로운 컨테이너 런타임 도구가 생겨남에 따라 쿠버네티스도 다양한 프로젝트를 지원해야 했으며, 이를 위해 인터페이스를 통일한 CRI (Container Runtime Interface)가 등장하게 되었습니다.

이후 CRI 스펙에 맞게 구현된 컨테이너 런타임 툴은 쿠버네티스와 호환이 가능해졌으나, 쿠버네티스 이전에 개발된 도커의 경우 CRI를 준수하지 않은 상태로 유지되고 있었습니다.

쿠버네티스는 도커를 위해 CRI를 도커 엔진에 맞게 변환해주는 'docker-shim' 이라는 미들웨어를 자체적으로 지원하며  도커 측에 CRI의 준수를 요청하였으나, 도커 측에서는 어떤 이유에서인지 이를 수용하지 않고 있으며, 사실상 도커 엔진의 업데이트는 멈춰 있는 상태입니다. (Github의 마지막 업데이트가 2020년 12월로 확인됩니다.)

그리고 결국 쿠버네티스에서 'docker-shim' 프로젝트의 지원을 중단한 것으로 보입니다.

대응 방안

도커 스웜

도커에서 지원하는 컨테이너 오케스트레이션 도구입니다. 도커 스웜은 사용이 간단하고 (도커와 동일한 명령어 시스템이 가볍다는 장점이 있으나, 컨테이너 관리/배포 정책의 유연성은 쿠버네티스 측이 높습니다.

프로젝트 구분 설명
쿠버네티스 스케일링 제한 - 5,000개의 노드 / 300,000개의 컨테이너
- 필수적으로 3개의 노드 필요
 * 각 노드에는 노드를 관리하고 쿠버네티스와 통신하기 위한 에이전트인 'kubelet' 필요
pod - 1개 이상의 컨테이너 집합
- 쿠버네티스의 실행 단위 (스케줄링 단위)
deployment - pod의 배포를 담당
- pod 인스턴스 수를 관리하는 replica-set 자동 생성
- pod 인스턴스에 대한 rolling-update 관리
service - pod 집합을 고정된 end-point로 관리
UI - 모니터링 / 정책 관리용 대시보드 제공
도커 스웜 스케일링 제한 - 2,000개의 노드 / 95,000개의 컨테이너
service - 1개 이상의 컨테이너 집합
- service 생성 시 옵션을 이용하여 replica 개수 설정
UI - 커맨드라인 기반으로, 별도 프로젝트 설치 필요
- portainer / swarmpit (리소스 모니터리이 / 자동 재배포 및 스택과 같은 대부분의 기능 제공)

cri-dockerd

미란티스(Mirantis) 라는 업체에서 docker-shim을 인수하여 지원하기로 결정하였으며, 현재 개발 중으로 보입니다. (공식 블로그, Github)

공식 블로그에 따르면 내장된 docker-shim에서 외부 docker-shim으로 전환하면 쿠버네티스의 최신 버전에서도 도커를 그대로 이용할 수 있다고 설명합니다.

다만, 첫 릴리즈가 2022. 01. 04에 되어 아직까지는 검색 결과도 많이 없을 뿐더러, 사용 커뮤니티 등도 많이 확인할 수 없었습니다.  

Podman (Pod Manager Tool)

RedHat에서 도커의 대안으로 개발된 컨테이너 엔진으로, 도커에서 사용하던 CLI 명령을 대부분 그대로 이용할 수 있습니다. 

또한, 도커의 아키텍처 상 발생하는 대표적인 문제점을 보완하였으며, 쿠버네티스나 openshift와 같은 컨테이너 플랫폼으로 쉽게 이관할 수 있도록 하는 기능을 포함합니다.

구분 Docker Podman
구동 방식 도커 데몬 사용 필수* Daemon-less 방식
실행 권한 root 권한으로만 실행 가능** root 권한 불필요
Monolithic Platform 도커에 모든 필요한 도구 통합 개별 오픈소스 설치 필요
- Podman : 컨테이너 실행
- Buildah : 컨테이너 빌드
- Skopeo : 컨테이너의 이미지 관리
docker-swam 지원 미 지원
docker-compose 지원 지원

※ daemon-less

도커는 서버-클라이언트 아키텍처로, 도커 데몬이 컨테이너를 관리하고 클라이언트와 서버 간의 통신을 관리하는 백그라운드 프로세스가 됩니다. 반면 Podman은 fork-exec 모델을 사용하여 컨테이너를 관리하며, 쿠버네티스의 Pod 개념과 동일하게 컨테이너 그룹을 관리합니다.

이러한 도커의 구조로 인해, 도커 데몬이 중지되거나 재 시작되는 경우 (도커의 설정을 변경하나 후 재 시작하는 등)에는 모든 컨테이너가 중지된다는 문제가 발생합니다.

※ root 권한

도커 데몬이 항상 root 권한으로 실행되기 때문에, 도커는 데몬과 통신을 위해 root 권한이 필요하게 됩니다. 만약 사용자가 관리 그룹에 소속되지 않을 경우에는 sudo 명령을 이용하여 도커를 실행해야 합니다. (관련 자료 : 링크)

컨테이너는 호스트로의 게이트웨이가 될 수 있으므로, 보안을 위해 컨테이너 사용자의 UID를 재 매핑하는 등 권한 상승을 방지하는 작업이 필요합니다. (Podman의 경우 1024 이하의 Well known 포트를 사용하는 등 root 권한이 필요한 작업이 아니라면 일반 사용자 권한으로 컨테이너를 실행할 수 있습니다.)

자료 출처

 

저작자표시 (새창열림)

'구축 & 운영 > Docker' 카테고리의 다른 글

[Ubuntu] - Docker 설치 방법  (0) 2022.03.27

'구축 & 운영/Docker'의 다른글

  • 현재글쿠버네티스의 도커 지원 중단 및 대응 방안

관련글

티스토리툴바