1. Docker 문제점
Docker의 문제점
-
권한 문제
- 모든 도커 명령은 root 권한을 가진 사용자에 의해서만 실행할 수 있으므로, 보안 문제가 발생할 수 있다
-
단일 실패점 문제
- 도커에서 서버를 담당하는 도커 데몬은 이미지 빌드, 관리 공유, 컨테이너 관리등 너무 많은 기능을 담당하며, 컨테이너들을 자식 프로세스로 소유한다. 따라서, 데몬이 너무 무거울 뿐만 아니라 만약 장애가 생기면, 모든 자식 프로세스에 영향을 끼치는 Single Point of Failure가 될 수 있다
Docker - Kubernetes 문제점
Kubernetes 1.20 부터 Dockershim을 제거하기로 했다. Dockershim을 제거한다는 것은 Docker를 Runtime으로 사용하지 않겠다는 의미다
-
CRI와 호환성이 없다 ( Dockershim 문제 )
- Kubernetes에서 CRI를 통해 Docker와 통신하기 위해선 Dockershim이 필요한데, Dockershim은 유지 보수 비용이 높다
- Dockershim으로 인해 배포 설능 저하 문제가 발생할 수 있다
-
Docker에는 Kubernetes에서 사용하지 않는 기능들이 많이 가지고 있으므로, 자원 오버 헤드가 높다
-
Container를 생성하는 것은 Docker 데몬이 아니라 Containerd 이므로, Docker 데몬은 불필요하다
-
Docker는 명령 실행을 위해 Root 권한을 가지고 있어야 한다
-
위에서 말한 단일 실패점 문제
- Docker 데몬에 문제가 생기면, Kubernetes 전체에 영향을 끼친다
따라서 Kubernetes 1.20 부터는 Kubelet이 CRI를 이용해 Containerd와 직접 통신한다
- Containerd 1.0 에서는 CRI와 직접 통신할 수가 없어서, 가운데 CRI-Containerd 라는 데몬이 필요했다
- Containerd 1.1 에서는 CRI 플러그인이 내장되었다
클라우드 내부 Image Build 문제
클라우드 내부에서 Image를 Build 하는 것은 실질적으로 Image 안에서 Image를 Build하는 것이다
- Docker를 빌드 도구로 사용할 경우 생기는 문제에 대해 알아보자
-
권한 문제
- Docker Image를 Build 하려면 필요한 Docker 데몬을 실행하기 위해선 root 권한이 필요한데, 클라우드에서는 보통 root 권한을 사용자에게 부여하지 않기에 권한 문제가 생긴다
-
Docker Image 안에서 Docker Daemon을 이용하여 Docker Image를 Build 할 경우, Build 성능 저하를 일으킨다
이와 같은 문제점을 해결하기 위해 Docker 데몬 없이 Docker Build를 수행하기 위한 오픈 소스를 사용한다
2. Kaniko
Kaniko 란
Kaniko는 Kubernetes 클러스터나 컨테이너 내부에서 Docker 데몬 없이 Dockerfile을 이용하여 컨테이너 이미지를 빌드하는데 사용하는 오픈 소스 도구이다
Kaniko는 Dockerd 와 같은 컨테이너 Daemon에 의존하지 않는다
Kaniko 실행 단계
- Image Build 할 Dockerfile 경로 설정 ( 인자 값 설정 )
- Image를 Push할 레포지토리 정보 설정 ( 인자 값 설정 )
- Kaniko 이미지 배포 ( 실행 )
- Kaniko 가 Image 를 Build 하고, 레포지토리에 Push 해준다
멋진 엔지니어가 될 때까지