문제 해결 AWS Batch - AWS Batch
AWS BatchAWS Batch 아마존에서 EKS

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

문제 해결 AWS Batch

컴퓨팅 환경, 작업 대기열, 작업 정의, 작업 등과 관련한 문제를 해결해야 하는 경우도 있습니다. 이 장에서는 사용자 환경에서 이러한 문제를 해결하고 해결하는 방법을 설명합니다. AWS Batch

AWS Batch IAM정책, 역할 및 권한을 사용하고 Amazon, Amazon 및 Amazon EC2 Elastic Kubernetes Service 인프라에서 실행됩니다. ECS AWS Fargate이러한 서비스와 관련된 문제를 해결하려면 다음을 참조하세요.

AWS Batch

INVALID 컴퓨팅 환경

관리형 컴퓨팅 환경을 잘못 구성했을 수 있습니다. 잘못 구성한 경우 컴퓨팅 환경이 INVALID 상태가 되어 배치 작업을 수락할 수 없습니다. 다음 섹션에서는 발생 가능한 원인과 원인에 따른 문제 해결 방법을 설명합니다.

역할 이름이 잘못되었거나 ARN

컴퓨팅 환경이 INVALID 상태로 전환되는 가장 일반적인 원인은 AWS Batch 서비스 역할 또는 Amazon EC2 스팟 플릿 역할의 이름 또는 Amazon Resource Name (ARN) 이 잘못되었기 때문입니다. 이는 AWS CLI 또는 를 사용하여 생성된 컴퓨팅 환경에서 더 흔합니다 AWS SDKs. 에서 컴퓨팅 환경을 생성하면 올바른 서비스 또는 스팟 플릿 역할을 선택하는 AWS Batch 데 도움이 됩니다. AWS Management Console하지만 이름을 수동으로 입력하거나 를 잘못 입력했다고 가정해 보겠습니다. ARN 그러면 컴퓨팅 환경 결과도 마찬가지로 INVALID입니다.

하지만 AWS CLI 명령이나 코드에서 IAM 리소스의 이름이나 ARN 이름을 수동으로 입력한다고 가정해 보겠습니다. SDK 이 경우 문자열의 유효성을 AWS Batch 검사할 수 없습니다. 대신 AWS Batch 는 잘못된 값을 수락하고 환경 생성을 시도해야 합니다. 환경 생성에 AWS Batch 실패하면 환경이 특정 INVALID 상태로 전환되고 다음과 같은 오류가 표시됩니다.

유효하지 않은 서비스 역할인 경우:

CLIENT_ERROR - Not authorized to perform sts:AssumeRole (Service: AWSSecurityTokenService; Status Code: 403; Error Code: AccessDenied; Request ID: dc0e2d28-2e99-11e7-b372-7fcc6fb65fe7)

유효하지 않은 스팟 집합 역할인 경우:

CLIENT_ERROR - Parameter: SpotFleetRequestConfig.IamFleetRole is invalid. (Service: AmazonEC2; Status Code: 400; Error Code: InvalidSpotFleetRequestConfig; Request ID: 331205f0-5ae3-4cea-bac4-897769639f8d) Parameter: SpotFleetRequestConfig.IamFleetRole is invalid

이 문제가 발생하는 한 가지 일반적인 원인은 다음 시나리오입니다. 전체 Amazon 리소스 이름 (ARN) 대신 AWS CLI 또는 를 사용할 때만 IAM 역할 이름을 지정합니다. AWS SDKs 역할을 생성한 방법에 따라 에 aws-service-role 경로 접두사가 ARN 포함될 수 있습니다. 예를 들어 의 절차를 사용하여 AWS Batch 서비스 역할을 수동으로 만드는 경우 서비스 역할은 다음과 같을 ARN 수 있습니다. 서비스 연결 역할 사용 AWS Batch 

arn:aws:iam::123456789012:role/AWSBatchServiceRole

하지만 오늘 콘솔 최초 실행 마법사의 일부로 서비스 역할을 만든 경우 서비스 역할은 다음과 같을 ARN 수 있습니다.

arn:aws:iam::123456789012:role/aws-service-role/AWSBatchServiceRole

이 문제는 AWS Batch 서비스 수준 정책 (AWSBatchServiceRole) 을 서비스가 아닌 역할에 연결하는 경우에도 발생할 수 있습니다. 예를 들어, 이 시나리오에서는 다음과 유사한 오류 메시지가 표시될 수 있습니다.

CLIENT_ERROR - User: arn:aws:sts::account_number:assumed-role/batch-replacement-role/aws-batch is not 
     authorized to perform: action on resource ...

이 문제를 해결하려면 다음 중 한 가지를 사용합니다.

  • 컴퓨팅 환경을 만들 때 서비스 역할에 빈 문자열을 사용하십시오. AWS Batch

  • arn:aws:iam::account_number:role/aws-service-role/batch.amazonaws.com/AWSServiceRoleForBatch 형식으로 서비스 역할을 지정합니다.

AWS CLI 또는 를 사용할 때 IAM 역할 이름만 지정하는 경우 AWS SDKs, 는 aws-service-role path 접두사를 사용하지 ARN 않는 AWS Batch 것으로 간주합니다. 따라서 컴퓨팅 환경을 만들 때 IAM 역할에 전체를 ARN 지정하는 것이 좋습니다.

이와 같이 잘못 구성된 컴퓨팅 환경을 복원하려면 INVALID 컴퓨팅 환경 복원 섹션을 참조하세요.

INVALID 컴퓨팅 환경 복원

INVALID 상태의 컴퓨팅 환경이 있는 경우에는 업데이트를 통해 유효하지 않은 파라미터를 복원합니다. 역할 이름이 잘못되었거나 ARN의 경우에는 올바른 서비스 역할을 사용하여 컴퓨팅 환경을 업데이트합니다.

잘못 구성된 컴퓨팅 환경을 복원하려면

  1. 에서 AWS Batch 콘솔을 https://console.aws.amazon.com/batch/여십시오.

  2. 탐색 표시줄에서 사용할 AWS 리전 항목을 선택합니다.

  3. 탐색 창에서 컴퓨팅 환경을 선택합니다.

  4. 컴퓨팅 환경 페이지에서 편집할 컴퓨팅 환경 옆의 라디오 버튼을 선택한 다음 편집을 선택합니다 .

  5. 컴퓨팅 환경 업데이트 페이지의 서비스 역할에서 컴퓨팅 환경에 사용할 IAM 역할을 선택합니다. AWS Batch 콘솔에는 컴퓨팅 환에 대해 올바른 신뢰 관계를 가지고 있는 역할만 표시됩니다.

  6. 저장을 선택하여 컴퓨팅 환경을 업데이트합니다.

RUNNABLE 상태에서 정체된 작업

컴퓨팅 환경에 컴퓨팅 리소스가 포함되어 있지만 작업이 RUNNABLE 상태 이상으로 진행되지 않는다고 가정해 보겠습니다. 그러면 무언가로 인해 작업이 컴퓨팅 리소스에 배치되지 않아 작업 대기열이 차단될 수 있습니다. 작업이 차례를 기다리고 있는지, 아니면 멈춰서 대기열을 막고 있는지 확인하는 방법은 다음과 같습니다.

대기열을 차단하고 있는 RUNNABLE 작업이 AWS Batch 감지되면 Amazon Events에서 해당 이유와 함께 차단된 작업 대기열 CloudWatch 이벤트를 받게 됩니다. ListJobsand DescribeJobs API 호출의 일부로도 같은 이유가 statusReason 필드에 업데이트됩니다.

선택적으로 CreateJobQueue 및 UpdateJobQueueAPI작업을 통해 jobStateTimeLimitActions 매개변수를 구성할 수 있습니다.

참고

현재 사용할 수 있는 유일한 조치는 작업을 취소하는 것입니다. jobStateLimitActions.action

jobStateTimeLimitActions매개 변수는 특정 상태의 작업에 대해 AWS Batch 수행하는 일련의 작업을 지정하는 데 사용됩니다. maxTimeSeconds필드를 통해 시간 임계값을 초 단위로 설정할 수 있습니다.

작업이 정의된 RUNNABLE statusReason 상태에 maxTimeSeconds 있으면 작업이 경과된 후 지정된 작업을 AWS Batch 수행합니다.

예를 들어, 충분한 용량을 사용할 수 있을 때까지 대기 중인 RUNNABLE 상태의 모든 작업이 최대 4시간까지 대기하도록 jobStateTimeLimitActions 매개 변수를 설정할 수 있습니다. 이렇게 하려면 작업을 취소하기 전에 144000으로 또는 144000으로 설정하고 statusReason 다음 작업이 작업 대기열의 맨 위로 넘어가도록 하면 됩니다. CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY maxTimeSeconds

작업 큐가 차단된 것을 AWS Batch 감지했을 때 나타나는 이유는 다음과 같습니다. 이 목록은 ListJobs 및 DescribeJobs API 작업에서 반환된 메시지를 제공합니다. 이 값도 jobStateLimitActions.statusReason 파라미터에 정의할 수 있는 값과 동일합니다.

  1. 원인: 연결된 모든 컴퓨팅 환경에서 용량 부족 오류가 발생합니다. 요청 시 용량 부족 오류가 발생하는 Amazon EC2 인스턴스를 AWS Batch 탐지합니다. 수동으로 또는 jobStateTimeLimitActions 파라미터를 statusReason 켜서 작업을 취소하면 후속 작업이 대기열의 맨 위로 이동할 수 있습니다.

    • statusReason작업이 중단된 상태에서의 메시지: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY - Service cannot fulfill the capacity requested for instance type [instanceTypeName]

    • reason사용 대상jobStateTimeLimitActions: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY

    • statusReason작업 취소 후의 메시지: Canceled by JobStateTimeLimit action due to reason: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY

    참고:

    1. 이 탐지가 작동하려면 AWS Batch 서비스 역할에 autoscaling:DescribeScalingActivities 권한이 필요합니다. AWSServiceRoleForBatch서비스 연결 역할 (SLR) 또는 AWSBatchServiceRolePolicy관리형 정책을 사용하는 경우 권한 정책이 업데이트되므로 별도의 조치를 취할 필요가 없습니다.

    2. SLR또는 관리형 정책을 사용하는 경우, 실행 시 차단된 작업 큐 이벤트와 업데이트된 작업 상태를 받을 수 있도록 autoscaling:DescribeScalingActivities 및 ec2:DescribeSpotFleetRequestHistory 권한을 추가해야 합니다. RUNNABLE 또한 작업 큐에 매개 변수가 구성되어 있더라도 jobStateTimeLimitActions 매개 변수를 통해 cancellation 작업을 수행하려면 이러한 권한이 AWS Batch 필요합니다.

    3. 다중 노드 parallel (MNP) 작업의 경우, 우선 순위가 높은 연결된 Amazon EC2 컴퓨팅 환경에서 insufficient capacity 오류가 발생하면 우선 순위가 낮은 컴퓨팅 환경에서 이 오류가 발생하더라도 대기열이 차단됩니다.

  2. 이유: 모든 컴퓨팅 환경의 maxvCpus파라미터는 작업 요구 사항보다 작습니다. 수동으로 또는 jobStateTimeLimitActions 매개 변수를 statusReason 켜서 작업을 취소하면 후속 작업이 대기열의 맨 위로 이동할 수 있습니다. 선택적으로 차단된 작업의 요구 사항에 맞게 기본 컴퓨팅 환경의 maxvCpus 매개 변수를 늘릴 수 있습니다.

    • statusReason작업이 중단된 상태에서의 메시지: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE - CE(s) associated with the job queue cannot meet the CPU requirement of the job.

    • reason사용 대상jobStateTimeLimitActions: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE

    • statusReason작업 취소 후의 메시지: Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE

  3. 이유: 컴퓨팅 환경 중 작업 요구 사항을 충족하는 인스턴스가 없습니다. 작업에서 리소스를 요청하면 들어오는 작업을 수용할 수 있는 연결된 컴퓨팅 환경이 없음을 AWS Batch 감지합니다. 수동으로 또는 jobStateTimeLimitActions 매개 변수를 statusReason 켜서 작업을 취소하면 후속 작업이 대기열의 맨 위로 이동할 수 있습니다. 선택적으로 컴퓨팅 환경의 허용된 인스턴스 유형을 재정의하여 필요한 작업 리소스를 추가할 수 있습니다.

    • statusReason작업이 중단된 상태에서의 메시지: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT - The job resource requirement (vCPU/memory/GPU) is higher than that can be met by the CE(s) attached to the job queue.

    • reason사용 대상jobStateTimeLimitActions: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT

    • statusReason작업 취소 후의 메시지: Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT

  4. 원인: 모든 컴퓨팅 환경에 서비스 역할 문제가 있습니다. 이 문제를 해결하려면 서비스 역할 권한을 AWS Batch 관리형 서비스 역할 권한과 비교하고 격차를 해결하세요.

    유사한 오류를 방지하려면 컴퓨팅AWS Batch SLR 환경용 를 사용하는 것이 가장 좋습니다.

    수동으로 또는 jobStateTimeLimitActions 매개 변수를 statusReason 켜서 작업을 취소하면 후속 작업이 대기열의 맨 위로 이동할 수 있습니다. 서비스 역할 문제를 해결하지 않으면 다음 작업도 차단될 수 있습니다. 이 문제를 수동으로 조사하여 해결하는 것이 가장 좋습니다.

    • statusReason작업이 중단된 상태에서의 메시지: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.

    • reason사용 대상jobStateTimeLimitActions: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS

    • statusReason작업 취소 후의 메시지: Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS

  5. 원인: 모든 컴퓨팅 환경이 유효하지 않습니다. 자세한 내용은 INVALID컴퓨팅 환경을 참조하십시오. 참고: 이 오류를 해결하기 위해 jobStateTimeLimitActions 파라미터를 통해 프로그래밍 가능한 동작을 구성할 수는 없습니다.

    • statusReason작업이 중단된 상태에서의 메시지: ACTION_REQUIRED - CE(s) associated with the job queue are invalid.

  6. 원인: AWS Batch 차단된 대기열을 감지했지만 이유를 확인할 수 없습니다. 참고: 이 오류를 해결하기 위해 jobStateTimeLimitActions 파라미터를 통해 프로그래밍 가능한 동작을 구성할 수는 없습니다. 문제 해결에 대한 자세한 내용은 RUNNABLE AWSre:Post에서 내 AWS Batch 작업이 중단되는 이유를 참조하십시오.

    • statusReason작업이 중단된 상태에서의 메시지: UNDETERMINED - Batch job is blocked, root cause is undetermined.

이벤트에서 이벤트를 받지 않았거나 원인 불명 CloudWatch 이벤트를 받은 경우 이 문제의 몇 가지 일반적인 원인은 다음과 같습니다.

컴퓨팅 리소스에 awslogs 로그 드라이버가 구성되어 있지 않습니다.

AWS Batch 작업은 로그 정보를 CloudWatch Logs로 전송합니다. 이를 위해서는 awslogs 로그 드라이버를 사용할 수 있도록 컴퓨팅 리소스를 구성해야 합니다. Amazon ECS 최적화 AMI (또는 Amazon Linux) 를 기반으로 컴퓨팅 리소스를 AMI 구축한다고 가정해 보겠습니다. 그러면 이 드라이버가 ecs-init 패키지에 기본적으로 등록됩니다. 이제 다른 기반을 사용한다고 가정해 보겠습니다. AMI 그런 다음 Amazon ECS 컨테이너 에이전트가 시작될 때 ECS_AVAILABLE_LOGGING_DRIVERS 환경 변수와 함께 로그 드라이버가 사용 가능한 로그 드라이버로 지정되었는지 확인해야 합니다. awslogs 자세한 내용은 컴퓨팅 리소스 AMI 사양 및 컴퓨팅 리소스 AMI 생성 단원을 참조하세요.

리소스가 부족합니다.

작업 정의에 컴퓨팅 리소스가 할당할 수 있는 양보다 많은 CPU 메모리 리소스가 지정되어 있으면 작업이 배치되지 않습니다. 예를 들어 작업에 4GiB의 메모리가 지정되어 있고 컴퓨팅 리소스의 메모리가 사용 가능한 메모리보다 적다고 가정해 보겠습니다. 그러면 해당 컴퓨팅 리소스에 작업을 배치할 수 없는 경우가 발생합니다. 이러한 경우에는 작업 정의에서 지정한 메모리 크기를 줄이거나, 혹은 용량이 더욱 큰 컴퓨팅 리소스를 환경에 추가해야 합니다. 일부 메모리는 Amazon ECS 컨테이너 에이전트 및 기타 중요한 시스템 프로세스용으로 예약되어 있습니다. 자세한 내용은 컴퓨팅 리소스 메모리 관리 단원을 참조하십시오.

컴퓨팅 리소스에 대한 인터넷 액세스 불가

컴퓨팅 리소스가 Amazon ECS 서비스 엔드포인트와 통신하려면 액세스 권한이 필요합니다. 이는 인터페이스 VPC 엔드포인트를 통하거나 퍼블릭 IP 주소가 있는 컴퓨팅 리소스를 통해 이루어질 수 있습니다.

인터페이스 VPC 엔드포인트에 대한 자세한 내용은 Amazon Elastic 컨테이너 서비스 개발자 안내서의 Amazon ECS 인터페이스 VPC 엔드포인트 (AWS PrivateLink) 를 참조하십시오.

인터페이스 VPC 엔드포인트가 구성되어 있지 않고 네트워크 주소 변환 (NAT) 을 사용하여 이러한 액세스를 제공해야 합니다. 자세한 내용은 Amazon VPC 사용 설명서 및 이 안내서의 NAT 참조하십시오. 자세한 내용은 VPC 생성 단원을 참조하십시오.

Amazon EC2 인스턴스 한도 도달

계정에서 시작할 수 있는 Amazon EC2 인스턴스의 수는 EC2 인스턴스 할당량에 따라 결정됩니다. AWS 리전 특정 인스턴스 유형에도 per-instance-type 할당량이 있습니다. 한도 증가를 요청하는 방법을 포함하여 계정의 Amazon EC2 인스턴스 할당량에 대한 자세한 내용은 Amazon EC2사용 설명서의 Amazon EC2 서비스 한도를 참조하십시오.

Amazon ECS 컨테이너 에이전트가 설치되지 않았습니다

작업을 AWS Batch 실행하려면 Amazon 머신 이미지 (AMI) 에 Amazon ECS 컨테이너 에이전트를 설치해야 합니다. Amazon ECS 컨테이너 에이전트는 기본적으로 Amazon에 ECS 최적화되어 설치됩니다AMIs. Amazon ECS 컨테이너 에이전트에 대한 자세한 내용은 Amazon Elastic ECS 컨테이너 서비스 개발자 안내서의 Amazon 컨테이너 에이전트를 참조하십시오.

자세한 내용은 AWS Batch 작업 RUNNABLE 상태가 중단되는 이유는 무엇입니까? 를 참조하십시오. re:Post에서

생성 시 태그가 지정되지 않은 스팟 인스턴스

AWS Batch 컴퓨팅 리소스에 대한 스팟 인스턴스 태깅은 2017년 10월 25일부터 지원됩니다. 이전에는 Amazon EC2 Spot Fleet 역할에 대한 권장 IAM 관리형 정책 (AmazonEC2SpotFleetRole) 에 시작 시 스팟 인스턴스에 태그를 지정할 권한이 없었습니다. 새로운 권장 IAM 관리형 정책이 호출됩니다AmazonEC2SpotFleetTaggingRole. 이 정책은 시작 시 스팟 인스턴스 태그 지정을 지원합니다.

생성 시 스팟 인스턴스 태깅을 수정하려면 다음 절차에 따라 현재 IAM 권장되는 관리형 정책을 Amazon EC2 스팟 플릿 역할에 적용하십시오. 이렇게 하면 향후 해당 역할로 생성되는 모든 스팟 인스턴스는 생성 시 인스턴스 태그를 적용할 권한을 갖게 됩니다.

현재 IAM 관리형 정책을 Amazon EC2 스팟 플릿 역할에 적용하려면

  1. 에서 IAM 콘솔을 엽니다 https://console.aws.amazon.com/iam/.

  2. 역할을 선택하고 Amazon EC2 스팟 플릿 역할을 선택합니다.

  3. 정책 연결을 선택합니다.

  4. Amazon을 EC2SpotFleetTaggingRole 선택하고 정책 연결을 선택합니다.

  5. Amazon EC2 스팟 플릿 역할을 다시 선택하여 이전 정책을 제거합니다.

  6. Amazon EC2SpotFleetRole 정책 오른쪽에 있는 x를 선택하고 [Detach] 를 선택합니다.

스팟 인스턴스가 스케일 다운되지 않음

AWS Batch 2021년 3월 10일에 AWSServiceRoleForBatch서비스 연결 역할을 도입했습니다. 컴퓨팅 환경의 serviceRole 파라미터에 역할이 지정되지 않은 경우 이 서비스 연결 역할이 서비스 역할로 사용됩니다. 하지만 서비스 연결 역할은 EC2 스팟 컴퓨팅 환경에서 사용되지만 사용된 스팟 역할에는 Amazon EC2SpotFleetTaggingRole 관리형 정책이 포함되지 않는다고 가정해 보겠습니다. 그러면 스팟 인스턴스는 스케일 다운되지 않습니다. 그 결과 “이 작업을 수행할 권한이 없습니다.” 라는 오류 메시지가 표시됩니다. 다음 단계를 사용하여 spotIamFleetRole 파라미터에 사용하는 스팟 플릿 역할을 업데이트합니다. 자세한 내용은 사용 설명서의 서비스 연결 역할 사용 및 서비스에 권한 위임을 위한 역할 생성을 참조하십시오. AWS IAM

Amazon EC2SpotFleetTaggingRole 관리형 정책을 다음과 같은 스팟 플릿 역할에 연결합니다. AWS Management Console

현재 IAM 관리형 정책을 Amazon EC2 스팟 플릿 역할에 적용하려면

  1. 에서 IAM 콘솔을 엽니다 https://console.aws.amazon.com/iam/.

  2. 역할을 선택하고 Amazon EC2 스팟 플릿 역할을 선택합니다.

  3. 정책 연결을 선택합니다.

  4. Amazon을 EC2SpotFleetTaggingRole 선택하고 정책 연결을 선택합니다.

  5. Amazon EC2 스팟 플릿 역할을 다시 선택하여 이전 정책을 제거합니다.

  6. Amazon EC2SpotFleetRole 정책 오른쪽에 있는 x를 선택하고 [Detach] 를 선택합니다.

다음을 사용하여 Amazon EC2SpotFleetTaggingRole 관리형 정책을 스팟 플릿 역할에 추가하십시오. AWS CLI

예제 명령은 Amazon EC2 스팟 플릿 역할의 이름이 지정되었다고 가정합니다.AmazonEC2SpotFleetRole. 역할에서 다른 이름을 사용하는 경우 그에 맞게 명령을 조정하세요.

Amazon EC2SpotFleetTaggingRole 관리형 정책을 스팟 플릿 역할에 연결하려면

  1. Amazon EC2SpotFleetTaggingRole 관리형 IAM 정책을 사용자 정책에 연결하려면 AmazonEC2SpotFleetRole 역할은 를 사용하여 다음 명령을 실행합니다 AWS CLI.

    $ aws iam attach-role-policy \
    --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2SpotFleetTaggingRole \
    --role-name AmazonEC2SpotFleetRole

  2. Amazon EC2SpotFleetRole 관리형 정책을 사용자 IAM 정책에서 분리하려면 AmazonEC2SpotFleetRole 역할: 를 사용하여 다음 AWS CLI명령을 실행합니다.

    $ aws iam detach-role-policy \
    --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2SpotFleetRole \
    --role-name AmazonEC2SpotFleetRole

Secrets Manager 암호를 검색할 수 없음

버전 1.16.0-1보다 낮은 Amazon ECS 에이전트와 AMI 함께 사용하는 경우 이 기능을 사용하려면 Amazon ECS 에이전트 구성 변수를 ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true 사용해야 합니다. 새 컨테이너 인스턴스를 생성할 때 새 컨테이너 인스턴스로 ./etc/ecs/ecs.config 파일에 추가할 수 있습니다. 또는 기존 인스턴스에 추가할 수 있습니다. 기존 인스턴스에 추가하는 경우 에이전트를 추가한 후 ECS 에이전트를 다시 시작해야 합니다. 자세한 내용은 Amazon Elastic ECS 컨테이너 서비스 개발자 안내서의 Amazon 컨테이너 에이전트 구성을 참조하십시오.

작업 정의 리소스 요구 사항을 재정의할 수 없음

에 전달된 구조의 및 vcpus 멤버에 지정된 메모리 memory 및 v CPU 오버라이드는 작업 정의의 containerOverrides구조에 지정된 메모리 및 v CPU 요구 사항을 재정의할 수 없습니다. SubmitJobresourceRequirements

이러한 리소스 요구 사항을 재정의하려고 하면 다음 오류 메시지가 표시될 수 있습니다.

“이 값은 더 이상 사용되지 않는 키로 제출되었으며 작업 정의의 리소스 요구 사항에서 제공하는 값과 충돌할 수 있습니다.”

이 문제를 해결하려면 resourceRequirements멤버에 메모리 및 v CPU 요구 사항을 지정하십시오. containerOverrides 예를 들어, 메모리와 v CPU 오버라이드가 다음 줄에 지정된 경우를 들 수 있습니다.

"containerOverrides": {
   "memory": 8192,
   "vcpus": 4
}

다음과 같이 변경합니다.

"containerOverrides": {
   "resourceRequirements": [
      {
         "type": "MEMORY",
         "value": "8192"
      },
      {
         "type": "VCPU",
         "value": "4"
      }
   ],
}

작업 정의의 containerProperties개체에 지정된 메모리 및 v CPU 요구 사항도 동일하게 변경하십시오. 예를 들어, 메모리 및 v CPU 요구 사항이 다음 줄에 지정된 경우를 들 수 있습니다.

{
   "containerProperties": {
      "memory": 4096,
      "vcpus": 2,
}

다음과 같이 변경합니다.

"containerProperties": {
   "resourceRequirements": [
      {
         "type": "MEMORY",
         "value": "4096"
      },
      {
         "type": "VCPU",
         "value": "2"
      }
   ],
}

desiredvCpus 설정을 업데이트할 때 나타나는 오류 메시지

를 사용하여 원하는 vCPUs (desiredvCpus) 설정을 업데이트할 때 다음 오류 메시지가 표시됩니다. AWS Batch API

Manually scaling down compute environment is not supported. Disconnecting job queues from compute environment will cause it to scale-down to minvCpus.

이 문제는 업데이트된 desiredvCpus 값이 현재 desiredvCpus 값보다 작을 경우 발생합니다. desiredvCpus 값을 업데이트할 때 다음 두 조건이 충족되어야 합니다.

  • desiredvCpus 값은 minvCpus 및 maxvCpus 값 사이에 있어야 합니다.

  • 업데이트된 desiredvCpus 값은 현재 desiredvCpus 값보다 크거나 같아야 합니다.

AWS Batch 아마존에서 EKS

INVALID 컴퓨팅 환경

관리형 컴퓨팅 환경을 잘못 구성했을 수 있습니다. 잘못 구성한 경우 컴퓨팅 환경이 INVALID 상태가 되어 배치 작업을 수락할 수 없습니다. 다음 섹션에서는 발생 가능한 원인과 원인에 따른 문제 해결 방법을 설명합니다.

지원되지 않는 Kubernetes 버전

CreateComputeEnvironmentAPI작업 또는 UpdateComputeEnvironment API 작업을 사용하여 컴퓨팅 환경을 생성하거나 업데이트할 때 다음과 유사한 오류 메시지가 표시될 수 있습니다. EC2Configuration에서 지원되지 않는 Kubernetes 버전을 지정하는 경우 이 문제가 발생합니다.

At least one imageKubernetesVersion in EC2Configuration is not supported.

이 문제를 해결하려면 컴퓨팅 환경을 삭제하고 지원되는 Kubernetes 버전으로 다시 생성하세요.

Amazon EKS 클러스터에서 마이너 버전 업그레이드를 수행할 수 있습니다. 예를 들어 마이너 버전이 지원되지 않는 경우에도 클러스터를 1.xx에서 1.yy로 업그레이드할 수 있습니다.

하지만 메이저 버전 업데이트 후에는 컴퓨팅 환경 상태가 INVALID로 변경될 수 있습니다. 메이저 버전을 1.xx에서 2.yy로 업그레이드하는 경우를 예로 들 수 있습니다. 에서 메이저 버전을 지원하지 않는 경우 다음과 유사한 오류 메시지가 표시됩니다. AWS Batch

reason=CLIENT_ERROR - ... EKS Cluster version [2.yy] is unsupported

이 문제를 해결하려면 API 작업을 사용하여 컴퓨팅 환경을 만들거나 업데이트할 때 지원되는 Kubernetes 버전을 지정하십시오.

AWS Batch Amazon에서는 EKS 현재 다음 Kubernetes 버전을 지원합니다.

  • 1.30

  • 1.29

  • 1.28

  • 1.27

  • 1.26

  • 1.25

  • 1.24

  • 1.23

인스턴스 프로파일이 존재하지 않음

지정된 인스턴스 프로필이 없는 경우 Amazon EKS 컴퓨팅 환경 상태가 로 변경됩니다INVALID. AWS Batch statusReason 파라미터에 다음과 유사한 오류 세트가 표시됩니다.

CLIENT_ERROR - Instance profile arn:aws:iam::...:instance-profile/<name> does not exist

이 문제를 해결하려면 작업 인스턴스 프로파일을 지정하거나 생성합니다. 자세한 내용은 Amazon EKS 사용 설명서의 Amazon EKS 노드 IAM 역할을 참조하십시오.

유효하지 않은 Kubernetes 네임스페이스

AWS Batch Amazon에서 컴퓨팅 환경의 네임스페이스를 EKS 검증할 수 없는 경우 컴퓨팅 환경 상태가 로 변경됩니다. INVALID 예를 들어 네임스페이스가 존재하지 않는 경우 이 문제가 발생할 수 있습니다.

statusReason 파라미터에 다음과 유사한 오류 메시지 세트가 표시됩니다.

CLIENT_ERROR - Unable to validate Kubernetes Namespace

다음 중 하나에 해당하면 이 문제가 발생할 수 있습니다.

  • CreateComputeEnvironment 호출의 Kubernetes 네임스페이스 문자열이 존재하지 않습니다. 자세한 내용은 CreateComputeEnvironment를 참조하세요.

  • 네임스페이스를 관리하는 데 필요한 역할 기반 액세스 제어 (RBAC) 권한이 올바르게 구성되지 않았습니다.

  • AWS Batch Amazon EKS Kubernetes API 서버 엔드포인트에 액세스할 수 없습니다.

이 문제를 해결하려면 aws-auth ConfigMap 필드가 제대로 구성되었는지 확인 섹션을 참조하세요. 자세한 정보는 아마존 AWS Batch EKS에서 시작하기 섹션을 참조하세요.

삭제된 컴퓨팅 환경

연결된 Amazon EKS 컴퓨팅 환경을 삭제하기 전에 Amazon EKS 클러스터를 삭제한다고 AWS Batch 가정해 보겠습니다. 그러면 컴퓨팅 환경 상태가 INVALID로 변경됩니다. 이 시나리오에서 Amazon EKS 클러스터를 같은 이름으로 다시 생성하면 컴퓨팅 환경이 제대로 작동하지 않습니다.

이 문제를 해결하려면 Amazon EKS 컴퓨팅 환경을 삭제한 다음 다시 생성하십시오 AWS Batch .

노드는 Amazon EKS 클러스터에 가입하지 않음

AWS Batch on Amazon은 모든 노드가 Amazon EKS 클러스터에 가입하지 않은 것으로 판단되는 경우 컴퓨팅 환경을 EKS 축소합니다. AWS Batch Amazon에서 컴퓨팅 환경을 EKS 축소하면 컴퓨팅 환경 상태가 로 변경됩니다INVALID.

참고

AWS Batch 문제를 디버깅할 수 있도록 컴퓨팅 환경 상태를 즉시 변경하지 않습니다.

statusReason 파라미터에 설정된 오류 메시지는 다음 중 하나와 유사합니다.

Your compute environment has been INVALIDATED and scaled down because none of the instances joined the underlying ECS Cluster. Common issues preventing instances joining are the following: VPC/Subnet configuration preventing communication to ECS, incorrect Instance Profile policy preventing authorization to ECS, or customized AMI or LaunchTemplate configurations affecting ECS agent.

Your compute environment has been INVALIDATED and scaled down because none of the nodes joined the underlying Amazon EKS Cluster. Common issues preventing nodes joining are the following: networking configuration preventing communication to Amazon EKS Cluster, incorrect Amazon EKS Instance Profile or Kubernetes RBAC policy preventing authorization to Amazon EKS Cluster, customized AMI or LaunchTemplate configurations affecting Amazon EKS/Kubernetes node bootstrap.

기본 EKS AMI Amazon을 사용하는 경우 이 문제의 가장 일반적인 원인은 다음과 같습니다.

AWS Batch Amazon에서 EKS 작업이 RUNNABLE 상태로 멈췄습니다.

aws-auth ConfigMap은 관리형 노드 그룹을 생성하거나 eksctl을 사용하여 노드 그룹을 생성할 때 자동으로 생성되어 클러스터에 적용됩니다. aws-auth ConfigMap은 처음에 노드가 클러스터에 조인할 수 있도록 하기 위해 생성됩니다. 하지만 를 사용하여 사용자 및 aws-auth ConfigMap 역할에 역할 기반 액세스 제어 (RBAC) 액세스를 추가할 수도 있습니다.

aws-auth ConfigMap이 제대로 구성되었는지 확인하려면

  1. aws-auth ConfigMap에서 매핑된 역할을 검색합니다.

    $ kubectl get configmap -n kube-system aws-auth -o yaml

  2. roleARN이 다음과 같이 구성되어 있는지 확인합니다.

    rolearn: arn:aws:iam::aws_account_number:role/AWSServiceRoleForBatch

    참고

    Amazon EKS 컨트롤 플레인 로그를 검토할 수도 있습니다. 자세한 내용은 Amazon EKS사용 설명서의 Amazon EKS 컨트롤 플레인 로깅을 참조하십시오.

작업이 RUNNABLE 상태에서 멈추는 문제를 해결하려면 kubectl을 사용하여 매니페스트를 다시 적용하는 것이 좋습니다. 자세한 내용은 1단계: Amazon EKS 클러스터를 위한 준비 AWS Batch 단원을 참조하십시오. 또는 kubectl을 사용하여 aws-auth ConfigMap을 수동으로 편집할 수 있습니다. 자세한 내용은 Amazon EKS 사용 설명서의 클러스터에 대한 IAM 사용자 및 역할 액세스 활성화를 참조하십시오.

aws-auth ConfigMap 필드가 제대로 구성되었는지 확인

aws-auth ConfigMap이 제대로 구성되었는지 확인하려면

  1. aws-auth ConfigMap에서 매핑된 역할을 검색합니다.

    $ kubectl get configmap -n kube-system aws-auth -o yaml

  2. roleARN이 다음과 같이 구성되어 있는지 확인합니다.

    rolearn: arn:aws:iam::aws_account_number:role/AWSServiceRoleForBatch

    참고

    서비스 연결 ARN 역할의 경로가 aws-service-role/batch.amazonaws.com/ 제거되었습니다. 이는 구성 맵에 aws-auth 문제가 있기 때문입니다. 자세한 내용은 경로가 에 포함되어 있는 경우 경로가 있는 역할이 작동하지 않음을 참조하십시오. ARN aws-auth configmap

    참고

    Amazon EKS 컨트롤 플레인 로그를 검토할 수도 있습니다. 자세한 내용은 Amazon EKS사용 설명서의 Amazon EKS 컨트롤 플레인 로깅을 참조하십시오.

작업이 RUNNABLE 상태에서 멈추는 문제를 해결하려면 kubectl을 사용하여 매니페스트를 다시 적용하는 것이 좋습니다. 자세한 내용은 1단계: Amazon EKS 클러스터를 위한 준비 AWS Batch 단원을 참조하십시오. 또는 kubectl을 사용하여 aws-auth ConfigMap을 수동으로 편집할 수 있습니다. 자세한 내용은 Amazon EKS 사용 설명서의 클러스터에 대한 IAM 사용자 및 역할 액세스 활성화를 참조하십시오.

RBAC권한 또는 바인딩이 제대로 구성되지 않았습니다.

RBAC권한 또는 바인딩 문제가 발생하는 경우 aws-batch Kubernetes 역할이 Kubernetes 네임스페이스에 액세스할 수 있는지 확인하세요.

$ kubectl get namespace namespace --as=aws-batch
$ kubectl auth can-i get ns --as=aws-batch

kubectl describe 명령을 사용하여 클러스터 역할 또는 Kubernetes 네임스페이스에 대한 권한을 볼 수도 있습니다.

$ kubectl describe clusterrole aws-batch-cluster-role

출력의 예제는 다음과 같습니다.

Name:         aws-batch-cluster-role
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources                                      Non-Resource URLs  Resource Names  Verbs
  ---------                                      -----------------  --------------  -----
  configmaps                                     []                 []              [get list watch]
  nodes                                          []                 []              [get list watch]
  pods                                           []                 []              [get list watch]
  daemonsets.apps                                []                 []              [get list watch]
  deployments.apps                               []                 []              [get list watch]
  replicasets.apps                               []                 []              [get list watch]
  statefulsets.apps                              []                 []              [get list watch]
  clusterrolebindings.rbac.authorization.k8s.io  []                 []              [get list]
  clusterroles.rbac.authorization.k8s.io         []                 []              [get list]
  namespaces                                     []                 []              [get]
$ kubectl describe role aws-batch-compute-environment-role -n my-aws-batch-namespace

출력의 예제는 다음과 같습니다.

Name:         aws-batch-compute-environment-role
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources                               Non-Resource URLs  Resource Names  Verbs
  ---------                               -----------------  --------------  -----
  pods                                    []                 []              [create get list watch delete patch]
  serviceaccounts                         []                 []              [get list]
  rolebindings.rbac.authorization.k8s.io  []                 []              [get list]
  roles.rbac.authorization.k8s.io         []                 []              [get list]

이 문제를 해결하려면 RBAC 권한과 명령을 다시 적용하세요. rolebinding 자세한 내용은 1단계: Amazon EKS 클러스터를 위한 준비 AWS Batch 단원을 참조하십시오.