CICD 제거됨: 임시 스토리지 초과

저는 클라우드 네이티브 환경으로의 여정을 즐기는 소프트웨어 엔지니어입니다. Medium에서 내 이전 게시물을 찾을 수 있습니다.

포드 임시 로컬 스토리지 사용량이 총 컨테이너 한도를 초과합니다.

최근 DevOps 파이프라인의 일부 AI 기반 구성 요소에 대한 빌드와 관련하여 주요 문제가 발생했습니다. 스토리지 또는 메모리 제한으로 인해. 모든 새로운 최신 DevOps 도구와 마찬가지로 빌드 및 패키징에 필요한 명령을 완료하기 위해 작업(기본적으로 Kubernetes 작업)이 실행됩니다.

문제가 무엇인지, 이러한 제한에 도달하는 것이 무엇을 의미하는지, 작업의 어떤 지점에서 이러한 제한에 도달하는지 정확히 찾아내는 것은 복잡할 수 있습니다.

ephemeral-storage = emptyDir && 매체 = 메모리

kubernetes에서 ephemeral-storage는 emptyDir에 매핑될 수 있습니다. 이는 기본적으로 종료되는 포드 기간 동안의 스크래치 공간입니다. 불행하게도 클러스터에서 각 노드의 최대 디스크 공간은 100Gb뿐이므로 매우 빠르게 채워집니다.

좋습니다. 이 멋진 매체 기능을 사용하고 메모리를 사용하도록 저장소를 설정해 보겠습니다. 보너스 작업 속도가 빨라져 성능이 약 20% 향상되었습니다. 불행히도 우리는 여전히 메모리 리소스 제한이 있는 작업의 최대값에 도달했습니다.

Volumes:
  cicd-vol-data:
    Type:    EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:  Memory

가시성 = 뉴렐릭 인프라

우리는 이러한 모든 CICD 작업이 무엇을 하고 있는지에 대한 현실적인 관점을 확보해야 했습니다. 더 이상 작업과 파이프라인에 대한 맹목적인 신뢰를 가지고 항해할 수는 없었습니다. 진정한 심층 분석을 위한 시간입니다.





kubernetes 노드의 새로운 유물 인프라 에이전트를 사용하여 작업에 사용되는 메모리, 스토리지 및 CPU의 분석을 보여주는 대시보드를 구성했습니다.

이 대시보드에서 AI 관련 작업자에 대한 스파이크가 다른 모든 작업과 비교하여 이상값임을 확인할 수 있습니다. 보시다시피 이전에 디스크 및 메모리(16Gb Ephemeral + 16Gb Memory as Disk)에 적용되었던 제한에 도달하고 갑자기 종료됩니다. CPU는 괜찮습니다.

스토리지에서 메모리로 문제를 방금 전송한 것 같습니다.

레이어 압축 풀기

메모리 사용량을 분석할 때 작업은 총 21.6Gb의 메모리를 소비합니다. 본질적으로 메모리의 작업 스크래치 디렉토리는 완료 시 ~18Gb였습니다. 그럼 거대합니다!

18GB를 분류하면 다음과 같습니다.

복제 후 = 1.7Gb

이미지 빌드 및 내보내기 후 = ~16Gb입니다.

이미지 빌드에는 빌드 컨텍스트, tempfs 및 출력 아카이브가 포함됩니다. 빌드 컨텍스트
**Dockerfile 명령( COPY . . 또는 RUN xyz . )이 있을 때마다 컨텍스트를 다른 레이어로 복사합니다. 컨테이너의 모든 명령은 레이어를 형성합니다.

핵심은 1.7Gb의 배수를 만드는 장소 주위에 파일 콘텐츠를 복사하기 시작하는 것을 확인하기 위해 구축 중인 다양한 계층을 이해하는 것이었습니다.

해결책

우리 팀을 위해 이 작업을 수행하기 위해 메모리 제한을 디스크보다 더 쉬운 24Gb로 늘렸습니다(또한 속도 증가를 원했습니다). 만세!

그리고 이제 우리는 Dockerfile과 코드 구조에 초점을 맞춰 이를 더 효율적으로 만들고 정상 범위 내로 되돌립니다.


이 문제를 해결하는 데 도움을 주신 팀 전체, 특히 해당 팀의 핵심 구성원과 Ionut Palada에게 감사드립니다.