Pemecahan masalah AWS Batch - AWS Batch
AWS BatchAWS Batch di Amazon EKS

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pemecahan masalah AWS Batch

Anda mungkin perlu memecahkan masalah yang terkait dengan lingkungan komputasi, antrian pekerjaan, definisi pekerjaan, atau pekerjaan Anda. Bab ini menjelaskan cara memecahkan masalah dan menyelesaikan masalah tersebut di lingkungan Anda AWS Batch .

AWS Batch menggunakan IAM kebijakan, peran, dan izin, dan berjalan di infrastruktur AmazonEC2, Amazon ECS AWS Fargate, dan Amazon Elastic Kubernetes Service. Untuk memecahkan masalah yang terkait dengan layanan ini, lihat berikut ini:

AWS Batch

INVALIDlingkungan komputasi

Ada kemungkinan bahwa Anda mungkin telah salah mengkonfigurasi lingkungan komputasi terkelola. Jika Anda melakukannya, lingkungan komputasi memasuki INVALID status dan tidak dapat menerima pekerjaan untuk penempatan. Bagian berikut menjelaskan kemungkinan penyebab dan cara memecahkan masalah berdasarkan penyebabnya.

Nama peran salah atau ARN

Penyebab paling umum lingkungan komputasi memasuki INVALID status adalah bahwa peran AWS Batch layanan atau peran Armada EC2 Spot Amazon memiliki nama yang salah atau Nama Sumber Daya Amazon (ARN). Ini lebih umum dengan lingkungan komputasi yang dibuat menggunakan AWS CLI atau. AWS SDKs Saat Anda membuat lingkungan komputasi di AWS Management Console, AWS Batch membantu Anda memilih layanan yang benar atau peran Armada Spot. Namun, anggaplah Anda memasukkan nama atau nama secara manual ARN dan memasukkannya dengan tidak benar. Kemudian, lingkungan komputasi yang dihasilkan jugaINVALID.

Namun, anggaplah Anda memasukkan nama atau IAM sumber daya ARN secara manual dalam AWS CLI perintah atau SDK kode Anda. Dalam hal ini, tidak AWS Batch dapat memvalidasi string. Sebaliknya, AWS Batch harus menerima nilai buruk dan berusaha menciptakan lingkungan. Jika AWS Batch gagal menciptakan lingkungan, lingkungan bergerak ke INVALID status, dan Anda melihat kesalahan berikut.

Untuk peran layanan yang tidak valid:

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

Untuk peran Armada Spot yang tidak valid:

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

Salah satu penyebab umum untuk masalah ini adalah skenario berikut. Anda hanya menentukan nama IAM peran saat menggunakan AWS CLI atau AWS SDKs, bukan Amazon Resource Name (ARN) lengkap. Bergantung pada cara Anda membuat peran, ARN mungkin berisi awalan aws-service-role jalur. Misalnya, jika Anda membuat peran AWS Batch layanan secara manual menggunakan prosedur diMenggunakan peran terkait layanan untuk AWS Batch, peran layanan Anda ARN mungkin terlihat seperti berikut.

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

Namun, jika Anda membuat peran layanan sebagai bagian dari wizard pertama kali dijalankan konsol hari ini, peran layanan Anda ARN mungkin terlihat seperti berikut.

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

Masalah ini juga dapat terjadi jika Anda melampirkan kebijakan AWS Batch tingkat layanan (AWSBatchServiceRole) ke peran non-layanan. Misalnya, Anda mungkin menerima pesan galat yang menyerupai berikut ini dalam skenario ini: 

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

Untuk mengatasi masalah ini, lakukan salah satu hal berikut.

  • Gunakan string kosong untuk peran layanan saat Anda membuat lingkungan AWS Batch komputasi.

  • Tentukan peran layanan dalam format berikut:arn:aws:iam::account_number:role/aws-service-role/batch.amazonaws.com/AWSServiceRoleForBatch.

Bila Anda hanya menentukan nama IAM peran saat menggunakan AWS CLI atau AWS SDKs, AWS Batch asumsikan bahwa Anda ARN tidak menggunakan awalan aws-service-role jalur. Karena itu, kami menyarankan Anda menentukan lengkap ARN untuk IAM peran Anda saat membuat lingkungan komputasi.

Untuk memperbaiki lingkungan komputasi yang salah dikonfigurasi seperti ini, lihat Memperbaiki lingkungan INVALID komputasi.

Memperbaiki lingkungan INVALID komputasi

Bila Anda memiliki lingkungan komputasi dalam INVALID keadaan, perbarui untuk memperbaiki parameter yang tidak valid. UntukNama peran salah atau ARN, perbarui lingkungan komputasi menggunakan peran layanan yang benar.

Untuk memperbaiki lingkungan komputasi yang salah dikonfigurasi

  1. Buka AWS Batch konsol di https://console.aws.amazon.com/batch/.

  2. Dari bilah navigasi, pilih yang Wilayah AWS akan digunakan.

  3. Di panel navigasi, pilih Compute environments (Lingkungan komputasi).

  4. Di halaman Compute environments (Lingkungan komputasi), pilih tombol radio di sebelah lingkungan komputasi untuk mengedit, lalu pilih Edit.

  5. Pada halaman Perbarui lingkungan komputasi, untuk peran Layanan, pilih IAM peran yang akan digunakan dengan lingkungan komputasi Anda. Konsol AWS Batch hanya menampilkan peran yang memiliki hubungan kepercayaan yang benar untuk lingkungan komputasi.

  6. Pilih Save (Simpan) untuk memperbarui lingkungan komputasi Anda.

Pekerjaan terjebak dalam RUNNABLE status

Misalkan lingkungan komputasi Anda berisi sumber daya komputasi, tetapi pekerjaan Anda tidak berkembang melampaui status. RUNNABLE Kemudian, kemungkinan ada sesuatu yang mencegah pekerjaan ditempatkan pada sumber daya komputasi dan menyebabkan antrian pekerjaan Anda diblokir. Berikut cara mengetahui apakah pekerjaan Anda sedang menunggu giliran atau macet dan memblokir antrian.

Jika AWS Batch mendeteksi bahwa Anda memiliki RUNNABLE pekerjaan di kepala dan memblokir antrian, Anda akan menerima acara antrian pekerjaan yang diblokir dari Amazon CloudWatch Events dengan alasannya. Alasan yang sama juga diperbarui ke statusReason bidang sebagai bagian dari ListJobs dan DescribeJobs API panggilan.

Secara opsional, Anda dapat mengkonfigurasi jobStateTimeLimitActions parameter melalui CreateJobQueue dan UpdateJobQueueAPItindakan.

catatan

Saat ini, satu-satunya tindakan yang dapat Anda gunakan jobStateLimitActions.action adalah membatalkan pekerjaan.

jobStateTimeLimitActionsParameter ini digunakan untuk menentukan serangkaian tindakan yang AWS Batch dilakukan pada pekerjaan dalam keadaan tertentu. Anda dapat mengatur ambang waktu dalam hitungan detik melalui maxTimeSeconds bidang.

Ketika pekerjaan telah dalam RUNNABLE keadaan dengan yang ditentukanstatusReason, AWS Batch melakukan tindakan yang ditentukan setelah maxTimeSeconds telah berlalu.

Misalnya, Anda dapat mengatur jobStateTimeLimitActions parameter untuk menunggu hingga 4 jam untuk pekerjaan apa pun di RUNNABLE negara bagian yang menunggu kapasitas yang cukup tersedia. Anda dapat melakukan ini dengan mengatur statusReason ke CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY dan maxTimeSeconds ke 144000 sebelum membatalkan pekerjaan dan memungkinkan pekerjaan berikutnya untuk maju ke kepala antrian pekerjaan.

Berikut ini adalah alasan yang AWS Batch memberikan ketika mendeteksi bahwa antrian pekerjaan diblokir. Daftar ini menyediakan pesan yang dikembalikan dari ListJobs dan DescribeJobs API tindakan. Ini juga merupakan nilai yang sama yang dapat Anda tentukan untuk jobStateLimitActions.statusReason parameter.

  1. Alasan: Semua lingkungan komputasi yang terhubung memiliki kesalahan kapasitas yang tidak mencukupi. Saat diminta, AWS Batch mendeteksi EC2 instans Amazon yang mengalami kesalahan kapasitas tidak mencukupi. Membatalkan pekerjaan, baik secara manual atau dengan mengatur jobStateTimeLimitActions parameterstatusReason, memungkinkan pekerjaan berikutnya untuk pindah ke kepala antrian.

    • statusReasonpesan saat pekerjaan macet: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY - Service cannot fulfill the capacity requested for instance type [instanceTypeName]

    • reasondigunakan untukjobStateTimeLimitActions: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY

    • statusReasonpesan setelah pekerjaan dibatalkan: Canceled by JobStateTimeLimit action due to reason: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY

    Catatan:

    1. Peran AWS Batch layanan memerlukan autoscaling:DescribeScalingActivities izin agar deteksi ini berfungsi. Jika Anda menggunakan peran AWSServiceRoleForBatchterkait layanan (SLR) atau kebijakan AWSBatchServiceRolePolicyterkelola, Anda tidak perlu mengambil tindakan apa pun karena kebijakan izin mereka diperbarui.

    2. Jika Anda menggunakan SLR atau kebijakan terkelola, Anda harus menambahkan ec2:DescribeSpotFleetRequestHistory izin autoscaling:DescribeScalingActivities dan agar Anda dapat menerima peristiwa antrian pekerjaan yang diblokir dan status pekerjaan yang diperbarui saat masuk. RUNNABLE Selain itu, AWS Batch perlu izin ini untuk melakukan cancellation tindakan melalui jobStateTimeLimitActions parameter bahkan jika mereka dikonfigurasi pada antrian pekerjaan.

    3. Dalam kasus pekerjaan paralel (MNP) multi-node, jika lingkungan EC2 komputasi Amazon prioritas tinggi yang dilampirkan mengalami insufficient capacity kesalahan, itu memblokir antrian meskipun lingkungan komputasi prioritas rendah mengalami kesalahan ini.

  2. Alasan: Semua lingkungan komputasi memiliki maxvCpusparameter yang lebih kecil dari persyaratan pekerjaan. Membatalkan pekerjaan, baik secara manual atau dengan mengatur jobStateTimeLimitActions parameterstatusReason, memungkinkan pekerjaan berikutnya untuk pindah ke kepala antrian. Secara opsional, Anda dapat meningkatkan maxvCpus parameter lingkungan komputasi utama untuk memenuhi kebutuhan pekerjaan yang diblokir.

    • statusReasonpesan saat pekerjaan macet: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE - CE(s) associated with the job queue cannot meet the CPU requirement of the job.

    • reasondigunakan untukjobStateTimeLimitActions: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE

    • statusReasonpesan setelah pekerjaan dibatalkan: Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE

  3. Alasan: Tidak ada lingkungan komputasi yang memiliki instance yang memenuhi persyaratan pekerjaan. Ketika pekerjaan meminta sumber daya, AWS Batch mendeteksi bahwa tidak ada lingkungan komputasi terlampir yang dapat mengakomodasi pekerjaan yang masuk. Membatalkan pekerjaan, baik secara manual atau dengan mengatur jobStateTimeLimitActions parameterstatusReason, memungkinkan pekerjaan berikutnya untuk pindah ke kepala antrian. Secara opsional, Anda dapat mendefinisikan ulang jenis instans yang diizinkan lingkungan komputasi untuk menambahkan sumber daya pekerjaan yang diperlukan.

    • statusReasonpesan saat pekerjaan macet: 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.

    • reasondigunakan untukjobStateTimeLimitActions: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT

    • statusReasonpesan setelah pekerjaan dibatalkan: Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT

  4. Alasan: Semua lingkungan komputasi memiliki masalah peran layanan. Untuk mengatasinya, bandingkan izin peran layanan Anda dengan izin peran layanan AWS Batch terkelola dan atasi celah apa pun.

    Ini adalah praktik terbaik untuk menggunakan lingkungan komputasi AWS Batch SLR untuk menghindari kesalahan serupa.

    Membatalkan pekerjaan, baik secara manual atau dengan mengatur jobStateTimeLimitActions parameterstatusReason, memungkinkan pekerjaan berikutnya untuk pindah ke kepala antrian. Tanpa menyelesaikan masalah peran layanan, kemungkinan pekerjaan berikutnya juga akan diblokir. Yang terbaik adalah menyelidiki dan menyelesaikan masalah ini secara manual.

    • statusReasonpesan saat pekerjaan macet: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.

    • reasondigunakan untukjobStateTimeLimitActions: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS

    • statusReasonpesan setelah pekerjaan dibatalkan: Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS

  5. Alasan: Semua lingkungan komputasi tidak valid. Untuk informasi selengkapnya, lihat lingkungan INVALID komputasi. Catatan: Anda tidak dapat mengonfigurasi tindakan yang dapat diprogram melalui jobStateTimeLimitActions parameter untuk mengatasi kesalahan ini.

    • statusReasonpesan saat pekerjaan macet: ACTION_REQUIRED - CE(s) associated with the job queue are invalid.

  6. Alasan: AWS Batch telah mendeteksi antrian yang diblokir, tetapi tidak dapat menentukan alasannya. Catatan: Anda tidak dapat mengonfigurasi tindakan yang dapat diprogram melalui jobStateTimeLimitActions parameter untuk mengatasi kesalahan ini. Untuk informasi selengkapnya tentang pemecahan masalah, lihat Mengapa AWS Batch pekerjaan saya macet RUNNABLE AWS di re:Post.

    • statusReasonpesan saat pekerjaan macet: UNDETERMINED - Batch job is blocked, root cause is undetermined.

Jika Anda tidak menerima acara dari Acara atau Anda menerima CloudWatch peristiwa alasan yang tidak diketahui, berikut adalah beberapa penyebab umum untuk masalah ini.

Driver awslogs log tidak dikonfigurasi pada sumber daya komputasi Anda

AWS Batch pekerjaan mengirim informasi log mereka ke CloudWatch Log. Untuk mengaktifkan ini, Anda harus mengonfigurasi sumber daya komputasi Anda untuk menggunakan driver log awslogs. Misalkan Anda mendasarkan sumber daya komputasi Anda AMI dari Amazon yang ECS dioptimalkan AMI (atau Amazon Linux). Kemudian, driver ini terdaftar secara default dengan ecs-init paket. Sekarang anggaplah Anda menggunakan basis yang berbedaAMI. Kemudian, Anda harus memverifikasi bahwa driver awslogs log ditentukan sebagai driver log yang tersedia dengan variabel ECS_AVAILABLE_LOGGING_DRIVERS lingkungan saat agen ECS penampung Amazon dimulai. Untuk informasi selengkapnya, silakan lihat Spesifikasi AMI sumber daya komputasi dan Membuat AMI sumber daya komputasi.

Sumber daya yang tidak mencukupi

Jika definisi pekerjaan Anda menentukan lebih banyak CPU atau sumber daya memori daripada sumber daya komputasi Anda dapat mengalokasikan, maka pekerjaan Anda tidak pernah ditempatkan. Misalnya, pekerjaan Anda menentukan 4 GiB memori, dan sumber daya komputasi Anda memiliki kurang dari yang tersedia. Maka itu adalah kasus bahwa pekerjaan tidak dapat ditempatkan pada sumber daya komputasi tersebut. Dalam hal ini, Anda harus mengurangi memori yang ditentukan dalam ketentuan tugas Anda atau menambahkan sumber daya komputasi yang lebih besar ke lingkungan Anda. Beberapa memori disediakan untuk agen ECS kontainer Amazon dan proses sistem penting lainnya. Untuk informasi selengkapnya, lihat Manajemen Memori Sumber Daya Komputasi.

Tidak ada akses internet untuk sumber daya komputasi

Sumber daya komputasi memerlukan akses untuk berkomunikasi dengan titik akhir ECS layanan Amazon. Ini bisa melalui VPC titik akhir antarmuka atau melalui Anda menghitung sumber daya yang memiliki alamat IP publik.

Untuk informasi selengkapnya tentang VPC titik akhir antarmuka, lihat Amazon ECS Interface VPC Endpoints (AWS PrivateLink) di Panduan Pengembang Layanan Amazon Elastic Container.

Jika Anda tidak memiliki VPC titik akhir antarmuka yang dikonfigurasi dan sumber daya komputasi Anda tidak memiliki alamat IP publik, maka mereka harus menggunakan terjemahan alamat jaringan (NAT) untuk menyediakan akses ini. Untuk informasi selengkapnya, lihat NATgateway di Panduan VPC Pengguna Amazon dan di panduan . Untuk informasi selengkapnya, lihat Buat VPC.

Batas EC2 instans Amazon tercapai

Jumlah EC2 instans Amazon yang dapat diluncurkan akun Anda Wilayah AWS ditentukan oleh kuota EC2 instans Anda. Jenis instans tertentu juga memiliki per-instance-type kuota. Untuk informasi selengkapnya tentang kuota EC2 instans Amazon akun Anda termasuk cara meminta peningkatan batas, lihat Batas EC2 Layanan Amazon di Panduan EC2 Pengguna Amazon.

Agen ECS kontainer Amazon tidak diinstal

Agen ECS penampung Amazon harus diinstal pada Amazon Machine Image (AMI) untuk membiarkan pekerjaan AWS Batch berjalan. Agen ECS penampung Amazon diinstal secara default di Amazon yang ECS dioptimalkanAMIs. Untuk informasi selengkapnya tentang agen ECS kontainer Amazon, lihat Agen ECS kontainer Amazon di Panduan Pengembang Layanan Kontainer Elastis Amazon.

Untuk informasi selengkapnya, lihat Mengapa AWS Batch pekerjaan saya terjebak dalam RUNNABLE status? di re:post.

Instans Spot tidak ditandai pada pembuatan

Penandaan Instans Spot untuk sumber daya AWS Batch komputasi didukung mulai 25 Oktober 2017. Sebelumnya, kebijakan IAM terkelola (AmazonEC2SpotFleetRole) yang direkomendasikan untuk peran Amazon EC2 Spot Fleet tidak berisi izin untuk menandai Instans Spot saat diluncurkan. Kebijakan IAM terkelola baru yang direkomendasikan disebutAmazonEC2SpotFleetTaggingRole. Ini mendukung penandaan Instans Spot saat peluncuran.

Untuk memperbaiki penandaan Instance Spot saat pembuatan, ikuti prosedur berikut untuk menerapkan kebijakan IAM terkelola yang direkomendasikan saat ini ke peran Armada EC2 Spot Amazon Anda. Dengan begitu, Instans Spot masa depan yang dibuat dengan peran tersebut memiliki izin untuk menerapkan tag instance saat dibuat.

Untuk menerapkan kebijakan IAM terkelola saat ini ke peran Armada EC2 Spot Amazon Anda

  1. Buka IAM konsol di https://console.aws.amazon.com/iam/.

  2. Pilih Peran, dan pilih peran Armada EC2 Spot Amazon Anda.

  3. Pilih Lampirkan kebijakan.

  4. Pilih Amazon EC2SpotFleetTaggingRole dan pilih Lampirkan kebijakan.

  5. Pilih peran Armada EC2 Spot Amazon Anda lagi untuk menghapus kebijakan sebelumnya.

  6. Pilih x di sebelah kanan EC2SpotFleetRole kebijakan Amazon, dan pilih Lepaskan.

Instans Spot tidak menskalakan ke bawah

AWS Batch memperkenalkan peran AWSServiceRoleForBatchterkait layanan pada 10 Maret 2021. Jika tidak ada peran yang ditentukan dalam serviceRole parameter lingkungan komputasi, peran terkait layanan ini digunakan sebagai peran layanan. Namun, misalkan peran terkait layanan digunakan di lingkungan komputasi EC2 Spot, tetapi peran Spot yang digunakan tidak menyertakan kebijakan terkelola Amazon EC2SpotFleetTaggingRole. Kemudian, Instance Spot tidak menurunkan skala. Akibatnya, Anda akan menerima kesalahan dengan pesan berikut: “Anda tidak berwenang untuk melakukan operasi ini.” Gunakan langkah-langkah berikut untuk memperbarui peran armada spot yang Anda gunakan dalam spotIamFleetRole parameter. Untuk informasi selengkapnya, lihat Menggunakan peran terkait layanan dan Membuat peran untuk mendelegasikan izin ke AWS Layanan di Panduan Pengguna. IAM

Lampirkan kebijakan EC2SpotFleetTaggingRole terkelola Amazon ke peran Armada Spot Anda di AWS Management Console

Untuk menerapkan kebijakan IAM terkelola saat ini ke peran Armada EC2 Spot Amazon Anda

  1. Buka IAM konsol di https://console.aws.amazon.com/iam/.

  2. Pilih Peran, dan pilih peran Armada EC2 Spot Amazon Anda.

  3. Pilih Lampirkan kebijakan.

  4. Pilih Amazon EC2SpotFleetTaggingRole dan pilih Lampirkan kebijakan.

  5. Pilih peran Armada EC2 Spot Amazon Anda lagi untuk menghapus kebijakan sebelumnya.

  6. Pilih x di sebelah kanan EC2SpotFleetRole kebijakan Amazon, dan pilih Lepaskan.

Lampirkan kebijakan EC2SpotFleetTaggingRole terkelola Amazon ke peran Armada Spot Anda dengan AWS CLI

Perintah contoh mengasumsikan bahwa peran Armada EC2 Spot Amazon Anda diberi nama AmazonEC2SpotFleetRole. Jika peran Anda menggunakan nama yang berbeda, sesuaikan perintah agar sesuai.

Untuk melampirkan kebijakan EC2SpotFleetTaggingRole terkelola Amazon ke peran Armada Spot Anda

  1. Untuk melampirkan IAM kebijakan EC2SpotFleetTaggingRole terkelola Amazon ke AmazonEC2SpotFleetRole peran, jalankan perintah berikut menggunakan AWS CLI.

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

  2. Untuk melepaskan IAM kebijakan EC2SpotFleetRole terkelola Amazon dari AmazonEC2SpotFleetRole peran, jalankan perintah berikut menggunakan AWS CLI.

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

Tidak dapat mengambil rahasia Secrets Manager

Jika Anda menggunakan ECS agen AMI dengan Amazon yang lebih awal dari versi 1.16.0-1, maka Anda harus menggunakan variabel konfigurasi ECS agen Amazon ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true untuk menggunakan fitur ini. Anda dapat menambahkannya ke ./etc/ecs/ecs.config file ke instance container baru saat Anda membuat instance itu. Atau, Anda dapat menambahkannya ke instance yang ada. Jika Anda menambahkannya ke instance yang ada, Anda harus me-restart ECS agen setelah Anda menambahkannya. Untuk informasi selengkapnya, lihat Konfigurasi Agen ECS Kontainer Amazon di Panduan Pengembang Layanan Kontainer Elastis Amazon.

Tidak dapat mengesampingkan persyaratan sumber daya definisi pekerjaan

Memori dan CPU penggantian v yang ditentukan dalam memory dan vcpus anggota containerOverridesstruktur, yang diteruskan ke SubmitJob, tidak dapat mengganti memori dan CPU persyaratan v yang ditentukan dalam resourceRequirementsstruktur dalam definisi pekerjaan.

Jika Anda mencoba mengganti persyaratan sumber daya ini, Anda mungkin melihat pesan galat berikut:

“Nilai ini dikirimkan dalam kunci usang dan mungkin bertentangan dengan nilai yang diberikan oleh persyaratan sumber daya definisi pekerjaan.”

Untuk memperbaikinya, tentukan memori dan CPU persyaratan v di resourceRequirementsanggota containerOverrides. Misalnya, jika memori dan CPU penggantian v Anda ditentukan dalam baris berikut.

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

Ubah menjadi yang berikut:

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

Lakukan perubahan yang sama pada memori dan CPU persyaratan v yang ditentukan dalam containerPropertiesobjek dalam definisi pekerjaan. Misalnya, jika CPU persyaratan memori dan v Anda ditentukan dalam baris berikut.

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

Ubah menjadi yang berikut:

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

Pesan galat saat Anda memperbarui desiredvCpus pengaturan

Anda melihat pesan galat berikut saat Anda menggunakan pengaturan AWS Batch API untuk memperbarui vCPUs (desiredvCpus) yang diinginkan.

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

Masalah ini terjadi jika desiredvCpus nilai yang diperbarui kurang dari desiredvCpus nilai saat ini. Saat Anda memperbarui desiredvCpus nilainya, kedua hal berikut harus benar:

  • desiredvCpusNilai harus antara maxvCpus nilai minvCpus dan.

  • desiredvCpusNilai yang diperbarui harus lebih besar dari atau sama dengan desiredvCpus nilai saat ini.

AWS Batch di Amazon EKS

INVALIDlingkungan komputasi

Ada kemungkinan bahwa Anda mungkin telah salah mengkonfigurasi lingkungan komputasi terkelola. Jika Anda melakukannya, lingkungan komputasi memasuki INVALID status dan tidak dapat menerima pekerjaan untuk penempatan. Bagian berikut menjelaskan kemungkinan penyebab dan cara memecahkan masalah berdasarkan penyebabnya.

Versi yang tidak didukung Kubernetes

Anda mungkin melihat pesan galat yang menyerupai berikut ini ketika Anda menggunakan CreateComputeEnvironment API operasi atau UpdateComputeEnvironment API operasi untuk membuat atau memperbarui lingkungan komputasi. Masalah ini terjadi jika Anda menentukan Kubernetes versi yang tidak didukung diEC2Configuration.

At least one imageKubernetesVersion in EC2Configuration is not supported.

Untuk mengatasi masalah ini, hapus lingkungan komputasi lalu buat ulang dengan versi yang didukungKubernetes.

Anda dapat melakukan upgrade versi minor di EKS klaster Amazon Anda. Misalnya, Anda dapat memutakhirkan cluster dari 1.xx ke 1.yy meskipun versi minor tidak didukung.

Namun, status lingkungan komputasi mungkin berubah menjadi INVALID setelah pembaruan versi utama. Misalnya, jika Anda melakukan upgrade versi utama dari 1.xx ke2.yy. Jika versi utama tidak didukung oleh AWS Batch, Anda akan melihat pesan galat yang menyerupai berikut ini.

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

Untuk mengatasi masalah ini, tentukan Kubernetes versi yang didukung saat Anda menggunakan API operasi untuk membuat atau memperbarui lingkungan komputasi.

AWS Batch di Amazon EKS saat ini mendukung Kubernetes versi berikut:

  • 1.30

  • 1.29

  • 1.28

  • 1.27

  • 1.26

  • 1.25

  • 1.24

  • 1.23

Profil instance tidak ada

Jika profil instance yang ditentukan tidak ada, status lingkungan EKS komputasi AWS Batch di Amazon akan diubah menjadiINVALID. Anda melihat set kesalahan dalam statusReason parameter yang menyerupai berikut ini.

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

Untuk mengatasi masalah ini, tentukan atau buat profil instans kerja. Untuk informasi selengkapnya, lihat IAMPeran EKS node Amazon di Panduan EKS Pengguna Amazon.

Namespace tidak valid Kubernetes

Jika AWS Batch di Amazon tidak EKS dapat memvalidasi namespace untuk lingkungan komputasi, status lingkungan komputasi akan diubah menjadi. INVALID Misalnya, masalah ini dapat terjadi jika namespace tidak ada.

Anda melihat pesan galat diatur dalam statusReason parameter yang menyerupai berikut ini.

CLIENT_ERROR - Unable to validate Kubernetes Namespace

Masalah ini dapat terjadi jika salah satu dari berikut ini benar:

  • String Kubernetes namespace dalam CreateComputeEnvironment panggilan tidak ada. Untuk informasi lebih lanjut, lihat CreateComputeEnvironment.

  • Izin Kontrol Akses Berbasis Peran (RBAC) yang diperlukan untuk mengelola namespace tidak dikonfigurasi dengan benar.

  • AWS Batch tidak memiliki akses ke titik akhir EKS Kubernetes API server Amazon.

Untuk mengatasi masalah ini, lihat Verifikasi bahwa aws-auth ConfigMap sudah dikonfigurasi dengan benar. Untuk informasi selengkapnya, lihat Memulai dengan AWS Batch di Amazon EKS.

Lingkungan komputasi yang dihapus

Misalkan Anda menghapus EKS klaster Amazon sebelum menghapus lingkungan EKS komputasi AWS Batch Amazon yang dilampirkan. Kemudian, status lingkungan komputasi diubah menjadiINVALID. Dalam skenario ini, lingkungan komputasi tidak berfungsi dengan baik jika Anda membuat ulang EKS cluster Amazon dengan nama yang sama.

Untuk mengatasi masalah ini, hapus lalu buat ulang lingkungan EKS komputasi AWS Batch di Amazon.

Node tidak bergabung dengan EKS cluster Amazon

AWS Batch di Amazon EKS menurunkan lingkungan komputasi jika menentukan bahwa tidak semua node bergabung dengan EKS cluster Amazon. Saat AWS Batch di Amazon menurunkan EKS skala lingkungan komputasi, status lingkungan komputasi diubah menjadi. INVALID

catatan

AWS Batch tidak segera mengubah status lingkungan komputasi sehingga Anda dapat men-debug masalah.

Anda melihat pesan kesalahan diatur dalam statusReason parameter yang menyerupai salah satu dari berikut ini:

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.

Saat menggunakan Amazon default EKSAMI, penyebab paling umum dari masalah ini adalah sebagai berikut:

AWS Batch di Amazon EKS pekerjaan macet dalam RUNNABLE status

An aws-auth ConfigMap secara otomatis dibuat dan diterapkan ke cluster Anda ketika Anda membuat grup node terkelola atau grup node menggunakaneksctl. An awalnya aws-auth ConfigMap dibuat untuk memungkinkan node bergabung dengan cluster Anda. Namun, Anda juga menggunakan aws-auth ConfigMap untuk menambahkan akses kontrol akses berbasis peran (RBAC) ke pengguna dan peran.

Untuk memverifikasi bahwa aws-auth ConfigMap dikonfigurasi dengan benar:

  1. Ambil peran yang dipetakan di: aws-auth ConfigMap

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

  2. Verifikasi bahwa roleARN dikonfigurasi sebagai berikut.

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

    catatan

    Anda juga dapat meninjau log pesawat EKS kontrol Amazon. Untuk informasi selengkapnya, lihat pencatatan pesawat EKS kontrol Amazon di Panduan EKS Pengguna Amazon.

Untuk mengatasi masalah di mana pekerjaan macet dalam RUNNABLE status, sebaiknya gunakan kubectl untuk menerapkan kembali manifes. Untuk informasi selengkapnya, lihat Langkah 1: Mempersiapkan cluster Amazon EKS Anda AWS Batch. Atau, Anda dapat menggunakan kubectl untuk mengedit file secara manual aws-authConfigMap. Untuk informasi selengkapnya, lihat Mengaktifkan akses IAM pengguna dan peran ke klaster Anda di Panduan EKS Pengguna Amazon.

Verifikasi bahwa aws-auth ConfigMap sudah dikonfigurasi dengan benar

Untuk memverifikasi bahwa aws-auth ConfigMap dikonfigurasi dengan benar:

  1. Ambil peran yang dipetakan di. aws-auth ConfigMap

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

  2. Verifikasi bahwa roleARN dikonfigurasi sebagai berikut.

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

    catatan

    Jalur aws-service-role/batch.amazonaws.com/ telah dihapus ARN dari peran terkait layanan. Ini karena masalah dengan peta aws-auth konfigurasi. Untuk informasi selengkapnya, lihat Peran dengan jalur tidak berfungsi saat jalur disertakan ARN di dalamnya aws-authconfigmap.

    catatan

    Anda juga dapat meninjau log pesawat EKS kontrol Amazon. Untuk informasi selengkapnya, lihat pencatatan pesawat EKS kontrol Amazon di Panduan EKS Pengguna Amazon.

Untuk mengatasi masalah di mana pekerjaan macet dalam RUNNABLE status, sebaiknya gunakan kubectl untuk menerapkan kembali manifes. Untuk informasi selengkapnya, lihat Langkah 1: Mempersiapkan cluster Amazon EKS Anda AWS Batch. Atau, Anda dapat menggunakan kubectl untuk mengedit file secara manual aws-authConfigMap. Untuk informasi selengkapnya, lihat Mengaktifkan akses IAM pengguna dan peran ke klaster Anda di Panduan EKS Pengguna Amazon.

RBACizin atau binding tidak dikonfigurasi dengan benar

Jika Anda mengalami masalah RBAC izin atau pengikatan, verifikasi bahwa aws-batch Kubernetes peran tersebut dapat mengakses Kubernetes namespace:

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

Anda juga dapat menggunakan kubectl describe perintah untuk melihat otorisasi untuk peran cluster atau Kubernetes namespace.

$ kubectl describe clusterrole aws-batch-cluster-role

Berikut ini adalah output contoh.

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

Berikut ini adalah output contoh.

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]

Untuk mengatasi masalah ini, terapkan kembali RBAC izin dan rolebinding perintah. Untuk informasi selengkapnya, lihat Langkah 1: Mempersiapkan cluster Amazon EKS Anda AWS Batch.