**Bantu tingkatkan halaman ini** 

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

Untuk berkontribusi pada panduan pengguna ini, pilih **Edit halaman ini pada GitHub** tautan yang terletak di panel kanan setiap halaman.

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

# Sederhanakan siklus hidup node dengan grup node terkelola
<a name="managed-node-groups"></a>

Grup node terkelola Amazon EKS mengotomatiskan penyediaan dan pengelolaan siklus hidup node (instans Amazon EC2 ) untuk klaster Amazon EKS Kubernetes.

Dengan grup node terkelola Amazon EKS, Anda tidak perlu menyediakan atau mendaftarkan EC2 instans Amazon secara terpisah yang menyediakan kapasitas komputasi untuk menjalankan aplikasi Kubernetes Anda. Anda dapat membuat, memperbarui secara otomatis, atau mengakhiri simpul untuk klaster Anda dengan satu pengoperasian. Pembaruan dan penghentian node secara otomatis menguras node untuk memastikan bahwa aplikasi Anda tetap tersedia.

Setiap node terkelola disediakan sebagai bagian dari grup Auto EC2 Scaling Amazon yang dikelola untuk Anda oleh Amazon EKS. Setiap sumber daya termasuk instans dan grup Auto Scaling berjalan di dalam AWS akun Anda. Setiap grup node berjalan di beberapa Availability Zone yang Anda tentukan.

Grup node terkelola juga dapat secara opsional memanfaatkan perbaikan otomatis node, yang terus memantau kesehatan node. Secara otomatis bereaksi terhadap masalah yang terdeteksi dan menggantikan node bila memungkinkan. Ini membantu ketersediaan cluster secara keseluruhan dengan intervensi manual minimal. Untuk informasi selengkapnya, lihat [Mendeteksi masalah kesehatan node dan mengaktifkan perbaikan node otomatis](node-health.md).

Anda dapat menambahkan grup node terkelola ke kluster baru atau yang sudah ada menggunakan konsol Amazon EKS`eksctl`, AWS CLI, API AWS , atau infrastruktur sebagai alat kode yang disertakan. AWS CloudFormation [Node yang diluncurkan sebagai bagian dari grup node terkelola secara otomatis ditandai untuk penemuan otomatis oleh Kubernetes Cluster Autoscaler.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) Anda dapat menggunakan grup simpul untuk menerapkan label Kubernetes ke simpul dan memperbaruinya kapan saja.

Tidak ada biaya tambahan untuk menggunakan grup node terkelola Amazon EKS, Anda hanya membayar AWS sumber daya yang Anda sediakan. Ini termasuk EC2 instans Amazon, volume Amazon EBS, jam cluster Amazon EKS, dan infrastruktur lainnya AWS . Tidak ada biaya minimum dan tidak ada komitmen di muka.

Untuk memulai dengan klaster Amazon EKS baru dan grup simpul terkelola, lihat [Memulai Amazon EKS — Konsol Manajemen AWS dan AWS CLI](getting-started-console.md).

Untuk menambahkan grup simpul terkelola ke klaster yang ada, lihat [Buat grup node terkelola untuk klaster Anda](create-managed-node-group.md).

## Konsep grup simpul terkelola
<a name="managed-node-group-concepts"></a>
+ Grup node terkelola Amazon EKS membuat dan mengelola EC2 instans Amazon untuk Anda.
+ Setiap node terkelola disediakan sebagai bagian dari grup Auto EC2 Scaling Amazon yang dikelola untuk Anda oleh Amazon EKS. Selain itu, setiap sumber daya termasuk EC2 instans Amazon dan grup Auto Scaling berjalan di dalam AWS akun Anda.
+ Grup Auto Scaling dari grup node terkelola mencakup setiap subnet yang Anda tentukan saat membuat grup.
+ [Amazon EKS menandai resource grup node terkelola sehingga dikonfigurasi untuk menggunakan Kubernetes Cluster Autoscaler.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)
**penting**  
Jika Anda menjalankan aplikasi stateful di beberapa Availability Zone yang didukung oleh volume Amazon EBS dan menggunakan Kubernetes [Cluster Autoscaler, Anda harus mengonfigurasi beberapa grup node, masing-masing dicakup](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) ke satu Availability Zone. Selain itu, Anda harus mengaktifkan opsi fitur `--balance-similar-node-groups`.
+ Anda dapat menggunakan templat peluncuran khusus untuk tingkat fleksibilitas dan penyesuaian yang lebih besar saat menerapkan node terkelola. Misalnya, Anda dapat menentukan `kubelet` argumen tambahan dan menggunakan AMI kustom. Untuk informasi selengkapnya, lihat [Sesuaikan node terkelola dengan templat peluncuran](launch-templates.md). Jika Anda tidak menggunakan templat peluncuran khusus saat pertama kali membuat grup node terkelola, ada templat peluncuran yang dibuat secara otomatis. Jangan memodifikasi templat yang dibuat secara otomatis ini atau terjadi kesalahan secara manual.
+ Amazon EKS mengikuti model tanggung jawab bersama untuk patch keamanan CVEs dan pada grup node terkelola. Ketika simpul terkelola menjalankan Amazon EKS yang dioptimalkan AMI, Amazon EKS bertanggung jawab untuk membangun versi patch AMI ketika bug atau masalah dilaporkan. Kita bisa memublikasikan perbaikan. Namun, Anda bertanggung jawab untuk menerapkan versi AMI yang ditambal ini ke grup node terkelola Anda. Saat node terkelola menjalankan AMI kustom, Anda bertanggung jawab untuk membuat versi AMI yang ditambal saat bug atau masalah dilaporkan dan kemudian menerapkan AMI. Untuk informasi selengkapnya, lihat [Memperbarui grup node terkelola untuk klaster Anda](update-managed-node-group.md).
+ Grup simpul terkelola Amazon EKS dapat diluncurkan di subnet publik maupun privat. Jika Anda meluncurkan grup simpul terkelola di subnet publik pada atau setelah 22 April 2020, subnet tersebut harus mengatur `MapPublicIpOnLaunch` ke BETUL agar instans berhasil bergabung dengan klaster. Jika subnet publik dibuat menggunakan `eksctl` atau [AWS CloudFormation templat penjual Amazon EKS](creating-a-vpc.md) pada atau setelah 26 Maret 2020, maka pengaturan ini sudah disetel ke true. Jika subnet publik dibuat sebelum 26 Maret 2020, Anda harus mengubah pengaturan secara manual. Untuk informasi selengkapnya, lihat [Memodifikasi atribut IPv4 pengalamatan publik untuk subnet Anda](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip).
+ Saat menerapkan grup node terkelola di subnet pribadi, Anda harus memastikan bahwa grup tersebut dapat mengakses Amazon ECR untuk menarik gambar kontainer. [Anda dapat melakukan ini dengan menghubungkan gateway NAT ke tabel rute subnet atau dengan menambahkan titik akhir VPC berikut AWS PrivateLink :](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create)
  + Antarmuka titik akhir API Amazon ECR - `com.amazonaws.region-code.ecr.api` 
  + Antarmuka titik akhir API registri Amazon ECR Docker - `com.amazonaws.region-code.ecr.dkr` 
  + Titik akhir gerbang Amazon S3 - `com.amazonaws.region-code.s3` 

  Untuk layanan dan titik akhir lainnya yang umum digunakan, lihat. [Menyebarkan kluster pribadi dengan akses internet terbatas](private-clusters.md)
+ [Grup node terkelola tidak dapat digunakan di [AWS Outposts](eks-outposts.md) atau di Wavelength.AWS](https://docs.aws.amazon.com/wavelength/) Grup node terkelola dapat dibuat di [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). Untuk informasi selengkapnya, lihat [Luncurkan klaster EKS latensi rendah dengan Local Zones AWS](local-zones.md).
+ Anda dapat membuat beberapa grup simpul terkelola dalam satu klaster. Misalnya, Anda dapat membuat satu grup node dengan Amazon EKS standar yang dioptimalkan Amazon Linux AMI untuk beberapa beban kerja dan lainnya dengan varian GPU untuk beban kerja yang memerlukan dukungan GPU.
+ Jika grup node terkelola mengalami kegagalan [pemeriksaan status EC2 instans Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html), Amazon EKS mengembalikan kode kesalahan untuk membantu Anda mendiagnosis masalah tersebut. Untuk informasi selengkapnya, lihat [Kode kesalahan grup node terkelola](troubleshooting.md#troubleshoot-managed-node-groups).
+ Amazon EKS menambahkan label Kubernetes pada instans grup simpul terkelola. Amazon EKS yang diberi label ini diawali dengan `eks.amazonaws.com`.
+ Amazon EKS otomatis membuang simpul menggunakan API Kubernetes selama pengakhiran atau pembaruan.
+ Anggaran gangguan pod tidak dihormati saat mengakhiri sebuah node dengan `AZRebalance` atau mengurangi jumlah node yang diinginkan. Tindakan ini mencoba untuk mengusir Pod pada node. Tetapi jika dibutuhkan lebih dari 15 menit, node akan dihentikan terlepas dari apakah semua Pod pada node dihentikan. Untuk memperpanjang periode hingga node dihentikan, tambahkan hook siklus hidup ke grup Auto Scaling. Untuk informasi selengkapnya, lihat [Menambahkan kait siklus hidup](https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html) di Panduan Pengguna Amazon * EC2 Auto Scaling*.
+ Untuk menjalankan proses drain dengan benar setelah menerima notifikasi interupsi Spot atau notifikasi penyeimbangan kapasitas, `CapacityRebalance` harus diatur ke. `true`
+ Memperbarui grup node terkelola akan menghormati anggaran gangguan Pod yang Anda tetapkan untuk Pod Anda. Untuk informasi selengkapnya, lihat [Memahami setiap fase pembaruan node](managed-node-update-behavior.md).
+ Tidak ada biaya tambahan untuk menggunakan grup simpul terkelola Amazon EKS. Anda hanya membayar untuk AWS sumber daya yang Anda berikan.
+ Jika Anda ingin mengenkripsi volume Amazon EBS untuk simpul Anda, Anda dapat men-deploy simpul menggunakan templat peluncuran. Untuk menerapkan node terkelola dengan volume Amazon EBS terenkripsi tanpa menggunakan templat peluncuran, enkripsi semua volume Amazon EBS baru yang dibuat di akun Anda. Untuk informasi selengkapnya, lihat [Enkripsi secara default](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) di *Panduan EC2 Pengguna Amazon*.

## Tipe kapasitas grup simpul terkelola
<a name="managed-node-group-capacity-types"></a>

Saat membuat grup simpul terkelola, Anda dapat memilih tipe kapasitas Sesuai Permintaan atau Spot. Amazon EKS menerapkan grup node terkelola dengan grup EC2 Auto Scaling Amazon yang hanya berisi On-Demand atau hanya Instans Spot Amazon EC2 . Anda dapat menjadwalkan Pod untuk aplikasi toleran kesalahan ke grup node yang dikelola Spot, dan kesalahan aplikasi yang tidak toleran pada grup node On-Demand dalam satu cluster Kubernetes. Secara default, grup node terkelola menerapkan instans Amazon EC2 On-Demand.

### Sesuai Permintaan
<a name="managed-node-group-capacity-types-on-demand"></a>

Dengan Instans Sesuai Permintaan, Anda membayar kapasitas komputasi pada jam kedua tanpa komitmen jangka panjang.

Secara default, jika Anda tidak menentukan **Tipe kapasitas**, grup simpul terkelola disediakan dengan instans Sesuai Permintaan. Grup node terkelola mengonfigurasi grup EC2 Auto Scaling Amazon atas nama Anda dengan setelan berikut diterapkan:
+ Strategi alokasi untuk penyediaan kapasitas Sesuai Permintaan diatur ke `prioritized`. Grup simpul terkelola menggunakan urutan tipe instans yang dilewatkan dalam API untuk menentukan tipe instans mana yang akan digunakan pertama kali ketika memenuhi kapasitas Sesuai Permintaan. Misalnya, Anda dapat menentukan tiga tipe instans dalam urutan berikut: `c5.large`, `c4.large`, dan `c3.large`. Ketika Instans Sesuai Permintaan Anda diluncurkan, grup simpul terkelola memenuhi kapasitas Sesuai Permintaan dengan memulai `c5.large`, lalu `c4.large`, dan kemudian `c3.large`. Untuk informasi selengkapnya, lihat [grup Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies) di Panduan Pengguna *Amazon Auto EC2 Scaling*.
+ Amazon EKS menambahkan label Kubernetes berikut untuk semua simpul dalam grup simpul terkelola Anda yang menentukan tipe kapasitas: `eks.amazonaws.com/capacityType: ON_DEMAND`. Anda dapat menggunakan label ini untuk menjadwalkan aplikasi yang tidak menoleransi stateful atau kesalahan pada simpul Sesuai Permintaan.

### Spot
<a name="managed-node-group-capacity-types-spot"></a>

Instans EC2 Spot Amazon adalah EC2 kapasitas Amazon cadangan yang menawarkan diskon tajam dari harga On-Demand. Instans EC2 Spot Amazon dapat diinterupsi dengan pemberitahuan interupsi dua menit saat EC2 membutuhkan kapasitas kembali. Untuk informasi selengkapnya, lihat [Instans Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) di *Panduan EC2 Pengguna Amazon*. Anda dapat mengonfigurasi grup node terkelola dengan Instans EC2 Spot Amazon untuk mengoptimalkan biaya node komputasi yang berjalan di klaster Amazon EKS Anda.

Untuk menggunakan Instans Spot di dalam grup node terkelola, buat grup node terkelola dengan menyetel tipe kapasitas sebagai`spot`. Grup node terkelola mengonfigurasi grup EC2 Auto Scaling Amazon atas nama Anda dengan praktik terbaik Spot berikut yang diterapkan:
+ Untuk memastikan bahwa node Spot Anda disediakan dalam kumpulan kapasitas Spot yang optimal, strategi alokasi diatur ke salah satu dari berikut ini:
  +  `price-capacity-optimized`(PCO) — Saat membuat grup node baru di cluster dengan versi Kubernetes `1.28` atau lebih tinggi, strategi alokasi diatur ke. `price-capacity-optimized` Namun, strategi alokasi tidak akan diubah untuk grup node yang sudah dibuat `capacity-optimized` sebelum grup node terkelola Amazon EKS mulai mendukung PCO.
  +  `capacity-optimized`(CO) — Saat membuat grup node baru di cluster dengan versi Kubernetes `1.27` atau lebih rendah, strategi alokasi diatur ke. `capacity-optimized`

  Untuk meningkatkan jumlah kumpulan kapasitas Spot yang tersedia untuk mengalokasikan kapasitas, konfigurasikan grup node terkelola untuk menggunakan beberapa jenis instance.
+ Amazon EC2 Spot Capacity Rebalancing diaktifkan sehingga Amazon EKS dapat menguras dan menyeimbangkan kembali node Spot Anda dengan anggun untuk meminimalkan gangguan aplikasi saat node Spot berisiko tinggi mengalami gangguan. Untuk informasi selengkapnya, lihat [Penyeimbangan Kembali Kapasitas EC2 Auto Scaling Amazon di Panduan Pengguna](https://docs.aws.amazon.com/autoscaling/ec2/userguide/capacity-rebalance.html) Amazon Auto *Scaling. EC2 *
  + Saat node Spot menerima rekomendasi penyeimbangan ulang, Amazon EKS secara otomatis mencoba meluncurkan node Spot pengganti baru.
  + Jika pemberitahuan gangguan Spot dua menit tiba sebelum pengganti simpul Spot berada dalam status `Ready`, Amazon EKS mulai membuang simpul Spot yang menerima rekomendasi penyeimbangan kembali. Amazon EKS menguras node dengan upaya terbaik. Akibatnya, tidak ada jaminan bahwa Amazon EKS akan menunggu node pengganti bergabung dengan cluster sebelum menguras node yang ada.
  + Ketika pengganti simpul Spot node mengalami bootstrapped dan dalam status `Ready` pada Kubernetes, Amazon EKS menutup dan membuang simpul Spot yang menerima rekomendasi penyeimbangan kembali. Mengepung node Spot memastikan bahwa pengontrol layanan tidak mengirim permintaan baru ke node Spot ini. Hal ini juga menghapusnya dari daftar simpul Spot yang sehat, aktif. Menguras node Spot memastikan bahwa Pod yang sedang berjalan diusir dengan baik.
+ Amazon EKS menambahkan label Kubernetes berikut pada semua simpul dalam grup simpul terkelola Anda yang menentukan tipe kapasitas: `eks.amazonaws.com/capacityType: SPOT`. Anda dapat menggunakan label ini untuk menjadwalkan aplikasi toleran kesalahan pada simpul Spot.
**penting**  
EC2 mengeluarkan [pemberitahuan gangguan Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) dua menit sebelum menghentikan Instans Spot Anda. Namun, Pod pada node Spot mungkin tidak menerima jendela 2 menit penuh untuk shutdown yang anggun. Saat EC2 mengeluarkan pemberitahuan, ada penundaan sebelum Amazon EKS mulai mengusir Pod. Penggusuran terjadi secara berurutan untuk melindungi server API Kubernetes, sehingga selama beberapa reklamasi Spot secara simultan, beberapa Pod mungkin menerima pemberitahuan penggusuran yang tertunda. Pod dapat dihentikan secara paksa tanpa menerima sinyal terminasi, terutama pada node dengan kepadatan Pod tinggi, selama reklamasi bersamaan, atau saat menggunakan masa tenggang terminasi yang lama. Untuk beban kerja Spot, kami sarankan merancang aplikasi agar toleran terhadap interupsi, menggunakan masa tenggang terminasi 30 detik atau kurang, menghindari kait PreStop yang berjalan lama, dan memantau metrik penggusuran Pod untuk memahami masa tenggang aktual dalam klaster Anda. Untuk beban kerja yang membutuhkan penghentian yang terjamin dengan anggun, sebaiknya gunakan kapasitas Sesuai Permintaan.

Ketika ingin memutuskan apakah akan men-deploy grup simpul dengan kapasitas Sesuai Permintaan atau Spot, Anda harus mempertimbangkan kondisi berikut:
+ Instans Spot cocok untuk aplikasi tanpa kewarganegaraan, toleran kesalahan, dan fleksibel. Ini termasuk beban kerja pelatihan pembelajaran batch dan mesin, data besar ETLs seperti Apache Spark, aplikasi pemrosesan antrian, dan titik akhir API stateless. Karena Spot adalah EC2 kapasitas Amazon cadangan, yang dapat berubah seiring waktu, kami menyarankan Anda menggunakan kapasitas Spot untuk beban kerja yang toleran interupsi. Lebih khusus lagi, kapasitas Spot cocok untuk beban kerja yang dapat mentolerir periode di mana kapasitas yang diperlukan tidak tersedia.
+ Kami menyarankan Anda menggunakan On-Demand untuk aplikasi yang tidak toleran terhadap kesalahan. Ini termasuk alat manajemen klaster seperti alat pemantauan dan operasional, penerapan yang memerlukan`StatefulSets`, dan aplikasi stateful, seperti database.
+ Untuk memaksimalkan ketersediaan aplikasi Anda saat menggunakan Instans Spot, sebaiknya konfigurasikan grup simpul terkelola Spot untuk menggunakan beberapa tipe instans. Kami merekomendasikan agar Anda menerapkan aturan berikut ketika menggunakan beberapa tipe instans:
  + Dalam grup node terkelola, jika Anda menggunakan [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), sebaiknya gunakan kumpulan tipe instans yang fleksibel dengan jumlah vCPU dan sumber daya memori yang sama. Ini untuk memastikan bahwa node dalam skala cluster Anda seperti yang diharapkan. Misalnya, jika Anda memerlukan empat v CPUs dan delapan memori GiB, gunakan,`c3.xlarge`,,`c4.xlarge`,`c5.xlarge`, `c5d.xlarge` `c5a.xlarge``c5n.xlarge`, atau jenis instance serupa lainnya.
  + Untuk meningkatkan ketersediaan aplikasi, sebaiknya gunakan beberapa grup node terkelola Spot. Untuk ini, setiap grup harus menggunakan satu set tipe instance fleksibel yang memiliki vCPU dan sumber daya memori yang sama. Misalnya, jika Anda memerlukan memori 4 v CPUs dan 8 GiB, kami sarankan Anda membuat satu grup node terkelola dengan`c3.xlarge`,,,,`c4.xlarge`,`c5.xlarge`, `c5d.xlarge` `c5a.xlarge``c5n.xlarge`, atau jenis instance serupa lainnya, dan grup node terkelola kedua dengan`m3.xlarge`,,,`m4.xlarge`,, `m5.xlarge` `m5d.xlarge``m5a.xlarge`, `m5n.xlarge` atau jenis instance serupa lainnya.
  + Saat menerapkan grup node Anda dengan tipe kapasitas Spot yang menggunakan templat peluncuran khusus, gunakan API untuk meneruskan beberapa jenis instance. Jangan melewatkan satu jenis instance melalui template peluncuran. Untuk informasi selengkapnya tentang men-deploy grup simpul menggunakan templat peluncuran, lihat [Sesuaikan node terkelola dengan templat peluncuran](launch-templates.md).

# Buat grup node terkelola untuk klaster Anda
<a name="create-managed-node-group"></a>

Topik ini menjelaskan bagaimana Anda dapat meluncurkan grup node terkelola Amazon EKS dari node yang mendaftar dengan kluster Amazon EKS Anda. Setelah simpul bergabung dengan klaster, Anda dapat men-deploy aplikasi Kubernetes pada mereka.

Jika ini adalah pertama kalinya Anda meluncurkan grup node terkelola Amazon EKS, kami sarankan Anda mengikuti salah satu panduan kami di[Memulai dengan Amazon EKS](getting-started.md). Panduan ini menyediakan panduan untuk membuat cluster Amazon EKS dengan node.

**penting**  
Simpul Amazon EKS adalah instans Amazon EC2 standar. Anda ditagih berdasarkan harga Amazon EC2 normal. Untuk informasi selengkapnya, lihat [Penetapan Harga Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Anda tidak dapat membuat node terkelola di AWS Wilayah yang mengaktifkan AWS Outposts atau AWS Wavelength. Anda dapat membuat node yang dikelola sendiri sebagai gantinya. Lihat informasi selengkapnya di [Buat node Amazon Linux yang dikelola sendiri](launch-workers.md), [Buat node Microsoft Windows yang dikelola sendiri](launch-windows-workers.md), dan [Buat node Bottlerocket yang dikelola sendiri](launch-node-bottlerocket.md). Anda juga dapat membuat grup node Amazon Linux yang dikelola sendiri di Outpost. Untuk informasi selengkapnya, lihat [Buat node Amazon Linux di AWS Outposts](eks-outposts-self-managed-nodes.md).
Jika Anda tidak [menentukan ID AMI](launch-templates.md#launch-template-custom-ami) untuk `bootstrap.sh` file yang disertakan dengan Linux atau Bottlerocket yang dioptimalkan Amazon EKS, grup node terkelola menerapkan angka maksimum pada nilai. `maxPods` Untuk contoh dengan kurang dari 30 vCPUs, jumlah maksimumnya adalah`110`. Untuk contoh dengan lebih besar dari 30 vCPUs, angka maksimum melompat ke. `250` Penegakan ini mengesampingkan `maxPods` konfigurasi lain, termasuk. `maxPodsExpression` Untuk informasi selengkapnya tentang cara `maxPods` ditentukan dan cara menyesuaikannya, lihat[Bagaimana MaxPods ditentukan](choosing-instance-type.md#max-pods-precedence).
+ Sebuah klaster Amazon EKS yang sudah ada. Untuk menyebarkan satu, lihat[Buat kluster Amazon EKS](create-cluster.md).
+ Peran IAM yang ada untuk digunakan node. Untuk membuatnya, lihat [IAM role simpul Amazon EKS](create-node-role.md). Jika peran ini tidak memiliki salah satu kebijakan untuk VPC CNI, peran terpisah yang mengikuti diperlukan untuk pod VPC CNI.
+ (Opsional, tetapi disarankan) Plugin Amazon VPC CNI untuk add-on Kubernetes dikonfigurasi dengan peran IAM sendiri yang memiliki kebijakan IAM yang diperlukan yang melekat padanya. Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md).
+ Keakraban dengan pertimbangan yang tercantum dalam [Pilih jenis instans node Amazon EC2 yang optimal](choosing-instance-type.md). Bergantung pada jenis instans yang Anda pilih, mungkin ada prasyarat tambahan untuk cluster dan VPC Anda.
+ Untuk menambahkan grup node terkelola Windows, Anda harus terlebih dahulu mengaktifkan dukungan Windows untuk klaster Anda. Untuk informasi selengkapnya, lihat [Menerapkan node Windows pada kluster EKS](windows-support.md).

Anda dapat membuat grup node terkelola dengan salah satu dari berikut ini:
+  [`eksctl`](#eksctl_create_managed_nodegroup) 
+  [Konsol Manajemen AWS](#console_create_managed_nodegroup) 

## `eksctl`
<a name="eksctl_create_managed_nodegroup"></a>

 **Buat grup node terkelola dengan eksctl** 

Prosedur ini membutuhkan `eksctl` versi `0.215.0` atau yang lebih baru. Anda dapat memeriksa versi Anda dengan perintah berikut:

```
eksctl version
```

Untuk petunjuk tentang cara menginstal atau meningkatkan`eksctl`, lihat [Instalasi](https://eksctl.io/installation) dalam `eksctl` dokumentasi.

1. (Opsional) Jika kebijakan IAM terkelola **Amazoneks\$1CNI\$1Policy** dilampirkan ke peran IAM [node Amazon EKS Anda, kami sarankan untuk menetapkannya ke peran IAM yang Anda](create-node-role.md) kaitkan ke akun layanan Kubernetes sebagai gantinya. `aws-node` Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md).

1. Buat grup node terkelola dengan atau tanpa menggunakan templat peluncuran kustom. Menentukan template peluncuran secara manual memungkinkan penyesuaian yang lebih besar dari grup node. Misalnya, ini dapat memungkinkan penerapan AMI khusus atau memberikan argumen ke `boostrap.sh` skrip di AMI Amazon EKS yang dioptimalkan. Untuk daftar lengkap setiap opsi yang tersedia dan default, masukkan perintah berikut.

   ```
   eksctl create nodegroup --help
   ```

   Dalam perintah berikut, ganti *my-cluster* dengan nama cluster Anda dan ganti *my-mng* dengan nama grup node Anda. Nama grup node tidak boleh lebih dari 63 karakter. Itu harus dimulai dengan huruf atau digit, tetapi juga dapat menyertakan tanda hubung dan garis bawah untuk karakter yang tersisa.
**penting**  
Jika Anda tidak menggunakan templat peluncuran kustom saat pertama kali membuat grup node terkelola, jangan gunakan satu di lain waktu untuk grup node. Jika Anda tidak menentukan templat peluncuran kustom, sistem akan secara otomatis membuat templat peluncuran yang tidak kami sarankan agar Anda memodifikasi secara manual. Memodifikasi templat peluncuran yang dibuat secara otomatis ini secara manual dapat menyebabkan kesalahan.

 **Tanpa template peluncuran** 

 `eksctl`membuat template peluncuran Amazon EC2 default di akun Anda dan menyebarkan grup node menggunakan templat peluncuran yang dibuat berdasarkan opsi yang Anda tentukan. Sebelum menentukan nilai untuk`--node-type`, lihat[Pilih jenis instans node Amazon EC2 yang optimal](choosing-instance-type.md).

Ganti *ami-family* dengan kata kunci yang diizinkan. Untuk informasi selengkapnya, lihat [Menyetel simpul AMI Family](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family) dalam `eksctl` dokumentasi. Ganti *my-key* dengan nama pasangan kunci atau kunci publik Amazon EC2 Anda. Kunci ini digunakan untuk SSH ke simpul Anda setelah diluncurkan.

**catatan**  
Untuk Windows, perintah ini tidak mengaktifkan SSH. Sebagai gantinya, ini mengaitkan key pair Amazon EC2 Anda dengan instans dan memungkinkan Anda untuk RDP ke instans.

Jika Anda belum memiliki key pair Amazon EC2, Anda dapat membuatnya di. Konsol Manajemen AWS Untuk informasi Linux, lihat [pasangan kunci Amazon EC2 dan instans Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) di Panduan Pengguna *Amazon* EC2. Untuk informasi Windows, lihat [pasangan kunci Amazon EC2 dan instans Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) di Panduan Pengguna *Amazon* EC2.

Sebaiknya blokir akses Pod ke IMDS jika kondisi berikut benar:
+ Anda berencana untuk menetapkan peran IAM ke semua akun layanan Kubernetes Anda sehingga Pod hanya memiliki izin minimum yang mereka butuhkan.
+ Tidak ada Pod dalam klaster yang memerlukan akses ke layanan metadata instans Amazon EC2 (IMDS) karena alasan lain, seperti mengambil Region saat ini. AWS 

Untuk informasi selengkapnya, lihat [Membatasi akses ke profil instance yang ditetapkan ke node pekerja](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

Jika Anda ingin memblokir akses Pod ke IMDS, tambahkan `--disable-pod-imds` opsi ke perintah berikut.

```
eksctl create nodegroup \
  --cluster my-cluster \
  --region region-code \
  --name my-mng \
  --node-ami-family ami-family \
  --node-type m5.large \
  --nodes 3 \
  --nodes-min 2 \
  --nodes-max 4 \
  --ssh-access \
  --ssh-public-key my-key
```

Instance Anda secara opsional dapat menetapkan jumlah alamat IP yang jauh lebih tinggi ke Pod, menetapkan alamat IP ke Pod dari blok CIDR yang berbeda dari instans, dan di-deploy ke klaster tanpa akses internet. Untuk informasi selengkapnya[Tetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan](cni-increase-ip-addresses.md), lihat[Menerapkan Pod di subnet alternatif dengan jaringan khusus](cni-custom-network.md),, dan [Menyebarkan kluster pribadi dengan akses internet terbatas](private-clusters.md) untuk opsi tambahan untuk ditambahkan ke perintah sebelumnya.

Grup node terkelola menghitung dan menerapkan satu nilai untuk jumlah maksimum Pod yang dapat dijalankan pada setiap node grup node Anda, berdasarkan tipe instance. Jika Anda membuat grup node dengan tipe instans yang berbeda, nilai terkecil yang dihitung di semua tipe instance diterapkan sebagai jumlah maksimum Pod yang dapat dijalankan pada setiap tipe instance dalam grup node. Grup node terkelola menghitung nilai menggunakan skrip yang direferensikan di .

 **Dengan template peluncuran** 

Template peluncuran harus sudah ada dan harus memenuhi persyaratan yang ditentukan dalam [Dasar-dasar konfigurasi template Luncurkan](launch-templates.md#launch-template-basics). Sebaiknya blokir akses Pod ke IMDS jika kondisi berikut benar:
+ Anda berencana untuk menetapkan peran IAM ke semua akun layanan Kubernetes Anda sehingga Pod hanya memiliki izin minimum yang mereka butuhkan.
+ Tidak ada Pod dalam klaster yang memerlukan akses ke layanan metadata instans Amazon EC2 (IMDS) karena alasan lain, seperti mengambil Region saat ini. AWS 

Untuk informasi selengkapnya, lihat [Membatasi akses ke profil instance yang ditetapkan ke node pekerja](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

Jika Anda ingin memblokir akses Pod ke IMDS, maka tentukan pengaturan yang diperlukan dalam template peluncuran.

1. Salin konten berikut ke perangkat Anda. Ganti nilai contoh dan kemudian jalankan perintah yang dimodifikasi untuk membuat `eks-nodegroup.yaml` file. Beberapa pengaturan yang Anda tentukan saat men-deploy tanpa templat peluncuran dipindahkan ke templat peluncuran. Jika Anda tidak menentukan`version`, versi default template akan digunakan.

   ```
   cat >eks-nodegroup.yaml <<EOF
   apiVersion: eksctl.io/v1alpha5
   kind: ClusterConfig
   metadata:
     name: my-cluster
     region: region-code
   managedNodeGroups:
   - name: my-mng
     launchTemplate:
       id: lt-id
       version: "1"
   EOF
   ```

   Untuk daftar selengkapnya tentang `eksctl` pengaturan file konfigurasi, lihat [Skema file Config](https://eksctl.io/usage/schema/) di dokumentasi `eksctl`. Instance Anda secara opsional dapat menetapkan jumlah alamat IP yang jauh lebih tinggi ke Pod, menetapkan alamat IP ke Pod dari blok CIDR yang berbeda dari instans, dan di-deploy ke klaster tanpa akses internet keluar. Untuk informasi selengkapnya[Tetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan](cni-increase-ip-addresses.md), lihat[Menerapkan Pod di subnet alternatif dengan jaringan khusus](cni-custom-network.md),, dan [Menyebarkan kluster pribadi dengan akses internet terbatas](private-clusters.md) untuk opsi tambahan untuk ditambahkan ke file konfigurasi.

   Jika Anda tidak menentukan ID AMI dalam template peluncuran, grup node terkelola menghitung dan menerapkan satu nilai untuk jumlah maksimum Pod yang dapat dijalankan pada setiap node grup node Anda, berdasarkan jenis instance. Jika Anda membuat grup node dengan tipe instans yang berbeda, nilai terkecil yang dihitung di semua tipe instance diterapkan sebagai jumlah maksimum Pod yang dapat dijalankan pada setiap tipe instance dalam grup node. Grup node terkelola menghitung nilai menggunakan skrip yang direferensikan di .

   Jika Anda menetapkan ID AMI di template peluncuran, tentukan jumlah maksimum Pod yang dapat berjalan di setiap node grup node jika Anda menggunakan [jaringan khusus](cni-custom-network.md) atau ingin [menambah jumlah alamat IP yang ditetapkan ke instans Anda](cni-increase-ip-addresses.md). Untuk informasi selengkapnya, lihat .

1. Men-deploy grup simpul dengan perintah berikut.

   ```
   eksctl create nodegroup --config-file eks-nodegroup.yaml
   ```

## Konsol Manajemen AWS
<a name="console_create_managed_nodegroup"></a>

 **Buat grup node terkelola menggunakan Konsol Manajemen AWS ** 

1. Tunggu status klaster Anda ditampilkan sebagai `ACTIVE`. Anda tidak dapat membuat grup node terkelola untuk klaster yang belum ada`ACTIVE`.

1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Pilih nama cluster tempat Anda ingin membuat grup node terkelola.

1. Pilih tab **Compute**.

1. Pilih **Tambahkan grup simpul**.

1. Pada halaman **Konfigurasi grup simpul**, isi parameter yang sesuai, dan kemudian pilih **Selanjutnya**.
   +  **Nama** — Masukkan nama unik untuk grup simpul terkelola Anda. Nama grup node tidak boleh lebih dari 63 karakter. Itu harus dimulai dengan huruf atau digit, tetapi juga dapat menyertakan tanda hubung dan garis bawah untuk karakter yang tersisa.
   +  **Peran IAM Node** — Pilih peran instance node yang akan digunakan dengan grup node Anda. Untuk informasi selengkapnya, lihat [IAM role simpul Amazon EKS](create-node-role.md).
**penting**  
Anda tidak dapat menggunakan peran yang sama yang digunakan untuk membuat cluster apa pun.
Sebaiknya gunakan peran yang saat ini tidak digunakan oleh grup node yang dikelola sendiri. Jika tidak, Anda berencana untuk menggunakan grup node baru yang dikelola sendiri. Untuk informasi selengkapnya, lihat [Menghapus grup node terkelola dari klaster](delete-managed-node-group.md).
   +  **Gunakan template peluncuran** - (Opsional) Pilih jika Anda ingin menggunakan template peluncuran yang ada. Pilih **Nama Template Luncurkan**. Kemudian, pilih **versi Template Luncurkan**. Jika Anda tidak memilih versi, Amazon EKS menggunakan versi default template. Template peluncuran memungkinkan lebih banyak penyesuaian grup node Anda, seperti memungkinkan Anda untuk menerapkan AMI kustom, menetapkan jumlah alamat IP yang jauh lebih tinggi ke Pod, menetapkan alamat IP ke Pod dari blok CIDR yang berbeda dari instans, dan menerapkan node ke cluster tanpa akses internet keluar. Lihat informasi selengkapnya di [Tetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan](cni-increase-ip-addresses.md), [Menerapkan Pod di subnet alternatif dengan jaringan khusus](cni-custom-network.md), dan [Menyebarkan kluster pribadi dengan akses internet terbatas](private-clusters.md).

     Template peluncuran harus memenuhi persyaratan di [Sesuaikan node terkelola dengan templat peluncuran](launch-templates.md). Jika Anda tidak menggunakan template peluncuran Anda sendiri, Amazon EKS API akan membuat template peluncuran Amazon EC2 default di akun Anda dan menyebarkan grup node menggunakan templat peluncuran default.

     Jika Anda menerapkan [peran IAM untuk akun layanan](iam-roles-for-service-accounts.md), menetapkan izin yang diperlukan secara langsung ke setiap Pod yang memerlukan akses ke AWS layanan, dan tidak ada Pod di klaster Anda yang memerlukan akses ke IMDS karena alasan lain, seperti mengambil AWS Region saat ini, maka Anda juga dapat menonaktifkan akses ke IMDS untuk Pod yang tidak menggunakan jaringan host dalam template peluncuran. Untuk informasi selengkapnya, lihat [Membatasi akses ke profil instance yang ditetapkan ke node pekerja](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
   +  **Label Kubernetes** — (Opsional) Anda dapat memilih untuk menerapkan label Kubernetes ke simpul dalam grup simpul terkelola Anda.
   +  **Kubernetes taints** — (Opsional) Anda dapat memilih untuk menerapkan taints Kubernetes ke node di grup node terkelola Anda. Pilihan yang tersedia di menu **Effect** adalah` NoSchedule `,` NoExecute `, dan` PreferNoSchedule `. Untuk informasi selengkapnya, lihat [Resep: Mencegah pod agar tidak dijadwalkan pada node tertentu](node-taints-managed-node-groups.md).
   +  **Tanda** – (Opsional) Anda dapat memilih untuk menandai grup simpul terkelola Amazon EKS Anda. Tag ini tidak menyebar ke sumber daya lain di grup node, seperti grup Auto Scaling atau instance. Untuk informasi selengkapnya, lihat [Mengatur sumber daya Amazon EKS dengan tag](eks-using-tags.md).

1. Pada halaman **Atur konfigurasi komputasi dan penskalaan**, isi parameter yang sesuai, dan kemudian pilih **Selanjutnya**.
   +  **Jenis AMI** - Pilih tipe AMI. Jika Anda menerapkan instance Arm, pastikan untuk meninjau pertimbangan di Amazon [EKS yang dioptimalkan Arm Amazon Linux AMIs](eks-optimized-ami.md#arm-ami) sebelum menerapkan.

     Jika Anda menentukan template peluncuran di halaman sebelumnya, dan menetapkan AMI di template peluncuran, maka Anda tidak dapat memilih nilai. Nilai dari templat ditampilkan. AMI yang ditentukan dalam template harus memenuhi persyaratan dalam [Menentukan AMI](launch-templates.md#launch-template-custom-ami).
   +  **Tipe kapasitas** – Pilih tipe kapasitas. Untuk informasi selengkapnya tentang memilih tipe kapasitas, lihat [Tipe kapasitas grup simpul terkelola](managed-node-groups.md#managed-node-group-capacity-types). Anda tidak dapat mencampur tipe kapasitas yang berbeda dalam grup node yang sama. Jika Anda ingin menggunakan kedua tipe kapasitas, buatlah grup simpul terpisah, masing-masing dengan tipe kapasitas dan instans mereka sendiri. Lihat [Reserve GPUs untuk grup node terkelola](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html) untuk informasi tentang penyediaan dan penskalaan node pekerja yang dipercepat GPU.
   +  **Jenis instans** - Secara default, satu atau lebih jenis instance ditentukan. Untuk menghapus tipe instans default, pilih `X` di sisi kanan tipe instans. Pilih tipe instans yang akan digunakan dalam grup simpul terkelola. Untuk informasi selengkapnya, lihat [Pilih jenis instans node Amazon EC2 yang optimal](choosing-instance-type.md).

     Konsol menampilkan satu set tipe instans yang umum digunakan. Jika Anda perlu membuat grup node terkelola dengan tipe instance yang tidak ditampilkan, gunakan`eksctl`, AWS CLI AWS CloudFormation, atau SDK untuk membuat grup node. Jika Anda menentukan template peluncuran pada halaman sebelumnya, maka Anda tidak dapat memilih nilai karena jenis instance harus ditentukan dalam template peluncuran. Nilai dari templat peluncuran ditampilkan. Jika Anda memilih **Spot** untuk **tipe Kapasitas**, maka kami merekomendasikan untuk menentukan beberapa tipe instans untuk meningkatkan ketersediaan.
   +  **Ukuran disk** — Masukkan ukuran disk (dalam GiB) yang akan digunakan untuk volume root node Anda.

     Jika Anda menentukan template peluncuran di halaman sebelumnya, maka Anda tidak dapat memilih nilai karena harus ditentukan dalam template peluncuran.
   +  **Ukuran yang diinginkan** – Tentukan jumlah simpul yang harus dipertahankan oleh grup simpul terkelola saat peluncuran.
**catatan**  
Amazon EKS tidak secara otomatis menskalakan grup node Anda masuk atau keluar. Namun, Anda dapat mengkonfigurasi Kubernetes Cluster Autoscaler untuk melakukan ini untuk Anda. Untuk informasi selengkapnya, lihat [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di. AWS
   +  **Ukuran minimum** – Tentukan jumlah simpul minimum yang dapat diskalakan kedalam oleh grup simpul terkelola.
   +  **Ukuran maksimum** – Tentukan jumlah simpul maksimum yang dapat diskalakan keluar oleh grup simpul terkelola.
   +  **Konfigurasi pembaruan grup node** — (Opsional) Anda dapat memilih jumlah atau persentase node yang akan diperbarui secara paralel. Node ini tidak akan tersedia selama pembaruan. Untuk **Maksimum tidak tersedia**, pilih salah satu opsi berikut dan tentukan **Nilai**:
     +  **Angka** — Pilih dan tentukan jumlah node dalam grup node Anda yang dapat diperbarui secara paralel.
     +  **Persentase** — Pilih dan tentukan persentase node dalam grup node Anda yang dapat diperbarui secara paralel. Ini berguna jika Anda memiliki sejumlah besar node di grup node Anda.
   +  **Konfigurasi perbaikan otomatis node** — (Opsional) Jika Anda mengaktifkan kotak centang **Aktifkan perbaikan otomatis node**, Amazon EKS akan secara otomatis mengganti node saat masalah yang terdeteksi terjadi. Untuk informasi selengkapnya, lihat [Mendeteksi masalah kesehatan node dan mengaktifkan perbaikan node otomatis](node-health.md).

1. Di halaman **Tentukan jaringan**, isi parameter yang sesuai, dan pilih **Selanjutnya**.
   +  **Subnet** — Pilih subnet untuk meluncurkan simpul terkelola Anda.
**penting**  
Jika Anda menjalankan aplikasi stateful di beberapa Availability Zone yang didukung oleh volume Amazon EBS dan menggunakan Kubernetes [Cluster Autoscaler, Anda harus mengonfigurasi beberapa grup node, masing-masing dicakup](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) ke satu Availability Zone. Selain itu, Anda harus mengaktifkan fitur `--balance-similar-node-groups`.
**penting**  
Jika Anda memilih subnet publik, dan klaster Anda hanya memiliki titik akhir server API publik yang diaktifkan, maka subnet harus mengatur `MapPublicIPOnLaunch` ke `true` agar instans dapat bergabung dengan klaster. Jika subnet dibuat menggunakan `eksctl` atau [AWS CloudFormation templat penjual Amazon EKS](creating-a-vpc.md) pada atau setelah 26 Maret 2020, maka pengaturan ini sudah diatur ke. `true` Jika subnet dibuat dengan `eksctl` atau AWS CloudFormation templat sebelum 26 Maret 2020, maka Anda perlu mengubah pengaturan secara manual. Untuk informasi selengkapnya, lihat [Memodifikasi atribut IPv4 pengalamatan publik untuk subnet Anda](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip).
Jika Anda menggunakan templat peluncuran dan menentukan beberapa antarmuka jaringan, Amazon EC2 tidak akan menetapkan alamat `IPv4` publik secara otomatis, meskipun `MapPublicIpOnLaunch` disetel ke. `true` Agar node dapat bergabung dengan cluster dalam skenario ini, Anda harus mengaktifkan titik akhir server API pribadi cluster, atau meluncurkan node di subnet pribadi dengan akses internet keluar yang disediakan melalui metode alternatif, seperti NAT Gateway. Untuk informasi selengkapnya, lihat [Pengalamatan IP instans Amazon EC2 di Panduan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html) Pengguna *Amazon* EC2.
   +  **Konfigurasikan akses SSH ke node** (Opsional). Mengaktifkan SSH mengizinkan Anda untuk tekoneksi ke instans dan mengumpulkan informasi diagnostik jika ada masalah. Kami sangat menyarankan untuk mengaktifkan akses jarak jauh saat Anda membuat grup node. Anda tidak dapat mengaktifkan akses jarak jauh setelah grup node dibuat.

     Jika Anda memilih untuk menggunakan template peluncuran, maka opsi ini tidak ditampilkan. Untuk mengaktifkan akses jarak jauh ke simpul Anda, tentukan pasangan kunci di templat peluncuran dan pastikan bahwa port yang tepat terbuka untuk simpul dalam grup keamanan yang Anda tentukan di templat peluncuran. Untuk informasi selengkapnya, lihat [Menggunakan grup keamanan kustom](launch-templates.md#launch-template-security-groups).
**catatan**  
Untuk Windows, perintah ini tidak mengaktifkan SSH. Sebagai gantinya, ini mengaitkan key pair Amazon EC2 Anda dengan instans dan memungkinkan Anda untuk RDP ke instans.
   + Untuk **pasangan kunci SSH** (Opsional), pilih kunci SSH Amazon EC2 untuk digunakan. Untuk informasi Linux, lihat [pasangan kunci Amazon EC2 dan instans Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) di Panduan Pengguna *Amazon* EC2. Untuk informasi Windows, lihat [pasangan kunci Amazon EC2 dan instans Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) di Panduan Pengguna *Amazon* EC2. Jika Anda memilih untuk menggunakan template peluncuran, maka Anda tidak dapat memilih salah satu. Ketika kunci SSH Amazon EC2 disediakan untuk grup node menggunakan Bottlerocket AMIs, wadah administratif juga diaktifkan. Untuk informasi selengkapnya, lihat [Kontainer admin](https://github.com/bottlerocket-os/bottlerocket#admin-container) di GitHub.
   + Untuk **Izinkan akses jarak jauh SSH dari**, jika Anda ingin membatasi akses ke instance tertentu, pilih grup keamanan yang terkait dengan instance tersebut. Jika Anda tidak memilih grup keamanan tertentu, maka akses SSH diizinkan dari mana saja di internet (`0.0.0.0/0`).

1. Pada halaman **Tinjauan dan buat**, tinjau konfigurasi grup simpul terkelola dan pilih **Buat**.

   Jika node gagal bergabung dengan cluster, maka lihat [Simpul gagal untuk bergabung dengan klaster](troubleshooting.md#worker-node-fail) di chapter Troubleshooting.

1. Perhatikan status simpul Anda dan tunggu sampai simpul mencapai Status `Ready`.

   ```
   kubectl get nodes --watch
   ```

1. (Hanya node GPU) Jika Anda memilih jenis instans GPU dan AMI akselerasi Amazon EKS yang dioptimalkan, maka Anda harus menerapkan [plugin perangkat NVIDIA untuk Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) sebagai a di cluster Anda. DaemonSet Ganti *vX.X.X* dengan s-device-plugin versi [NVIDIA/K8](https://github.com/NVIDIA/k8s-device-plugin/releases) yang Anda inginkan sebelum menjalankan perintah berikut.

   ```
   kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
   ```

## Instal add-on Kubernetes
<a name="_install_kubernetes_add_ons"></a>

Sekarang setelah Anda memiliki kluster Amazon EKS yang berfungsi dengan node, Anda siap untuk mulai menginstal add-on Kubernetes dan menerapkan aplikasi ke klaster Anda. Topik dokumentasi berikut membantu Anda untuk memperluas fungsionalitas klaster Anda.
+ [Prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang membuat klaster adalah satu-satunya prinsipal yang dapat melakukan panggilan ke server API Kubernetes dengan atau. `kubectl` Konsol Manajemen AWS Jika Anda ingin prinsipal IAM lainnya memiliki akses ke cluster Anda, maka Anda perlu menambahkannya. Untuk informasi selengkapnya, lihat [Berikan akses kepada pengguna dan peran IAM ke Kubernetes APIs](grant-k8s-access.md) dan [Izin yang diperlukan](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ Sebaiknya blokir akses Pod ke IMDS jika kondisi berikut benar:
  + Anda berencana untuk menetapkan peran IAM ke semua akun layanan Kubernetes Anda sehingga Pod hanya memiliki izin minimum yang mereka butuhkan.
  + Tidak ada Pod dalam klaster yang memerlukan akses ke layanan metadata instans Amazon EC2 (IMDS) karena alasan lain, seperti mengambil Region saat ini. AWS 

  Untuk informasi selengkapnya, lihat [Membatasi akses ke profil instance yang ditetapkan ke node pekerja](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
+ Konfigurasikan Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) untuk secara otomatis menyesuaikan jumlah node dalam grup node Anda.
+ Menerapkan [aplikasi sampel](sample-deployment.md) ke cluster Anda.
+  [Atur dan pantau sumber daya klaster](eks-managing.md) dengan alat penting untuk mengelola klaster Anda.

# Memperbarui grup node terkelola untuk klaster Anda
<a name="update-managed-node-group"></a>

Saat Anda memulai pembaruan grup node terkelola, Amazon EKS secara otomatis memperbarui node untuk Anda, menyelesaikan langkah-langkah yang tercantum dalam [Memahami setiap fase pembaruan node](managed-node-update-behavior.md). Jika Anda menggunakan AMI Amazon EKS yang dioptimalkan, Amazon EKS secara otomatis menerapkan patch keamanan terbaru dan pembaruan sistem operasi ke node Anda sebagai bagian dari versi rilis AMI terbaru.

Ada beberapa skenario yang berguna untuk memperbarui versi atau konfigurasi grup node terkelola Amazon EKS Anda:
+ Anda telah memperbarui versi Kubernetes untuk klaster Amazon EKS dan ingin memperbarui simpul Anda untuk menggunakan versi Kubernetes yang sama.
+ Versi perilisan AMI yang baru tersedia untuk grup simpul terkelola Anda. Untuk informasi selengkapnya tentang versi AMI, lihat bagian ini:
  +  [Ambil informasi versi Amazon Linux AMI](eks-linux-ami-versions.md) 
  +  [Buat node dengan Bottlerocket yang dioptimalkan AMIs](eks-optimized-ami-bottlerocket.md) 
  +  [Ambil informasi versi Windows AMI](eks-ami-versions-windows.md) 
+ Anda ingin menyesuaikan jumlah instans minimum, maksimum, atau diinginkan di grup simpul terkelola Anda.
+ Anda ingin menambah atau menghapus label Kubernetes dari instans di grup simpul terkelola Anda.
+ Anda ingin menambahkan atau menghapus AWS tag dari grup node terkelola Anda.
+ Anda harus men-deploy versi templat peluncuran yang baru dengan perubahan konfigurasi, seperti AMI kustom yang diperbarui.
+ Anda telah menerapkan add-on Amazon VPC CNI versi `1.9.0` atau yang lebih baru, mengaktifkan add-on untuk delegasi awalan, dan ingin instance Sistem Nitro AWS baru dalam grup node mendukung peningkatan jumlah Pod secara signifikan. Untuk informasi selengkapnya, lihat [Tetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan](cni-increase-ip-addresses.md).
+ Anda telah mengaktifkan delegasi awalan IP untuk node Windows dan menginginkan instans Sistem AWS Nitro baru dalam grup node untuk mendukung peningkatan jumlah Pod secara signifikan. Untuk informasi selengkapnya, lihat [Tetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan](cni-increase-ip-addresses.md).

Jika ada versi rilis AMI yang lebih baru untuk versi Kubernetes grup node terkelola Anda, Anda dapat memperbarui versi grup node Anda untuk menggunakan versi AMI yang lebih baru. Demikian pula, jika klaster Anda menjalankan versi Kubernetes yang lebih baru dari grup node Anda, Anda dapat memperbarui grup node untuk menggunakan versi rilis AMI terbaru agar sesuai dengan versi Kubernetes klaster Anda.

Ketika sebuah node dalam grup node terkelola dihentikan karena operasi penskalaan atau pembaruan, Pod dalam node tersebut akan terkuras terlebih dahulu. Untuk informasi selengkapnya, lihat [Memahami setiap fase pembaruan node](managed-node-update-behavior.md).

## Memperbarui versi grup simpul
<a name="mng-update"></a>

Anda dapat memperbarui versi grup node dengan salah satu dari berikut ini:
+  [`eksctl`](#eksctl_update_managed_nodegroup) 
+  [Konsol Manajemen AWS](#console_update_managed_nodegroup) 

Versi yang Anda perbarui tidak boleh lebih besar dari versi pesawat kontrol.

## `eksctl`
<a name="eksctl_update_managed_nodegroup"></a>

 **Memperbarui grup node terkelola menggunakan `eksctl`** 

Perbarui grup node terkelola ke rilis AMI terbaru dari versi Kubernetes yang sama yang saat ini digunakan di node dengan perintah berikut. Ganti setiap *example value* dengan nilai-nilai Anda sendiri.

```
eksctl upgrade nodegroup \
  --name=node-group-name \
  --cluster=my-cluster \
  --region=region-code
```

**catatan**  
Jika Anda memutakhirkan grup node yang digunakan dengan template peluncuran ke versi template peluncuran baru, tambahkan `--launch-template-version version-number ` ke perintah sebelumnya. Template peluncuran harus memenuhi persyaratan yang dijelaskan dalam [Sesuaikan node terkelola dengan templat peluncuran](launch-templates.md). Jika template peluncuran menyertakan AMI kustom, AMI harus memenuhi persyaratan dalam [Menentukan AMI](launch-templates.md#launch-template-custom-ami). Saat Anda memutakhirkan grup node ke versi template peluncuran yang lebih baru, setiap node didaur ulang agar sesuai dengan konfigurasi baru dari versi template peluncuran yang ditentukan.

Anda tidak dapat langsung memutakhirkan grup node yang digunakan tanpa template peluncuran ke versi template peluncuran baru. Sebaliknya, Anda harus men-deploy grup simpul baru dengan menggunakan templat peluncuran untuk memperbarui grup simpul ke versi templat peluncuran baru.

Anda dapat memutakhirkan grup node ke versi yang sama dengan versi Kubernetes pesawat kontrol. Misalnya, jika Anda memiliki klaster yang menjalankan Kubernetes`1.35`, Anda dapat meng-upgrade node yang saat ini menjalankan Kubernetes `1.34` ke versi dengan perintah berikut. `1.35`

```
eksctl upgrade nodegroup \
  --name=node-group-name \
  --cluster=my-cluster \
  --region=region-code \
  --kubernetes-version=1.35
```

## Konsol Manajemen AWS
<a name="console_update_managed_nodegroup"></a>

 **Memperbarui grup node terkelola menggunakan Konsol Manajemen AWS ** 

1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Pilih klaster yang berisi grup simpul yang akan diperbarui.

1. Jika setidaknya tersedia satu grup simpul yang memiliki pembaruan, maka akan ada kotak yang muncul di bagian atas halaman yang memberitahukan Anda tentang pembaruan yang tersedia. Jika Anda memilih tab **Compute**, Anda akan melihat **Perbarui sekarang** di kolom **versi rilis AMI** di tabel **grup Node** untuk grup node yang memiliki pembaruan yang tersedia. Untuk memperbarui grup node, pilih **Perbarui sekarang**.

   Anda tidak akan melihat pemberitahuan untuk grup node yang digunakan dengan AMI kustom. Jika simpul di-deploy dengan AMI kustom, selesaikan langkah-langkah berikut untuk men-deploy AMI kustom yang baru diperbarui.

   1. Buat versi baru AMI Anda.

   1. Buat versi templat peluncuran baru dengan ID AMI baru.

   1. Mutakhirkan simpul ke versi templat peluncuran baru.

1. Pada kotak dialog **Perbarui versi grup node**, aktifkan atau nonaktifkan opsi berikut:
   +  **Perbarui versi grup node** - Opsi ini tidak tersedia jika Anda menerapkan AMI khusus atau AMI Amazon EKS yang dioptimalkan saat ini ada di versi terbaru untuk klaster Anda.
   +  **Ubah versi template peluncuran** - Opsi ini tidak tersedia jika grup simpul dikerahkan tanpa templat peluncuran khusus. Anda hanya dapat memperbarui versi templat peluncuran untuk grup simpul yang telah di-deploy dengan templat peluncuran kustom. Pilih **versi Template Luncurkan** yang ingin Anda perbarui grup node. Jika grup simpul dikonfigurasi dengan AMI kustom, maka versi yang Anda pilih juga harus menentukan AMI. Saat Anda memutakhirkan ke versi template peluncuran yang lebih baru, setiap node didaur ulang agar sesuai dengan konfigurasi baru dari versi template peluncuran yang ditentukan.

1. Untuk **strategi Update**, pilih salah satu opsi berikut:
   +  **Pembaruan bergulir** — Opsi ini menghormati anggaran gangguan Pod untuk klaster Anda. Pembaruan gagal jika ada masalah anggaran gangguan Pod yang menyebabkan Amazon EKS tidak dapat menguras Pod yang berjalan di grup node ini dengan baik.
   +  **Update paksa** — Opsi ini tidak menghormati anggaran gangguan Pod. Pembaruan terjadi terlepas dari masalah anggaran gangguan Pod dengan memaksa restart node terjadi.

1. Pilih **Perbarui**.

## Edit konfigurasi grup simpul
<a name="mng-edit"></a>

Anda dapat mengubah beberapa konfigurasi dari grup simpul terkelola.

1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Pilih klaster yang berisi grup simpul untuk mengedit.

1. Pilih tab **Compute**.

1. Pilih grup node yang akan diedit, lalu pilih **Edit**.

1. (Opsional) Pada halaman **grup Edit node**, lakukan hal berikut:

   1. Edit **konfigurasi penskalaan grup Node**.
      +  **Ukuran yang diinginkan** – Tentukan jumlah simpul saat ini yang harus dipertahankan oleh grup simpul terkelola.
      +  **Ukuran minimum** – Tentukan jumlah simpul minimum yang dapat diskalakan kedalam oleh grup simpul terkelola.
      +  **Ukuran maksimum** – Tentukan jumlah maksimum simpul yang dapat diskalakan keluar oleh grup simpul terkelola. Untuk jumlah maksimal simpul yang didukung dalam grup simpul, lihat [Lihat dan kelola kuota layanan Amazon EKS dan Fargate](service-quotas.md).

   1. (Opsional) Tambahkan atau hapus **label Kubernetes** ke node di grup node Anda. Label yang ditampilkan di sini hanya label yang telah Anda terapkan dengan Amazon EKS. Label lain mungkin ada di node Anda yang tidak ditampilkan di sini.

   1. (Opsional) Tambahkan atau hapus **taints Kubernetes** ke node di grup node Anda. Kecacatan yang ditambahkan dapat memiliki efek, baik ` NoSchedule `, ` NoExecute `, atau ` PreferNoSchedule `. Untuk informasi selengkapnya, lihat [Resep: Mencegah pod agar tidak dijadwalkan pada node tertentu](node-taints-managed-node-groups.md).

   1. (Opsional) Tambahkan atau hapus **Tag** dari sumber daya grup node Anda. Tanda ini hanya diterapkan pada grup simpul Amazon EKS. Mereka tidak menyebar ke sumber daya lain, seperti subnet atau instans Amazon EC2 di grup node.

   1. (Opsional) Edit **konfigurasi pembaruan Grup Node**. Pilih **Nomor** atau **Persentase**.
      +  **Angka** — Pilih dan tentukan jumlah node dalam grup node Anda yang dapat diperbarui secara paralel. Node ini tidak akan tersedia selama pembaruan.
      +  **Persentase** — Pilih dan tentukan persentase node dalam grup node Anda yang dapat diperbarui secara paralel. Node ini tidak akan tersedia selama pembaruan. Ini berguna jika Anda memiliki banyak node di grup node Anda.

   1. Setelah selesai mengedit, pilih **Simpan perubahan**.

**penting**  
Saat memperbarui konfigurasi grup node, memodifikasi [https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html)tidak menghormati anggaran gangguan Pod (). PDBs Tidak seperti proses [grup node pembaruan](managed-node-update-behavior.md) (yang menguras node dan respek PDBs selama fase upgrade), memperbarui konfigurasi penskalaan menyebabkan node segera dihentikan melalui panggilan scale-down Auto Scaling Group (ASG). Ini terjadi tanpa mempertimbangkan PDBs, terlepas dari ukuran target yang Anda turunkan. Itu berarti ketika Anda mengurangi grup node terkelola Amazon EKS, Pod akan diusir segera setelah node dihentikan, tanpa menghormati apa pun. `desiredSize` PDBs

# Memahami setiap fase pembaruan node
<a name="managed-node-update-behavior"></a>

Strategi upgrade node pekerja terkelola Amazon EKS memiliki empat fase berbeda yang dijelaskan di bagian berikut.

## Fase pengaturan
<a name="managed-node-update-set-up"></a>

Fase pengaturan memiliki langkah-langkah berikut:

1. Ini membuat versi template EC2 peluncuran Amazon baru untuk Grup Auto Scaling yang terkait dengan grup node Anda. Versi template peluncuran baru menggunakan AMI target atau versi template peluncuran khusus untuk pembaruan.

1. Ini memperbarui Grup Auto Scaling untuk menggunakan versi template peluncuran terbaru.

1. Ini menentukan jumlah maksimum node untuk meng-upgrade secara paralel menggunakan `updateConfig` properti untuk kelompok node. Maksimum yang tidak tersedia memiliki kuota 100 node. Nilai defaultnya adalah satu node. Untuk informasi selengkapnya, lihat properti [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) di Referensi API *Amazon* EKS.

## Tingkatkan fase
<a name="managed-node-update-scale-up"></a>

Saat memutakhirkan node dalam grup node terkelola, node yang ditingkatkan diluncurkan di Availability Zone yang sama dengan yang sedang ditingkatkan. Untuk menjamin penempatan ini, kami menggunakan Availability EC2 Zone Rebalancing Amazon. Untuk informasi selengkapnya, lihat [Penyeimbangan Kembali Zona Ketersediaan](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) di Panduan Pengguna *Auto EC2 Scaling Amazon*. Untuk memenuhi persyaratan ini, ada kemungkinan bahwa kami akan meluncurkan hingga dua instance per Availability Zone di grup node terkelola Anda.

Fase peningkatan skala memiliki langkah-langkah berikut:

1. Ini meningkatkan ukuran maksimum Grup Auto Scaling dan ukuran yang diinginkan dengan ukuran yang lebih besar dari keduanya:
   + Hingga dua kali jumlah Availability Zone yang digunakan oleh Grup Auto Scaling.
   + Upgrade maksimum yang tidak tersedia.

     Misalnya, jika grup node Anda memiliki lima Availability Zones dan `maxUnavailable` sebagai satu, proses upgrade dapat meluncurkan maksimal 10 node. Namun ketika `maxUnavailable` 20 (atau apa pun yang lebih tinggi dari 10), proses akan meluncurkan 20 node baru.

1. Setelah menskalakan Grup Auto Scaling, ia memeriksa apakah node yang menggunakan konfigurasi terbaru ada di grup node. Langkah ini hanya berhasil jika memenuhi kriteria ini:
   + Setidaknya satu node baru diluncurkan di setiap Availability Zone di mana node ada.
   + Setiap node baru harus dalam `Ready` keadaan.
   + Node baru harus memiliki label yang diterapkan Amazon EKS.

     Ini adalah label yang diterapkan Amazon EKS pada node pekerja dalam grup simpul biasa:
     +  `eks.amazonaws.com/nodegroup-image=$amiName` 
     +  `eks.amazonaws.com/nodegroup=$nodeGroupName` 

     Ini adalah label yang diterapkan Amazon EKS pada node pekerja dalam template peluncuran khusus atau grup node AMI:
     +  `eks.amazonaws.com/nodegroup-image=$amiName` 
     +  `eks.amazonaws.com/nodegroup=$nodeGroupName` 
     +  `eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId` 
     +  `eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion` 

1. Ini menandai node sebagai tidak dapat dijadwalkan untuk menghindari penjadwalan Pod baru. Ini juga memberi label node `node.kubernetes.io/exclude-from-external-load-balancers=true` untuk menghapus node lama dari penyeimbang beban sebelum mengakhiri node.

Berikut ini adalah alasan yang diketahui yang menyebabkan `NodeCreationFailure` kesalahan dalam fase ini:

 **Kapasitas tidak mencukupi di Availability Zone**   
Ada kemungkinan bahwa Availability Zone mungkin tidak memiliki kapasitas tipe instans yang diminta. Disarankan untuk mengonfigurasi beberapa jenis instance saat membuat grup node terkelola.

 **EC2 batas instans di akun Anda**   
Anda mungkin perlu menambah jumlah EC2 instans Amazon yang dapat dijalankan akun Anda secara bersamaan menggunakan Service Quotas. Untuk informasi selengkapnya, lihat [EC2 Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) di *Panduan Pengguna Amazon Elastic Compute Cloud untuk* Instans Linux.

 **Data pengguna kustom**   
Data pengguna khusus terkadang dapat merusak proses bootstrap. Skenario ini dapat menyebabkan `kubelet` tidak dimulai pada node atau node tidak mendapatkan label Amazon EKS yang diharapkan pada mereka. Untuk informasi selengkapnya, lihat [Menentukan AMI](launch-templates.md#launch-template-custom-ami).

 **Setiap perubahan yang membuat node tidak sehat atau tidak siap**   
Tekanan disk node, tekanan memori, dan kondisi serupa dapat menyebabkan node tidak akan `Ready` berstatus.

 **Setiap node paling bootstrap dalam waktu 15 menit**   
Jika ada node yang membutuhkan waktu lebih dari 15 menit untuk bootstrap dan bergabung dengan cluster, itu akan menyebabkan pemutakhiran menjadi time out. Ini adalah total runtime untuk bootstrap node baru yang diukur dari saat node baru diperlukan hingga saat bergabung dengan cluster. Saat memutakhirkan grup node terkelola, penghitung waktu dimulai segera setelah ukuran Grup Auto Scaling meningkat.

## Fase upgrade
<a name="managed-node-update-upgrade"></a>

Fase peningkatan berperilaku dalam dua cara berbeda, tergantung pada *strategi pembaruan*. Ada dua strategi pembaruan: **default** dan **minimal**.

Kami merekomendasikan strategi default di sebagian besar skenario. Ini menciptakan node baru sebelum mengakhiri yang lama, sehingga kapasitas yang tersedia dipertahankan selama fase upgrade. Strategi minimal berguna dalam skenario di mana Anda dibatasi untuk sumber daya atau biaya, misalnya dengan akselerator perangkat keras seperti. GPUs Ini mengakhiri node lama sebelum membuat yang baru, sehingga kapasitas total tidak pernah meningkat melebihi kuantitas yang Anda konfigurasi.

Strategi pembaruan *default* memiliki langkah-langkah berikut:

1. Ini meningkatkan jumlah node (jumlah yang diinginkan) di Auto Scaling Group, menyebabkan grup node untuk membuat node tambahan.

1. Ini secara acak memilih node yang perlu ditingkatkan, hingga maksimum yang tidak tersedia yang dikonfigurasi untuk grup node.

1. Ini menguras Pod dari node. Jika Pod tidak meninggalkan node dalam waktu 15 menit dan tidak ada force flag, fase upgrade gagal dengan `PodEvictionFailure` error. Untuk skenario ini, Anda dapat menerapkan flag force dengan `update-nodegroup-version` permintaan untuk menghapus Pod.

1. Ini menutup node setelah setiap Pod diusir dan menunggu selama 60 detik. Hal ini dilakukan agar pengontrol layanan tidak mengirim permintaan baru ke node ini dan menghapus node ini dari daftar node aktifnya.

1. Ini mengirimkan permintaan penghentian ke Grup Auto Scaling untuk node yang diapit.

1. Ini mengulangi langkah-langkah upgrade sebelumnya sampai tidak ada node dalam grup node yang digunakan dengan versi sebelumnya dari template peluncuran.

Strategi pembaruan *minimal* memiliki langkah-langkah berikut:

1. Ini mengikat semua node dari grup node di awal, sehingga pengontrol layanan tidak mengirim permintaan baru ke node ini.

1. Ini secara acak memilih node yang perlu ditingkatkan, hingga maksimum yang tidak tersedia yang dikonfigurasi untuk grup node.

1. Ini menguras Pod dari node yang dipilih. Jika Pod tidak meninggalkan node dalam waktu 15 menit dan tidak ada force flag, fase upgrade gagal dengan `PodEvictionFailure` error. Untuk skenario ini, Anda dapat menerapkan flag force dengan `update-nodegroup-version` permintaan untuk menghapus Pod.

1. Setelah setiap Pod diusir dan menunggu selama 60 detik, ia mengirimkan permintaan penghentian ke Grup Auto Scaling untuk node yang dipilih. Grup Auto Scaling membuat node baru (sama dengan jumlah node yang dipilih) untuk menggantikan kapasitas yang hilang.

1. Ini mengulangi langkah-langkah upgrade sebelumnya sampai tidak ada node dalam grup node yang digunakan dengan versi sebelumnya dari template peluncuran.

### `PodEvictionFailure`kesalahan selama fase upgrade
<a name="_podevictionfailure_errors_during_the_upgrade_phase"></a>

Berikut ini adalah alasan yang diketahui yang menyebabkan `PodEvictionFailure` kesalahan dalam fase ini:

 **PDB Agresif**   
PDB agresif didefinisikan pada Pod atau ada beberapa yang PDBs menunjuk ke Pod yang sama.

 **Penerapan yang menoleransi semua noda**   
Setelah setiap Pod diusir, node diharapkan kosong karena node [tercemar](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) pada langkah-langkah sebelumnya. Namun, jika penerapan mentolerir setiap taint, maka node lebih cenderung tidak kosong, yang menyebabkan kegagalan penggusuran Pod.

## Skala turun fase
<a name="managed-node-update-scale-down"></a>

Fase penurunan skala mengurangi ukuran maksimum grup Auto Scaling dan ukuran yang diinginkan satu per satu untuk kembali ke nilai sebelum pembaruan dimulai.

Jika alur kerja Upgrade menentukan bahwa Cluster Autoscaler meningkatkan grup node selama fase penurunan skala alur kerja, ia segera keluar tanpa membawa grup node kembali ke ukuran aslinya.

# Sesuaikan node terkelola dengan templat peluncuran
<a name="launch-templates"></a>

Untuk kustomisasi tingkat tertinggi, Anda dapat menerapkan node terkelola dengan templat peluncuran Anda sendiri berdasarkan langkah-langkah di halaman ini. Menggunakan template peluncuran memungkinkan kemampuan seperti menyediakan argumen bootstrap selama penerapan node (misalnya, argumen [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) ekstra), menetapkan alamat IP ke Pod dari blok CIDR yang berbeda dari alamat IP yang ditetapkan ke node, menerapkan AMI kustom Anda sendiri ke node, atau menerapkan CNI kustom Anda sendiri ke node.

Saat Anda memberikan template peluncuran Anda sendiri saat pertama kali membuat grup node terkelola, Anda juga akan memiliki fleksibilitas yang lebih besar nanti. Selama Anda menerapkan grup node terkelola dengan templat peluncuran Anda sendiri, Anda dapat memperbaruinya secara berulang dengan versi berbeda dari template peluncuran yang sama. Saat Anda memperbarui grup node ke versi template peluncuran yang berbeda, semua node dalam grup didaur ulang agar sesuai dengan konfigurasi baru dari versi template peluncuran yang ditentukan.

Grup node terkelola selalu digunakan dengan template peluncuran untuk digunakan dengan grup Amazon EC2 Auto Scaling. Jika Anda tidak menyediakan template peluncuran, Amazon EKS API membuatnya secara otomatis dengan nilai default di akun Anda. Namun, kami tidak menyarankan Anda memodifikasi templat peluncuran yang dibuat secara otomatis. Selain itu, grup node yang ada yang tidak menggunakan templat peluncuran kustom tidak dapat diperbarui secara langsung. Sebagai gantinya, Anda harus membuat grup node baru dengan template peluncuran khusus untuk melakukannya.

## Luncurkan dasar-dasar konfigurasi templat
<a name="launch-template-basics"></a>

Anda dapat membuat template Konsol Manajemen AWS peluncuran Amazon EC2 Auto Scaling dengan AWS , CLI, atau SDK. AWS Untuk informasi selengkapnya, lihat [Membuat Template Peluncuran untuk grup Auto Scaling di Panduan](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) Pengguna *Amazon EC2* Auto Scaling. Beberapa pengaturan dalam templat peluncuran mirip dengan pengaturan yang digunakan untuk konfigurasi simpul terkelola. Saat menerapkan atau memperbarui grup node dengan template peluncuran, beberapa pengaturan harus ditentukan baik dalam konfigurasi grup node atau template peluncuran. Jangan tentukan pengaturan di kedua tempat. Jika pengaturan ada di tempat yang seharusnya tidak, maka operasi seperti membuat atau memperbarui grup node gagal.

Tabel berikut mencantumkan pengaturan yang dilarang dalam template peluncuran. Ini juga mencantumkan pengaturan serupa, jika ada yang tersedia, yang diperlukan dalam konfigurasi grup node terkelola. Pengaturan yang tercantum adalah pengaturan yang muncul di konsol. Mereka mungkin memiliki nama yang mirip tetapi berbeda di AWS CLI dan SDK.


| Peluncuran templat — Dilarang | Konfigurasi grup simpul Amazon EKS | 
| --- | --- | 
|   **Subnet** dalam **Antarmuka Jaringan** (**Tambahkan antarmuka jaringan**)  |   **Subnet** di bawah **konfigurasi jaringan grup Node** pada halaman **Tentukan jaringan**  | 
|   **Profil instans IAM** dalam **Detail lanjutan**   |   **Peran IAM** **node di bawah konfigurasi grup Node** pada halaman **grup Configure Node**  | 
|   **Perilaku Shutdown** dan **Perilaku Berhenti - Hibernasi** dalam **Detail lanjutan**. Pertahankan default **Jangan sertakan dalam pengaturan template peluncuran** di template peluncuran untuk kedua pengaturan.  |  Tidak setara. Amazon EKS harus mengontrol siklus hidup instans, bukan grup Auto Scaling.  | 

Tabel berikut mencantumkan pengaturan yang dilarang dalam konfigurasi grup node terkelola. Ini juga mencantumkan pengaturan serupa, jika ada yang tersedia, yang diperlukan dalam template peluncuran. Pengaturan yang tercantum adalah pengaturan yang muncul di konsol. Mereka mungkin memiliki nama yang mirip di AWS CLI dan SDK.


| Konfigurasi grup simpul Amazon EKS - Dilarang | Luncurkan templat | 
| --- | --- | 
|  (Hanya jika Anda menetapkan AMI kustom dalam template peluncuran) **Jenis AMI** di bawah konfigurasi **komputasi grup Node pada halaman konfigurasi** **Set komputasi dan penskalaan** — Tampilan konsol **Ditentukan dalam templat peluncuran dan ID AMI yang ditentukan**. Jika **Gambar Aplikasi dan OS (Amazon Machine Image)** tidak ditentukan dalam template peluncuran, Anda dapat memilih AMI dalam konfigurasi grup node.  |   Gambar **Aplikasi dan OS (Gambar Mesin Amazon)** di bawah **Meluncurkan konten template** - Anda harus menentukan ID jika Anda memiliki salah satu dari persyaratan berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/launch-templates.html)  | 
|   **Ukuran disk** di bawah konfigurasi **komputasi grup Node pada Mengatur halaman konfigurasi** **komputasi dan penskalaan** — Tampilan konsol **Ditentukan dalam templat peluncuran**.  |   **Ukuran** dalam **Penyimpanan (Volume)** (**Tambahkan volume baru**). Anda harus menentukan ini dalam templat peluncuran.  | 
|   **SSH key pair** di bawah **konfigurasi grup Node** pada halaman **Specify Networking** - Konsol menampilkan kunci yang ditentukan dalam template peluncuran atau menampilkan **Tidak ditentukan dalam template peluncuran**.  |   **Nama pasangan kunci** dalam **Pasangan kunci (login)**.  | 
|  Anda tidak dapat menentukan grup keamanan sumber yang diizinkan akses jarak jauh saat menggunakan templat peluncuran.  |   **Grup keamanan** dalam **Pengaturan jaringan** untuk instans atau **Grup keamanan** di bawah **Antarmuka jaringan** (**Tambahkan antarmuka jaringan**), tapi tidak keduanya. Untuk informasi selengkapnya, lihat [Menggunakan grup keamanan kustom](#launch-template-security-groups).  | 

**catatan**  
Jika Anda menerapkan grup node menggunakan template peluncuran, tentukan nol atau satu **jenis Instance** di bawah **Meluncurkan konten template** dalam template peluncuran. Atau, Anda dapat menentukan 0—20 jenis instans untuk **tipe Instance** di halaman **Setel konfigurasi komputasi dan penskalaan** di konsol. Atau, Anda dapat melakukannya menggunakan alat lain yang menggunakan Amazon EKS API. Jika Anda menentukan jenis instance dalam template peluncuran, dan menggunakan template peluncuran tersebut untuk menyebarkan grup node, Anda tidak dapat menentukan jenis instance apa pun di konsol atau menggunakan alat lain yang menggunakan Amazon EKS API. Jika Anda tidak menentukan jenis instance dalam template peluncuran, di konsol, atau menggunakan alat lain yang menggunakan Amazon EKS API, jenis `t3.medium` instance akan digunakan. Jika grup simpul Anda menggunakan tipe kapasitas Spot, sebaiknya tentukan beberapa tipe instans menggunakan konsol. Untuk informasi selengkapnya, lihat [Tipe kapasitas grup simpul terkelola](managed-node-groups.md#managed-node-group-capacity-types).
Jika kontainer apa pun yang Anda terapkan ke grup node menggunakan Layanan Metadata Instans Versi 2, pastikan untuk menetapkan **batas hop respons Metadata** ke `2` dalam template peluncuran Anda. Untuk informasi selengkapnya, lihat [Metadata instans dan data pengguna](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) di Panduan Pengguna *Amazon EC2*.
Template peluncuran tidak mendukung `InstanceRequirements` fitur yang memungkinkan pemilihan jenis instans yang fleksibel.

## Penandaan instans Amazon EC2
<a name="launch-template-tagging"></a>

Anda dapat menggunakan parameter `TagSpecification` dari templat peluncuran untuk menentukan tanda mana yang akan diterapkan ke instans Amazon EC2 di grup simpul Anda. Entitas IAM memanggil `CreateNodegroup` atau `UpdateNodegroupVersion` APIs harus memiliki izin untuk `ec2:RunInstances` dan`ec2:CreateTags`, dan tag harus ditambahkan ke template peluncuran.

## Menggunakan grup keamanan kustom
<a name="launch-template-security-groups"></a>

Anda dapat menggunakan templat peluncuran untuk menentukan Amazon EC2 kustom [grup keamanan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) untuk diterapkan ke instans dalam grup simpul Anda. Ini dapat berupa parameter grup keamanan tingkat instans atau sebagai bagian dari parameter konfigurasi antarmuka jaringan. Namun, Anda tidak dapat membuat template peluncuran yang menentukan tingkat instans dan grup keamanan antarmuka jaringan. Pertimbangkan kondisi yang berlaku berikut untuk menggunakan grup keamanan kustom dengan grup simpul terkelola:
+ Saat menggunakan Konsol Manajemen AWS, Amazon EKS hanya mengizinkan template peluncuran dengan spesifikasi antarmuka jaringan tunggal.
+ Secara default, Amazon EKS menerapkan [grup keamanan klaster](sec-group-reqs.md) untuk instans dalam grup simpul Anda guna memfasilitasi komunikasi antara simpul dan pesawat kontrol. Jika Anda menentukan grup keamanan kustom dalam template peluncuran menggunakan salah satu opsi yang disebutkan sebelumnya, Amazon EKS tidak menambahkan grup keamanan klaster. Jadi, Anda harus memastikan bahwa aturan masuk dan keluar dari grup keamanan Anda memungkinkan komunikasi dengan titik akhir klaster Anda. Jika aturan grup keamanan Anda salah, node pekerja tidak dapat bergabung dengan cluster. Untuk informasi selengkapnya tentang aturan grup keamanan, lihat[Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md).
+ Jika Anda memerlukan akses SSH ke instance di grup node Anda, sertakan grup keamanan yang memungkinkan akses tersebut.

## Data pengguna Amazon EC2
<a name="launch-template-user-data"></a>

Template peluncuran mencakup bagian untuk data pengguna kustom. Anda dapat menentukan pengaturan konfigurasi untuk grup node Anda di bagian ini tanpa membuat kustom individual secara manual AMIs. Untuk informasi selengkapnya tentang pengaturan yang tersedia untuk Bottlerocket, lihat [Menggunakan](https://github.com/bottlerocket-os/bottlerocket#using-user-data) data pengguna di. GitHub

Anda dapat menyediakan data pengguna Amazon EC2 di templat peluncuran menggunakan `cloud-init` saat meluncurkan instans Anda. Untuk informasi selengkapnya, lihat dokumentasi [cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html). Data pengguna Anda dapat digunakan untuk melakukan operasi konfigurasi umum. Ini termasuk operasi berikut:
+  [Termasuk pengguna atau grup](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) 
+  [Menginstal paket](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages) 

Data pengguna Amazon EC2 dalam template peluncuran yang digunakan dengan grup node terkelola harus dalam format arsip [multi-bagian MIME untuk Amazon Linux AMIs dan format TOMM](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) untuk Bottlerocket. AMIs Ini karena data pengguna Anda digabungkan dengan data pengguna Amazon EKS yang diperlukan simpul untuk bergabung dengan klaster. Jangan tentukan perintah apa pun dalam data pengguna Anda yang memulai atau memodifikasi`kubelet`. Ini dilakukan sebagai bagian dari data pengguna yang digabungkan oleh Amazon EKS. Parameter `kubelet` tertentu, seperti pengaturan label pada simpul, dapat dikonfigurasi secara langsung melalui API grup simpul terkelola.

**catatan**  
Untuk informasi selengkapnya tentang `kubelet` kustomisasi lanjutan, termasuk memulainya secara manual atau meneruskan parameter konfigurasi kustom, lihat[Menentukan AMI](#launch-template-custom-ami). Jika ID AMI kustom ditentukan dalam template peluncuran, Amazon EKS tidak menggabungkan data pengguna.

Rincian berikut memberikan informasi lebih lanjut tentang bagian data pengguna.

 **Data pengguna Amazon Linux 2**   
Anda dapat menggabungkan beberapa blok data pengguna menjadi satu file multi-bagian MIME. Misalnya, Anda dapat menggabungkan cloud boothook yang mengonfigurasi Docker daemon dengan skrip shell data pengguna yang menginstal paket kustom. File multi-bagian MIME terdiri dari komponen berikut:  
+ Tipe konten dan deklarasi batas bagian – `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="` 
+ Deklarasi versi MIME – `MIME-Version: 1.0` 
+ Satu atau lebih blok data pengguna, yang berisi komponen berikut:
  + Batas pembukaan, yang menandakan awal dari blok data pengguna – `--==MYBOUNDARY==` 
  + Deklarasi tipe konten untuk blok: `Content-Type: text/cloud-config; charset="us-ascii"`. Untuk informasi selengkapnya, lihat dokumentasi [cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html).
  + Isi data pengguna (misalnya, daftar perintah atau `cloud-init` arahan shell).
  + Batas penutupan, yang menandakan akhir dari file multi-bagian MIME: `--==MYBOUNDARY==--` 

  Berikut ini adalah contoh file multi-bagian MIME yang dapat Anda gunakan untuk membuat milik Anda sendiri.

```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
echo "Running custom user data script"

--==MYBOUNDARY==--
```

 **Data pengguna Amazon Linux 2023**   
Amazon Linux 2023 (AL2023) memperkenalkan proses inisialisasi node baru `nodeadm` yang menggunakan skema konfigurasi YAMM. Jika Anda menggunakan grup node yang dikelola sendiri atau AMI dengan template peluncuran, Anda sekarang harus menyediakan metadata klaster tambahan secara eksplisit saat membuat grup node baru. [Contoh](https://awslabs.github.io/amazon-eks-ami/nodeadm/) parameter minimum yang diperlukan adalah sebagai berikut, di mana`apiServerEndpoint`,`certificateAuthority`, dan layanan sekarang `cidr` diperlukan:  

```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16
```
Anda biasanya akan mengatur konfigurasi ini dalam data pengguna Anda, baik apa adanya atau disematkan dalam dokumen multi-bagian MIME:  

```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]

--BOUNDARY--
```
Pada tahun AL2, metadata dari parameter ini ditemukan dari panggilan Amazon EKS `DescribeCluster` API. Dengan AL2023, perilaku ini telah berubah karena panggilan API tambahan berisiko melambat selama peningkatan skala node besar. Perubahan ini tidak memengaruhi Anda jika Anda menggunakan grup node terkelola tanpa templat peluncuran atau jika Anda menggunakan Karpenter. Untuk informasi selengkapnya tentang `certificateAuthority` dan layanan`cidr`, lihat [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html)di *Referensi API Amazon EKS*.  
Berikut adalah contoh lengkap data AL2023 pengguna yang menggabungkan skrip shell untuk menyesuaikan node (seperti menginstal paket atau gambar wadah pra-caching) dengan konfigurasi yang diperlukan. `nodeadm` Contoh ini menunjukkan kustomisasi umum termasuk: \$1 Menginstal paket sistem tambahan\$1 Gambar kontainer pra-caching untuk meningkatkan waktu startup Pod \$1 Menyiapkan konfigurasi proxy HTTP \$1 Mengkonfigurasi flag untuk pelabelan node `kubelet`  

```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
set -o errexit
set -o pipefail
set -o nounset

# Install additional packages
yum install -y htop jq iptables-services

# Pre-cache commonly used container images
nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 &

# Configure HTTP proxy if needed
cat > /etc/profile.d/http-proxy.sh << 'EOF'
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"
export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal"
EOF

--BOUNDARY
Content-Type: application/node.eks.aws

apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16
  kubelet:
    config:
      clusterDNS:
      - 10.100.0.10
    flags:
    - --node-labels=app=my-app,environment=production

--BOUNDARY--
```

 **Data pengguna bottlerocket**   
Bottlerocket menyusun data pengguna dalam format TOMB. Anda dapat memberikan data pengguna untuk digabungkan dengan data pengguna yang disediakan oleh Amazon EKS. Misalnya, Anda dapat memberikan `kubelet` pengaturan tambahan.  

```
[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"
```
Untuk informasi selengkapnya tentang pengaturan yang didukung, lihat dokumentasi [Bottlerocket](https://github.com/bottlerocket-os/bottlerocket). Anda dapat mengonfigurasi label node dan [taints](node-taints-managed-node-groups.md) dalam data pengguna Anda. Namun, kami menyarankan Anda mengonfigurasi ini dalam grup node Anda sebagai gantinya. Amazon EKS menerapkan konfigurasi ini saat Anda melakukannya.  
Saat data pengguna digabungkan, pemformatan tidak dipertahankan, tetapi kontennya tetap sama. Konfigurasi yang Anda berikan dalam data pengguna akan mengesampingkan pengaturan apa pun yang dikonfigurasi oleh Amazon EKS. Jadi, jika Anda menetapkan `settings.kubernetes.max-pods` atau`settings.kubernetes.cluster-dns-ip`, nilai-nilai ini dalam data pengguna Anda diterapkan ke node.  
Amazon EKS tidak mendukung semua TOMB yang valid. Berikut ini adalah daftar format yang tidak didukung yang diketahui:  
+ Kutipan dalam kunci yang dikutip: `'quoted "value"' = "value"` 
+ Kutipan lolos dalam nilai: `str = "I’m a string. \"You can quote me\""` 
+ Campuran pelampung dan bilangan bulat: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]` 
+ Jenis campuran dalam array: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]` 
+ Header bertanda kurung dengan tombol yang dikutip: `[foo."bar.baz"]` 

 **Data pengguna Windows**   
Data pengguna Windows menggunakan PowerShell perintah. Saat membuat grup node terkelola, data pengguna kustom Anda digabungkan dengan data pengguna terkelola Amazon EKS. PowerShell Perintah Anda didahulukan, diikuti oleh perintah data pengguna terkelola, semuanya dalam satu `<powershell></powershell>` tag.  
Saat membuat grup node Windows, Amazon EKS memperbarui `aws-auth` `ConfigMap` untuk memungkinkan node berbasis Linux bergabung dengan cluster. Layanan tidak secara otomatis mengkonfigurasi izin untuk Windows AMIs. Jika Anda menggunakan node Windows, Anda harus mengelola akses baik melalui API entri akses atau dengan memperbarui secara `aws-auth` `ConfigMap` langsung. Untuk informasi selengkapnya, lihat [Menerapkan node Windows pada kluster EKS](windows-support.md).
Ketika tidak ada ID AMI yang ditentukan dalam template peluncuran, jangan gunakan skrip Bootstrap Windows Amazon EKS dalam data pengguna untuk mengonfigurasi Amazon EKS.
Contoh data pengguna adalah sebagai berikut.  

```
<powershell>
Write-Host "Running custom user data script"
</powershell>
```

## Menentukan AMI
<a name="launch-template-custom-ami"></a>

Jika Anda memiliki salah satu dari persyaratan berikut, maka tentukan ID AMI di `ImageId` bidang template peluncuran Anda. Pilih persyaratan yang Anda miliki untuk informasi tambahan.

### Berikan data pengguna untuk meneruskan argumen ke `bootstrap.sh` file yang disertakan dengan Linux/Bottlerocket AMI Amazon EKS yang dioptimalkan
<a name="mng-specify-eks-ami"></a>

Bootstrapping adalah istilah yang digunakan untuk menggambarkan penambahan perintah yang dapat dijalankan ketika sebuah instance dimulai. [Misalnya, bootstrapping memungkinkan penggunaan argumen kubelet ekstra.](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) Anda dapat meneruskan argumen ke `bootstrap.sh` skrip dengan menggunakan `eksctl` tanpa menentukan template peluncuran. Atau Anda dapat melakukannya dengan menentukan informasi di bagian data pengguna dari template peluncuran.

 **eksctl tanpa menentukan template peluncuran**   
Buat file bernama *my-nodegroup.yaml* dengan isi berikut ini. Ganti setiap *example value* dengan nilai-nilai Anda sendiri. `--dns-cluster-ip`Argumen `--apiserver-endpoint``--b64-cluster-ca`,, dan bersifat opsional. Namun, mendefinisikannya memungkinkan `bootstrap.sh` skrip untuk menghindari `describeCluster` panggilan. Ini berguna dalam pengaturan cluster pribadi atau cluster tempat Anda sering menskalakan node masuk dan keluar. Untuk informasi selengkapnya tentang `bootstrap.sh` skrip, lihat file [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) di GitHub.  
+ Satu-satunya argumen yang diperlukan adalah nama cluster (*my-cluster*).
+ Untuk mengambil ID AMI yang dioptimalkan`ami-1234567890abcdef0 `, lihat bagian berikut:
  +  [Ambil AMI Amazon Linux yang direkomendasikan IDs](retrieve-ami-id.md) 
  +  [Ambil Bottlerocket AMI yang direkomendasikan IDs](retrieve-ami-id-bottlerocket.md) 
  +  [Ambil Microsoft Windows AMI yang direkomendasikan IDs](retrieve-windows-ami-id.md) 
+ Untuk mengambil *certificate-authority* untuk cluster Anda, jalankan perintah berikut.

  ```
  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  ```
+ Untuk mengambil *api-server-endpoint* untuk cluster Anda, jalankan perintah berikut.

  ```
  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  ```
+ Nilai untuk `--dns-cluster-ip` adalah CIDR layanan Anda dengan `.10` di akhir. Untuk mengambil *service-cidr* untuk cluster Anda, jalankan perintah berikut. Misalnya, jika nilai yang dikembalikan adalah`ipv4 10.100.0.0/16`, maka nilai Anda adalah*10.100.0.10*.

  ```
  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  ```
+ Contoh ini memberikan `kubelet` argumen untuk menetapkan `max-pods` nilai kustom menggunakan `bootstrap.sh` skrip yang disertakan dengan AMI Amazon EKS yang dioptimalkan. Nama grup node tidak boleh lebih dari 63 karakter. Itu harus dimulai dengan huruf atau digit, tetapi juga dapat menyertakan tanda hubung dan garis bawah untuk karakter yang tersisa. Untuk bantuan dalam memilih*my-max-pods-value*, lihat. Untuk informasi selengkapnya tentang cara `maxPods` ditentukan saat menggunakan grup node terkelola, lihat[Bagaimana MaxPods ditentukan](choosing-instance-type.md#max-pods-precedence).

  ```
  ---
  apiVersion: eksctl.io/v1alpha5
  kind: ClusterConfig
  
  metadata:
    name: my-cluster
    region: region-code
  
  managedNodeGroups:
    - name: my-nodegroup
      ami: ami-1234567890abcdef0
      instanceType: m5.large
      privateNetworking: true
      disableIMDSv1: true
      labels: { x86-al2-specified-mng }
      overrideBootstrapCommand: |
        #!/bin/bash
        /etc/eks/bootstrap.sh my-cluster \
          --b64-cluster-ca certificate-authority \
          --apiserver-endpoint api-server-endpoint \
          --dns-cluster-ip service-cidr.10 \
          --kubelet-extra-args '--max-pods=my-max-pods-value' \
          --use-max-pods false
  ```

  Untuk setiap opsi `eksctl` `config` file yang tersedia, lihat [Skema file Config dalam dokumentasi](https://eksctl.io/usage/schema/). `eksctl` `eksctl`Utilitas masih membuat template peluncuran untuk Anda dan mengisi data penggunanya dengan data yang Anda berikan dalam `config` file.

  Buat grup node dengan perintah berikut.

  ```
  eksctl create nodegroup --config-file=my-nodegroup.yaml
  ```

 **Data pengguna dalam template peluncuran**   
Tentukan informasi berikut di bagian data pengguna dari template peluncuran Anda. Ganti setiap *example value* dengan nilai-nilai Anda sendiri. `--dns-cluster-ip`Argumen `--apiserver-endpoint``--b64-cluster-ca`,, dan bersifat opsional. Namun, mendefinisikannya memungkinkan `bootstrap.sh` skrip untuk menghindari `describeCluster` panggilan. Ini berguna dalam pengaturan cluster pribadi atau cluster tempat Anda sering menskalakan node masuk dan keluar. Untuk informasi selengkapnya tentang `bootstrap.sh` skrip, lihat file [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) di GitHub.  
+ Satu-satunya argumen yang diperlukan adalah nama cluster (*my-cluster*).
+ Untuk mengambil *certificate-authority* untuk cluster Anda, jalankan perintah berikut.

  ```
  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  ```
+ Untuk mengambil *api-server-endpoint* untuk cluster Anda, jalankan perintah berikut.

  ```
  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  ```
+ Nilai untuk `--dns-cluster-ip` adalah CIDR layanan Anda dengan `.10` di akhir. Untuk mengambil *service-cidr* untuk cluster Anda, jalankan perintah berikut. Misalnya, jika nilai yang dikembalikan adalah`ipv4 10.100.0.0/16`, maka nilai Anda adalah*10.100.0.10*.

  ```
  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  ```
+ Contoh ini memberikan `kubelet` argumen untuk menetapkan `max-pods` nilai kustom menggunakan `bootstrap.sh` skrip yang disertakan dengan AMI Amazon EKS yang dioptimalkan. Untuk bantuan dalam memilih*my-max-pods-value*, lihat. Untuk informasi selengkapnya tentang cara `maxPods` ditentukan saat menggunakan grup node terkelola, lihat[Bagaimana MaxPods ditentukan](choosing-instance-type.md#max-pods-precedence).

  ```
  MIME-Version: 1.0
  Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
  
  --==MYBOUNDARY==
  Content-Type: text/x-shellscript; charset="us-ascii"
  
  #!/bin/bash
  set -ex
  /etc/eks/bootstrap.sh my-cluster \
    --b64-cluster-ca certificate-authority \
    --apiserver-endpoint api-server-endpoint \
    --dns-cluster-ip service-cidr.10 \
    --kubelet-extra-args '--max-pods=my-max-pods-value' \
    --use-max-pods false
  
  --==MYBOUNDARY==--
  ```

### Berikan data pengguna untuk meneruskan argumen ke `Start-EKSBootstrap.ps1` file yang disertakan dengan AMI Windows Amazon EKS yang dioptimalkan
<a name="mng-specify-eks-ami-windows"></a>

Bootstrapping adalah istilah yang digunakan untuk menggambarkan penambahan perintah yang dapat dijalankan ketika sebuah instance dimulai. Anda dapat meneruskan argumen ke `Start-EKSBootstrap.ps1` skrip dengan menggunakan `eksctl` tanpa menentukan template peluncuran. Atau Anda dapat melakukannya dengan menentukan informasi di bagian data pengguna dari template peluncuran.

Jika Anda ingin menentukan ID AMI Windows kustom, ingatlah pertimbangan berikut:
+ Anda harus menggunakan template peluncuran dan memberikan perintah bootstrap yang diperlukan di bagian data pengguna. Untuk mengambil ID Windows yang Anda inginkan, Anda dapat menggunakan tabel di [Buat node dengan Windows AMIs yang dioptimalkan](eks-optimized-windows-ami.md).
+ Ada beberapa batasan dan kondisi. Misalnya, Anda harus menambahkan `eks:kube-proxy-windows` ke peta konfigurasi AWS IAM Authenticator Anda. Untuk informasi selengkapnya, lihat [Batas dan ketentuan saat menentukan ID AMI](#mng-ami-id-conditions).

Tentukan informasi berikut di bagian data pengguna dari template peluncuran Anda. Ganti setiap *example value* dengan nilai-nilai Anda sendiri. `-DNSClusterIP`Argumen `-APIServerEndpoint``-Base64ClusterCA`,, dan bersifat opsional. Namun, mendefinisikannya memungkinkan `Start-EKSBootstrap.ps1` skrip untuk menghindari `describeCluster` panggilan.
+ Satu-satunya argumen yang diperlukan adalah nama cluster (*my-cluster*).
+ Untuk mengambil *certificate-authority* untuk cluster Anda, jalankan perintah berikut.

  ```
  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  ```
+ Untuk mengambil *api-server-endpoint* untuk cluster Anda, jalankan perintah berikut.

  ```
  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  ```
+ Nilai untuk `--dns-cluster-ip` adalah CIDR layanan Anda dengan `.10` di akhir. Untuk mengambil *service-cidr* untuk cluster Anda, jalankan perintah berikut. Misalnya, jika nilai yang dikembalikan adalah`ipv4 10.100.0.0/16`, maka nilai Anda adalah*10.100.0.10*.

  ```
  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  ```
+ Untuk argumen tambahan, lihat[Parameter konfigurasi skrip bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
**catatan**  
Jika Anda menggunakan layanan khusus CIDR, maka Anda perlu menentukannya menggunakan `-ServiceCIDR` parameter. Jika tidak, resolusi DNS untuk Pod di klaster akan gagal.

```
<powershell>
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
	 -Base64ClusterCA certificate-authority `
	 -APIServerEndpoint api-server-endpoint `
	 -DNSClusterIP service-cidr.10
</powershell>
```

### Jalankan AMI khusus karena persyaratan keamanan, kepatuhan, atau kebijakan internal tertentu
<a name="mng-specify-custom-ami"></a>

Untuk informasi selengkapnya, lihat [Amazon Machine Image (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) di *Panduan Pengguna Amazon EC2*. Spesifikasi build Amazon EKS AMI berisi sumber daya dan skrip konfigurasi untuk membuat Amazon EKS AMI khusus berdasarkan Amazon Linux. Untuk informasi selengkapnya, lihat [Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami/) on GitHub. Untuk membuat kustom yang AMIs diinstal dengan sistem operasi lain, lihat [Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis) di GitHub.

Anda tidak dapat menggunakan referensi parameter dinamis untuk AMI IDs di Template Peluncuran yang digunakan dengan grup node terkelola.

**penting**  
Saat menentukan AMI, Amazon EKS tidak memvalidasi versi Kubernetes yang disematkan di AMI Anda terhadap versi control plane cluster Anda. Anda bertanggung jawab untuk memastikan bahwa versi Kubernetes dari AMI kustom Anda sesuai dengan kebijakan miring versi [Kubernetes](https://kubernetes.io/releases/version-skew-policy):  
`kubelet`Versi pada node Anda tidak boleh lebih baru dari versi cluster Anda
`kubelet`Versi pada node Anda harus sama dengan atau hingga 3 versi minor di belakang versi cluster Anda (untuk versi Kubernetes `1.28` atau lebih tinggi), atau hingga 2 versi minor di belakang versi cluster Anda (untuk versi Kubernetes atau lebih rendah) `1.27`  
Membuat grup node terkelola dengan pelanggaran versi miring dapat mengakibatkan:
Node gagal bergabung dengan cluster
Perilaku tidak terdefinisi atau ketidakcocokan API
Ketidakstabilan cluster atau kegagalan beban kerja
Saat menentukan AMI, Amazon EKS tidak menggabungkan data pengguna apa pun. Sebaliknya, Anda bertanggung jawab untuk menyediakan `bootstrap` perintah yang diperlukan untuk node untuk bergabung dengan cluster. Jika simpul Anda gagal untuk bergabung dengan klaster, tindakan Amazon EKS `CreateNodegroup` dan `UpdateNodegroupVersion` juga gagal.

## Batas dan ketentuan saat menentukan ID AMI
<a name="mng-ami-id-conditions"></a>

Berikut ini adalah batasan dan kondisi yang terkait dengan menentukan ID AMI dengan grup node terkelola:
+ Anda harus membuat grup node baru untuk beralih antara menentukan ID AMI dalam template peluncuran dan tidak menentukan ID AMI.
+ Anda tidak diberi tahu di konsol saat versi AMI yang lebih baru tersedia. Untuk memperbarui grup node ke versi AMI yang lebih baru, Anda perlu membuat versi baru template peluncuran dengan ID AMI yang diperbarui. Kemudian, Anda perlu memperbarui grup node dengan versi template peluncuran baru.
+ Kolom berikut tidak dapat disetel di API jika Anda menentukan ID AMI:
  +  `amiType` 
  +  `releaseVersion` 
  +  `version` 
+ Setiap `taints` set dalam API diterapkan secara asinkron jika Anda menentukan ID AMI. Untuk menerapkan taints sebelum node bergabung dengan cluster, Anda harus meneruskan taints ke `kubelet` dalam data pengguna Anda menggunakan flag baris `--register-with-taints` perintah. Untuk informasi selengkapnya, lihat [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) dalam dokumentasi Kubernetes.
+ Saat menentukan ID AMI khusus untuk grup node terkelola Windows, tambahkan `eks:kube-proxy-windows` ke peta konfigurasi AWS IAM Authenticator Anda. Ini diperlukan agar DNS berfungsi dengan baik.

  1. Buka peta konfigurasi AWS IAM Authenticator untuk mengedit.

     ```
     kubectl edit -n kube-system cm aws-auth
     ```

  1. Tambahkan entri ini ke `groups` daftar di bawah masing-masing `rolearn` yang terkait dengan node Windows. Peta konfigurasi Anda akan terlihat mirip [aws-auth-cm-windowsdengan.yaml.](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml)

     ```
     - eks:kube-proxy-windows
     ```

  1. Simpan file dan keluar dari editor teks Anda.
+ Untuk AMI apa pun yang menggunakan templat peluncuran kustom, default `HttpPutResponseHopLimit` untuk grup node terkelola diatur ke`2`.

# Menghapus grup node terkelola dari klaster
<a name="delete-managed-node-group"></a>

Topik ini menjelaskan cara menghapus grup simpul terkelola Amazon EKS. Saat Anda menghapus grup node terkelola, Amazon EKS pertama-tama menetapkan ukuran minimum, maksimum, dan yang diinginkan dari grup Auto Scaling Anda ke nol. Ini kemudian menyebabkan grup node Anda menurunkan skala.

Sebelum setiap instance dihentikan, Amazon EKS mengirimkan sinyal untuk menguras node itu. Selama proses drain, Kubernetes melakukan hal berikut untuk setiap pod pada node: menjalankan semua kait `preStop` siklus hidup yang dikonfigurasi, mengirimkan `SIGTERM` sinyal ke container, lalu menunggu shutdown yang anggun. `terminationGracePeriodSeconds` Jika node belum terkuras setelah 5 menit, Amazon EKS memungkinkan Auto Scaling melanjutkan penghentian paksa instance. Setelah semua instance dihentikan, grup Auto Scaling akan dihapus.

**penting**  
Jika Anda menghapus grup node terkelola yang menggunakan peran IAM node yang tidak digunakan oleh grup node terkelola lainnya di klaster, peran tersebut akan dihapus dari. `aws-auth` `ConfigMap` Jika salah satu grup node yang dikelola sendiri di cluster menggunakan peran IAM node yang sama, node yang dikelola sendiri pindah ke status. `NotReady` Selain itu, operasi cluster juga terganggu. Untuk menambahkan pemetaan untuk peran yang Anda gunakan hanya untuk grup node yang dikelola sendiri, lihat[Buat entri akses](creating-access-entries.md), apakah versi platform klaster Anda setidaknya merupakan versi minimum yang tercantum di bagian prasyarat [Grant IAM pengguna akses ke Kubernetes dengan entri akses](access-entries.md) EKS. Jika versi platform Anda lebih awal dari versi minimum yang diperlukan untuk entri akses, Anda dapat menambahkan entri kembali ke `aws-auth``ConfigMap`. Untuk informasi lebih lanjut, masukkan `eksctl create iamidentitymapping --help` di terminal Anda.

Anda dapat menghapus grup node terkelola dengan:
+  [`eksctl`](#eksctl-delete-managed-nodegroup) 
+  [Konsol Manajemen AWS](#console-delete-managed-nodegroup) 
+  [AWS CLI](#awscli-delete-managed-nodegroup) 

## `eksctl`
<a name="eksctl-delete-managed-nodegroup"></a>

 **Hapus grup node terkelola dengan `eksctl`** 

Masukkan perintah berikut. Ganti setiap `<example value>` dengan nilai-nilai Anda sendiri.

```
eksctl delete nodegroup \
  --cluster <my-cluster> \
  --name <my-mng> \
  --region <region-code>
```

Untuk opsi lainnya, lihat [Menghapus dan menguras nodegroup](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) dalam dokumentasi. `eksctl`

## Konsol Manajemen AWS
<a name="console-delete-managed-nodegroup"></a>

 **Hapus grup node terkelola dengan Konsol Manajemen AWS ** 

1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Pada halaman **Clusters**, pilih cluster yang berisi grup node untuk dihapus.

1. Pada halaman cluster yang dipilih, pilih tab **Compute**.

1. Di bagian **Node groups**, pilih grup node yang akan dihapus. Lalu pilih **Hapus**.

1. Dalam kotak dialog **Hapus konfirmasi grup simpul**, masukkan nama grup simpul. Lalu pilih **Hapus**.

## AWS CLI
<a name="awscli-delete-managed-nodegroup"></a>

 **Hapus grup node terkelola dengan AWS CLI** 

1. Masukkan perintah berikut. Ganti setiap `<example value>` dengan nilai-nilai Anda sendiri.

   ```
   aws eks delete-nodegroup \
     --cluster-name <my-cluster> \
     --nodegroup-name <my-mng> \
     --region <region-code>
   ```

1. Jika `cli_pager=` diatur dalam konfigurasi CLI, gunakan tombol panah pada keyboard Anda untuk menggulir output respons. Tekan `q` tombol ketika Anda selesai.

   Untuk opsi lainnya, lihat ` [delete-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/delete-nodegroup.html) ` perintah di * AWS CLI Command* Reference.