Kubernetes에서 대규모 AI/ML 워크로드를 실행하는 것은 특히 확실한 계획이 없는 경우 리소스 할당, 보안 장애물 및 모니터링 요구 사항의 미로를 탐색하는 것처럼 느껴질 수 있습니다. 물론 이미지 인식이나 이탈 예측과 같은 신경망 작업을 보는 것은 흥미롭지만 클러스터를 한계까지 밀어붙이는 것에 대한 우려는 항상 있습니다.
MLOps는 모델 생성, 테스트 및 릴리스를 추적하는 데 도움이 되는 아이디어와 도구 세트로서 데이터 과학자, DevOps 담당자 및 보안 팀 간의 격차를 해소하는 친근한 앵커입니다. 긴밀한 협업을 장려하므로 한 팀의 데이터 과학자와 다른 팀의 Kubernetes 전문가는 서로를 밟지 않고 자신 있게 모델을 업데이트할 수 있습니다'발가락. MLOps가 컨테이너 오케스트레이션을 만나면 AI 파이프라인을 보다 예측 가능한 방식으로 제어할 수 있습니다.
이 글의 목표는 쿠버네티스에서 복잡한 AI 작업을 실행하기 위한 모범 사례를 공유하는 것입니다. 우리'확장, 스케줄링, 보안, 리소스 관리 및 노련한 플랫폼 엔지니어와 Kubernetes에서 기계 학습에 막 발을 들여놓는 사람들에게 중요한 기타 요소에 대해 이야기하겠습니다. 각 섹션을 거닐면'클러스터를 보호하기 위한 실용적인 팁을 얻을 수 있습니다. AI 보안 위험, 비용을 억제하고 모델이 원하는 컴퓨팅 성능을 제공합니다.
쿠버네티스 보안 코딩 관행 [치트 시트]
이 10페이지 분량의 치트 시트는 인프라 및 플랫폼 개발자가 컨테이너화된 애플리케이션을 보호하기 위한 실행 가능한 고급 지침을 제공합니다.
다운로드 PDF
자원 관리
훈련 또는 추론을 위해 컨테이너를 가동하기 전에 클러스터 리소스가 워크로드의 강도와 일치하는지 확인하는 것이 중요합니다. 결국 GPU 요구 사항을 무시하거나 적절한 CPU 크기 조정을 건너뛰면 성능 저하, 무작위 메모리 부족 및 팀 실망으로 이어집니다.
GPU 및 특수 하드웨어 할당
GPU, TPU 및 기타 가속기는 클러스터의 스포츠카와 같습니다's 차고. 이를 통해 대규모 모델을 훈련하거나 추론 중에 엄청난 처리량을 처리할 수 있습니다. 파드 내에서 이러한 하드웨어 리소스를 사용할 수 있도록 하려면 쿠버네티스에서 제공하는 디바이스 플러그인에 의존한다. 예를 들어, 공식 NVIDIA 장치 플러그인을 사용하면 Pod당 GPU 슬라이스를 요청할 수 있습니다.
한 가지 중요한 팁은? 적절한 리소스 요청을 설정하면 스케줄러가 올바른 GPU를 사용하여 올바른 노드를 찾을 수 있습니다. 이러한 리소스 정의를 건너뛰면 워크로드가 가속기가 없는 노드에 착륙하여 작업 실패가 발생할 수 있습니다. nodeSelector 또는 nodeAffinity를 통해 쉽게 타겟팅할 수 있도록 nvidia.com/gpu=true 와 같은 이름으로 GPU 노드에 레이블을 지정하는 것도 도움이 됩니다.
아래 코드 스니펫은 NVIDIA에서 하나의 GPU를 요청하는 기본 Pod 사양을 보여줍니다.
api버전: v1
종류: 포드
메타데이터:
이름: gpu-training-pod
사양:
컨테이너:
- 이름: gpu-training-container
이미지: nvcr.io/nvidia/tensorflow:22.01-tf2-py3
리소스:
제한:
nvidia.com/gpu: 1
nodeSelector를 사용합니다.
nvidia.com/gpu: "참"CPU 및 메모리 크기 조정
모든 데이터 파이프라인 또는 모델 학습 작업에 GPU가 필요한 것은 아닙니다. 많은 작업은 크기를 올바르게 지정하면 CPU에서 완벽하게 실행됩니다. 요청과 제한을 설정함으로써 쿠버네티스 스케줄러는 노드에 얼마나 많은 포드가 들어갈 수 있는지 알 수 있다. 이러한 매개변수가 없으면 스케줄링이 제대로 이루어지지 않거나 동일한 CPU 코어를 놓고 경쟁하는 파드가 발생할 위험이 있습니다. 일정을 다음 단계로 끌어올리려면 클러스터 자동 크기 조정 교통 또는 교육 작업의 갑작스러운 급증을 흡수합니다.
Prometheus와 같은 모니터링 시스템을 사용하여 실제 사용량 지표를 주의 깊게 관찰하는 것을 잊지 마십시오. Pod가 지속적으로 90% CPU에 도달하면 요청을 약간 조정합니다. 반대로 Pod의 CPU 사용량이 약 20%로 유지되면 요청을 줄일 수 있습니다.
다음은 CPU 및 메모리 요청량과 제한을 정의하는 배포의 예입니다.
apiVersion: apps/v1
kind: 배포
메타데이터:
이름: ml-inference-deployment
사양:
복제본: 2
템플렛:
사양:
컨테이너:
- 이름: ml-inference-container
이미지: your-registry/ml-inference:latest
리소스:
요청:
CPU: "500미터"
기억: "512마일"
제한:
CPU: "1000미터"
기억: "1024마일"AI/ML 워크로드 확장
일단'리소스를 요청하고 할당하는 방법을 파악했으므로 이제 확장할 때입니다. 일부 시나리오에서는 급증하는 수신 요청을 처리하기 위해 유추 Pod를 수평으로 확장합니다. 다른 경우에는 특수 노드 유형이 필요할 수 있는 대규모 학습 작업을 예약합니다.
수평적 및 수직적 확장
수평 확장은 특히 추론 엔드포인트의 경우 예측할 수 없는 사용자 부하를 처리하는 데 필요한 것입니다. 설정하는 것이 가장 좋습니다. HPA CPU 또는 GPU 사용량을 관찰한 다음 상황이 뜨거워지면 새 포드를 가동합니다. 그래도 컨테이너에 단일 노드에 더 많은 메모리 또는 CPU 코어가 필요한 경우 수직 확장이 더 나은 해답이 될 수 있습니다. VPA(Vertical Pod Autoscaler) 시간이 지남에 따라 안정적인 워크로드에 대한 요청을 조정하는 데 도움이 될 수 있습니다.
여기's CPU 사용량별로 배포를 참조하는 HPA의 스니펫입니다.
apiVersion: 자동 크기 조정/v2
종류: HorizontalPodAutoscaler
메타데이터:
이름: inference-hpa
사양:
scaleTargetRef를 사용합니다.
apiVersion: apps/v1
kind: 배포
이름: inference-deployment
최소 복제본: 2
최대 복제본: 15
운율학:
- 유형: 리소스
자원:
이름: CPU
과녁:
유형: 활용
평균 사용률: 75배치 작업 및 스케줄링
대규모 학습은 배치 프로세스로 더 나은 경우가 많습니다. 파이프라인을 간소화하려면 일회성 실험에는 Kubernetes Jobs를 사용하고 야간 재학습과 같은 예약된 작업에는 CronJobs를 사용합니다. 이 접근 방식을 사용하면 작업 실행이 성공할 때마다 모델 또는 아티팩트가 나중에 사용할 수 있도록 어딘가에 자동으로 저장될 수 있습니다.
잘 구조화된 배치 작업은 장기 실행 훈련 작업이 클러스터 노드에 과부하를 주지 않도록 합니다. 이를 위해 다른 파드와 동일한 방식으로 GPU 또는 CPU 리소스를 요청하여 효과적으로 관리할 수 있다.
다음은 야간 훈련 실행을 시작하는 CronJob입니다.
api버전: 배치/v1
종류: CronJob
메타데이터:
이름: nightly-model-training
사양:
일정: "0 2 * * *"
jobTemplate을 사용합니다.
사양:
템플렛:
사양:
컨테이너:
- 이름: training-container
이미지: your-registry/training-image:latest
리소스:
제한:
nvidia.com/gpu: 1
명령: ["파이썬", "train.py"]
restartPolicy: 안 함Multi-cluster and hybrid 전략
때로는 워크로드를 여러 개에 분산해야 하는 경우가 있습니다. Kubernetes 클러스터, 특히 중복성을 원하거나 일부 작업을 온프레미스에서 실행하고 다른 작업을 클라우드에서 실행하려는 경우. 이를 통해 비용을 절약하고 위험을 줄일 수 있습니다. 다음과 같은 도구 안토스 작업이 분산되는 방식을 보여 주는 관리 콘솔을 제공합니다. 거기에 있다면'한 환경에서 문제가 발생하면 다른 환경으로 장애 조치할 수 있으므로 다음과 같은 경우 마음의 평화를 얻을 수 있습니다.'중요한 사용자 대면 추론 작업을 다시 저글링합니다.
스토리지 및 데이터 관리
작업을 효율적으로 확장할 수 있게 되면 데이터가 중심이 됩니다. 어디에 저장되나요? 얼마나 빨리 읽을 수 있습니까? 어떻게 백업합니까? 이러한 질문은 대규모 훈련 데이터 세트를 다룰 때 많이 나타나며, 데이터 검색이 병목 현상이 되는 것을 방지하는 데 중요합니다.
고성능 스토리지 클래스
SSD로 지원되는 StorageClass는 읽기/쓰기 요구가 많은 워크로드를 훈련하는 데 이상적입니다. 이를 최대한 활용하려면 올바른 StorageClass를 참조하는 PVC(PersistentVolumeClaim)와 백업 스토리지에 적합한 클러스터 프로비저닝을 정의합니다. 또한 읽기/쓰기 IOPS(초당 입력/출력 작업 수)를 모니터링하여 스토리지 볼륨이 필요한 처리량을 처리할 수 있는지 확인해야 합니다.
다음은 고성능 스토리지 클래스를 요청하는 PVC입니다.
파이 버전: v1
종류: PersistentVolumeClaim
메타데이터:
이름: FAST-PVC
사양:
accessModes를 사용합니다.
- 한 번 읽기
storageClassName: 고성능 SSD
리소스:
요청:
저장: 100Gi데이터 지역성 및 캐싱
분산 학습에서는 데이터 지역성이 중요합니다. 작업자가 원격 볼륨에서 데이터를 가져올 때 네트워크 지연 시간으로 인해 속도가 느려질 수 있습니다. 해결책은 무엇일까요? 원격 스토리지 앞에 캐싱 계층을 배치하거나 노드-로컬 SSD 볼륨을 선택합니다. 또 다른 전략은 동일한 포드에서 데이터 읽기 및 쓰기를 처리하는 캐싱 사이드카 컨테이너를 실행하여 특정 워크플로의 성능을 향상시키는 것입니다.
아래 스니펫은 학습 데이터에 대한 캐싱을 제공하는 사이드카 컨테이너를 보여줍니다.
apiVersion: apps/v1
kind: 배포
메타데이터:
이름: training-deployment
사양:
복제본: 2
선택자:
matchLabels를 사용합니다.
앱: training-app
템플렛:
메타데이터:
레이블:
앱: training-app
사양:
컨테이너:
- 이름: caching-sidecar
이미지: your-registry/caching-sidecar:latest
volumeMounts를 사용합니다.
- 이름: 캐시 볼륨
마운트 경로: /캐시
- 이름: training-container
이미지: your-registry/training-image:latest
volumeMounts를 사용합니다.
- 이름: 캐시 볼륨
마운트 경로: /데이터 세트
볼륨:
- 이름: 캐시 볼륨
empty디렉토리: {}백업 및 버전 관리
모델 버전을 추적하는 것은 그럴 만한 이유가 있습니다: 새 모델이 프로덕션에서 실패하면(이봐, 그런 일이 발생합니다!) 자주 롤백해야 합니다. 모델 아티팩트를 오브젝트 스토리지에 저장하는 것과 함께 예약된 백업을 실행하는 것도 중요합니다. 당신이'자동 백업을 제공하는 클라우드 서비스를 다시 사용하면 추가 백업을 통해 문제를 예방할 수 있습니다.
아래는 Argo 워크플로 모델 아티팩트를 S3의 원격 버킷에 업로드합니다.
api버전: argoproj.io/v1alpha1
kind: 워크플로
메타데이터:
generateName: 모델 백업-
사양:
진입점: 백업 모델
템플릿:
- 이름: backup-model
컨테이너:
이미지: your-registry/backup-tool:latest
명령: ["백업 모델"]
인수: ["--모델 경로=/모델", "--대상=s3://ml-백업s"]보안 고려 사항
우리'2024년 5월과 같이 클러스터가 하이재킹되거나 데이터가 유출되었다는 헤드라인을 모두 본 적이 있습니다 Hugging Face에서 무단 액세스 사건 공격자가 AI 모델 호스팅 플랫폼을 표적으로 삼은 곳입니다. 이러한 위반은 그 이유를 강조합니다. Kubernetes 보안 그리고 AI 보안 큰 우선순위가 되었습니다. 컨테이너화된 워크로드를 고급 ML 파이프라인과 결합하면 위협 벡터가 빠르게 증가합니다. 하자'이러한 위험을 억제하는 몇 가지 방법을 안내합니다.
AI 에이전트 25명. 257번의 진짜 공격. 누가 이길까?
제로데이 디스커버리부터 클라우드 권한 강화에 이르기까지, 우리는 257개의 실제 공격적 보안 과제에서 25개의 에이전트-모델 조합을 테스트했습니다. 결과가 놀라울 수도 있습니다 👀
쿠버네티스 보안의 기초
보안을 강화하려면 다음 모범 사례를 따르세요.
컨테이너 이미지 스캔 배포 전에 취약점을 감지합니다.
RBAC(역할 기반 액세스 제어) 적용 워크로드를 배포, 수정 또는 삭제할 수 있는 사용자를 제한합니다.
PSS(Pod Security Standards) 적용 클러스터를 위협에 노출시킬 수 있는 잘못된 구성을 방지하기 위해.
액세스 제한 컨테이너 레지스트리 무단 변경을 모니터링합니다.
안정적인 참조로 이미지 태그 지정 검증된 버전만 프로덕션에서 사용되도록 합니다.
여기'는 네임스페이스에 최소한의 권한을 부여하는 RBAC 스니펫입니다.
종류: 역할
apiVersion: rbac.authorization.k8s.io/v1
메타데이터:
네임스페이스: ml-project
이름: ml-project-role
규칙:
- api그룹: ["", "앱"]
리소스: ["포드", "배포"]
동사: ["가져오기", "목록", "창조하다", "업데이트", "삭제하다"]
---
종류: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
메타데이터:
이름: ml-project-rolebinding
네임스페이스: ml-project
과목:
- 종류: 사용자
이름: ml-user
apiGroup: rbac.authorization.k8s.io
roleRef:
종류: 역할
이름: ml-project-role
apiGroup: rbac.authorization.k8s.io모델 무결성 보호
AI 모델이 더욱 강력해지고 널리 배포됨에 따라 적대적 공격, 데이터 중독 및 배포 드리프트의 표적이 되기도 합니다. 공격자는 훈련 데이터를 조작하여 모델 성능을 저하시키거나 모델 로직의 약점을 악용할 수 있습니다.
이러한 위협을 완화하려면 들어오는 데이터에 이상 징후가 있는지 모니터링하고, 드리프트 탐지 도구를 사용하여 모델의 실제 성능이 떨어지기 시작하는 시기를 파악하고, 검증된 데이터 세트에 대해서만 훈련(또는 재훈련)합니다. 이러한 경계를 유지하면 진화하는 위협에 직면하여 모델이 정확하고 탄력적으로 유지되도록 하는 데 도움이 됩니다.
다음은 Alibi Detect 라이브러리를 사용하여 데이터 드리프트를 감지하는 방법을 보여주는 샘플 Python 스니펫입니다.
alibi_detect.cd에서 KSDrift 가져오기
numpy를 np로 가져오기
# 참조 데이터(예: 기준 학습 데이터)
X_ref = np.random.rand(1000, 10)
# 새로운 수신 데이터(예: 실시간 트래픽 샘플)
X = np.random.rand(1000, 10) # 실제 생산 데이터로 바꾸기
# 드리프트 감지기 초기화
cd = KSDrift(X_ref, p_val=0.05)
# 드리프트 검사 실행
preds = cd.predict(X)
포식['data_drift']:
인쇄("데이터 드리프트가 감지되었습니다! P-값:", preds['p_val'])
# 선택적으로 재교육 파이프라인 또는 경고를 트리거합니다.
다른:
인쇄("데이터 드리프트가 감지되지 않았습니다. P-값:", preds['p_val'])이미지 서명
모델 무결성을 유지하기 위한 조치를 취한 후 다음 방어 계층은 모델 아티팩트를 보유하는 컨테이너 이미지에 서명하여 모델의 신뢰성을 확인하는 것입니다. 다음과 같은 도구 공동 서명 디지털 서명을 간단하게 추가할 수 있으며, 미사용 암호화 및 교육 데이터에 대한 관리 체인은 특히 규제 산업에서 에코시스템을 더욱 보호하는 데 도움이 됩니다.
간단한 Cosign 명령을 사용하여 컨테이너 이미지에 서명할 수 있습니다.
$ cosign 서명 --key cosign.key your-registry/your-image:tag또한 CI 파이프라인에 자동화된 코드 검사 단계를 추가합니다. 이는 프로덕션에 도달하기 전에 종속성의 잠재적인 취약점을 포착하는 데 도움이 됩니다. 다음은 오픈 소스 보안 스캐너인 Trivy를 GitHub Actions 파이프라인에 통합하는 코드 조각입니다.
이름: code-scanning-workflow
켜기: [푸시, pull_request]
작업:
스캔하다:
실행 : 우분투 최신
단계:
- 용도: 액션/checkout@v2
- 이름: Trivy로 스캔
용도: aquasecurity/trivy-action@master
와:
이미지 참조: "your-registry/your-image:최신"
판: "테이블"네트워크 격리 및 제로 트러스트
AI 워크로드 보안은 강력한 네트워크 격리에서 시작됩니다. 한 가지 효과적인 접근 방식은 네트워크 정책 어떤 Pod를 제한하고 네임스페이스 서로 소통할 수 있습니다. 그 외에도'동일한 클러스터의 다른 애플리케이션과 함께 AI/ML 워크로드를 실행하지 않도록 하는 모범 사례입니다. 추론 서비스를 일반 웹 애플리케이션에서 분리하는 등 목적에 따라 워크로드를 분할하면 침해 발생 시 측면 이동의 위험을 최소화할 수 있습니다.
이 접근 방식은 모든 네트워크 트래픽이 신중하게 처리되는 제로 트러스트 원칙과 일치합니다.'s 클러스터 내부에 있습니다. 강력한 ID 액세스 관리와 결합된 이러한 가드레일은 우발적인 데이터 유출 및 침투 시도를 방지하는 데 도움이 됩니다.
여기's 유추 네임스페이스로만 트래픽을 제한하는 NetworkPolicy를 사용합니다.
api버전: networking.k8s.io/v1
종류: NetworkPolicy
메타데이터:
이름: allow-namespace-traffic
네임스페이스: 추론
사양:
podSelector: {}
진입:
-보낸 사람:
- 네임스페이스 선택기:
matchLabels를 사용합니다.
목적: 추론엔드 투 엔드 가시성: 코드에서 런타임까지
AI/ML 워크로드는 코드 개발에서 런타임 실행에 이르기까지 전체 수명 주기에 걸쳐 복잡한 보안 및 규정 준수 문제를 야기합니다. 완전한 가시성이 없으면 잘못된 구성, 취약성 및 드리프트가 Kubernetes 클러스터에 스며들어 침해 위험이 높아질 수 있습니다.
이 문제를 해결하기 위해 팀은 AI 파이프라인의 모든 단계를 포괄하는 보안 전략이 필요합니다: 코드형 인프라(IaC) 구성 스캔, 컨테이너 이미지 보안, 런타임 보호 적용그리고 지속적인 모니터링 이상 현상에 대해. 파이프라인 전반에 걸쳐 보안 제어를 통합하면 AI 워크로드의 복원력과 규정 준수를 유지할 수 있습니다.
Wiz는 클러스터 전체의 취약성, 규정 준수 문제 및 보안 태세를 실시간으로 추적할 수 있는 플랫폼을 제공합니다. Wiz 대시보드를 활용하여 컨테이너 이미지 문제, 잘못된 구성 등을 찾아냅니다. 비밀 코드에 숨어 있음:
Observability: 모니터링, 로깅 및 추적
기계 학습 워크로드에 맞게 클러스터를 튜닝할 때 무엇이 무엇인지 명확하게 파악하는 것을 목표로 합니다.'의 일이 일어나고 있습니다. 즉, 포드에서 메트릭을 수집하고, 중앙 집중식 위치에 로그를 저장하고, 마이크로서비스 전반에서 요청을 추적해야 합니다. 철저한 관찰 가능성은 무언가 불발 시 문제 해결을 쉽게 만듭니다.
메트릭 및 경고
Prometheus는 일반적으로 모니터링 스택의 중심에 위치하여 주요 성능 지표를 추적하는 데 도움이 됩니다. 원활한 AI/ML 작업을 보장하려면 다음과 같은 도구를 조합하여 사용하십시오.
프로메테우스 모델 추론 서비스에서 CPU, 메모리 및 GPU 사용량 지표를 수집합니다.
그라파나 클러스터 성능을 시각화하고 이상 징후를 감지할 수 있는 실시간 대시보드를 제공합니다.
경고 규칙 리소스 사용량이 정의된 임계값을 초과할 때 알림(예: Slack 알림)을 자동으로 트리거합니다.
다음은 높은 GPU 사용량에 대해 경고하는 PrometheusRule입니다.
다음은 높은 GPU 사용량에 대해 경고하는 PrometheusRule입니다.
api버전: monitoring.coreos.com/v1
종류: PrometheusRule
메타데이터:
이름: gpu-usage-rules
네임스페이스: 모니터링
사양:
그룹:
- 이름: GPU-Alerts
규칙:
- 경고: HighGPUUsage
expr: nvidia_gpu_utilization > 90
대상: 5m
레이블:
심각도: 경고
주석:
요약: "높은 GPU 사용량이 감지됨"분산 추적 및 성능 통찰력
OpenTelemetry는 특히 AI 파이프라인에 여러 마이크로서비스가 포함된 경우 분산 추적에 탁월한 선택입니다. 각 서비스는 추적 범위를 내보내므로 병목 현상이 발생할 수 있는 위치를 정확히 찾아낼 수 있습니다. 이 접근 방식은 데이터 처리 흐름에서 느린 요청이나 임의의 성능 이상을 디버깅할 때 매우 중요합니다.
OpenTelemetry Collector와 Jaeger가 함께 작동하여 AI/ML 워크로드에 대한 엔드 투 엔드 추적 및 성능 인사이트를 제공하는 방법은 다음과 같습니다.
보안 및 성능을 Wiz와 연관
경우에 따라 성능 저하가 보안 관련 이벤트와 관련이 있습니다. Wiz는 보안 결과 및 성능 데이터를 혼합하여 이러한 상관 관계를 확인하는 데 도움이 됩니다. 의심스러운 프로세스가 GPU 리소스를 차지하고 있거나 알려진 취약점으로 인해 클러스터가 불안정해질 수 있습니다. 이러한 패턴이 보이면 Wiz는 즉각적인 수정을 요청합니다.
🚨쿠버네티스 보안 연구 보고서 2025
200,000+ 클라우드 계정에서 얻은 새로운 인사이트는 Kubernetes 환경의 최신 위험, 공격 동향, 보안 공백을 밝혀냅니다.
다운로드 PDF
AI/ML 워크플로우를 위한 CI/CD
우리 모두는 훈련된 모델을 출시하는 데 단순히 파일을 복사하는 것 이상이 포함된다는 것을 알고 있습니다. ML 아티팩트 빌드, 테스트 및 배포를 완전히 자동화하려고 합니다. CI/CD 파이프라인이 유용한 곳입니다. 테스트를 실행하고, 이미지를 스캔하고, 레지스트리에 푸시한 다음, 새 버전을 프로덕션에 롤아웃하는 작업을 연결할 수 있습니다.
모델 라이프사이클 관리 자동화
다음과 같은 도구 텍톤 또는 Argo 워크플로 데이터 준비에서 훈련, 배포에 이르기까지 전체 모델 수명 주기에 대한 파이프라인을 정의할 수 있습니다. 각 단계는 변경 사항을 커밋할 때마다 자동으로 트리거되므로 프로세스가 일관되게 유지됩니다. 또한 검증 검사를 추가하여 프로덕션을 위해 태그를 지정하기 전에 모델이 사전 정의된 정확도 임계값을 충족하는지 확인할 수 있습니다. 이를 통해 성능이 저조한 모델이 배포되어 사용자 경험에 영향을 미치는 것을 방지할 수 있습니다.
아래는 Tekton 파이프라인런 모델 구축 및 배포가 시작됩니다.
api버전: tekton.dev/v1beta1
종류: PipelineRun
메타데이터:
이름: ml-pipeline-run
사양:
pipelineRef를 사용합니다.
이름: ml-build-deploy-pipeline
작업 공간:
- 이름: shared-data
volumeClaimTemplate을 사용합니다.
사양:
액세스 모드: ["한 번 읽기"]
리소스:
요청:
스토리지: 5Gi
매개변수:
- 이름: model-name
값: "마이-ML 모델"변경할 수 없는 아티팩트 및 GitOps
커밋 해시로 이미지에 태그를 지정하면 어떤 버전의 코드나 모델을 사용할 수 있는지 정확히 알 수 있습니다.'다시 실행. GitOps는 Kubernetes 매니페스트를 Git 리포지토리에 저장할 수 있도록 하여 이러한 관행을 확장합니다. 이러한 매니페스트에 대한 모든 변경 사항은 제어된 방식으로 클러스터에 자동으로 적용됩니다. 이 방법을 사용하면 변경 사항이 발생하는 시기와 이유를 정확하게 추적할 수 있습니다.
여기's 안 Argo CD 응용 프로그램 배포 구성 관리를 위해 Git 리포지토리를 참조합니다.
api버전: argoproj.io/v1alpha1
종류: 신청
메타데이터:
이름: ml-inference-app
사양:
목적지:
네임스페이스: ml-inference
서버: https://kubernetes.default.svc
근원:
repoURL을 사용합니다. 'https://github.com/your-org/ml-deploy-configs.git'
target개정: main
경로: 매니페스트/추론
프로젝트: 기본값
syncPolicy를 사용합니다.
자동:
가지치기: true
selfHeal: 참성능 최적화
모델은 빠르게 응답해야 하며 값비싼 GPU 또는 CPU 시간을 낭비하지 않아야 합니다. 다행히도 HPA 매개변수나 로드 밸런싱 규칙을 사소한 조정으로 귀중한 밀리초를 단축하고 비용을 크게 절감할 수 있습니다.
부하 분산Load balancing
Ingress 리소스를 사용한 로드 밸런싱은 트래픽을 올바른 추론 서비스로 라우팅하는 데 도움이 됩니다. 모델의 다른 버전을 분리하려면 경로 기반 라우팅을 사용할 수 있습니다.
다음은 여러 추론 서비스에 대한 경로 기반 라우팅을 사용하는 Ingress입니다.
api버전: networking.k8s.io/v1
종류: 수신
메타데이터:
이름: inference-ingress
사양:
규칙:
- 호스트: ml.example.com
http:
경로:
- 경로: /v1/
pathType: 접두사
백엔드:
서비스:
이름: inference-model-v1
항구:
번호: 8081
- 경로: /v2/
pathType: 접두사
백엔드:
서비스:
이름: inference-model-v2
항구:
번호: 8081비용 프로파일링 및 최적화
누구나 GPU 노드, CPU 노드 및 메모리 사용량이 지출과 어떻게 일치하는지 관찰하는 것을 좋아합니다. 그러나 리소스를 수동으로 조정하는 것은 시간이 많이 걸리고 비효율적일 수 있습니다. 다음과 같은 도구가 있는 곳입니다. 카펜터 그리고 자동 조종 장치 리소스 수요에 맞게 클러스터 노드를 자동으로 확장할 수 있으므로 수동 노드 프로비저닝을 피할 수 있습니다. 영구 컴퓨팅이 필요하지 않은 워크로드를 훈련하는 경우 스팟 인스턴스 비용을 크게 절감할 수 있으므로 파이프라인이 잠재적인 중단을 처리할 수 있는지 확인하십시오.
다음은 인스턴스 유형을 워크로드와 일치시키기 위한 Karpenter 구성의 예입니다.
api버전: karpenter.sh/v1alpha5
종류: 프로비저너
메타데이터:
이름: 기본값
사양:
요구 사항:
-열쇠: "node.kubernetes.io/instance-type"
연산자: In
값: ["m5.대형", "m5.xlarge(영어)"]
공급자:
subnetSelector를 사용합니다.
karpenter.sh/discovery: "내 클러스터"
securityGroupSelector를 사용합니다.
karpenter.sh/discovery: "내 클러스터"큰 비용을 절약할 수 있는 또 다른 방법은 무엇입니까? Wiz와 같은 도구를 사용하여 잘못 구성된 리소스나 비정상적인 사용 패턴과 관련된 비용 동인이 있는지 확인하세요. Wiz는 또한 노드를 생성하는 동안 노드를 강화하여 자동으로 확장될 뿐만 아니라 보안을 유지하는 데 도움이 됩니다.
결론
우리'Kubernetes의 기계 학습 워크플로에 대한 다양한 전략에 대해 이야기했습니다. 리소스 관리부터 AI 보안 모범 사례, Tekton 파이프라인 연결에 이르기까지 우리는'각 조각이 안정적인 플랫폼에 어떻게 기여할 수 있는지 살펴보았습니다. 주요 아이디어는 AI 보안 위험을 주시하고, 비용 초과를 감시하고, 사람들이 신뢰할 수 있는 파이프라인을 구축하는 것입니다.
이러한 모범 사례를 구현하면 클러스터 중단을 최소화하고 데이터 과학자가 자신 있게 업데이트를 푸시할 수 있습니다. 우리'이러한 제안이 귀하의 작업에 어떻게 적용되는지 기대됩니다. 우리'여러분이 만든 것, 발견한 교훈, Kubernetes 워크플로에서 머신 러닝의 수준을 계속 높이는 방법에 대해 듣고 싶습니다.
이 여정은 복잡하게 느껴질 수 있지만 Wiz와 같은 올바른 도구를 사용하면'의 실시간 스캔, 대시보드 및 규정 준수 기능을 통해 교육 및 추론을 위한 보다 안전한 환경을 구축할 수 있습니다. 만약 당신이'보안을 유지하면서 AI/ML 프로젝트를 개선하고 확장하려는 경우 Wiz에 컨테이너 취약성, 클러스터 설정 및 규정 준수 벤치마크를 전반적으로 볼 수 있는 기회를 제공하십시오. Wiz를 사용하면 클러스터를 건강하고 비용 효율적이며 침입으로부터 안전하게 유지할 수 있습니다.
코드에서 프로덕션까지 클라우드 보호
가장 빠르게 성장하는 기업들이 빌드 시간에서 실시간에 이르기까지 컨테이너, 쿠버네티스 및 클라우드 환경을 보호하기 위해 Wiz를 선택하는 이유를 알아보세요.
