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 kebijakan, peran, dan izin IAM, dan berjalan di Amazon EC2, Amazon AWS Fargate ECS, dan infrastruktur Amazon Elastic Kubernetes Service. Untuk memecahkan masalah yang terkait dengan layanan ini, lihat berikut ini:

AWS Batch

INVALIDlingkungan komputasi

Mungkin saja Anda salah mengonfigurasi 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 atau ARN salah

Penyebab paling umum lingkungan komputasi memasuki INVALID status adalah peran AWS Batch layanan atau peran Armada Spot Amazon EC2 memiliki nama yang salah atau Nama Sumber Daya Amazon (ARN). Ini lebih umum dengan lingkungan komputasi yang dibuat menggunakan AWS CLI atau AWS SDK. 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 ARN secara manual dan memasukkannya dengan tidak benar. Kemudian, lingkungan komputasi yang dihasilkan jugaINVALID.

Namun, misalkan Anda memasukkan nama atau ARN secara manual untuk sumber daya IAM dalam AWS CLI perintah atau kode SDK 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 peran IAM saat menggunakan AWS CLI atau AWS SDK, bukan Nama Sumber Daya Amazon (ARN) lengkap. Bergantung pada bagaimana 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, ARN peran layanan Anda mungkin terlihat seperti berikut.

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

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

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.

Jika Anda hanya menentukan nama peran IAM saat menggunakan AWS CLI atau AWS SDK, AWS Batch asumsikan bahwa ARN Anda tidak menggunakan awalan jalur. aws-service-role Karena itu, kami sarankan Anda menentukan ARN lengkap dari IAM role Anda ketika 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 atau ARN salah, perbarui lingkungan komputasi menggunakan peran layanan yang benar.

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 panggilan DescribeJobs API.

Secara opsional, Anda dapat mengonfigurasi jobStateTimeLimitActions parameter melalui CreateJobQueue dan tindakan UpdateJobQueueAPI.

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 tindakan ListJobs dan DescribeJobs API. Ini juga merupakan nilai yang sama yang dapat Anda tentukan untuk jobStateLimitActions.statusReason parameter.

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 terkelola IAM (AmazonEC2SpotFleetRole) yang direkomendasikan untuk peran Armada Spot Amazon EC2 tidak berisi izin untuk menandai Instans Spot saat diluncurkan. Kebijakan terkelola IAM baru yang disarankan disebut AmazonEC2SpotFleetTaggingRole. Ini mendukung penandaan Instans Spot saat peluncuran.

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

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 dalam lingkungan komputasi EC2 Spot, tetapi peran Spot yang digunakan tidak menyertakan kebijakan terkelola AmazonEC2. SpotFleet TaggingRole 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 SpotFleet TaggingRole terkelola AmazonEC2 ke peran Armada Spot Anda di AWS Management Console

Lampirkan kebijakan SpotFleet TaggingRole terkelola AmazonEC2 ke peran Armada Spot Anda dengan AWS CLI

Perintah contoh mengasumsikan bahwa peran Armada Spot Amazon EC2 Anda diberi nama Peran SpotFleetAmazonEC2. Jika peran Anda menggunakan nama yang berbeda, sesuaikan perintah untuk mencocokkannya.

Tidak dapat mengambil rahasia Secrets Manager

Jika Anda menggunakan AMI dengan agen Amazon ECS yang lebih awal dari versi 1.16.0-1, maka Anda harus menggunakan variabel ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true konfigurasi agen Amazon ECS 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 agen ECS setelah Anda menambahkannya. Untuk informasi lebih lanjut, lihat Kontainer Amazon ECS Container Agent di Panduan Developer Amazon Elastic Container Service.

Tidak dapat mengesampingkan persyaratan sumber daya definisi pekerjaan

Penggantian memori dan vCPU yang ditentukan dalam memory dan vcpus anggota struktur containerOverrides, yang diteruskan ke, tidak SubmitJobdapat mengganti persyaratan memori dan vCPU yang ditentukan dalam struktur ResourceREquirements 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 persyaratan memori dan vCPU di anggota ResourceRequirements dari ContainerOverrides. Misalnya, jika penggantian memori dan vCPU 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 persyaratan vCPU yang ditentukan dalam objek ContainerProperties dalam definisi pekerjaan. Misalnya, jika persyaratan memori dan vCPU Anda ditentukan pada 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 ketika Anda menggunakan AWS Batch API untuk memperbarui setelan desiredvCpus vCPUs () 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:

AWS Batch di Amazon EKS

INVALIDlingkungan komputasi

Mungkin saja Anda salah mengonfigurasi 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 saat menggunakan operasi CreateComputeEnvironment API atau operasi UpdateComputeEnvironment API 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 pada kluster Amazon EKS Anda. Misalnya, Anda dapat memutakhirkan cluster dari 1.xx ke 1.yy bahkan jika 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 mayor 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 operasi API untuk membuat atau memperbarui lingkungan komputasi.

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

Profil instance tidak ada

Jika profil instance yang ditentukan tidak ada, status lingkungan komputasi AWS Batch di Amazon EKS 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 lebih lanjut, lihat IAM role simpul Amazon EKS di Panduan Pengguna Amazon EKS.

Namespace tidak valid Kubernetes

Jika AWS Batch di Amazon EKS tidak 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:

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 klaster Amazon EKS sebelum menghapus lingkungan komputasi AWS Batch Amazon EKS yang dilampirkan. Kemudian, status lingkungan komputasi diubah menjadiINVALID. Dalam skenario ini, lingkungan komputasi tidak berfungsi dengan baik jika Anda membuat ulang kluster Amazon EKS dengan nama yang sama.

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

Node tidak bergabung dengan cluster Amazon EKS

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

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 EKS AMI default, 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:

Untuk mengatasi masalah di mana pekerjaan macet dalam RUNNABLE status, sebaiknya gunakan kubectl untuk menerapkan kembali manifes tersebut. 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 pengguna IAM dan akses peran ke klaster Anda di Panduan Pengguna Amazon EKS.

Verifikasi bahwa aws-auth ConfigMap sudah dikonfigurasi dengan benar

Untuk memverifikasi bahwa aws-auth ConfigMap dikonfigurasi dengan benar:

Untuk mengatasi masalah di mana pekerjaan macet dalam RUNNABLE status, sebaiknya gunakan kubectl untuk menerapkan kembali manifes tersebut. 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 pengguna IAM dan akses peran ke klaster Anda di Panduan Pengguna Amazon EKS.

Izin atau binding RBAC tidak dikonfigurasi dengan benar

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

$ 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 klaster 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 izin dan perintah RBAC. rolebinding Untuk informasi selengkapnya, lihat Langkah 1: Mempersiapkan cluster Amazon EKS Anda AWS Batch.