Blog

컨테이너 기술이 발전하면서 Kubernetes(K8s)는 클라우드 네이티브 환경의 표준 오케스트레이션 플랫폼으로 자리 잡았습니다. 하지만 Kubernetes의 런타임 환경은 시간이 지나면서 변화를 거듭했고, Docker를 중심으로 하던 초창기에서 벗어나 CRI(Container Runtime Interface) 표준을 따르는 컨테이너 런타임을 필요로 하게 되었습니다. 이 과정에서 등장한 Podman은 Docker와 차별화된 구조를 통해 Kubernetes와의 연동성을 강화하며 필수적인 도구로 자리 잡고 있습니다.

그렇다면 Podman은 무엇이며, 왜 등장하게 되었을까요? 그리고 Docker와 어떤 차별점을 가지며, 이를 통해 어떤 문제를 해결할 수 있을까요?

Podman은 Red Hat이 중심이 되어 개발한 컨테이너 런타임으로, OCI(Open Container Initiative) 표준을 준수하는 컨테이너와 Pod를 실행, 관리할 수 있는 도구입니다. Podman은 Docker와 마찬가지로 컨테이너를 실행하고 관리하는 도구입니다. 하지만 Podman은 Docker와는 다른 철학을 가지고 탄생했습니다.

핵심적인 특징은 데몬리스(Daemonless) 아키텍처를 채택했다는 점입니다. Docker는 컨테이너를 관리하기 위해 데몬 프로세스를 사용합니다. 이 데몬 프로세스는 시스템 전체에 영향을 미칠 수 있으며, 보안과 안정성에 대한 우려를 낳기도 했습니다. 이러한 문제점을 해결하고자, Red Hat을 중심으로 한 개발자들이 데몬리스(daemonless) 아키텍처를 채택한 Podman을 개발하게 되었습니다.Docker와 달리 별도의 지속적으로 실행되는 데몬 프로세스가 없으며, 각 컨테이너는 개별적인 프로세스로 실행됩니다.

이러한 구조는 보안성을 강화하고, 시스템 리소스를 보다 효율적으로 활용할 수 있도록 돕습니다. 특히 rootless 컨테이너 실행을 기본적으로 지원하여, 사용자 권한으로 컨테이너를 실행할 수 있습니다. 이는 보안 취약점을 줄이고, 호스트 시스템에 대한 불필요한 접근을 최소화하는 장점이 있습니다.

Podman은 Red Hat이 중심이 되어 개발한 컨테이너 런타임으로, 2018년에 Apache License 2.0 으로 완전한 오픈소스 소프트웨어로 공개되었습니다.

이 프로젝트는 Red Hat의 “libpod(Pod Management Library)“에서 출발했으며, Docker의 기존 한계를 극복하고 보다 보안성이 강화된 컨테이너 환경을 제공하기 위해 만들어졌습니다.

Red Hat은 Podman의 개발을 주도하면서도, 동시에 사용자들의 피드백을 적극적으로 수렴하고 있습니다. 다양한 오픈소스 기여자들은 Podman의 기능 개선, 버그 수정, 새로운 기능 추가 등에 참여하며 Podman의 완성도를 높이는 데 기여하고 있습니다. 이러한 협력적인 개발 방식은 Podman이 더욱 견고하고 신뢰할 수 있는 컨테이너 도구로 성장하는 데 중요한 원동력이 되고 있습니다.

특히, Podman은 Red Hat이 제공하는 다양한 Linux 배포판에서 기본적으로 지원되고 있습니다. Fedora, RHEL (Red Hat Enterprise Linux), CentOS Stream 등 Red Hat의 주요 배포판에서는 Podman이 기본 컨테이너 관리 도구로 채택되어 있으며, 이를 통해 사용자들은 Podman을 쉽게 설치하고 활용할 수 있습니다. 이러한 공식적인 지원은 Podman의 안정성을 입증하는 중요한 지표이며, 기업 환경에서 Podman을 도입하는 데 큰 신뢰를 제공하고 있습니다.

Docker는 컨테이너 기술의 발전에 크게 기여했지만, 몇 가지 문제점을 가지고 있었습니다. Docker 데몬의 보안 취약점, 시스템 안정성 문제, 그리고 root 권한 실행의 필요성은 많은 사용자의 우려를 낳았습니다. Podman은 이러한 문제점을 해결하고자 데몬리스 아키텍처를 채택하고 보안성과 안정성을 강화한 새로운 컨테이너 도구입니다.

Docker는 컨테이너 표준을 제시하며 컨테이너 생태계를 선도하고 있었지만, 몇 가지 문제점이 점차 부각되었습니다.

• Docker Daemon의 보안 문제

Docker는 단일 데몬(Docker Daemon) 프로세스를 통해 컨테이너를 관리하는 구조였습니다. 하지만 이 데몬은 root 권한으로 실행되었으며, 취약점이 발생하면 전체 시스템에 영향을 줄 수 있었습니다.

• Kubernetes와의 관계 변화

초기에는 Kubernetes에서도 Docker가 기본 런타임이었지만, 이후 컨테이너 런타임의 표준화가 이루어지면서 OCI 기반 런타임인 containerd와 CRI-O 등이 도입되었습니다. Podman은 Kubernetes와의 자연스러운 통합을 고려하여 개발되었습니다.

• 컨테이너의 경량화 및 유연성 필요

기존 Docker는 컨테이너 엔진 자체가 무겁고, 불필요한 기능이 포함된 경우가 많았습니다. 이에 비해 Podman은 필요한 기능만을 제공하여 가볍고 빠른 컨테이너 환경을 구축할 수 있도록 설계되었습니다.

Docker는 여전히 널리 사용되는 컨테이너 도구입니다. 하지만 Docker가 단순한 컨테이너 실행 도구로 자리 잡았다면, Podman은 Kubernetes 네이티브 환경에 최적화된 컨테이너 관리 도구로 발전해 나가고 있습니다.

Docker는 컨테이너 기술의 대중화에 기여한 바는 크지만 아키텍처 한계로 인하여 클라우드 네이티브 확산에는 다른 대안이 필요 했습니다. Docker는 중앙 데몬(dockerd)을 통해 모든 컨테이너를 관리하는 방식으로 인해 단일 실패 지점(Single Point of Failure)이 존재하며, root 권한을 필요로 하는 보안 취약점이 지속적으로 제기되었습니다. 또한, Kubernetes의 등장으로 파드(Pod) 단위의 관리 수요가 증가함에 따라, 기존 도구로는 다중 컨테이너를 하나의 논리적 단위로 묶는 작업이 번거로웠습니다.

Red Hat은 이러한 문제를 해결하기 위해 Linux 커널 기능(e.g., cgroups, namespaces)을 직접 활용하는 방식을 채택했고, Docker와의 호환성을 유지하면서도 보안과 확장성을 강화한 Podman을 개발했습니다. 이는 Open Container Initiative(OCI) 표준을 준수하며, Kubernetes의 YAML 형식과도 호환되어 클라우드 네이티브 생태계와의 통합을 원활하게 합니다.

• Podman의 핵심 개념: 데몬리스(Daemonless)

Podman의 핵심적인 차별점은 바로 데몬리스 아키텍처입니다. Docker는 컨테이너를 실행하고 관리하기 위해 dockerd라는 데몬 프로세스를 사용합니다. 이 데몬 프로세스는 시스템 전체에 대한 권한을 가지고 있으며, 만약 문제가 발생하면 전체 시스템에 영향을 미칠 수 있습니다. 반면에 Podman은 데몬 없이 컨테이너를 실행합니다. 만약 Podman과 같은 데몬리스 컨테이너 도구가 없다면, 컨테이너를 사용하면서 보안 및 안정성 문제를 항상 우려해야 합니다. Docker 데몬의 보안 취약점은 곧 시스템 전체의 보안 취약점으로 이어질 수 있으며, 이는 심각한 피해를 초래할 수 있습니다. Podman은 이러한 위험을 줄여주기 때문에 컨테이너 환경을 더욱 안전하게 사용할 수 있도록 돕습니다.

• OCI (Open Container Initiative) 표준 준수

Podman은 컨테이너 이미지와 런타임에 대한 OCI (Open Container Initiative) 표준을 준수합니다. OCI는 컨테이너 기술의 호환성을 높이기 위해 제정된 표준으로, OCI 표준을 준수하는 컨테이너 도구는 상호 운용성이 높습니다. 즉, Podman으로 빌드한 컨테이너 이미지를 다른 OCI 준수 컨테이너 도구에서도 실행할 수 있으며, 반대로 다른 컨테이너 도구에서 빌드한 컨테이너 이미지를 Podman에서도 실행할 수 있습니다. 이러한 호환성은 컨테이너 기술 생태계의 발전에 큰 기여를 하고 있습니다.

• Podman이 Kubernetes와 잘 맞는 이유

컨테이너 기술이 발전하면서 Kubernetes(K8s)는 클라우드 네이티브 환경의 표준 오케스트레이션 플랫폼으로 자리 잡았습니다. Kubernetes는 초기부터 Docker를 컨테이너 런타임으로 사용해 왔습니다. 하지만 Kubernetes 1.20(2020년 12월 릴리스)부터는 공식적으로 Dockershim(내부 Docker 지원 모듈) 을 더 이상 지원하지 않겠다고 발표했습니다. 이 결정은 Docker가 Kubernetes의 컨테이너 표준인 CRI를 직접 지원하지 않기 때문입니다. 대신 Kubernetes는 CRI-O 와 containerd 같은 컨테이너 런타임을 지원합니다.여기서 Podman은 CRI-O와 깊은 관계를 가지며 Kubernetes와의 통합성이 강화된 대안이 됩니다.
Podman은 Docker와 달리 Pod(Pod 단위의 컨테이너 그룹) 관리 기능을 기본 지원합니다. Podman은 기본적으로 Kubernetes와의 원활한 통합을 목표로 설계된 도구입니다. 특히 Kubernetes의 Pod 개념을 기본적으로 반영하고 있어, 개발 환경에서 직접 Kubernetes와 연동하기 용이합니다.

즉, Kubernetes의 기본 단위인 Pod을 로컬 환경에서도 동일한 방식으로 실행할 수 있습니다. 이렇게 실행된 Pod는 Kubernetes의 Pod와 동일한 개념으로 동작하므로, 로컬 개발 환경에서 Kubernetes 클러스터로 손쉽게 이관할 수 있습니다.

Podman은 실행 중인 컨테이너나 Pod을 바로 Kubernetes에서 사용할 수 있도록 YAML 파일로 변환하는 기능을 기본 제공합니다. 이 기능은 Kubernetes 배포를 위해 별도로 YAML 파일을 수작업으로 작성하는 번거로움을 줄여 줍니다.

Docker는 여전히 컨테이너 환경에서 널리 사용되지만, Podman은 보다 안전하고 유연한 대안으로 자리 잡고 있습니다. 특히 rootless 컨테이너 실행과 Kubernetes 연동이 중요한 환경에서는 Podman이 더욱 강력한 선택지가 될 수 있습니다.

Podman은 다양한 방법으로 구현할 수 있습니다.

• Linux 환경

대부분의 Linux 배포판에서 패키지 관리자를 통해 Podman을 쉽게 설치할 수 있습니다. yum, apt, dnf 등의 패키지 관리자를 사용하여 Podman을 설치하고 사용할 수 있습니다.

• macOS 및 Windows 환경

macOS 및 Windows 환경에서는 가상 머신을 사용하여 Podman을 실행할 수 있습니다. podman machine 명령을 사용하여 가상 머신을 생성하고, 그 안에서 Podman을 실행할 수 있습니다.

또한, Podman은 Docker와 유사한 인터페이스를 제공하기 때문에 Docker 사용 경험이 있는 사용자라면 Podman을 쉽게 배울 수 있습니다. docker run 명령 대신 podman run 명령을 사용하고, docker ps 대신 podman ps 명령을 사용하는 방식으로, Docker와 거의 동일하게 컨테이너를 관리할 수 있습니다.

클라우드 네이티브 환경은 컨테이너를 기반으로 애플리케이션을 배포하고 관리하는 환경을 의미합니다. Podman은 클라우드 네이티브 환경에서 중요한 역할을 합니다. Podman은 CNCF(Cloud Native Computing Foundation)의 OCI 표준을 충실히 준수하며, Kubernetes의 CRI(Container Runtime Interface)와도 호환됩니다.

이는 하이브리드 클라우드 환경에서 로컬 개발과 프로덕션 배포를 일관되게 관리할 수 있음을 의미합니다. 예를 들어, 개발자는 로컬에서 Podman으로 파드를 테스트한 후 동일한 YAML 파일을 프로덕션 Kubernetes 클러스터에 배포할 수 있습니다. 또한, Red Hat의 OpenShift는 Podman을 기반으로 한 Kubernetes 플랫폼으로, 엔터프라이즈급 보안과 관리를 제공합니다.

Podman은 단순한 Docker 대체제가 아니라, 더 안전하고 유연한 컨테이너 운영 환경을 제공하는 도구입니다. 특히 클라우드 네이티브 환경을 고려하는 조직이라면, Podman을 적극적으로 검토할 가치가 있습니다.

즉, Kubernetes 기반의 컨테이너 운영을 고려하는 경우, Podman은 Docker보다 더 적합한 도구이며 필수적인 기술이라고 볼 수 있습니다.

Docker가 단순한 컨테이너 실행 도구로 자리 잡았다면, Podman은 Kubernetes 네이티브 환경에 최적화된 컨테이너 관리 도구로 발전해 나가고 있습니다.