Kaniko 의 한계 부분에 대한 질문

안녕하세요.

"기본적인 이미지"의 의미는 "파이프라인에서 생성되어야 하는 것을 제외한 모든 것들"이라고 봐주시면 됩니다.(무조건은 아닙니다. 당연히 환경마다 달라질 수 있겠죠?)

강의는 Python을 기반으로 하기 때문에, 파이프라인에서도 컨테이너 이미지를 생성하기 위한 빌드를 제외하면 추가로 빌드할 것들이 없었습니다.

하지만, 소스코드를 바이너리로 바꾸는 과정이 필요한 언어들(golang 등)은 파이프라인 내에서 추가적인 빌드가 필요할 겁니다. 이러한 과정을 위해 필요한 파일들을 언급한거다(굳이 CI/CD 파이프라인에서 받을 필요가 없는 것들) 라고 봐주시면 됩니다.

이외에도, 필수 패키지(net-tools, procps 등)가 될 수도 있고, 내가 운영하고 있는 환경에 맞춰 추가적인 무언가가 필요할 수도 있을 겁니다.

요약하면, kaniko의 태생적 한계(호스트에 다운로드 후 스냅샷 생성)를 극복하기 위해 다양한 옵션(--use-new-run, --single-snapshot)을 사용하게 되면 레이어에 대한 캐시 적중률 문제와 (거의 그럴 일은 없지만 동작방식의 한계로 인한)비정상적인 이미지가 생성되는 것을 막기 위해, 최대한 파이프라인 과정에서 생성되는 파일을 줄이고 캐시를 활용하자라는 취지로 말씀드렸습니다.(어느 정도의 스냅샷은 감수할 수 있도록요.)

감사합니다.