기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
kubectl을 사용하여 로컬 NVMe 스토리지에서 모델 배포
이 주제에서는 Amazon S3 또는 Amazon FSx에서 네트워크를 통해 모델 가중치를 가져오는 대신 노드의 로컬 NVMe 스토리지에서 모델 가중치를 로드하는 추론 엔드포인트를 Amazon SageMaker HyperPod에 배포하는 방법을 보여줍니다. NVMe Amazon S3 FSx 로컬에서 가중치를 읽으면 포드 시작 중에 네트워크 홉이 제거되므로 추론 포드 콜드 스타트 시간이 줄어들고 이벤트, scale-from-zero 워크로드 및 지연 시간에 민감한 장애 조치를 자동으로 조정하는 데 유용합니다. 콜드 스타트 지연 시간이 문제가 되지 않는 워크로드의 경우 modelSourceType: s3 또는를 사용하고이 주제를 fsx 건너뜁니다.
로컬 NVMe는 노드-로컬 및 임시: 스팟 중단, 하드웨어 장애 또는 AMI 새로 고침과 같이 노드를 교체할 때 NVMe의 데이터가 손실됩니다. 이 주제의 접근 방식은 이를 다르게 처리합니다. 일부 노드는 모든 노드를 미리 채워야 하며, 다른 노드는 모델이 로컬로 캐시되지 않을 때 자동으로 Amazon S3로 돌아갑니다. 로컬 NVMe 인스턴스 스토리지는 일반적으로 P, G 및 Trn 인스턴스 패밀리에서 찾을 수 있습니다. 인스턴스 유형의 가용성을 확인하려면 Amazon EC2 인스턴스 스토어 사양을 참조하세요.
스토리지 요구 사항에 따라 다음 접근 방식 중에서 선택할 수 있습니다.
| # | 접근 방식 | 설명 |
|---|---|---|
| 1 | Kubernetes 볼륨(폴백 없음) | 모든 노드의 NVMe에 모델 가중치가 존재할 때 사용합니다. Amazon S3, Amazon FSx, PV/PVC 또는 initContainers 없이 가장 간단하게 설정할 수 있습니다. |
| 2 | 폴백이 있는 Kubernetes 볼륨 | 모든 노드의 NVMe에 모델이 없을 때 사용합니다. 모델이 누락된 경우 먼저 NVMe를 확인하고 IRSA 자격 증명을 사용하여 Amazon S3에서 다운로드initContainer하는 사용자 지정을 제공합니다. |
| 3 | 미리 가져오기 및 대체 기능이 있는 Amazon S3 | 포드 시작을 위해 모델 가중치를 RAM으로 스테이징하려는 경우를 사용합니다. NVMe를 먼저 확인하고 모델initContainer이 로컬로 캐시되지 않은 경우 운영자가 프로비저닝한 Amazon S3 마운트에서 복사하는 것으로 돌아가는 사용자 지정을 제공합니다. |
사전 조건
시작하기 전에 다음을 수행했는지 확인합니다.
-
Amazon SageMaker HyperPod 클러스터에서 추론 기능을 설정합니다. 자세한 내용은 모델 배포를 위한 HyperPod 클러스터 설정 단원을 참조하십시오.
-
대상 노드의 로컬 NVMe 스토리지에 미리 채워진 모델 가중치(지침NVMe에 모델 가중치 사전 로드은 참조).
배포 접근 방식 선택
다음 결정 흐름을 사용하여 사용 사례에 적합한 접근 방식을 결정합니다.
┌────────────────────────────┐ │ Want to use a volume of │ │ your choice, e.g. NVMe? │ └─────┬──────────────┬───────┘ YES │ │ NO ▼ ▼ ┌──────────────────────┐ Use S3/FSx/HF │ Are you sure EVERY │ as-is (no volume │ node has the model │ override needed) │ on NVMe? │ └─────┬──────────┬─────┘ YES │ │ NO ▼ ▼ ┌─────────────────┐ ┌───────────────────────────────┐ │ Approach 1 │ │ Do you need the operator to │ │ │ │ create S3/FSx PVCs as a │ │ Use k8sVolume │ │ fallback when the model is │ │ field in CRD to │ │ missing on a node? │ │ read from NVMe │ └──────┬────────────────┬───────┘ │ directly. │ YES │ │ NO └─────────────────┘ ▼ ▼ ┌──────────────────┐ ┌──────────────────────┐ │ Approach 3 │ │ Approach 2 │ │ │ │ │ │ Use S3 with │ │ Use k8sVolume with a │ │ prefetch enabled.│ │ custom initContainer │ │ Custom │ │ you create that │ │ initContainer │ │ checks NVMe first │ │ checks NVMe │ │ and downloads from │ │ first, falls │ │ S3 via IRSA if the │ │ back to S3, and │ │ model is missing. │ │ copies to RAM. │ └──────────────────────┘ └──────────────────┘
Kubernetes 볼륨을 사용하여 배포(폴백 없음)
모든 노드의 NVMe에 모델 가중치가 있고 Amazon S3 또는 Amazon FSx 구성, PV/PVC, initContainers 등 가장 간단한 설정을 원하는 경우이 접근 방식을 사용합니다.
modelSourceType: kubernetesVolume를 설정하면 연산자는 PV/PVC 생성을 완전히 건너뜁니다. CSI 드라이버, Amazon S3 퓨즈 탑재 또는 Amazon FSx 탑재는 사용되지 않습니다. 고객 제공 model-weights 볼륨은 포드 사양에서 직접 사용되며 작업자는의 NVMe에서 모델 데이터를 읽습니다/opt/ml/model.
중요
modelSourceType: kubernetesVolume를 사용할 때 연산자는 작업자 구성의 modelVolumeMount.name에서 예상 볼륨 이름을 추출합니다. 에는 동일한 이름의 볼륨이 포함되어야 kubernetes.volumes 합니다. 연산자는 이를 검증하고 일치하는 볼륨을 찾을 수 없는 경우 KubernetesVolumeValidationFailed 조건으로 배포를 거부합니다. 다음 예제에서는 둘 다를 사용합니다model-weights.
-
InferenceEndpointConfigYAML 파일을 생성합니다. 자리 표시자 값을 실제 리소스 식별자로 바꿉니다.cat <<EOF> deploy_nvme_k8s_volume.yaml apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: nvme-k8s-volume namespace: default spec: endpointName: nvme-k8s-volume modelName: Qwen2.5-VL-7B-Instruct invocationEndpoint: v1/chat/completions replicas: 1 modelSourceConfig: modelSourceType: kubernetesVolume kubernetes: volumes: - name: model-weights hostPath: path: /opt/dlami/nvme/<YOUR_MODEL> type: Directory loadBalancer: healthCheckPath: /health worker: image: lmcache/vllm-openai:latest args: - /opt/ml/model - --max-model-len - "15000" - --tensor-parallel-size - "1" modelInvocationPort: containerPort: 8000 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model resources: limits: nvidia.com/gpu: "1" requests: cpu: "6" memory: 30Gi nvidia.com/gpu: "1" environmentVariables: - name: PYTHONHASHSEED value: "123" - name: VLLM_REQUEST_TIMEOUT value: "600" EOF -
를 배포합니다
InferenceEndpointConfig.kubectl apply -f deploy_nvme_k8s_volume.yaml -
배포 상태를 확인합니다.
kubectl describe InferenceEndpointConfig nvme-k8s-volume -n default
폴백이 있는 Kubernetes 볼륨을 사용하여 배포
모델이 지정된 노드의 NVMe에 있거나 없을 때이 접근 방식을 사용합니다. hostPath 볼륨은 데이터가 있는 노드에서만 작동합니다. 다른 노드에 예약된 포드는 빈 경로 또는 존재하지 않는 경로를 탑재하여 모델 서버가 실패합니다.
이 접근 방식에서는 NVMe를 먼저 확인하고 모델이 누락된 경우 IRSA 자격 증명을 사용하여 Amazon S3에서 다운로드initContainer하는 사용자 지정를 설정하고 modelSourceType: kubernetesVolume 제공합니다.
IRSA 설정
배포하기 전에 Amazon S3에서 다운로드할 수 있는 자격 증명을 포드에 부여하도록 서비스 계정에 대한 IAM 역할(IRSA)을 구성합니다.
-
클러스터의 OIDC 공급자 ID를 가져옵니다.
aws eks describe-cluster --name <CLUSTER_NAME> --region <REGION> \ --query "cluster.identity.oidc.issuer" --output text -
IAM 신뢰 정책을 생성합니다. 다음을 로 저장
trust-policy.json하고 자리 표시자 값을 바꿉니다.{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/oidc.eks.<REGION>.amazonaws.com/id/<OIDC_ID>" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks.<REGION>.amazonaws.com/id/<OIDC_ID>:sub": "system:serviceaccount:<NAMESPACE>:<SA_NAME>", "oidc.eks.<REGION>.amazonaws.com/id/<OIDC_ID>:aud": "sts.amazonaws.com" } } }] }주의
항상 신뢰 정책의 범위를 특정 네임스페이스 및 ServiceAccount 이름으로 지정합니다. 모든 네임스페이스의 모든 ServiceAccount가 역할을 수임할 수 있으므로 제목 조건(예:
system:serviceaccount:*:*)에 와일드카드를 사용하지 마세요. -
IAM 역할을 생성하고 모델 버킷에 대해 범위가 지정된 Amazon S3 읽기 정책을 연결합니다.
aws iam create-role --role-name <ROLE_NAME> \ --assume-role-policy-document file://trust-policy.json aws iam put-role-policy --role-name <ROLE_NAME> \ --policy-name S3ModelReadAccess \ --policy-document '{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::<YOUR_BUCKET>", "arn:aws:s3:::<YOUR_BUCKET>/<YOUR_MODEL_PREFIX>/*" ] }] }' -
IRSA 주석을 사용하여 Kubernetes 서비스 계정을 생성합니다.
kubectl create sa <SA_NAME> -n <NAMESPACE> kubectl annotate sa <SA_NAME> -n <NAMESPACE> \ eks.amazonaws.com/role-arn=arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>
모델 배포
-
InferenceEndpointConfigYAML 파일을 생성합니다. 자리 표시자 값을 실제 리소스 식별자로 바꿉니다.cat <<EOF> deploy_nvme_k8s_volume_fallback.yaml apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: nvme-k8s-volume-fallback namespace: default spec: endpointName: nvme-k8s-volume-fallback modelName: Qwen2.5-VL-7B-Instruct invocationEndpoint: v1/chat/completions replicas: 1 modelSourceConfig: modelSourceType: kubernetesVolume kubernetes: serviceAccountName: <YOUR_SERVICE_ACCOUNT> initContainers: - name: smart-loader image: public.ecr.aws/aws-cli/aws-cli:latest command: ["/bin/bash", "-c"] args: - | if [ "$(ls -A /model)" ]; then echo "NVMe hit — model already present ($(du -sh /model | cut -f1))" else echo "NVMe miss — downloading from S3" aws s3 sync s3://<YOUR_BUCKET>/<YOUR_MODEL>/ /model/ fi volumeMounts: - name: model-weights mountPath: /model volumes: - name: model-weights hostPath: path: /opt/dlami/nvme/<YOUR_MODEL> type: DirectoryOrCreate loadBalancer: healthCheckPath: /health worker: image: lmcache/vllm-openai:latest args: - /opt/ml/model - --max-model-len - "15000" - --tensor-parallel-size - "1" modelInvocationPort: containerPort: 8000 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model resources: limits: nvidia.com/gpu: "1" requests: cpu: "6" memory: 30Gi nvidia.com/gpu: "1" environmentVariables: - name: PYTHONHASHSEED value: "123" EOF -
를 배포합니다
InferenceEndpointConfig.kubectl apply -f deploy_nvme_k8s_volume_fallback.yaml -
배포 상태를 확인합니다.
kubectl describe InferenceEndpointConfig nvme-k8s-volume-fallback -n default
미리 가져오기 및 NVMe 폴백과 함께 Amazon S3를 사용하여 배포
모델 가중치를 RAM으로 스테이징하여 추론 성능을 원하는 경우이 접근 방식을 사용하고, 모델이 NVMe에서 로컬로 캐시되지 않은 경우 Amazon S3로 자동 대체합니다.
modelSourceType: s3 로를 설정하면 연산자는 두 개의 볼륨prefetchEnabled: true을 자동으로 생성합니다.
-
modelVolumeMount.name(일반적으로model-weights)의 이름을 따서 명명된 볼륨 - 모델을 포함하는 Amazon S3 CSI 퓨즈 마운트 -
model-weights-copy-emptyDir작업자가 읽는 RAM 지원
노드의 로컬 NVMe 스토리지를 가리키는 사용자 지정 nvme-cache 볼륨과 다음과 initContainer 같은 사용자 지정 볼륨을 추가합니다.
-
NVMe에 모델이 있는 경우는 NVMe에서 RAM(
model-weights-copy)으로 복사하여 네트워크를 완전히 건너뜁니다. -
모델이 누락된 경우 - Amazon S3 탑재(
model-weights)에서 RAM()으로 복사하는 것으로 돌아갑니다model-weights-copy. 동일한 노드에서 후속 포드 시작이 빠른 로컬 경로를 사용하도록 NVMe에 복사할 수도 있습니다.
중요
이 접근 방식을 사용할 kubernetes.volumes 때는 model-weights에서 재정의하지 마십시오. 연산자는 Amazon S3 CSI 볼륨을 model-weights 가리키는를 생성합니다. 재정의하면 initContainer가 폴백에 필요한 운영자 프로비저닝 볼륨이 제거됩니다. NVMe hostPath에 별도의 볼륨 이름(예: nvme-cache)을 사용합니다.
중요
model-weights-copy에를 포함하지 마십시오kubernetes.volumes. 연산자가 자동으로 생성한 예약 이름입니다. initContainer는에서 이를 참조할 수 volumeMounts 있지만 볼륨으로 선언해서는 안 됩니다.
-
InferenceEndpointConfigYAML 파일을 생성합니다. 자리 표시자 값을 실제 리소스 식별자로 바꿉니다.cat <<EOF> deploy_nvme_s3_prefetch_fallback.yaml apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: nvme-s3-prefetch-fallback namespace: default spec: endpointName: nvme-s3-prefetch-fallback modelName: Qwen2.5-VL-7B-Instruct invocationEndpoint: v1/chat/completions replicas: 1 modelSourceConfig: modelSourceType: s3 s3Storage: bucketName: <YOUR_BUCKET> region: <YOUR_REGION> prefetchEnabled: true kubernetes: serviceAccountName: <YOUR_SERVICE_ACCOUNT> initContainers: - name: smart-loader image: public.ecr.aws/aws-cli/aws-cli:latest command: ["/bin/bash", "-c"] args: - | # Check NVMe first, fall back to S3 mount, then copy to RAM if [ "$(ls -A /nvme)" ]; then echo "NVMe hit ($(du -sh /nvme | cut -f1))" echo "Copying model from NVMe to RAM..." cp -r /nvme/* /model/ else echo "NVMe miss — copying from S3 mount to NVMe, then NVMe to RAM" cp -r /s3-model/* /nvme/ cp -r /nvme/* /model/ fi echo "Done. $(du -sh /model | cut -f1) in RAM." volumeMounts: - name: model-weights mountPath: /s3-model - name: nvme-cache mountPath: /nvme - name: model-weights-copy mountPath: /model volumes: - name: nvme-cache hostPath: path: /opt/dlami/nvme/<YOUR_MODEL> type: DirectoryOrCreate loadBalancer: healthCheckPath: /health worker: image: lmcache/vllm-openai:latest args: - /opt/ml/model - --max-model-len - "15000" - --tensor-parallel-size - "1" modelInvocationPort: containerPort: 8000 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model resources: limits: nvidia.com/gpu: "1" requests: cpu: "6" memory: 30Gi nvidia.com/gpu: "1" environmentVariables: - name: PYTHONHASHSEED value: "123" - name: VLLM_REQUEST_TIMEOUT value: "600" EOF -
를 배포합니다
InferenceEndpointConfig.kubectl apply -f deploy_nvme_s3_prefetch_fallback.yaml -
배포 상태를 확인합니다.
kubectl describe InferenceEndpointConfig nvme-s3-prefetch-fallback -n default
미리 가져오기를 사용하여 model-weights 및 model-weights-copy 이해
미리 가져오기를 사용할 때 연산자는 두 개의 모델 관련 볼륨을 생성합니다.
-
modelVolumeMount.name(일반적으로model-weights)의 이름을 따서 명명된 볼륨 - 모델을 포함하는 Amazon S3 CSI 퓨즈 마운트 -
model-weights-copy- 작업자가 실제로 읽는 RAM 지원 emptyDir
에서 다음을 InferenceEndpointConfig정의합니다.
modelVolumeMount: name: model-weights mountPath: /opt/ml/model
model-weights를 참조하는 동안 prefetchEnabled: true는 실제로 작업자 컨테이너의 /opt/ml/model에 탑재model-weights-copy됩니다. 사용자 지정 initContainer를 사용할 때는 model-weights-copy 작업자가 찾을 것으로 예상되는 라는 볼륨에 데이터를 복사해야 합니다.
prefetchEnabled: false인 경우 볼륨이 하나만 있으며( 뒤에 이름이 지정됨modelVolumeMount.name)에 직접 마운트됩니다/opt/ml/model.
사용자 지정 서비스 계정 구성
의 spec.kubernetes.serviceAccountName 필드를 사용하여 추론 엔드포인트 포드에 사용자 지정 Kubernetes ServiceAccount를 할당할 수 있습니다InferenceEndpointConfig. 이는 예를 들어 폴백 시나리오에서 Amazon S3에서 모델 가중치를 다운로드하는 등 IRSA(서비스 계정에 대한 IAM 역할)를 통해 작업자 컨테이너 또는 초기화 컨테이너에 자격 증명을 제공하는 AWS 데 유용합니다.
중요
사용자 지정 서비스 계정 지원은 기본적으로 비활성화되어 있으며 사용하기 전에 클러스터 관리자가 명시적으로 활성화해야 합니다. 자세한 내용은 사용자 지정 서비스 계정 활성화 섹션을 참조하세요.
ServiceAccount를 지정하지 않으면 네임스페이스의 기본 ServiceAccount가 사용됩니다.
사용자 지정 서비스 계정 활성화
사용자 지정 서비스 계정 지원은 기본적으로 비활성화되어 있습니다. 사용자가에서 사용자 지정 ServiceAccounts를 참조하려면 클러스터 관리자가 운영자의 Helm 구성에서 이를 활성화해야 합니다InferenceEndpointConfig.
-
연산자 Helm 값을 업데이트하여 기능을 활성화합니다. Helm을 통해 연산자를 배포한 경우 플래그로 업그레이드합니다.
helm upgrade hyperpod-inference-operator <CHART_PATH> \ --set enableCustomServiceAccounts=true \ --reuse-values -
연산자를 Amazon EKS 추가 기능으로 배포한 경우 추가 기능 구성을 업데이트하여 고급 구성 설정에
enableCustomServiceAccounts: true포함시킵니다. -
연산자 포드에 환경 변수가 설정되어 있는지 확인합니다.
kubectl get deployment hyperpod-inference-operator-controller-manager \ -n hyperpod-inference-system \ -o jsonpath='{.spec.template.spec.containers[0].env}' | jq '.[] | select(.name=="ENABLE_CUSTOM_SERVICE_ACCOUNTS")'다음과 같은 내용이 표시되어야 합니다.
{ "name": "ENABLE_CUSTOM_SERVICE_ACCOUNTS", "value": "true" }
중요
이 기능이 활성화되지 않은 경우를 InferenceEndpointConfig 지정하는 모든이 DeploymentFailed 상태 및 메시지와 함께 거부kubernetes.serviceAccountName됩니다kubernetes.serviceAccountName is not enabled. Requires addon configuration (enableCustomServiceAccounts: true).
서비스 계정에 레이블 지정
사용자 지정 ServiceAccount를 참조하려면 클러스터 관리자가 사용자 지정 가능으로 레이블을 지정해야 합니다.
kubectl label serviceaccount <your-service-account> \ sagemaker.amazonaws.com/user-assignable=true \ -n <namespace>
추론 엔드포인트에서는이 레이블ServiceAccounts만 참조할 수 있습니다. 이는 무단 권한 에스컬레이션을 방지하기 위한 보안 제어입니다.
구성에서 서비스 계정 지정
의 아래에 serviceAccountName 필드를 추가합니다spec.kubernetesInferenceEndpointConfig.
apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: my-inference-endpoint namespace: my-namespace spec: kubernetes: serviceAccountName: my-inference-sa # ... rest of your config
검증 규칙
연산자는 생성 및 업데이트 작업 모두에서 serviceAccountName 필드를 검증합니다. 다음 조건 중 하나라도 충족되면 배포가 거부되고 DeploymentFailed 상태가 됩니다.
-
ServiceAccount가 네임스페이스에 존재하지 않습니다.
serviceAccountName "X" not found in namespace "Y" -
ServiceAccount에 필수 레이블이 없습니다.
serviceAccountName "X" is not labeled as user-assignable (requires label sagemaker.amazonaws.com/user-assignable=true) -
ServiceAccount는 운영자의 시스템 ServiceAccount입니다.
serviceAccountName must not reference the operator's service account
참고
추론 포드의 모든 컨테이너(작업자, init 컨테이너 및 사이드카)는 지정된 ServiceAccount의 권한을 상속합니다. ServiceAccount에 주석이 달린 경우 eks.amazonaws.com/role-arn포드는 해당 IAM 역할에 대한 임시 AWS 자격 증명을 받습니다. 클러스터 관리자는 연결된 RBAC 역할 및 IAM 권한을 검토한 후에만 ServiceAccounts에 사용자 할당 가능으로 레이블을 지정해야 합니다.
참고
가 이미 실행 중인 동안 ServiceAccountInferenceEndpointConfig가 삭제되면 기존 포드는 다시 시작될 때까지 현재 자격 증명으로 계속 실행됩니다. 그러나 ServiceAccount가 더 이상 존재하지 않으므로 새 포드 생성(예: 조정 또는 일정 조정 중)이 실패합니다. 배포가 처음 생성되고 IEC 사양이 업데이트될 때 운영자는 ServiceAccount를 검증합니다. ServiceAccount는 지속적으로 모니터링하지 않습니다. SA가 삭제된 후 IEC 사양을 업데이트하면 DeploymentFailed 상태가 됩니다.
사용자 지정 서비스 계정에 대한 보안 모범 사례
추론 엔드포인트와 함께 사용자 지정 ServiceAccount를 사용하면 HyperPod 추론 운영자가 사용자를 대신하여 배포를 생성합니다. 작업자, init 컨테이너 및 사이드카를 포함한 추론 포드의 모든 컨테이너는 지정된 ServiceAccount의 권한을 상속합니다. 다음 모범 사례에 따라 클러스터를 보호합니다.
RBAC 권한 잠금
-
각 추론 워크로드에 대한 전용 ServiceAccount를 생성합니다. 관련 없는 워크로드에서 ServiceAccounts 재사용하지 마세요.
-
필요한 최소 RBAC 권한만 바인딩합니다. 예를 들어 init 컨테이너가 Amazon S3에서만 읽어야 하는 경우 ServiceAccount에는 Kubernetes 리소스를 나열하거나 수정할 수 있는 권한이 없어야 합니다.
# Example: minimal Role for an inference workload that only needs S3 access via IRSA # No Kubernetes API permissions needed — IRSA provides AWS credentials directly apiVersion: v1 kind: ServiceAccount metadata: name: my-inference-sa namespace: my-namespace labels: sagemaker.amazonaws.com/user-assignable: "true" annotations: eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/<SCOPED_ROLE_NAME> -
추론 포드에서 사용하는 ServiceAccounts에 클러스터 전체 권한(ClusterRoleBindings)을 부여하지 마세요.
IRSA IAM 역할 범위 지정
-
로 ServiceAccount에 주석을 달 때는 IAM 역할이 최소 권한 원칙을 따르는지
eks.amazonaws.com/role-arn확인합니다. -
Amazon S3 권한 범위를 모델 가중치가 포함된 특정 버킷 및 접두사로 지정합니다.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::<YOUR_BUCKET>", "arn:aws:s3:::<YOUR_BUCKET>/<YOUR_MODEL_PREFIX>/*" ] }] } -
프로덕션
AmazonS3FullAccess환경에서와 같은 광범위한 관리형 정책을 사용하지 마십시오. 모델 버킷으로 범위가 지정된AmazonS3ReadOnlyAccess또는 사용자 지정 정책을 사용합니다.
사용자 할당 가능 레이블 보호
-
클러스터 관리자만
sagemaker.amazonaws.com/user-assignable=true레이블을 추가하거나 제거해야 합니다. Kubernetes RBAC를 사용하여 네임스페이스에서 ServiceAccount 레이블을 수정할 수 있는 사용자를 제한합니다. -
ServiceAccount와 연결된 RBAC 역할 및 IAM 권한을 검토한 후 사용자 할당 가능으로 레이블을 지정합니다.
-
user-assignable레이블이 있는 ServiceAccounts를 정기적으로 감사합니다.kubectl get serviceaccounts -n <NAMESPACE> -l sagemaker.amazonaws.com/user-assignable=true -
관리자가 아닌 역할에 ServiceAccount 리소스에 대한
patchupdate, 또는create동사가 포함되어 있지 않은지 확인합니다. 운영자는 배포 시user-assignable레이블을 검증하지만 권한이 없는 사용자가 ServiceAccount에 레이블을 추가하는 것을 방지하지는 않습니다. RBAC를 통해 ServiceAccounts를 수정할 수 있는 사용자를 제한하는 것이이 레이블을 보호하기 위한 기본 제어입니다. 관리자가 아닌 사용자는get및list액세스 권한만 있어야 합니다.# Example: RBAC Role for non-admin users — read-only access to ServiceAccounts apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: sa-read-only namespace: <NAMESPACE> rules: - apiGroups: [""] resources: ["serviceaccounts"] verbs: ["get", "list"]
중요
HyperPod 추론 연산자는 사용자를 대신하여 배포를 생성하는 중개자 역할을 합니다. 호출자가 포드를 직접 생성하는 표준 Kubernetes 워크로드와 달리 운영자는 생성한 포드에 지정된 ServiceAccount를 할당합니다. 즉, 사용자가 할당할 수 있는 ServiceAccount에 부여된 모든 권한은 해당 네임스페이스InferenceEndpointConfig에서를 생성할 수 있는 모든 사용자가 효과적으로 사용할 수 있습니다. 네임스페이스 수준 RBAC가 InferenceEndpointConfig 리소스를 생성하고 업데이트할 수 있는 사용자를 제어하는지 확인합니다.
NVMe에 모델 가중치 사전 로드
배포하기 전에 특정 노드에서 NVMe를 미리 채워야 하는 경우 일회성 포드를 사용하여 Amazon S3에서 동기화할 수 있습니다.
참고
이 접근 방식은를 통해 특정 노드를 대상으로 nodeName 하며 Auto Scaling에서는 작동하지 않습니다. Auto Scaling 시나리오의 경우 initContainer 폴백 로직을 통해 누락된 모델을 자동으로 처리하는 폴백이 있는 Kubernetes 볼륨 또는 미리 가져오기 접근 방식이 있는 Amazon S3를 사용합니다.
-
프리로드 포드 YAML 파일을 생성합니다. 자리 표시자 값을 실제 리소스 식별자로 바꿉니다.
cat <<EOF> nvme-s3-copy.yaml apiVersion: v1 kind: Pod metadata: name: nvme-s3-copy namespace: default spec: nodeName: <TARGET_NODE> restartPolicy: Never containers: - name: s3-copy image: public.ecr.aws/aws-cli/aws-cli:latest command: ["/bin/bash", "-c"] args: - | echo "=== Starting S3 sync to NVMe ===" aws s3 sync s3://<YOUR_BUCKET>/<YOUR_MODEL>/ /nvme/<YOUR_MODEL>/ --region <YOUR_REGION> echo "=== Sync complete ===" ls -la /nvme/<YOUR_MODEL>/ du -sh /nvme/<YOUR_MODEL>/ echo "=== Done ===" volumeMounts: - name: nvme-storage mountPath: /nvme serviceAccountName: default volumes: - name: nvme-storage hostPath: path: /opt/dlami/nvme type: Directory EOF -
포드를 적용하고 동기화 진행 상황을 모니터링합니다.
kubectl apply -f nvme-s3-copy.yaml kubectl get pod nvme-s3-copy -w kubectl logs nvme-s3-copy -f -
동기화가 완료된 후 포드를 정리합니다.
kubectl delete pod nvme-s3-copy
예약 볼륨 이름
연산자는를 통해 재정의할 수 없는 여러 내부 볼륨을 관리합니다kubernetes.volumes. 이러한 이름 중 하나를 사용하면 KubernetesVolumeValidationFailed 조건이 발생합니다.
| # | 이름 | 용도 |
|---|---|---|
| 1 | shm |
프로세스 간 통신을 위한 공유 메모리(/dev/shm) |
| 2 | model-weights-copy |
RAM 지원 emptyDir는 다음과 같은 경우에 사용됩니다. prefetchEnabled: true |
| 3 | parallel-copy-configmap |
병렬 복사 스크립트용 ConfigMap(사전 가져오기) |
| 4 | lmcache-config |
LMCache 구성 볼륨 |
| 5 | gated-model-downloader-configmap |
게이트 모델 다운로드 스크립트용 ConfigMap |
기억해야 할 사항
-
예약된 볼륨 이름은 사용하지 마세요. 연산자는 여러 내부 볼륨을 관리합니다( 참조예약 볼륨 이름). 에서 이러한 이름 중 하나를 사용하면
KubernetesVolumeValidationFailed조건이kubernetes.volumes발생합니다. -
볼륨 이름이 일치해야 합니다. 연산자는에서 볼륨 이름을 추출합니다
modelVolumeMount.name.modelSourceType: kubernetesVolume를 사용하는 경우 에는 동일한 이름의 볼륨이 포함되어야kubernetes.volumes합니다. -
initContainer의 올바른 위치에 볼륨을 마운트합니다. 생성한 볼륨이 initContainer의 올바른 경로에 마운트되었는지 확인합니다.
-
S3/FSx에는 사용자 지정 서비스 계정이 필요하지 않습니다. 사용자 지정 서비스 계정을 만들 수 없거나 만들지 않으려는 경우
modelSourceType: s3또는를 사용할 수 있습니다fsx. 연산자는 S3/FSx 볼륨을 자동으로 프로비저닝합니다. 여전히 운영자 관리형 스토리지 위에 사용자 지정 볼륨을 추가initContainers하고 재정의할 수 있습니다. -
IRSA 자격 증명은 모든 컨테이너에 주입됩니다. IRSA 주석이 있는 서비스 계정으로
kubernetes.serviceAccountName를 설정하면 Amazon EKS는 사용자 지정 initContainers를 포함한 모든 컨테이너에 AWS 자격 증명(aws-iam-token볼륨,AWS_ROLE_ARN,AWS_WEB_IDENTITY_TOKEN_FILE)을 주입합니다. -
를 사용할
modelLocation때는를 설정하지 마십시오kubernetesVolume. 볼륨 경로는에 의해 제어됩니다kubernetes.volumes.modelSourceType를modelLocation로 설정kubernetesVolume하면 검증 오류가 발생합니다. -
model-weights와가 사전 가져오기와model-weights-copy함께 작동하는 방식을 이해합니다.prefetchEnabled: true인 경우 연산자는 두 개의 모델 관련 볼륨을 생성합니다.-
model-weights- 소스 볼륨(Amazon S3/Amazon FSx PVC 또는 재정의) -
model-weights-copy- 작업자가 실제로 읽는 RAM 지원 emptyDir
-
-
구성
model-weights에서를 참조하는 동안prefetchEnabled: true는 실제로 작업자 컨테이너의/opt/ml/model에 탑재model-weights-copy됩니다. 사용자 지정 initContainer를 사용할 때는model-weights-copy작업자가 찾을 것으로 예상되는 라는 볼륨에 데이터를 복사해야 합니다.prefetchEnabled: false인 경우 볼륨이 하나만 있으며( 뒤에 이름이 지정됨modelVolumeMount.name)에 직접 마운트됩니다/opt/ml/model.
문제 해결
배포가 예상대로 작동하지 않는 경우 이러한 디버깅 명령을 사용합니다.
-
InferenceEndpointConfig상태를 확인하여 상위 수준 배포 상태와 구성 문제를 확인합니다.kubectl describe InferenceEndpointConfig <ENDPOINT_NAME> -n <NAMESPACE> -
Kubernetes 배포 상태를 확인합니다.
kubectl describe deployment <ENDPOINT_NAME> -n <NAMESPACE> -
네임스페이스에 있는 모든 Kubernetes 객체의 상태를 확인합니다.
kubectl get pods,svc,deployment,InferenceEndpointConfig,sagemakerendpointregistration -n <NAMESPACE> -
모델 로드 단계가 실패하면 initContainer 로그를 확인합니다.
kubectl logs <POD_NAME> -c smart-loader -n <NAMESPACE> -
"네임스페이스에서 찾을 수 없음"으로 배포에 실패하는 경우 ServiceAccount가 존재하는지 확인합니다.
kubectl get serviceaccount <name> -n <namespace> -
"사용자 할당 가능으로 레이블이 지정되지 않음"으로 배포에 실패하는 경우 클러스터 관리자에게 필요한 레이블을 추가하도록 요청합니다.
kubectl label serviceaccount <name> sagemaker.amazonaws.com/user-assignable=true -n <namespace> -
" 운영자의 서비스 계정을 참조해서는 안 됨"으로 배포에 실패하는 경우 워크로드에 대해 별도의 ServiceAccount를 생성합니다. HyperPod 추론 운영자의 자체 ServiceAccount는 사용할 수 없습니다.