**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.
# Mengelola sumber daya komputasi dengan menggunakan node
Node Kubernetes adalah mesin yang menjalankan aplikasi kontainer. Setiap node memiliki komponen-komponen berikut:
+ **[Container runtime](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)** — Perangkat lunak yang bertanggung jawab untuk menjalankan kontainer.
+ **[kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)** — Memastikan bahwa kontainer sehat dan berjalan di dalam Pod yang terkait.
+ **[kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)** — Mempertahankan aturan jaringan yang memungkinkan komunikasi ke Pod Anda.
Untuk informasi selengkapnya, lihat [Simpul](https://kubernetes.io/docs/concepts/architecture/nodes/) dalam dokumentasi Kubernetes.
Cluster Amazon EKS Anda dapat menjadwalkan Pod pada kombinasi node yang [dikelola EKS Auto Mode, node](automode.md) yang [dikelola sendiri, grup node terkelola](worker.md) [Amazon EKS](managed-node-groups.md), [AWS Fargate](fargate.md), dan [Amazon EKS](hybrid-nodes-overview.md) Hybrid Nodes. Untuk mempelajari lebih lanjut tentang node yang digunakan di klaster Anda, lihat[Lihat sumber daya Kubernetes di Konsol Manajemen AWS](view-kubernetes-resources.md).
**catatan**
Tidak termasuk node hybrid, node harus berada di VPC yang sama dengan subnet yang Anda pilih saat Anda membuat cluster. Namun, node tidak harus berada di subnet yang sama.
## Bandingkan opsi komputasi
Tabel berikut memberikan beberapa kriteria untuk dievaluasi saat memutuskan opsi mana yang paling sesuai dengan kebutuhan Anda. Node yang dikelola sendiri adalah opsi lain yang mendukung semua kriteria yang tercantum, tetapi mereka membutuhkan lebih banyak pemeliharaan manual. Untuk informasi selengkapnya, lihat [Pertahankan node sendiri dengan node yang dikelola sendiri](worker.md).
**catatan**
Bottlerocket memiliki beberapa perbedaan spesifik dari informasi umum dalam tabel ini. [Untuk informasi lebih lanjut, lihat dokumentasi Bottlerocket di.](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) GitHub
| Kriteria | Grup simpul terkelola EKS | Mode Otomatis EKS | Node Hibrida Amazon EKS |
| --- | --- | --- | --- |
| [Dapat dikerahkan ke Outposts AWS](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) | Tidak | Tidak | Tidak |
| Dapat dikerahkan ke Zona [AWS Lokal](local-zones.md) | Ya | Tidak | Tidak |
| Dapat menjalankan kontainer yang memerlukan Windows | Ya | Tidak | Tidak |
| Dapat menjalankan kontainer yang membutuhkan Linux | Ya | Ya | Ya |
| Dapat menjalankan beban kerja yang memerlukan Chip Inferentia | [Ya](inferentia-support.md) — Hanya untuk simpul Amazon Linux | Ya | Tidak |
| Dapat menjalankan beban kerja yang memerlukan GPU | [Ya](eks-optimized-ami.md#gpu-ami) — Hanya untuk simpul Amazon Linux | Ya | Ya |
| Dapat menjalankan beban kerja yang memerlukan prosesor Arm | [Ya](eks-optimized-ami.md#arm-ami) | Ya | Ya |
| Dapat menjalankan AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | Ya | Ya | Tidak |
| Pod berbagi CPU, memori, penyimpanan, dan sumber daya jaringan dengan Pod lain. | Ya | Ya | Ya |
| Harus menerapkan dan mengelola instans Amazon EC2 | Ya | Tidak - Pelajari tentang [instans EC2 terkelola](automode-learn-instances.md) | Ya — mesin fisik atau virtual lokal dikelola oleh Anda dengan alat pilihan Anda. |
| Harus mengamankan, memelihara, dan menambal sistem operasi EC2 instans Amazon | Ya | Tidak | Ya — sistem operasi yang berjalan pada mesin fisik atau virtual Anda dikelola oleh Anda dengan alat pilihan Anda. |
| Dapat memberikan argumen bootstrap pada penerapan node, seperti argumen [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) ekstra. | Ya — Menggunakan `eksctl` atau [meluncurkan template](launch-templates.md) dengan AMI kustom. | Tidak - [Gunakan a `NodeClass` untuk mengkonfigurasi node](create-node-class.md) | Ya - Anda dapat menyesuaikan argumen bootstrap dengan nodeadm. Lihat [`nodeadm`Referensi node hibrida](hybrid-nodes-nodeadm.md). |
| Dapat menetapkan alamat IP ke Pod dari blok CIDR yang berbeda dari alamat IP yang ditetapkan ke node. | Ya - Menggunakan template peluncuran dengan AMI kustom. Untuk informasi selengkapnya, lihat [Sesuaikan node terkelola dengan templat peluncuran](launch-templates.md). | Tidak | Ya - lihat[Konfigurasikan CNI untuk node hybrid](hybrid-nodes-cni.md). |
| Dapat SSH ke simpul | Ya | Tidak - [Pelajari cara memecahkan masalah node](auto-troubleshoot.md) | Ya |
| Dapat men-deploy AMI kustom Anda sendiri ke simpul | Ya - Menggunakan [template peluncuran](launch-templates.md) | Tidak | Ya |
| Dapat men-deploy CNI kustom Anda sendiri ke simpul | Ya — Menggunakan [templat peluncuran](launch-templates.md) dengan AMI kustom | Tidak | Ya |
| Harus memperbarui node AMI sendiri | [Ya](update-managed-node-group.md) - Jika Anda menerapkan AMI Amazon EKS yang dioptimalkan, Anda akan diberi tahu di konsol Amazon EKS saat pembaruan tersedia. Anda dapat melakukan pembaruan dengan satu klik di konsol. Jika Anda menerapkan AMI khusus, Anda tidak akan diberi tahu di konsol Amazon EKS saat pembaruan tersedia. Anda harus melakukan pembaruan sendiri. | Tidak | Ya - sistem operasi yang berjalan pada mesin fisik atau virtual Anda dikelola oleh Anda dengan perkakas pilihan Anda. Lihat [Siapkan sistem operasi untuk node hybrid](hybrid-nodes-os.md). |
| Harus memperbarui versi node Kubernetes sendiri | [Ya](update-managed-node-group.md) - Jika Anda menerapkan AMI Amazon EKS yang dioptimalkan, Anda akan diberi tahu di konsol Amazon EKS saat pembaruan tersedia. Anda dapat melakukan pembaruan dengan satu klik di konsol. Jika Anda menerapkan AMI khusus, Anda tidak akan diberi tahu di konsol Amazon EKS saat pembaruan tersedia. Anda harus melakukan pembaruan sendiri. | Tidak | Ya - Anda mengelola peningkatan node hibrida dengan perkakas pilihan Anda sendiri atau dengan. `nodeadm` Lihat [Tingkatkan node hybrid untuk klaster Anda](hybrid-nodes-upgrade.md). |
| Dapat menggunakan penyimpanan Amazon EBS dengan Pod | [Ya](ebs-csi.md) | Ya, sebagai kemampuan terintegrasi. Pelajari cara [membuat kelas penyimpanan.](create-storage-class.md) | Tidak |
| Dapat menggunakan penyimpanan Amazon EFS dengan Pod | [Ya](efs-csi.md) | Ya | Tidak |
| Dapat menggunakan Amazon FSx untuk penyimpanan Lustre dengan Pod | [Ya](fsx-csi.md) | Ya | Tidak |
| Dapat menggunakan Network Load Balancer untuk layanan | [Ya](network-load-balancing.md) | Ya | Ya - harus menggunakan tipe target`ip`. |
| Pods dapat berjalan dalam subnet publik | Ya | Ya | Tidak - pod berjalan di lingkungan lokal. |
| Dapat menetapkan grup keamanan VPC yang berbeda ke masing-masing Pod | [Ya](security-groups-for-pods.md) — Hanya untuk simpul Linux | Tidak | Tidak |
| Dapat menjalankan Kubernetes DaemonSets | Ya | Ya | Ya |
| Support `HostPort` dan `HostNetwork` dalam manifes Pod | Ya | Ya | Ya |
| AWS Ketersediaan wilayah | [Semua wilayah yang didukung Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [Semua wilayah yang didukung Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [Semua wilayah yang didukung Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) kecuali Wilayah AWS GovCloud (AS) dan Wilayah Tiongkok. |
| Dapat menjalankan kontainer di host EC2 khusus Amazon | Ya | Tidak | Tidak |
| Harga | Biaya EC2 instans Amazon yang menjalankan beberapa Pod. Untuk informasi selengkapnya, lihat [ EC2 harga Amazon](https://aws.amazon.com/ec2/pricing/). | Saat Mode Otomatis EKS diaktifkan di klaster, Anda membayar biaya terpisah, selain biaya EC2 instans standar, untuk instans yang diluncurkan menggunakan kemampuan komputasi Mode Otomatis. Jumlahnya bervariasi dengan jenis instans yang diluncurkan dan AWS wilayah tempat klaster Anda berada. Untuk informasi selengkapnya, lihat [harga Amazon EKS](https://aws.amazon.com/eks/pricing/). | Biaya node hybrid vCPU per jam. Untuk informasi selengkapnya, lihat [harga Amazon EKS](https://aws.amazon.com/eks/pricing/). |
# Sederhanakan siklus hidup node dengan grup node terkelola
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
+ 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
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
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
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
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`
**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 <
**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
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
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
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`
**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
**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
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
Strategi upgrade node pekerja terkelola Amazon EKS memiliki empat fase berbeda yang dijelaskan di bagian berikut.
## Fase pengaturan
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
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
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
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
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
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
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
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
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
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 `` 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.
```
Write-Host "Running custom user data script"
```
## Menentukan AMI
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
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
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.
```
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
-Base64ClusterCA certificate-authority `
-APIServerEndpoint api-server-endpoint `
-DNSClusterIP service-cidr.10
```
### Jalankan AMI khusus karena persyaratan keamanan, kepatuhan, atau kebijakan internal tertentu
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
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
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`
**Hapus grup node terkelola dengan `eksctl`**
Masukkan perintah berikut. Ganti setiap `` dengan nilai-nilai Anda sendiri.
```
eksctl delete nodegroup \
--cluster \
--name \
--region
```
Untuk opsi lainnya, lihat [Menghapus dan menguras nodegroup](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) dalam dokumentasi. `eksctl`
## Konsol Manajemen AWS
**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
**Hapus grup node terkelola dengan AWS CLI**
1. Masukkan perintah berikut. Ganti setiap `` dengan nilai-nilai Anda sendiri.
```
aws eks delete-nodegroup \
--cluster-name \
--nodegroup-name \
--region
```
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.
# Pertahankan node sendiri dengan node yang dikelola sendiri
Sebuah klaster berisi satu atau beberapa EC2 node Amazon tempat Pod dijadwalkan. Node Amazon EKS berjalan di AWS akun Anda dan terhubung ke bidang kontrol klaster Anda melalui titik akhir server API cluster. Anda ditagih untuk mereka berdasarkan EC2 harga Amazon. Untuk informasi selengkapnya, lihat [ EC2 harga Amazon](https://aws.amazon.com/ec2/pricing/).
Sebuah klaster dapat berisi beberapa grup simpul. Setiap grup node berisi satu atau beberapa node yang digunakan dalam grup [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html). [Jenis instance node dalam grup dapat bervariasi, seperti saat menggunakan [pemilihan tipe instance berbasis atribut](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) dengan Karpenter.](https://karpenter.sh/) Semua instance dalam grup node harus menggunakan peran [IAM node Amazon EKS](create-node-role.md).
Amazon EKS menyediakan Gambar Mesin Amazon khusus (AMIs) yang disebut Amazon EKS dioptimalkan AMIs. Itu AMIs dikonfigurasi untuk bekerja dengan Amazon EKS. Komponen mereka termasuk`containerd`,`kubelet`, dan AWS IAM Authenticator. Ini AMIs juga berisi [skrip bootstrap](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) khusus yang memungkinkannya menemukan dan terhubung ke bidang kontrol cluster Anda secara otomatis.
Jika Anda membatasi akses ke titik akhir publik klaster Anda menggunakan blok CIDR, sebaiknya Anda juga mengaktifkan akses titik akhir pribadi. Ini agar node dapat berkomunikasi dengan cluster. Jika titik akhir privat diaktifkan, blok CIDR yang Anda tentukan untuk akses publik harus menyertakan sumber jalan keluar dari VPC Anda. Untuk informasi selengkapnya, lihat [Titik akhir server API kluster](cluster-endpoint.md).
Untuk menambahkan simpul-simpul yang dikelola sendiri untuk klaster Amazon EKS Anda, lihat topik-topik berikutnya. Jika Anda meluncurkan node yang dikelola sendiri secara manual, tambahkan tag berikut ke setiap node sambil memastikan bahwa itu `` cocok dengan cluster Anda. Untuk informasi selengkapnya, lihat [Penambahan dan penghapusan tanda pada sumber daya individu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Jika Anda mengikuti langkah-langkah dalam panduan berikut, tag yang diperlukan secara otomatis ditambahkan ke node untuk Anda.
| Kunci | Nilai |
| --- | --- |
| `kubernetes.io/cluster/` | `owned` |
**penting**
Tag di Amazon EC2 Instance Metadata Service (IMDS) tidak kompatibel dengan node EKS. Saat Tag Metadata Instance diaktifkan, penggunaan garis miring maju ('/') dalam nilai tag dicegah. Keterbatasan ini dapat menyebabkan kegagalan peluncuran instance, terutama saat menggunakan alat manajemen node seperti Karpenter atau Cluster Autoscaler, karena layanan ini mengandalkan tag yang berisi garis miring ke depan untuk fungsionalitas yang tepat.
Untuk informasi selengkapnya terkait simpul dari perspektif Kubernetes umum, lihat [Simpul](https://kubernetes.io/docs/concepts/architecture/nodes/) dalam dokumentasi Kubernetes.
**Topics**
+ [Buat node Amazon Linux yang dikelola sendiri](launch-workers.md)
+ [Buat node Bottlerocket yang dikelola sendiri](launch-node-bottlerocket.md)
+ [Buat node Microsoft Windows yang dikelola sendiri](launch-windows-workers.md)
+ [Buat node Linux Ubuntu yang dikelola sendiri](launch-node-ubuntu.md)
+ [Perbarui node yang dikelola sendiri untuk klaster Anda](update-workers.md)
# Buat node Amazon Linux yang dikelola sendiri
Topik ini menjelaskan bagaimana Anda dapat meluncurkan grup Auto Scaling dari node Linux yang mendaftar dengan kluster Amazon EKS Anda. Setelah simpul bergabung dengan klaster, Anda dapat men-deploy aplikasi Kubernetes pada mereka. Anda juga dapat meluncurkan node Amazon Linux yang dikelola sendiri dengan `eksctl` atau. Konsol Manajemen AWS Jika Anda perlu meluncurkan node di AWS Outposts, lihat. [Buat node Amazon Linux di AWS Outposts](eks-outposts-self-managed-nodes.md)
+ Sebuah klaster Amazon EKS yang sudah ada. Untuk menyebarkan satu, lihat[Buat kluster Amazon EKS](create-cluster.md). Jika Anda memiliki subnet di AWS Wilayah tempat Anda mengaktifkan AWS Outposts, AWS Wavelength, atau AWS Local Zones, subnet tersebut tidak boleh diteruskan saat Anda membuat klaster.
+ 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 EC2 node Amazon yang](choosing-instance-type.md) optimal. Bergantung pada jenis instans yang Anda pilih, mungkin ada prasyarat tambahan untuk cluster dan VPC Anda.
Anda dapat meluncurkan node Linux yang dikelola sendiri menggunakan salah satu dari berikut ini:
+ [`eksctl`](#eksctl_create_managed_amazon_linux)
+ [Konsol Manajemen AWS](#console_create_managed_amazon_linux)
## `eksctl`
**Luncurkan node Linux yang dikelola sendiri menggunakan `eksctl`**
1. Instal versi `0.215.0` atau yang lebih baru dari alat baris `eksctl` perintah yang diinstal pada perangkat Anda atau AWS CloudShell. Untuk menginstal atau memperbarui`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. Perintah berikutnya membuat grup simpul dalam klaster yang ada. Ganti *al-nodes* dengan nama untuk 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. Ganti *my-cluster* dengan nama klaster Anda. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil) dan tanda hubung. Itu harus dimulai dengan karakter alfanumerik dan tidak boleh lebih dari 100 karakter. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat klaster. Ganti sisanya *example value* dengan nilai Anda sendiri. Simpul dibuat dengan versi Kubernetes yang sama dengan bidang kendali, secara default.
Sebelum memilih nilai untuk`--node-type`, tinjau [Pilih jenis instans EC2 node Amazon yang optimal](choosing-instance-type.md).
Ganti *my-key* dengan nama Amazon EC2 key pair atau public key Anda. Kunci ini digunakan untuk SSH ke simpul Anda setelah diluncurkan. Jika Anda belum memiliki EC2 key pair Amazon, Anda dapat membuatnya di Konsol Manajemen AWS. Untuk informasi selengkapnya, lihat [pasangan EC2 kunci Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) *di Panduan EC2 Pengguna Amazon*.
Buat grup simpul Anda dengan perintah berikut.
**penting**
Jika Anda ingin menyebarkan grup node ke subnet AWS Outposts, Wavelength, atau Local Zone, ada pertimbangan tambahan:
Subnet tidak boleh diteruskan saat Anda membuat cluster.
Anda harus membuat grup node dengan file konfigurasi yang menentukan subnet dan. ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2` Untuk informasi selengkapnya, lihat [Membuat nodegroup dari file konfigurasi dan skema](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) [file Config](https://eksctl.io/usage/schema/) dalam dokumentasi. `eksctl`
```
eksctl create nodegroup \
--cluster my-cluster \
--name al-nodes \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--ssh-access \
--managed=false \
--ssh-public-key my-key
```
Untuk menyebarkan grup simpul yang:
+ dapat menetapkan jumlah alamat IP yang jauh lebih tinggi ke Pod daripada konfigurasi default, lihat[Tetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan](cni-increase-ip-addresses.md).
+ dapat menetapkan `IPv4` alamat ke Pod dari blok CIDR yang berbeda dari instans, lihat. [Menerapkan Pod di subnet alternatif dengan jaringan khusus](cni-custom-network.md)
+ dapat menetapkan `IPv6` alamat ke Pod dan layanan, lihat[Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md).
+ tidak memiliki akses internet keluar, lihat[Menyebarkan kluster pribadi dengan akses internet terbatas](private-clusters.md).
Untuk daftar lengkap semua opsi dan default yang tersedia, masukkan perintah berikut.
```
eksctl create nodegroup --help
```
Jika node gagal bergabung dengan cluster, maka lihat [Simpul gagal untuk bergabung dengan klaster](troubleshooting.md#worker-node-fail) di chapter Troubleshooting.
Contoh output adalah sebagai berikut. Beberapa baris adalah output sementara node dibuat. Salah satu baris terakhir dari output adalah baris contoh berikutnya.
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (Opsional) Deploy [aplikasi sampel](sample-deployment.md) untuk menguji simpul klaster dan Linux Anda.
1. 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 EC2 instans Amazon (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).
## Konsol Manajemen AWS
**Langkah 1: Luncurkan node Linux yang dikelola sendiri menggunakan Konsol Manajemen AWS **
1. Unduh versi terbaru dari AWS CloudFormation template.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml
```
1. Tunggu status klaster Anda ditampilkan sebagai `ACTIVE`. Jika Anda meluncurkan node Anda sebelum cluster aktif, node gagal mendaftar dengan cluster dan Anda harus meluncurkannya kembali.
1. Buka [konsol AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/).
1. Pilih **Buat tumpukan** dan kemudian pilih **Dengan sumber daya baru (standar)**.
1. Untuk **Menentukan templat**, pilih **Unggah sebuah file templat** dan kemudian pilih **Pilih file**.
1. Pilih `amazon-eks-nodegroup.yaml` file yang Anda unduh.
1. Pilih **Selanjutnya**.
1. Pada halaman **Tentukan detail tumpukan**, masukkan parameter berikut yang sesuai, lalu pilih **Berikutnya**:
+ **Nama tumpukan**: Pilih nama tumpukan untuk AWS CloudFormation tumpukan Anda. Misalnya, Anda bisa menyebutnya*my-cluster-nodes*. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil) dan tanda hubung. Itu harus dimulai dengan karakter alfanumerik dan tidak boleh lebih dari 100 karakter. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat klaster.
+ **ClusterName**: Masukkan nama yang Anda gunakan saat membuat cluster Amazon EKS Anda. Nama ini harus sama dengan nama cluster atau node Anda tidak dapat bergabung dengan cluster.
+ **ClusterControlPlaneSecurityGroup**: Pilih **SecurityGroups**nilai dari AWS CloudFormation output yang Anda hasilkan saat Anda membuat [VPC](creating-a-vpc.md) Anda.
Langkah-langkah berikut menunjukkan satu operasi untuk mengambil grup yang berlaku.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih nama cluster.
1. Pilih tab **Jaringan**.
1. Gunakan nilai **grup keamanan tambahan** sebagai referensi saat memilih dari daftar **ClusterControlPlaneSecurityGroup**tarik-turun.
+ **ApiServerEndpoint**: Masukkan Endpoint API Server untuk EKS Cluster Anda. Ini dapat ditemukan di bagian Detail Konsol Kluster EKS
+ **CertificateAuthorityData**: Masukkan data Otoritas Sertifikat yang dikodekan base64 yang juga dapat ditemukan di bagian Deatils Konsol Kluster EKS.
+ **ServiceCidr**: Masukkan rentang CIDR yang digunakan untuk mengalokasikan alamat IP ke layanan Kubernetes di dalam klaster. Ini ditemukan dalam tab jaringan Konsol Kluster EKS.
+ **AuthenticationMode**: Pilih Mode Otentikasi yang digunakan di Kluster EKS dengan meninjau tab akses dalam Konsol Kluster EKS.
+ **NodeGroupName**: Masukkan nama untuk grup node Anda. Nama ini dapat digunakan nanti untuk mengidentifikasi grup node Auto Scaling yang dibuat untuk 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.
+ **NodeAutoScalingGroupMinSize**: Masukkan jumlah minimum node yang dapat diskalakan oleh grup Auto Scaling node Anda.
+ **NodeAutoScalingGroupDesiredCapacity**: Masukkan jumlah node yang diinginkan untuk diskalakan saat tumpukan Anda dibuat.
+ **NodeAutoScalingGroupMaxSize**: Masukkan jumlah maksimum node yang dapat diskalakan oleh grup Auto Scaling node Anda.
+ **NodeInstanceType**: Pilih jenis instance untuk node Anda. Untuk informasi selengkapnya, lihat [Pilih jenis instans node Amazon EC2 yang optimal](choosing-instance-type.md).
+ **NodeImageIdSSMParam**: Diisi sebelumnya dengan parameter Amazon EC2 Systems Manager dari Amazon EKS baru-baru ini yang mengoptimalkan Amazon Linux 2023 AMI untuk versi Kubernetes variabel. [Untuk menggunakan versi minor Kubernetes berbeda yang didukung dengan Amazon EKS, ganti *1.XX* dengan versi lain yang didukung.](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) Sebaiknya tentukan versi Kubernetes yang sama dengan klaster Anda.
Anda juga dapat mengganti *amazon-linux-2023* dengan tipe AMI yang berbeda. Untuk informasi selengkapnya, lihat [Ambil AMI Amazon Linux yang direkomendasikan IDs](retrieve-ami-id.md).
**catatan**
Node Amazon EKS AMIs didasarkan pada Amazon Linux. Anda dapat melacak peristiwa keamanan atau privasi untuk Amazon Linux 2023 di [Pusat Keamanan Amazon Linux](https://alas.aws.amazon.com/alas2023.html) atau berlangganan umpan [RSS](https://alas.aws.amazon.com/AL2023/alas.rss) terkait. Kejadian keamanan dan privasi mencakup gambaran umum mengenai masalah, paket apa yang terpengaruh, dan cara memperbarui instans Anda untuk memperbaiki masalah tersebut.
+ **NodeImageId**: (Opsional) Jika Anda menggunakan AMI kustom Anda sendiri (bukan AMI yang dioptimalkan Amazon EKS), masukkan ID AMI node untuk AWS Wilayah Anda. Jika Anda menentukan nilai di sini, itu akan mengganti nilai apa pun di bidang. **NodeImageIdSSMParam**
+ **NodeVolumeSize**: Tentukan ukuran volume root untuk node Anda, di GiB.
+ **NodeVolumeType**: Tentukan jenis volume root untuk node Anda.
+ **KeyName**: Masukkan nama key pair Amazon EC2 SSH yang dapat Anda gunakan untuk terhubung menggunakan SSH ke node Anda setelah diluncurkan. Jika Anda belum memiliki EC2 key pair Amazon, Anda dapat membuatnya di Konsol Manajemen AWS. Untuk informasi selengkapnya, lihat [pasangan EC2 kunci Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) *di Panduan EC2 Pengguna Amazon*.
+ **VpcId**: Masukkan ID untuk [VPC](creating-a-vpc.md) yang Anda buat.
+ **Subnet**: Pilih subnet yang sudah Anda buat untuk VPC Anda. Jika Anda membuat VPC menggunakan langkah-langkah yang dijelaskan dalam [Membuat VPC Amazon untuk kluster Amazon EKS Anda](creating-a-vpc.md), tentukan hanya subnet pribadi dalam VPC agar node Anda dapat diluncurkan. Anda dapat melihat subnet mana yang bersifat pribadi dengan membuka setiap subnet link dari tab **Networking** cluster Anda.
**penting**
Jika salah satu subnet adalah subnet publik, maka mereka harus mengaktifkan pengaturan tugas alamat IP publik otomatis. Jika pengaturan tidak diaktifkan untuk subnet publik, maka node apa pun yang Anda terapkan ke subnet publik tersebut tidak akan diberi alamat IP publik dan tidak akan dapat berkomunikasi dengan cluster atau layanan lainnya. AWS Jika subnet digunakan sebelum 26 Maret 2020 menggunakan salah satu [templat AWS CloudFormation VPC Amazon](creating-a-vpc.md) EKS, atau dengan menggunakan`eksctl`, maka penetapan alamat IP publik otomatis dinonaktifkan untuk subnet publik. Untuk informasi tentang cara mengaktifkan penetapan alamat IP publik untuk subnet, lihat [Memodifikasi atribut IPv4 pengalamatan publik](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) untuk subnet Anda. Jika node dikerahkan ke subnet pribadi, maka node dapat berkomunikasi dengan cluster dan AWS layanan lainnya melalui gateway NAT.
Jika subnet tidak memiliki akses internet, pastikan Anda mengetahui pertimbangan dan langkah tambahan dalam [Menyebarkan kluster pribadi dengan](private-clusters.md) akses internet terbatas.
Jika Anda memilih subnet AWS Outposts, Wavelength, atau Local Zone, subnet tidak boleh diteruskan saat Anda membuat cluster.
1. Pilih pilihan yang Anda inginkan di halaman **Configure stack options**, lalu pilih **Next**.
1. Pilih kotak centang di sebelah kiri **Saya mengakui yang AWS CloudFormation mungkin membuat sumber daya IAM**. , dan kemudian pilih **Buat tumpukan**.
1. Setelah tumpukan Anda selesai dibuat, pilih tumpukan di konsol dan pilih **Outputs**. Jika Anda menggunakan Mode `EKS API and ConfigMap` Otentikasi `EKS API` atau, ini adalah langkah terakhir.
1. Jika Anda menggunakan Mode `ConfigMap` Otentikasi, rekam **NodeInstanceRole**untuk grup node yang telah dibuat.
**Langkah 2: Aktifkan node untuk bergabung dengan cluster Anda**
**catatan**
Dua langkah berikut hanya diperlukan jika menggunakan Mode Otentikasi Configmap dalam Kluster EKS. Selain itu, jika Anda meluncurkan node di dalam VPC pribadi tanpa akses internet keluar, pastikan untuk mengaktifkan node untuk bergabung dengan cluster Anda dari dalam VPC.
1. Periksa untuk melihat apakah Anda sudah memiliki `aws-auth``ConfigMap`.
```
kubectl describe configmap -n kube-system aws-auth
```
1. Jika Anda ditampilkan `aws-auth``ConfigMap`, maka perbarui sesuai kebutuhan.
1. Buka `ConfigMap` untuk mengedit.
```
kubectl edit -n kube-system configmap/aws-auth
```
1. Tambahkan `mapRoles` entri baru sesuai kebutuhan. Tetapkan `rolearn` nilai ke **NodeInstanceRole**nilai yang Anda rekam dalam prosedur sebelumnya.
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
[...]
```
1. Simpan file dan keluar dari editor teks Anda.
1. Jika Anda menerima kesalahan yang menyatakan "`Error from server (NotFound): configmaps "aws-auth" not found`, maka terapkan stok`ConfigMap`.
1. Unduh peta konfigurasi.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. Dalam `aws-auth-cm.yaml` file, atur `rolearn` nilai ke **NodeInstanceRole**nilai yang Anda rekam dalam prosedur sebelumnya. Anda dapat melakukan ini dengan editor teks, atau dengan mengganti *my-node-instance-role* dan menjalankan perintah berikut:
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
1. Terapkan konfigurasi. Perintah ini mungkin memerlukan waktu beberapa menit untuk diselesaikan.
```
kubectl apply -f aws-auth-cm.yaml
```
1. Perhatikan status simpul Anda dan tunggu sampai simpul mencapai Status `Ready`.
```
kubectl get nodes --watch
```
Masukkan `Ctrl`\$1`C` untuk kembali ke prompt shell.
**catatan**
Jika Anda menerima kesalahan otorisasi atau jenis sumber daya, lihat [Tidak sah atau akses ditolak (`kubectl`)](troubleshooting.md#unauthorized) di topik pemecahan masalah.
Jika node gagal bergabung dengan cluster, maka lihat [Simpul gagal untuk bergabung dengan klaster](troubleshooting.md#worker-node-fail) di chapter Troubleshooting.
1. (Hanya node GPU) Jika Anda memilih jenis instans GPU dan AMI akselerasi Amazon EKS yang dioptimalkan, 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
```
**Langkah 3: Tindakan tambahan**
1. (Opsional) Deploy [aplikasi sampel](sample-deployment.md) untuk menguji simpul klaster dan Linux Anda.
1. (Opsional) Jika kebijakan IAM terkelola **Amazoneks\$1CNI\$1Policy** (jika Anda memiliki klaster) atau *AmazonEKS\$1CNI\$1IPv6\$1Policy* (yang Anda [buat sendiri](cni-iam-role.md#cni-iam-role-create-ipv6-policy) jika Anda memiliki `IPv4` klaster) dilampirkan ke peran IAM [node Amazon EKS Anda, kami sarankan untuk menetapkannya ke peran IAM](create-node-role.md) yang Anda kaitkan ke akun layanan Kubernetes sebagai gantinya. `IPv6` `aws-node` Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md).
1. 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 EC2 instans Amazon (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).
# Buat node Bottlerocket yang dikelola sendiri
**catatan**
Grup node terkelola mungkin menawarkan beberapa keuntungan untuk kasus penggunaan Anda. Untuk informasi selengkapnya, lihat [Sederhanakan siklus hidup node dengan grup node terkelola](managed-node-groups.md).
Topik ini menjelaskan cara meluncurkan grup Auto Scaling dari node [Bottlerocket](https://aws.amazon.com/bottlerocket/) yang mendaftar dengan cluster Amazon EKS Anda. Bottlerocket adalah sistem operasi open-source berbasis Linux AWS yang dapat Anda gunakan untuk menjalankan kontainer pada mesin virtual atau host bare metal. Setelah simpul bergabung dengan klaster, Anda dapat men-deploy aplikasi Kubernetes pada mereka. [Untuk informasi selengkapnya tentang Bottlerocket, lihat Menggunakan AMI [Bottlerocket dengan Amazon EKS aktif GitHub dan dukungan AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) Kustom dalam dokumentasi.](https://eksctl.io/usage/custom-ami-support/) `eksctl`
Untuk informasi tentang peningkatan di tempat, lihat Operator Pembaruan [Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-update-operator) di. GitHub
**penting**
Simpul Amazon EKS adalah instans Amazon EC2 standar, dan Anda dikenakan biaya berdasarkan harga instans Amazon EC2 normal. Untuk informasi selengkapnya, lihat [Harga Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Anda dapat meluncurkan node Bottlerocket di Amazon EKS cluster yang diperluas di AWS Outposts, tetapi Anda tidak dapat meluncurkannya di cluster lokal di Outposts. AWS Untuk informasi selengkapnya, lihat [Menerapkan Amazon EKS lokal dengan Outposts AWS](eks-outposts.md).
Anda dapat menerapkan ke instans Amazon EC2 `x86` dengan atau prosesor Arm. Namun, Anda tidak dapat menyebarkan ke instance yang memiliki chip Inferentia.
Bottlerocket kompatibel dengan. AWS CloudFormation Namun, tidak ada CloudFormation template resmi yang dapat disalin untuk menyebarkan node Bottlerocket untuk Amazon EKS.
Gambar bottlerocket tidak datang dengan server SSH atau shell. Anda dapat menggunakan metode out-of-band akses untuk memungkinkan SSH mengaktifkan wadah admin dan meneruskan beberapa langkah konfigurasi bootstrap dengan data pengguna. Untuk informasi lebih lanjut, lihat bagian ini di [bottlerocket](https://github.com/bottlerocket-os/bottlerocket) README.md di: GitHub
[Eksplorasi](https://github.com/bottlerocket-os/bottlerocket#exploration)
[Kontainer admin](https://github.com/bottlerocket-os/bottlerocket#admin-container)
[Pengaturan Kubernetes](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings)
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. Catatan: Prosedur ini hanya berfungsi untuk cluster yang dibuat dengan. `eksctl`
1. Salin konten berikut ke perangkat Anda. Ganti *my-cluster* dengan nama klaster Anda. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil) dan tanda hubung. Itu harus dimulai dengan karakter alfanumerik dan tidak boleh lebih dari 100 karakter. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat klaster. Ganti *ng-bottlerocket* dengan nama untuk 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. Untuk menerapkan pada instance Arm, ganti *m5.large* dengan tipe instance Arm. Ganti *my-ec2-keypair-name* dengan nama key pair Amazon EC2 SSH yang dapat Anda gunakan untuk terhubung menggunakan SSH ke node Anda setelah diluncurkan. Jika Anda belum memiliki key pair Amazon EC2, Anda dapat membuatnya di. Konsol Manajemen AWS Untuk informasi selengkapnya, lihat [pasangan kunci Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) di Panduan Pengguna *Amazon EC2*. Ganti semua nilai contoh yang tersisa dengan nilai Anda sendiri. Setelah Anda membuat penggantian, jalankan perintah yang dimodifikasi untuk membuat `bottlerocket.yaml` file.
Jika menentukan jenis instans Arm Amazon EC2, tinjau pertimbangan [di Amazon EKS yang dioptimalkan Arm AMIs Amazon Linux sebelum menerapkan](eks-optimized-ami.md#arm-ami). Untuk petunjuk tentang cara menerapkan menggunakan AMI kustom, lihat [Membangun Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) dan dukungan [AMI GitHub ](https://eksctl.io/usage/custom-ami-support/) Kustom dalam dokumentasi. `eksctl` Untuk menerapkan grup node terkelola, terapkan AMI kustom menggunakan template peluncuran. Untuk informasi selengkapnya, lihat [Sesuaikan node terkelola dengan templat peluncuran](launch-templates.md).
**penting**
Untuk menyebarkan grup node ke subnet AWS Outposts, AWS Wavelength, atau AWS Local Zone, jangan lewatkan subnet AWS Outposts, Wavelength, atau Local Zone saat Anda membuat AWS cluster. AWS Anda harus menentukan subnet dalam contoh berikut. Untuk informasi selengkapnya lihat [Buat nodegroup dari file config](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) dan [Skema file config](https://eksctl.io/usage/schema/) di dalam dokumentasi `eksctl`. Ganti *region-code* dengan AWS Wilayah tempat klaster Anda berada.
```
cat >bottlerocket.yaml <
Topik ini menjelaskan cara meluncurkan grup Auto Scaling dari node Windows yang mendaftar dengan kluster Amazon EKS Anda. Setelah simpul bergabung dengan klaster, Anda dapat men-deploy aplikasi Kubernetes pada mereka.
**penting**
Simpul Amazon EKS adalah instans Amazon EC2 standar, dan Anda dikenakan biaya berdasarkan harga instans Amazon EC2 normal. Untuk informasi selengkapnya, lihat [Harga Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Anda dapat meluncurkan node Windows di Amazon EKS cluster yang diperluas di AWS Outposts, tetapi Anda tidak dapat meluncurkannya di cluster AWS lokal di Outposts. Untuk informasi selengkapnya, lihat [Menerapkan Amazon EKS lokal dengan Outposts AWS](eks-outposts.md).
Aktifkan dukungan Windows untuk cluster Anda. Kami menyarankan Anda meninjau pertimbangan penting sebelum meluncurkan grup node Windows. Untuk informasi selengkapnya, lihat [Aktifkan dukungan Windows](windows-support.md#enable-windows-support).
Anda dapat meluncurkan node Windows yang dikelola sendiri dengan salah satu dari berikut ini:
+ [`eksctl`](#eksctl_create_windows_nodes)
+ [Konsol Manajemen AWS](#console_create_windows_nodes)
## `eksctl`
**Luncurkan node Windows yang dikelola sendiri menggunakan `eksctl`**
Prosedur ini mengharuskan Anda untuk sudah menginstal `eksctl`, dan bahwa `eksctl` versi yang Anda miliki setidaknya `0.215.0`. Anda dapat memeriksa versi Amazon Linux Anda dengan perintah berikut.
```
eksctl version
```
Untuk petunjuk tentang cara menginstal atau meningkatkan`eksctl`, lihat [Instalasi](https://eksctl.io/installation) dalam `eksctl` dokumentasi.
**catatan**
Prosedur ini hanya bekerja untuk klaster yang dibuat dengan `eksctl`.
1. (Opsional) Jika kebijakan IAM terkelola **Amazoneks\$1CNI\$1Policy** (jika Anda memiliki klaster) atau *AmazonEKS\$1CNI\$1IPv6\$1Policy* (yang Anda [buat sendiri](cni-iam-role.md#cni-iam-role-create-ipv6-policy) jika Anda memiliki `IPv4` klaster) dilampirkan ke peran IAM [node Amazon EKS Anda, kami sarankan untuk menetapkannya ke peran IAM](create-node-role.md) yang Anda kaitkan ke akun layanan Kubernetes sebagai gantinya. `IPv6` `aws-node` Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md).
1. Prosedur ini mengasumsikan bahwa Anda memiliki cluster yang ada. Jika Anda belum memiliki kluster Amazon EKS dan grup node Amazon Linux untuk menambahkan grup node Windows, kami sarankan Anda mengikuti[Memulai dengan Amazon EKS - `eksctl`](getting-started-eksctl.md). Panduan ini memberikan panduan lengkap tentang cara membuat cluster Amazon EKS dengan node Amazon Linux.
Buat grup simpul Anda dengan perintah berikut. Ganti *region-code* dengan AWS Wilayah tempat cluster Anda berada. Ganti *my-cluster* dengan nama klaster Anda. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil) dan tanda hubung. Itu harus dimulai dengan karakter alfanumerik dan tidak boleh lebih dari 100 karakter. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat cluster. Ganti *ng-windows* dengan nama untuk 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. Anda dapat mengganti *2019* dengan `2022` menggunakan Windows Server 2022 atau `2025` menggunakan Windows Server 2025. Ganti sisa nilai contoh dengan nilai Anda sendiri.
**penting**
Untuk menyebarkan grup node ke subnet AWS Outposts, AWS Wavelength, atau Local Zone, jangan lewatkan subnet AWS Outposts, Wavelength, AWS atau Local Zone saat Anda membuat cluster. Buat grup node dengan file konfigurasi, tentukan subnet AWS Outposts, Wavelength, atau Local Zone. Untuk informasi selengkapnya, lihat [Membuat nodegroup dari file konfigurasi dan skema](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) [file Config](https://eksctl.io/usage/schema/) dalam dokumentasi. `eksctl`
```
eksctl create nodegroup \
--region region-code \
--cluster my-cluster \
--name ng-windows \
--node-type t2.large \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--managed=false \
--node-ami-family WindowsServer2019FullContainer
```
**catatan**
Jika simpul gagal bergabung dengan klaster, lihat [Simpul gagal untuk bergabung dengan klaster](troubleshooting.md#worker-node-fail) dalam panduan Pemecahan Masalah.
Untuk melihat opsi yang tersedia untuk `eksctl` perintah, masukkan perintah berikut.
```
eksctl command -help
```
Contoh output adalah sebagai berikut. Beberapa baris adalah output sementara node dibuat. Salah satu baris terakhir dari output adalah baris contoh berikutnya.
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (Opsional) Deploy [aplikasi sampel](sample-deployment.md) untuk menguji simpul klaster dan Windows Anda.
1. 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).
## Konsol Manajemen AWS
**Prasyarat**
+ Klaster Amazon EKS yang sudah ada dan grup simpul Linux. Jika Anda tidak memiliki sumber daya ini, kami sarankan Anda membuatnya menggunakan salah satu panduan kami di[Memulai dengan Amazon EKS](getting-started.md). Panduan ini menjelaskan cara membuat cluster Amazon EKS dengan node Linux.
+ Grup VPC dan keamanan yang ada yang memenuhi persyaratan untuk klaster Amazon EKS. Untuk informasi selengkapnya, lihat [Lihat persyaratan jaringan Amazon EKS untuk VPC dan subnet](network-reqs.md) dan [Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md). Panduan dalam [Memulai dengan Amazon EKS](getting-started.md) membuat VPC yang memenuhi persyaratan. Atau, Anda juga dapat mengikuti [Buat VPC Amazon untuk kluster Amazon EKS](creating-a-vpc.md) Anda untuk membuatnya secara manual.
+ Cluster Amazon EKS yang ada yang menggunakan VPC dan grup keamanan yang memenuhi persyaratan kluster Amazon EKS. Untuk informasi selengkapnya, lihat [Buat kluster Amazon EKS](create-cluster.md). Jika Anda memiliki subnet di AWS Wilayah di mana Anda mengaktifkan AWS Outposts, AWS Wavelength, atau AWS Local Zones, subnet tersebut tidak boleh diteruskan saat Anda membuat cluster.
**Langkah 1: Luncurkan node Windows yang dikelola sendiri menggunakan Konsol Manajemen AWS **
1. Tunggu status klaster Anda ditampilkan sebagai `ACTIVE`. Jika Anda meluncurkan node sebelum cluster aktif, node gagal mendaftar dengan cluster dan Anda perlu meluncurkannya kembali.
1. Buka [konsol AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/)
1. Pilih **Buat tumpukan**.
1. Untuk **Tentukan templat**, pilih **Amazon S3 URL**.
1. Salin URL berikut dan tempel ke URL **Amazon S3**.
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml
```
1. Pilih **Berikutnya** dua kali.
1. Pada halaman **Quick create stack**, masukkan parameter berikut yang sesuai:
+ **Nama tumpukan**: Pilih nama tumpukan untuk AWS CloudFormation tumpukan Anda. Misalnya, Anda bisa menyebutnya`my-cluster-nodes`.
+ **ClusterName**: Masukkan nama yang Anda gunakan saat membuat cluster Amazon EKS Anda.
**penting**
Nama ini harus sama persis dengan nama yang Anda gunakan di [Langkah 1: Buat cluster Amazon EKS Anda](getting-started-console.md#eks-create-cluster). Jika tidak, node Anda tidak dapat bergabung dengan cluster.
+ **ClusterControlPlaneSecurityGroup**: Pilih grup keamanan dari AWS CloudFormation output yang Anda hasilkan saat membuat [VPC](creating-a-vpc.md) Anda. Langkah-langkah berikut menunjukkan satu metode untuk mengambil grup yang berlaku.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih nama cluster.
1. Pilih tab **Jaringan**.
1. Gunakan nilai **grup keamanan tambahan** sebagai referensi saat memilih dari daftar **ClusterControlPlaneSecurityGroup**tarik-turun.
+ **NodeGroupName**: Masukkan nama untuk grup node Anda. Nama ini dapat digunakan nanti untuk mengidentifikasi grup node Auto Scaling yang dibuat untuk 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.
+ **NodeAutoScalingGroupMinSize**: Masukkan jumlah minimum node yang dapat diskalakan oleh grup Auto Scaling node Anda.
+ **NodeAutoScalingGroupDesiredCapacity**: Masukkan jumlah node yang diinginkan untuk diskalakan saat tumpukan Anda dibuat.
+ **NodeAutoScalingGroupMaxSize**: Masukkan jumlah maksimum node yang dapat diskalakan oleh grup Auto Scaling node Anda.
+ **NodeInstanceType**: Pilih jenis instance untuk node Anda. Untuk informasi selengkapnya, lihat [Pilih jenis instans node Amazon EC2 yang optimal](choosing-instance-type.md).
**catatan**
[Tipe instans yang didukung untuk versi terbaru [plugin Amazon VPC CNI untuk Kubernetes tercantum di vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s) on.](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) GitHub Anda mungkin perlu memperbarui versi CNI untuk menggunakan jenis instans terbaru yang didukung. Untuk informasi selengkapnya, lihat [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md).
+ **NodeImageIdSSMParam**: Diisi sebelumnya dengan parameter Amazon EC2 Systems Manager dari ID AMI Windows Core Windows Core Amazon EKS yang direkomendasikan saat ini. Untuk menggunakan versi lengkap Windows, ganti *Core* dengan`Full`.
+ **NodeImageId**: (Opsional) Jika Anda menggunakan AMI kustom Anda sendiri (bukan AMI yang dioptimalkan Amazon EKS), masukkan ID AMI node untuk AWS Wilayah Anda. Jika Anda menentukan nilai untuk bidang ini, itu akan menggantikan nilai apa pun di **NodeImageIdSSMParam**bidang.
+ **NodeVolumeSize**: Tentukan ukuran volume root untuk node Anda, di GiB.
+ **KeyName**: Masukkan nama key pair Amazon EC2 SSH yang dapat Anda gunakan untuk terhubung menggunakan SSH ke node Anda setelah diluncurkan. Jika Anda belum memiliki key pair Amazon EC2, Anda dapat membuatnya di. Konsol Manajemen AWS Untuk informasi selengkapnya, lihat [pasangan kunci Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) di Panduan Pengguna *Amazon EC2*.
**catatan**
Jika Anda tidak menyediakan key pair di sini, AWS CloudFormation tumpukan gagal dibuat.
+ **BootstrapArguments**: Tentukan argumen opsional apa pun untuk diteruskan ke skrip bootstrap simpul, seperti `kubelet` argumen tambahan yang digunakan`-KubeletExtraArgs`.
+ **Nonaktifkan IMDSv1**: Secara default, setiap node mendukung Layanan Metadata Instans Versi 1 (IMDSv1) dan. IMDSv2 Anda dapat menonaktifkan IMDSv1. Untuk mencegah penggunaan node dan Pod future dalam grup node MDSv1, setel **Disable IMDSv1** ke **true**. Untuk informasi selengkapnya tentang IMDS, lihat [Mengonfigurasi layanan metadata instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html).
+ **VpcId**: Pilih ID untuk [VPC](creating-a-vpc.md) yang Anda buat.
+ **NodeSecurityGroups**: Pilih grup keamanan yang dibuat untuk grup node Linux Anda saat Anda membuat [VPC](creating-a-vpc.md) Anda. Jika node Linux Anda memiliki lebih dari satu grup keamanan yang melekat padanya, tentukan semuanya. Ini untuk, misalnya, jika grup node Linux dibuat dengan`eksctl`.
+ **Subnet**: Pilih subnet yang Anda buat. Jika Anda membuat VPC menggunakan langkah-langkah dalam [Membuat VPC Amazon untuk kluster Amazon EKS Anda](creating-a-vpc.md), tentukan hanya subnet pribadi dalam VPC untuk node Anda untuk diluncurkan.
**penting**
Jika salah satu subnet adalah subnet publik, maka mereka harus mengaktifkan pengaturan tugas alamat IP publik otomatis. Jika pengaturan tidak diaktifkan untuk subnet publik, maka node apa pun yang Anda terapkan ke subnet publik tersebut tidak akan diberi alamat IP publik dan tidak akan dapat berkomunikasi dengan cluster atau layanan lainnya. AWS Jika subnet digunakan sebelum 26 Maret 2020 menggunakan salah satu [templat AWS CloudFormation VPC Amazon](creating-a-vpc.md) EKS, atau dengan menggunakan`eksctl`, maka penetapan alamat IP publik otomatis dinonaktifkan untuk subnet publik. Untuk informasi tentang cara mengaktifkan penetapan alamat IP publik untuk subnet, lihat [Memodifikasi atribut IPv4 pengalamatan publik](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) untuk subnet Anda. Jika node dikerahkan ke subnet pribadi, maka node dapat berkomunikasi dengan cluster dan AWS layanan lainnya melalui gateway NAT.
Jika subnet tidak memiliki akses internet, pastikan Anda mengetahui pertimbangan dan langkah tambahan dalam [Menyebarkan kluster pribadi dengan](private-clusters.md) akses internet terbatas.
Jika Anda memilih subnet AWS Outposts, Wavelength, atau Local Zone, maka subnet tidak boleh diteruskan saat Anda membuat cluster.
1. Nyatakan bahwa tumpukan dapat membuat sumber daya IAM, kemudian pilih **Buat tumpukan**.
1. Setelah tumpukan Anda selesai dibuat, pilih tumpukan di konsol dan pilih **Outputs**.
1. Rekam **NodeInstanceRole**untuk grup node yang telah dibuat. Anda memerlukan ini saat mengonfigurasi simpul Amazon EKS Windows Anda.
**Langkah 2: Aktifkan node untuk bergabung dengan cluster Anda**
1. Periksa untuk melihat apakah Anda sudah memiliki `aws-auth``ConfigMap`.
```
kubectl describe configmap -n kube-system aws-auth
```
1. Jika Anda ditampilkan `aws-auth``ConfigMap`, maka perbarui sesuai kebutuhan.
1. Buka `ConfigMap` untuk mengedit.
```
kubectl edit -n kube-system configmap/aws-auth
```
1. Tambahkan `mapRoles` entri baru sesuai kebutuhan. Tetapkan `rolearn` nilai ke **NodeInstanceRole**nilai yang Anda rekam dalam prosedur sebelumnya.
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows
[...]
```
1. Simpan file dan keluar dari editor teks Anda.
1. Jika Anda menerima kesalahan yang menyatakan "`Error from server (NotFound): configmaps "aws-auth" not found`, maka terapkan stok`ConfigMap`.
1. Unduh peta konfigurasi.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml
```
1. Dalam `aws-auth-cm-windows.yaml` file, atur `rolearn` nilai ke nilai yang berlaku **NodeInstanceRole**yang Anda rekam dalam prosedur sebelumnya. Anda dapat melakukan ini dengan editor teks, atau dengan mengganti nilai contoh dan menjalankan perintah berikut:
```
sed -i.bak -e 's||my-node-linux-instance-role|' \
-e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml
```
**penting**
Jangan mengubah baris lain dalam file ini.
Jangan gunakan peran IAM yang sama untuk node Windows dan Linux.
1. Terapkan konfigurasi. Perintah ini mungkin memakan waktu beberapa menit untuk menyelesaikannya.
```
kubectl apply -f aws-auth-cm-windows.yaml
```
1. Perhatikan status simpul Anda dan tunggu sampai simpul mencapai Status `Ready`.
```
kubectl get nodes --watch
```
Masukkan `Ctrl`\$1`C` untuk kembali ke prompt shell.
**catatan**
Jika Anda menerima kesalahan otorisasi atau jenis sumber daya, lihat [Tidak sah atau akses ditolak (`kubectl`)](troubleshooting.md#unauthorized) di topik pemecahan masalah.
Jika node gagal bergabung dengan cluster, maka lihat [Simpul gagal untuk bergabung dengan klaster](troubleshooting.md#worker-node-fail) di chapter Troubleshooting.
**Langkah 3: Tindakan tambahan**
1. (Opsional) Deploy [aplikasi sampel](sample-deployment.md) untuk menguji simpul klaster dan Windows Anda.
1. (Opsional) Jika kebijakan IAM terkelola **Amazoneks\$1CNI\$1Policy** (jika Anda memiliki klaster) atau *AmazonEKS\$1CNI\$1IPv6\$1Policy* (yang Anda [buat sendiri](cni-iam-role.md#cni-iam-role-create-ipv6-policy) jika Anda memiliki `IPv4` klaster) dilampirkan ke peran IAM [node Amazon EKS Anda, kami sarankan untuk menetapkannya ke peran IAM](create-node-role.md) yang Anda kaitkan ke akun layanan Kubernetes sebagai gantinya. `IPv6` `aws-node` Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md).
1. 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).
# Buat node Linux Ubuntu yang dikelola sendiri
**catatan**
Grup node terkelola mungkin menawarkan beberapa keuntungan untuk kasus penggunaan Anda. Untuk informasi selengkapnya, lihat [Sederhanakan siklus hidup node dengan grup node terkelola](managed-node-groups.md).
Topik ini menjelaskan cara meluncurkan grup Auto Scaling [Ubuntu di Amazon Elastic Kubernetes Service (EKS) atau Ubuntu Pro di node Amazon Elastic Kubernetes Service](https://cloud-images.ubuntu.com/aws-eks/) [(EKS) yang mendaftar dengan cluster Amazon EKS](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) Anda. Ubuntu dan Ubuntu Pro untuk EKS didasarkan pada Ubuntu Minimal LTS resmi, termasuk AWS kernel khusus yang dikembangkan bersama AWS, dan telah dibangun khusus untuk EKS. Ubuntu Pro menambahkan cakupan keamanan tambahan dengan mendukung periode dukungan EKS yang diperpanjang, livepatch kernel, kepatuhan FIPS, dan kemampuan untuk menjalankan kontainer Pro tanpa batas.
Setelah node bergabung dengan cluster, Anda dapat menyebarkan aplikasi kontainer ke mereka. Untuk informasi selengkapnya, kunjungi dokumentasi untuk [Ubuntu on AWS](https://documentation.ubuntu.com/aws/en/latest/) dan [dukungan Custom AMI](https://eksctl.io/usage/custom-ami-support/) dalam `eksctl` dokumentasi.
**penting**
Simpul Amazon EKS adalah instans Amazon EC2 standar, dan Anda dikenakan biaya berdasarkan harga instans Amazon EC2 normal. Untuk informasi selengkapnya, lihat [Harga Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Anda dapat meluncurkan node Ubuntu di Amazon EKS cluster yang diperluas di AWS Outposts, tetapi Anda tidak dapat meluncurkannya di cluster AWS lokal di Outposts. Untuk informasi selengkapnya, lihat [Menerapkan Amazon EKS lokal dengan Outposts AWS](eks-outposts.md).
Anda dapat menerapkan ke instans Amazon EC2 `x86` dengan atau prosesor Arm. Namun, contoh yang memiliki chip Inferentia mungkin perlu menginstal [Neuron SDK](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/) terlebih dahulu.
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. Catatan: Prosedur ini hanya berfungsi untuk cluster yang dibuat dengan. `eksctl`
1. Salin konten berikut ke perangkat Anda. Ganti `my-cluster` dengan nama klaster Anda. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil) dan tanda hubung. Itu harus dimulai dengan karakter alfabet dan tidak boleh lebih dari 100 karakter. Ganti `ng-ubuntu` dengan nama untuk 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. Untuk menerapkan pada instance Arm, ganti `m5.large` dengan tipe instance Arm. Ganti `my-ec2-keypair-name` dengan nama key pair Amazon EC2 SSH yang dapat Anda gunakan untuk terhubung menggunakan SSH ke node Anda setelah diluncurkan. Jika Anda belum memiliki key pair Amazon EC2, Anda dapat membuatnya di. Konsol Manajemen AWS Untuk informasi selengkapnya, lihat [pasangan kunci Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) di Panduan Pengguna Amazon EC2. Ganti semua nilai contoh yang tersisa dengan nilai Anda sendiri. Setelah Anda membuat penggantian, jalankan perintah yang dimodifikasi untuk membuat `ubuntu.yaml` file.
**penting**
Untuk menyebarkan grup node ke subnet AWS Outposts, AWS Wavelength, atau AWS Local Zone, jangan lewatkan subnet AWS Outposts, Wavelength, atau Local Zone saat Anda membuat AWS cluster. AWS Anda harus menentukan subnet dalam contoh berikut. Untuk informasi selengkapnya lihat [Buat nodegroup dari file config](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) dan [Skema file config](https://eksctl.io/usage/schema/) di dalam dokumentasi `eksctl`. Ganti *region-code* dengan AWS Wilayah tempat klaster Anda berada.
```
cat >ubuntu.yaml <
Saat AMI Amazon EKS baru yang dioptimalkan dirilis, pertimbangkan untuk mengganti node di grup node yang dikelola sendiri dengan AMI baru. Demikian juga, jika Anda telah memperbarui versi Kubernetes untuk cluster Amazon EKS Anda, perbarui node untuk menggunakan node dengan versi Kubernetes yang sama.
**penting**
Topik ini mencakup pembaruan simpul untuk simpul yang dikelola sendiri. Jika Anda menggunakan [grup node terkelola](managed-node-groups.md), lihat[Memperbarui grup node terkelola untuk klaster Anda](update-managed-node-group.md).
Ada dua cara dasar untuk memperbarui grup simpul yang dikelola sendiri di klaster Anda untuk menggunakan AMI baru:
**[Migrasikan aplikasi ke grup node baru](migrate-stack.md)**
Buat grup node baru dan migrasi Pod Anda ke grup tersebut. Migrasi ke grup node baru lebih anggun daripada sekadar memperbarui ID AMI di tumpukan yang ada AWS CloudFormation . Ini karena proses migrasi [menodai](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) grup node lama `NoSchedule` dan menguras node setelah tumpukan baru siap menerima beban kerja Pod yang ada.
**[Perbarui tumpukan AWS CloudFormation simpul](update-stack.md)**
Perbarui AWS CloudFormation tumpukan untuk grup node yang ada untuk menggunakan AMI baru. Metode ini tidak didukung untuk grup node yang dibuat dengan`eksctl`.
# Migrasikan aplikasi ke grup node baru
Topik ini menjelaskan bagaimana Anda dapat membuat grup node baru, dengan anggun memigrasikan aplikasi yang ada ke grup baru, dan menghapus grup node lama dari cluster Anda. Anda dapat bermigrasi ke grup simpul baru menggunakan `eksctl` atau Konsol Manajemen AWS.
+ [`eksctl`](#eksctl_migrate_apps)
+ [Konsol Manajemen AWS dan AWS CLI](#console_migrate_apps)
## `eksctl`
**Migrasikan aplikasi Anda ke grup node baru dengan `eksctl`**
Untuk informasi selengkapnya tentang penggunaan eksctl untuk migrasi, lihat [Nodegroup tidak dikelola](https://eksctl.io/usage/nodegroup-unmanaged/) dalam dokumentasi. `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.
**catatan**
Prosedur ini hanya bekerja untuk grup klaster dan simpul yang dibuat dengan `eksctl`.
1. Ambil nama grup node yang ada, ganti *my-cluster* dengan nama cluster Anda.
```
eksctl get nodegroups --cluster=my-cluster
```
Contoh output adalah sebagai berikut.
```
CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID
default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12
```
1. Luncurkan grup node baru `eksctl` dengan perintah berikut. Dalam perintah, ganti setiap *example value* dengan nilai Anda sendiri. Nomor versi tidak boleh lebih lambat dari versi Kubernetes untuk pesawat kontrol Anda. Selain itu, tidak boleh lebih dari dua versi minor lebih awal dari versi Kubernetes untuk pesawat kontrol Anda. Kami menyarankan Anda menggunakan versi yang sama dengan pesawat kontrol Anda.
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).
Untuk memblokir akses Pod ke IMDS, tambahkan `--disable-pod-imds` opsi ke perintah berikut.
**catatan**
Untuk lebih banyak flag yang tersedia dan deskripsinya, lihat https://eksctl.io/.
```
eksctl create nodegroup \
--cluster my-cluster \
--version 1.35 \
--name standard-nodes-new \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--managed=false
```
1. Setelah perintah sebelumnya selesai, verifikasi bahwa semua simpul Anda telah mencapai status `Ready` dengan perintah berikut:
```
kubectl get nodes
```
1. Hapus grup node asli dengan perintah berikut. Dalam perintah, ganti setiap *example value* dengan nama grup cluster dan node Anda:
```
eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old
```
## Konsol Manajemen AWS dan AWS CLI
**Migrasikan aplikasi Anda ke grup node baru dengan Konsol Manajemen AWS dan CLI AWS **
1. Luncurkan grup node baru dengan mengikuti langkah-langkah yang diuraikan dalam [Buat node Amazon Linux yang dikelola sendiri](launch-workers.md).
1. Setelah tumpukan Anda selesai dibuat, pilih tumpukan di konsol dan pilih **Outputs**.
1. Rekam **NodeInstanceRole**untuk grup node yang telah dibuat. Anda memerlukan ini untuk menambahkan simpul Amazon EKS baru ke klaster Anda.
**catatan**
Jika Anda melampirkan kebijakan IAM tambahan ke peran IAM grup node lama Anda, lampirkan kebijakan yang sama tersebut ke peran IAM grup node baru Anda untuk mempertahankan fungsionalitas tersebut pada grup baru. Ini berlaku bagi Anda jika Anda menambahkan izin untuk [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), misalnya.
1. Perbarui grup keamanan untuk kedua grup simpul sehingga mereka dapat berkomunikasi satu sama lain. Untuk informasi selengkapnya, lihat [Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md).
1. Rekam grup keamanan IDs untuk kedua grup node. Ini ditampilkan sebagai **NodeSecurityGroup**nilai dalam output AWS CloudFormation stack.
Anda dapat menggunakan perintah AWS CLI berikut untuk mendapatkan grup keamanan IDs dari nama tumpukan. Dalam perintah ini, `oldNodes` adalah nama AWS CloudFormation tumpukan untuk tumpukan node lama Anda, dan `newNodes` merupakan nama tumpukan tempat Anda bermigrasi. Ganti setiap *example value* dengan nilai-nilai Anda sendiri.
```
oldNodes="old_node_CFN_stack_name"
newNodes="new_node_CFN_stack_name"
oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
```
1. Tambahkan aturan masuk ke setiap grup keamanan simpul sehingga mereka menerima lalu lintas dari satu sama lain.
Perintah AWS CLI berikut menambahkan aturan masuk ke setiap grup keamanan yang memungkinkan semua lalu lintas pada semua protokol dari grup keamanan lainnya. Konfigurasi ini memungkinkan Pod di setiap grup node untuk berkomunikasi satu sama lain saat Anda memigrasikan beban kerja Anda ke grup baru.
```
aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \
--source-group $newSecGroup --protocol -1
aws ec2 authorize-security-group-ingress --group-id $newSecGroup \
--source-group $oldSecGroup --protocol -1
```
1. Edit configmap `aws-auth` untuk memetakan peran instans simpul baru di RBAC.
```
kubectl edit configmap -n kube-system aws-auth
```
Tambahkan entri `mapRoles` baru untuk grup simpul baru.
```
apiVersion: v1
data:
mapRoles: |
- rolearn: ARN of instance role (not instance profile)
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes>
- rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
```
Ganti *ARN of instance role (not instance profile)* cuplikan dengan **NodeInstanceRole**nilai yang Anda rekam pada langkah [sebelumnya](#node-instance-role-step). Kemudian, simpan dan tutup file untuk menerapkan configmap yang diperbarui.
1. Perhatikan status simpul Anda dan tunggu simpul baru Anda bergabung dengan klaster dan mencapai status `Ready` tersebut.
```
kubectl get nodes --watch
```
1. (Opsional) Jika Anda menggunakan [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), turunkan skala deployment ke nol (0) replika untuk menghindari tindakan penskalaan yang bertentangan.
```
kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
```
1. Gunakan perintah berikut untuk mencemari setiap node yang ingin Anda hapus. `NoSchedule` Hal ini agar Pod baru tidak dijadwalkan atau dijadwal ulang pada node yang Anda ganti. Untuk informasi selengkapnya, lihat [Taints and Tolerations dalam dokumentasi](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) Kubernetes.
```
kubectl taint nodes node_name key=value:NoSchedule
```
Jika Anda memutakhirkan node Anda ke versi Kubernetes baru, Anda dapat mengidentifikasi dan mencemari semua node dari versi Kubernetes tertentu (dalam hal ini,) dengan cuplikan kode berikut. `1.33` Nomor versi tidak boleh lebih lambat dari versi Kubernetes dari pesawat kontrol Anda. Ini juga tidak boleh lebih dari dua versi minor lebih awal dari versi Kubernetes dari pesawat kontrol Anda. Kami menyarankan Anda menggunakan versi yang sama dengan pesawat kontrol Anda.
```
K8S_VERSION=1.33
nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
for node in ${nodes[@]}
do
echo "Tainting $node"
kubectl taint nodes $node key=value:NoSchedule
done
```
1. Tentukan penyedia DNS cluster Anda.
```
kubectl get deployments -l k8s-app=kube-dns -n kube-system
```
Contoh output adalah sebagai berikut. Cluster ini menggunakan CoreDNS untuk resolusi DNS, tetapi klaster Anda dapat kembali sebagai gantinya): `kube-dns`
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
coredns 1 1 1 1 31m
```
1. Jika deployment Anda saat ini berjalan kurang dari dua replika, skalakan deployment menjadi dua replika. Ganti *coredns* dengan `kubedns` jika output perintah Anda sebelumnya mengembalikannya.
```
kubectl scale deployments/coredns --replicas=2 -n kube-system
```
1. Keluarkan setiap simpul yang Anda ingin hapus dari klaster Anda dengan perintah berikut:
```
kubectl drain node_name --ignore-daemonsets --delete-local-data
```
Jika Anda memutakhirkan node Anda ke versi Kubernetes baru, identifikasi dan tiriskan semua node dari versi Kubernetes tertentu (dalam hal ini,*1.33*) dengan cuplikan kode berikut.
```
K8S_VERSION=1.33
nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
for node in ${nodes[@]}
do
echo "Draining $node"
kubectl drain $node --ignore-daemonsets --delete-local-data
done
```
1. Setelah node lama Anda selesai menguras, cabut aturan masuk grup keamanan yang Anda otorisasi sebelumnya. Kemudian, hapus AWS CloudFormation tumpukan untuk mengakhiri instance.
**catatan**
Jika Anda melampirkan kebijakan IAM tambahan apa pun ke peran IAM grup node lama Anda, seperti menambahkan izin untuk [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), lepaskan kebijakan tambahan tersebut dari peran tersebut sebelum Anda dapat menghapus tumpukan Anda. AWS CloudFormation
1. Cabut aturan masuk yang Anda buat untuk grup keamanan node Anda sebelumnya. Dalam perintah ini, `oldNodes` adalah nama AWS CloudFormation tumpukan untuk tumpukan node lama Anda, dan `newNodes` merupakan nama tumpukan tempat Anda bermigrasi.
```
oldNodes="old_node_CFN_stack_name"
newNodes="new_node_CFN_stack_name"
oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \
--source-group $newSecGroup --protocol -1
aws ec2 revoke-security-group-ingress --group-id $newSecGroup \
--source-group $oldSecGroup --protocol -1
```
1. Buka [konsol AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/).
1. Pilih tumpukan simpul lama Anda.
1. Pilih **Hapus**.
1. Di kotak dialog **Hapus tumpukan** konfirmasi, pilih **Hapus tumpukan**.
1. Edit `aws-auth` configmap untuk menghapus peran instans simpul lama dari RBAC.
```
kubectl edit configmap -n kube-system aws-auth
```
Hapus `mapRoles` entri untuk grup simpul lama.
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- rolearn: arn:aws: iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes>
```
Simpan dan tutup file untuk menerapkan configmap yang diperbarui.
1. (Opsional) Jika Anda menggunakan [Autoscaler Klaster](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) Kubernetes, skalakan kembali deployment ke satu replika.
**catatan**
Anda juga harus menandai grup Auto Scaling baru Anda dengan tepat (misalnya,`k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`) dan memperbarui perintah untuk penerapan Cluster Autoscaler Anda untuk menunjuk ke grup Auto Scaling yang baru ditandai. Untuk informasi selengkapnya, lihat [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws) di. AWS
```
kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
```
1. (Opsional) Verifikasi bahwa Anda menggunakan versi terbaru dari [plugin Amazon VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) untuk Kubernetes. Anda mungkin perlu memperbarui versi CNI untuk menggunakan jenis instans terbaru yang didukung. Untuk informasi selengkapnya, lihat [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md).
1. Jika klaster Anda menggunakan `kube-dns` resolusi DNS (lihat[[migrate-determine-dns-step]](#migrate-determine-dns-step)), skalakan `kube-dns` penerapan ke satu replika.
```
kubectl scale deployments/kube-dns --replicas=1 -n kube-system
```
# Perbarui tumpukan AWS CloudFormation simpul
Topik ini menjelaskan bagaimana Anda dapat memperbarui tumpukan node yang AWS CloudFormation dikelola sendiri dengan AMI baru. Anda dapat menggunakan prosedur ini untuk memperbarui node Anda ke versi baru Kubernetes setelah pembaruan klaster. Jika tidak, Anda dapat memperbarui ke AMI Amazon EKS terbaru yang dioptimalkan untuk versi Kubernetes yang ada.
**penting**
Topik ini mencakup pembaruan simpul untuk simpul yang dikelola sendiri. Untuk informasi tentang penggunaan [Simplify node lifecycle dengan grup node terkelola](managed-node-groups.md), lihat. [Memperbarui grup node terkelola untuk klaster Anda](update-managed-node-group.md)
AWS CloudFormation Template node Amazon EKS default terbaru dikonfigurasi untuk meluncurkan instance dengan AMI baru ke dalam klaster Anda sebelum menghapus yang lama, satu per satu. Konfigurasi ini memastikan bahwa Anda selalu memiliki jumlah instans aktif yang diinginkan grup Auto Scaling di klaster selama pembaruan bergulir.
**catatan**
Metode ini tidak didukung untuk grup simpul yang dibuat dengan`eksctl`. Jika Anda membuat grup klaster atau simpul dengan `eksctl`, lihat [Migrasikan aplikasi ke grup node baru](migrate-stack.md).
1. Tentukan penyedia DNS untuk klaster Anda.
```
kubectl get deployments -l k8s-app=kube-dns -n kube-system
```
Contoh output adalah sebagai berikut. Cluster ini menggunakan CoreDNS untuk resolusi DNS, tetapi klaster Anda mungkin kembali. `kube-dns` Output Anda mungkin terlihat berbeda tergantung pada versi `kubectl` yang Anda gunakan.
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
coredns 1 1 1 1 31m
```
1. Jika deployment Anda saat ini berjalan kurang dari dua replika, skalakan deployment menjadi dua replika. Ganti *coredns* dengan `kube-dns` jika output perintah Anda sebelumnya mengembalikannya.
```
kubectl scale deployments/coredns --replicas=2 -n kube-system
```
1. (Opsional) Jika Anda menggunakan Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), turunkan skala deployment ke nol (0) replika untuk menghindari tindakan penskalaan yang bertentangan.
```
kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
```
1. Tentukan jenis instance dan jumlah instans yang diinginkan dari grup node Anda saat ini. Anda memasukkan nilai-nilai ini nanti ketika Anda memperbarui AWS CloudFormation template untuk grup.
1. Buka konsol Amazon EC2 di. https://console.aws.amazon.com/ec2/
1. Di panel navigasi kiri, pilih **Luncurkan Konfigurasi**, dan catat jenis instans untuk konfigurasi peluncuran node yang ada.
1. **Di panel navigasi kiri, pilih Grup **Auto Scaling**, dan catat jumlah instans yang diinginkan untuk grup Auto Scaling node yang ada.**
1. Buka [konsol AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/).
1. Pilih tumpukan grup simpul Anda, dan kemudian pilih **Perbarui**.
1. Pilih **Ganti template saat ini** dan pilih **URL Amazon S3**.
1. Untuk **URL Amazon S3**, rekatkan URL berikut ke area teks untuk memastikan bahwa Anda menggunakan template node AWS CloudFormation versi terbaru. Kemudian, pilih **Berikutnya**:
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml
```
1. Pada halaman **Menentukan detail tumpukan**, isilah parameter berikut dan pilih **Selanjutnya**:
+ **NodeAutoScalingGroupDesiredCapacity**— Masukkan jumlah instans yang diinginkan yang Anda rekam pada [langkah sebelumnya](#existing-worker-settings-step). Atau, masukkan jumlah node baru yang Anda inginkan untuk diskalakan saat tumpukan Anda diperbarui.
+ **NodeAutoScalingGroupMaxSize**— Masukkan jumlah maksimum node yang dapat diskalakan oleh grup Auto Scaling node Anda. Nilai ini harus setidaknya satu node lebih dari kapasitas yang Anda inginkan. Ini agar Anda dapat melakukan pembaruan bergulir dari node Anda tanpa mengurangi jumlah node Anda selama pembaruan.
+ **NodeInstanceType**— Pilih jenis instans yang Anda rekam di [langkah sebelumnya](#existing-worker-settings-step). Atau, pilih jenis instance yang berbeda untuk node Anda. Sebelum memilih jenis instans yang berbeda, tinjau [Pilih jenis instans node Amazon EC2 yang optimal](choosing-instance-type.md). Setiap jenis instans Amazon EC2 mendukung jumlah maksimum antarmuka jaringan elastis (antarmuka jaringan) dan setiap antarmuka jaringan mendukung jumlah maksimum alamat IP. Karena setiap node pekerja dan Pod, diberi alamat IP sendiri, penting untuk memilih jenis instance yang akan mendukung jumlah maksimum Pod yang ingin Anda jalankan di setiap node Amazon EC2. Untuk daftar jumlah antarmuka jaringan dan alamat IP yang didukung oleh jenis instans, lihat [alamat IP per antarmuka jaringan per jenis instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Misalnya, tipe `m5.large` instans mendukung maksimal 30 alamat IP untuk node pekerja dan Pod.
**catatan**
[Tipe instans yang didukung untuk versi terbaru [plugin Amazon VPC CNI untuk Kubernetes ditampilkan di vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s) on.](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) GitHub Anda mungkin perlu memperbarui plugin Amazon VPC CNI untuk versi Kubernetes untuk menggunakan jenis instans terbaru yang didukung. Untuk informasi selengkapnya, lihat [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md).
**penting**
Beberapa jenis instance mungkin tidak tersedia di semua AWS Wilayah.
+ **NodeImageIdSSMParam**— Parameter Amazon EC2 Systems Manager dari ID AMI yang ingin Anda perbarui. Nilai berikut menggunakan AMI Amazon EKS terbaru yang dioptimalkan untuk versi Kubernetes. `1.35`
```
/aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id
```
Anda dapat mengganti *1.35* dengan [versi platform yang](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) sama. Atau, itu harus hingga satu versi lebih awal dari versi Kubernetes yang berjalan di bidang kontrol Anda. Kami rekomendasikan supaya Anda menyimpan simpul pada versi yang sama dengan bidang kendali Anda. Anda juga dapat mengganti *amazon-linux-2* dengan tipe AMI yang berbeda. Untuk informasi selengkapnya, lihat [Ambil AMI Amazon Linux yang direkomendasikan IDs](retrieve-ami-id.md).
**catatan**
Menggunakan parameter Amazon EC2 Systems Manager memungkinkan Anda memperbarui node di masa mendatang tanpa harus mencari dan menentukan ID AMI. Jika AWS CloudFormation tumpukan Anda menggunakan nilai ini, setiap pembaruan tumpukan selalu meluncurkan AMI terbaru yang dioptimalkan Amazon EKS yang dioptimalkan untuk versi Kubernetes yang Anda tentukan. Ini bahkan terjadi bahkan jika Anda tidak mengubah nilai apa pun di template.
+ **NodeImageId**— Untuk menggunakan AMI kustom Anda sendiri, masukkan ID untuk AMI yang akan digunakan.
**penting**
Nilai ini mengesampingkan nilai apa pun yang ditentukan untuk. **NodeImageIdSSMParam** Jika Anda ingin menggunakan **NodeImageIdSSMParam**nilainya, pastikan nilainya kosong. **NodeImageId**
+ **Nonaktifkan IMDSv1** — Secara default, setiap node mendukung Layanan Metadata Instans Versi 1 (IMDSv1) dan. IMDSv2 Namun, Anda dapat menonaktifkan IMDSv1. Pilih **true** jika Anda tidak ingin node atau Pod apa pun yang dijadwalkan dalam grup node untuk digunakan IMDSv1. Untuk informasi selengkapnya tentang IMDS, lihat [Mengonfigurasi layanan metadata instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Jika Anda telah menerapkan peran IAM untuk akun layanan, tetapkan izin yang diperlukan secara langsung ke semua Pod yang memerlukan akses ke layanan. AWS Dengan cara ini, tidak ada Pod di klaster Anda yang memerlukan akses ke IMDS karena alasan lain, seperti mengambil Region saat ini AWS . Kemudian, Anda juga dapat menonaktifkan akses ke IMDSv2 Pod yang tidak menggunakan jaringan host. 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).
1. (Opsional) Di halaman **Opsi**, tandai sumber daya tumpukan Anda. Pilih **Berikutnya**.
1. Pada halaman **Tinjauan**, tinjau informasi Anda, nyatakan bahwa tumpukan dapat membuat sumber daya IAM, kemudian pilih **Perbarui tumpukan**.
**catatan**
Pembaruan setiap simpul dalam klaster membutuhkan waktu beberapa menit. Tunggu pembaruan semua simpul selesai sebelum melakukan langkah berikutnya.
1. Jika penyedia DNS klaster Anda`kube-dns`, skalakan `kube-dns` penerapan ke satu replika.
```
kubectl scale deployments/kube-dns --replicas=1 -n kube-system
```
1. (Opsional) Jika Anda menggunakan [Autoscaler Klaster](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) Kubernetes, skalakan kembali deployment ke jumlah replika yang Anda inginkan.
```
kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
```
1. (Opsional) Verifikasi bahwa Anda menggunakan versi terbaru dari [plugin Amazon VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) untuk Kubernetes. Anda mungkin perlu memperbarui plugin Amazon VPC CNI untuk versi Kubernetes untuk menggunakan jenis instans terbaru yang didukung. Lihat informasi yang lebih lengkap di [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md).
# Sederhanakan manajemen komputasi dengan Fargate AWS
Topik ini membahas penggunaan Amazon EKS untuk menjalankan Kubernetes Pods di Fargate. AWS [Fargate adalah teknologi yang menyediakan kapasitas komputasi sesuai permintaan dan berukuran tepat untuk kontainer.](https://aws.amazon.com/what-are-containers) Dengan Fargate, Anda tidak perlu menyediakan, mengonfigurasi, atau menskalakan grup mesin virtual sendiri untuk menjalankan kontainer. Anda juga tidak perlu memilih jenis server, memutuskan kapan harus menskalakan grup node Anda, atau mengoptimalkan pengemasan cluster.
[Anda dapat mengontrol Pod mana yang dimulai di Fargate dan bagaimana mereka berjalan dengan profil Fargate.](fargate-profile.md) Profil Fargate didefinisikan sebagai bagian dari cluster Amazon EKS Anda. Amazon EKS mengintegrasikan Kubernetes dengan Fargate dengan menggunakan kontroler yang dibangun menggunakan model upstream yang dapat diperluas yang disediakan AWS oleh Kubernetes. Pengontrol ini berjalan sebagai bagian dari bidang kontrol Kubernetes yang dikelola Amazon EKS dan bertanggung jawab untuk menjadwalkan Pod Kubernetes asli ke Fargate. Pengendali Fargate termasuk penjadwal baru yang berjalan dengan penjadwal Kubernetes default selain beberapa pengendali masuk urusan mutasi dan validasi. Ketika Anda memulai sebuah Pod yang memenuhi kriteria untuk berjalan di Fargate, pengendali Fargate yang berjalan di klaster mengenali, memperbarui, dan menjadwalkan Pod ke Fargate.
Topik ini menjelaskan berbagai komponen Pod yang berjalan di Fargate, dan memunculkan pertimbangan khusus untuk menggunakan Fargate dengan Amazon EKS.
## AWS Pertimbangan Fargate
Berikut adalah beberapa hal yang perlu dipertimbangkan tentang menggunakan Fargate di Amazon EKS.
+ Setiap Pod yang berjalan di Fargate memiliki batas komputasinya sendiri. Mereka tidak berbagi kernel yang mendasarinya, sumber daya CPU, sumber daya memori, atau elastic network interface dengan Pod lain.
+ Network Load Balancers dan Application Load Balancers (ALBs) dapat digunakan dengan Fargate dengan target IP saja. Untuk informasi selengkapnya, lihat [Buat penyeimbang beban jaringan](network-load-balancing.md#network-load-balancer) dan [Rute aplikasi dan lalu lintas HTTP dengan Application Load Balancers](alb-ingress.md).
+ Layanan terbuka Fargate hanya berjalan pada mode IP tipe target, dan bukan pada mode IP node. Cara yang disarankan untuk memeriksa konektivitas dari layanan yang berjalan pada node terkelola dan layanan yang berjalan di Fargate adalah dengan menghubungkan melalui nama layanan.
+ Pod harus cocok dengan profil Fargate pada saat mereka dijadwalkan untuk berjalan di Fargate. Pod yang tidak cocok dengan profil Fargate mungkin macet sebagai. `Pending` Jika ada profil Fargate yang cocok, Anda dapat menghapus Pod yang tertunda yang telah Anda buat untuk menjadwalkannya kembali ke Fargate.
+ Daemonset tidak didukung di Fargate. Jika aplikasi Anda memerlukan daemon, konfigurasikan ulang daemon tersebut untuk dijalankan sebagai wadah sespan di Pod Anda.
+ Kontainer istimewa tidak didukung di Fargate.
+ Pod yang berjalan di Fargate tidak dapat menentukan `HostPort` atau `HostNetwork` dalam manifes Pod.
+ Default `nofile` dan `nproc` soft limit adalah 1024 dan hard limit adalah 65535 untuk Fargate Pods.
+ GPUs saat ini tidak tersedia di Fargate.
+ Pod yang berjalan di Fargate hanya didukung pada subnet pribadi (dengan akses gateway NAT ke AWS layanan, tetapi bukan rute langsung ke Internet Gateway), jadi VPC klaster Anda harus memiliki subnet pribadi yang tersedia. Untuk klaster tanpa akses internet luar, lihat [Menyebarkan kluster pribadi dengan akses internet terbatas](private-clusters.md).
+ Anda dapat menggunakan [sumber daya Adjust pod dengan Vertical Pod Autoscaler](vertical-pod-autoscaler.md) untuk mengatur ukuran CPU dan memori awal yang benar untuk Pod Fargate Anda, dan kemudian menggunakan [penerapan pod Scale dengan Horizontal Pod Autoscaler untuk menskalakan Pod](horizontal-pod-autoscaler.md) tersebut. Jika Anda ingin Vertical Pod Autoscaler untuk secara otomatis men-deploy ulang Pod ke Fargate dengan kombinasi CPU dan memori yang lebih besar, atur mode untuk Vertical Pod Autoscaler ke salah satu atau untuk memastikan fungsionalitas yang benar. `Auto` `Recreate` Untuk informasi selengkapnya, lihat dokumentasi [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) pada. GitHub
+ Resolusi DNS dan nama host DNS harus diaktifkan untuk VPC Anda. Untuk informasi selengkapnya, lihat [Melihat dan memperbarui dukungan DNS untuk VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
+ Amazon EKS Fargate menambahkan aplikasi defense-in-depth Kubernetes dengan mengisolasi setiap Pod dalam Virtual Machine (VM). Batas VM ini mencegah akses ke sumber daya berbasis host yang digunakan oleh Pod lain jika terjadi pelarian kontainer, yang merupakan metode umum untuk menyerang aplikasi kontainer dan mendapatkan akses ke sumber daya di luar container.
Menggunakan Amazon EKS tidak mengubah tanggung jawab Anda berdasarkan [model tanggung jawab bersama](security.md). Anda harus hati-hati mempertimbangkan konfigurasi keamanan klaster dan kontrol tata kelola. Cara teraman untuk mengisolasi aplikasi adalah selalu menjalankannya di cluster terpisah.
+ Profil Fargate mendukung penentuan subnet dari blok CIDR sekunder VPC. Anda mungkin ingin menentukan blok CIDR sekunder. Ini karena ada sejumlah alamat IP yang tersedia di subnet. Akibatnya, ada juga sejumlah Pod yang dapat dibuat di klaster. Dengan menggunakan subnet yang berbeda untuk Pod, Anda dapat menambah jumlah alamat IP yang tersedia. Untuk informasi selengkapnya, lihat [Menambahkan blok IPv4 CIDR ke VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize).
+ Layanan metadata EC2 instans Amazon (IMDS) tidak tersedia untuk Pod yang di-deploy ke node Fargate. [Jika Anda memiliki Pod yang di-deploy ke Fargate yang membutuhkan kredensyal IAM, tetapkan Pod tersebut ke Pod Anda menggunakan peran IAM untuk akun layanan.](iam-roles-for-service-accounts.md) Jika Pod Anda memerlukan akses ke informasi lain yang tersedia melalui IMDS, maka Anda harus membuat kode keras informasi ini ke dalam spesifikasi Pod Anda. Ini termasuk AWS Region atau Availability Zone tempat Pod digunakan.
+ Anda tidak dapat menerapkan Pod Fargate ke AWS Outposts, AWS Wavelength, atau Local Zones. AWS
+ Amazon EKS harus menambal Pod Fargate secara berkala agar tetap aman. Kami mencoba pembaruan dengan cara yang mengurangi dampak, tetapi ada kalanya Pod harus dihapus jika tidak berhasil diusir. Ada beberapa tindakan yang dapat Anda lakukan untuk meminimalkan gangguan. Untuk informasi selengkapnya, lihat [Tetapkan tindakan untuk AWS acara patching OS Fargate](fargate-pod-patching.md).
+ [Plugin Amazon VPC CNI untuk Amazon EKS diinstal](https://github.com/aws/amazon-vpc-cni-plugins) pada node Fargate. Anda tidak dapat menggunakan [plugin Alternatif CNI untuk kluster Amazon EKS dengan node Fargate](alternate-cni-plugins.md).
+ Pod yang berjalan di Fargate secara otomatis memasang sistem file Amazon EFS, tanpa memerlukan langkah penginstalan driver secara manual. Anda tidak dapat menggunakan penyediaan volume persisten dinamis dengan node Fargate, tetapi Anda dapat menggunakan penyediaan statis.
+ Amazon EKS tidak mendukung Fargate Spot.
+ Anda tidak dapat memasang volume Amazon EBS ke Pod Fargate.
+ Anda dapat menjalankan pengontrol Amazon EBS CSI di node Fargate, tetapi node Amazon EBS CSI DaemonSet hanya dapat berjalan di instans Amazon. EC2
+ Setelah [Job Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/job/) `Completed` ditandai `Failed` atau, Pod yang dibuat oleh Job biasanya akan tetap ada. Perilaku ini memungkinkan Anda untuk melihat log dan hasil Anda, tetapi dengan Fargate Anda akan dikenakan biaya jika Anda tidak membersihkan Job sesudahnya.
Untuk menghapus Pod terkait secara otomatis setelah Job selesai atau gagal, Anda dapat menentukan periode waktu menggunakan pengontrol time-to-live (TTL). Contoh berikut menunjukkan spesifikasi `.spec.ttlSecondsAfterFinished` dalam manifes Job Anda.
```
apiVersion: batch/v1
kind: Job
metadata:
name: busybox
spec:
template:
spec:
containers:
- name: busybox
image: busybox
command: ["/bin/sh", "-c", "sleep 10"]
restartPolicy: Never
ttlSecondsAfterFinished: 60 # <-- TTL controller
```
## Tabel Perbandingan Fargate
| Kriteria | AWS Fargate |
| --- | --- |
| [Dapat dikerahkan ke Outposts AWS](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) | Tidak |
| Dapat dikerahkan ke Zona [AWS Lokal](local-zones.md) | Tidak |
| Dapat menjalankan kontainer yang memerlukan Windows | Tidak |
| Dapat menjalankan kontainer yang membutuhkan Linux | Ya |
| Dapat menjalankan beban kerja yang memerlukan Chip Inferentia | Tidak |
| Dapat menjalankan beban kerja yang memerlukan GPU | Tidak |
| Dapat menjalankan beban kerja yang memerlukan prosesor Arm | Tidak |
| Dapat menjalankan AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | Tidak |
| Pod berbagi lingkungan runtime kernel dengan Pod lain | Tidak - Setiap Pod memiliki kernel khusus |
| Pod berbagi CPU, memori, penyimpanan, dan sumber daya jaringan dengan Pod lain. | Tidak - Setiap Pod memiliki sumber daya khusus dan dapat diukur secara independen untuk memaksimalkan pemanfaatan sumber daya. |
| Pod dapat menggunakan lebih banyak perangkat keras dan memori daripada yang diminta dalam spesifikasi Pod | Tidak - Pod dapat di-deploy ulang menggunakan vCPU dan konfigurasi memori yang lebih besar. |
| Harus menerapkan dan mengelola instans Amazon EC2 | Tidak |
| Harus mengamankan, memelihara, dan menambal sistem operasi EC2 instans Amazon | Tidak |
| Dapat memberikan argumen bootstrap pada penerapan node, seperti argumen [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) ekstra. | Tidak |
| Dapat menetapkan alamat IP ke Pod dari blok CIDR yang berbeda dari alamat IP yang ditetapkan ke node. | Tidak |
| Dapat SSH ke simpul | Tidak - Tidak ada sistem operasi host node untuk SSH. |
| Dapat men-deploy AMI kustom Anda sendiri ke simpul | Tidak |
| Dapat men-deploy CNI kustom Anda sendiri ke simpul | Tidak |
| Harus memperbarui node AMI sendiri | Tidak |
| Harus memperbarui versi node Kubernetes sendiri | Tidak - Anda tidak mengelola node. |
| Dapat menggunakan penyimpanan Amazon EBS dengan Pod | Tidak |
| Dapat menggunakan penyimpanan Amazon EFS dengan Pod | [Ya](efs-csi.md) |
| Dapat menggunakan Amazon FSx untuk penyimpanan Lustre dengan Pod | Tidak |
| Dapat menggunakan Network Load Balancer untuk layanan | Ya, saat menggunakan [Buat penyeimbang beban jaringan](network-load-balancing.md#network-load-balancer) |
| Pods dapat berjalan dalam subnet publik | Tidak |
| Dapat menetapkan grup keamanan VPC yang berbeda ke masing-masing Pod | Ya |
| Dapat menjalankan Kubernetes DaemonSets | Tidak |
| Support `HostPort` dan `HostNetwork` dalam manifes Pod | Tidak |
| AWS Ketersediaan wilayah | [Beberapa wilayah yang didukung Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) |
| Dapat menjalankan kontainer di host EC2 khusus Amazon | Tidak |
| Harga | Biaya memori Fargate secara individu dan konfigurasi CPU. Setiap Pod memiliki biaya sendiri. Untuk informasi lebih lanjut, lihat [AWS harga Fargate](https://aws.amazon.com/fargate/pricing/). |
# Memulai AWS Fargate untuk klaster Anda
Topik ini menjelaskan cara memulai menjalankan Pod di AWS Fargate dengan klaster Amazon EKS Anda.
Jika Anda membatasi akses ke titik akhir publik klaster Anda menggunakan blok CIDR, sebaiknya Anda juga mengaktifkan akses titik akhir pribadi. Dengan cara ini, Fargate Pod dapat berkomunikasi dengan cluster. Tanpa mengaktifkan titik akhir pribadi, blok CIDR yang Anda tentukan untuk akses publik harus menyertakan sumber keluar dari VPC Anda. Untuk informasi selengkapnya, lihat [Titik akhir server API kluster](cluster-endpoint.md).
**Prasyarat**
Sebuah klaster yang sudah ada. Jika Anda belum memiliki kluster Amazon EKS, lihat[Memulai dengan Amazon EKS](getting-started.md).
## Langkah 1: Pastikan node yang ada dapat berkomunikasi dengan Fargate Pods
Jika Anda bekerja dengan cluster baru tanpa node, atau cluster dengan hanya grup node terkelola (lihat[Sederhanakan siklus hidup node dengan grup node terkelola](managed-node-groups.md)), Anda dapat melompat ke[Langkah 2: Buat peran eksekusi Fargate Pod](#fargate-sg-pod-execution-role).
Asumsikan bahwa Anda bekerja dengan cluster yang sudah ada yang sudah memiliki node yang terkait dengannya. Pastikan bahwa Pod pada node ini dapat berkomunikasi secara bebas dengan Pod yang berjalan di Fargate. Pod yang berjalan di Fargate secara otomatis dikonfigurasi untuk menggunakan grup keamanan klaster untuk klaster yang terkait dengannya. Pastikan bahwa setiap node yang ada di cluster Anda dapat mengirim dan menerima lalu lintas ke dan dari grup keamanan klaster. Grup node terkelola secara otomatis dikonfigurasi untuk menggunakan grup keamanan klaster juga, jadi Anda tidak perlu memodifikasi atau memeriksa kompatibilitas ini (lihat[Sederhanakan siklus hidup node dengan grup node terkelola](managed-node-groups.md)).
Untuk grup node yang sudah ada yang dibuat dengan `eksctl` atau AWS CloudFormation templat terkelola Amazon EKS, Anda dapat menambahkan grup keamanan klaster ke node secara manual. Atau, sebagai alternatif, Anda dapat memodifikasi templat peluncuran grup Auto Scaling untuk grup node untuk melampirkan grup keamanan klaster ke instance. Untuk informasi selengkapnya, lihat [Mengubah grup keamanan instans](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership) di *Panduan Pengguna Amazon VPC*.
Anda dapat memeriksa grup keamanan untuk klaster Anda di bagian Konsol Manajemen AWS bawah **Jaringan** untuk klaster. Atau, Anda dapat melakukan ini menggunakan perintah AWS CLI berikut. Saat menggunakan perintah ini, ganti `` dengan nama cluster Anda.
```
aws eks describe-cluster --name --query cluster.resourcesVpcConfig.clusterSecurityGroupId
```
## Langkah 2: Buat peran eksekusi Fargate Pod
Saat klaster Anda membuat Pod di AWS Fargate, komponen yang berjalan di infrastruktur Fargate harus melakukan panggilan atas nama Anda. AWS APIs Peran eksekusi Amazon EKS Pod memberikan izin IAM untuk melakukan ini. Untuk membuat peran eksekusi AWS Fargate Pod, lihat. [Peran IAM eksekusi Pod Amazon EKS](pod-execution-role.md)
**catatan**
Jika Anda membuat klaster dengan `eksctl` menggunakan `--fargate` opsi, klaster Anda sudah memiliki peran eksekusi Pod yang dapat Anda temukan di konsol IAM dengan pola `eksctl-my-cluster-FargatePodExecutionRole-ABCDEFGHIJKL` tersebut. Demikian pula, jika Anda menggunakan `eksctl` untuk membuat profil Fargate Anda, `eksctl` buat peran eksekusi Pod Anda jika belum dibuat.
## Langkah 3: Buat profil Fargate untuk cluster Anda
Sebelum Anda dapat menjadwalkan Pod yang berjalan di Fargate di klaster Anda, Anda harus menentukan profil Fargate yang menentukan Pod mana yang menggunakan Fargate saat diluncurkan. Untuk informasi selengkapnya, lihat [Tentukan Pod mana yang menggunakan AWS Fargate saat diluncurkan](fargate-profile.md).
**catatan**
Jika Anda membuat klaster dengan `eksctl` menggunakan `--fargate` opsi, maka profil Fargate sudah dibuat untuk klaster Anda dengan pemilih untuk semua Pod di dan namespace. `kube-system` `default` Gunakan prosedur berikut untuk membuat profil Fargate untuk namespaces lain yang ingin Anda gunakan dengan Fargate.
Anda dapat membuat profil Fargate menggunakan salah satu alat ini:
+ [`eksctl`](#eksctl_fargate_profile_create)
+ [Konsol Manajemen AWS](#console_fargate_profile_create)
### `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.
**Untuk membuat profil Fargate dengan `eksctl`**
Buat profil Fargate Anda dengan `eksctl` perintah berikut, ganti masing-masing `` dengan nilai Anda sendiri. Anda diminta untuk menentukan namespace. Namun, `--labels` opsi tidak diperlukan.
```
eksctl create fargateprofile \
--cluster \
--name \
--namespace \
--labels
```
Anda dapat menggunakan wildcard tertentu untuk `` dan `` label. Untuk informasi selengkapnya, lihat [Wildcard profil Fargate](fargate-profile.md#fargate-profile-wildcards).
### Konsol Manajemen AWS
**Untuk membuat profil Fargate dengan Konsol Manajemen AWS **
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih klaster untuk membuat profil Fargate untuk.
1. Pilih tab **Compute**.
1. Di bawah **Profil Fargate**, pilih **Tambahkan profil Fargate**.
1. Pada halaman **profil Konfigurasi Fargate**, lakukan hal berikut:
1. Untuk **Nama**, masukkan nama untuk profil Fargate Anda. Nama harus unik.
1. Untuk **peran eksekusi Pod**, pilih peran eksekusi Pod yang akan digunakan dengan profil Fargate Anda. Hanya peran IAM dengan kepala `eks-fargate-pods.amazonaws.com` layanan yang ditampilkan. Jika Anda tidak melihat peran apa pun yang terdaftar, Anda harus membuatnya. Untuk informasi selengkapnya, lihat [Peran IAM eksekusi Pod Amazon EKS](pod-execution-role.md).
1. Ubah **Subnet** yang dipilih sesuai kebutuhan.
**catatan**
Hanya subnet pribadi yang didukung untuk Pod yang berjalan di Fargate.
1. Untuk **Tandai**, Anda dapat menandai profil Fargate Anda secara opsional. Tag ini tidak menyebar ke sumber daya lain yang terkait dengan profil seperti Pod.
1. Pilih **Berikutnya**.
1. Pada halaman **pemilihan Configure Pod**, lakukan hal berikut:
1. Untuk **Namespace**, masukkan namespace yang cocok dengan Pod.
+ Anda dapat menggunakan ruang nama tertentu untuk mencocokkan, seperti `kube-system` atau. `default`
+ Anda dapat menggunakan wildcard tertentu (misalnya,`prod-*`) untuk mencocokkan beberapa ruang nama (misalnya, `prod-deployment` dan). `prod-test` Untuk informasi selengkapnya, lihat [Wildcard profil Fargate](fargate-profile.md#fargate-profile-wildcards).
1. (Opsional) Tambahkan label Kubernetes ke pemilih. Secara khusus menambahkannya ke salah satu yang harus dicocokkan dengan Pod di namespace tertentu.
+ Anda dapat menambahkan label `infrastructure: fargate` ke pemilih sehingga hanya Pod di namespace tertentu yang juga memiliki label `infrastructure: fargate` Kubernetes yang cocok dengan pemilih.
+ Anda dapat menggunakan wildcard tertentu (misalnya,`key?: value?`) untuk mencocokkan beberapa ruang nama (misalnya, `keya: valuea` dan). `keyb: valueb` Untuk informasi selengkapnya, lihat [Wildcard profil Fargate](fargate-profile.md#fargate-profile-wildcards).
1. Pilih **Berikutnya**.
1. Pada halaman **Periksa dan buat**, tinjau informasi untuk profil Fargate Anda dan pilih **Buat**.
## Langkah 4: Perbarui CoreDNS
Secara default, CoreDNS dikonfigurasi untuk berjalan di EC2 infrastruktur Amazon di kluster Amazon EKS. Jika Anda *hanya* ingin menjalankan Pod di Fargate di klaster Anda, selesaikan langkah-langkah berikut.
**catatan**
Jika Anda membuat cluster Anda dengan `eksctl` menggunakan `--fargate` opsi, maka Anda dapat melompat ke[Langkah selanjutnya](#fargate-gs-next-steps).
1. Buat profil Fargate untuk CoreDNS dengan perintah berikut. Ganti `` dengan nama klaster Anda, `<111122223333>` dengan ID akun Anda, `` dengan nama peran eksekusi Pod Anda, dan `<000000000000000a>``<000000000000000b>`,, dan `<000000000000000c>` dengan subnet pribadi Anda. IDs Jika Anda tidak memiliki peran eksekusi Pod, Anda harus membuatnya terlebih dahulu (lihat[Langkah 2: Buat peran eksekusi Fargate Pod](#fargate-sg-pod-execution-role)).
**penting**
Peran ARN tidak dapat menyertakan [jalur](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) selain. `/` Misalnya, jika nama peran Anda`development/apps/AmazonEKSFargatePodExecutionRole`, Anda perlu mengubahnya menjadi `AmazonEKSFargatePodExecutionRole` saat menentukan ARN untuk peran tersebut. Format ARN peran harus ` arn:aws: iam::<111122223333>:role/`.
```
aws eks create-fargate-profile \
--fargate-profile-name coredns \
--cluster-name \
--pod-execution-role-arn arn:aws: iam::<111122223333>:role/ \
--selectors namespace=kube-system,labels={k8s-app=kube-dns} \
--subnets subnet-<000000000000000a> subnet-<000000000000000b> subnet-<000000000000000c>
```
1. Memicu peluncuran penyebaran. `coredns`
```
kubectl rollout restart -n kube-system deployment coredns
```
## Langkah selanjutnya
+ Anda dapat mulai memigrasi aplikasi yang ada untuk berjalan di Fargate dengan alur kerja berikut.
1. [Buat profil Fargate](fargate-profile.md#create-fargate-profile)yang cocok dengan namespace Kubernetes dan label Kubernetes aplikasi Anda.
1. Hapus dan buat ulang Pod yang ada sehingga dijadwalkan di Fargate. Ubah `` dan `` untuk memperbarui Pod spesifik Anda.
```
kubectl rollout restart -n deployment
```
+ Terapkan [Rute aplikasi dan lalu lintas HTTP dengan Application Load Balancers](alb-ingress.md) untuk mengizinkan objek Ingress untuk Pod Anda yang berjalan di Fargate.
+ Anda dapat menggunakannya [Sesuaikan sumber daya pod dengan Vertical Pod Autoscaler](vertical-pod-autoscaler.md) untuk mengatur ukuran CPU dan memori awal yang benar untuk Pod Fargate Anda, lalu gunakan [Menskalakan penerapan pod dengan Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md) untuk menskalakan Pod tersebut. Jika Anda ingin Vertical Pod Autoscaler untuk secara otomatis men-deploy ulang Pod ke Fargate dengan kombinasi CPU dan memori yang lebih tinggi, atur mode Vertical Pod Autoscaler ke salah satu atau. `Auto` `Recreate` Ini untuk memastikan fungsionalitas yang benar. Untuk informasi selengkapnya, lihat dokumentasi [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) pada. GitHub
+ Anda dapat mengatur kolektor [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel) (ADOT) untuk pemantauan aplikasi dengan mengikuti petunjuk [ini](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-otel.html).
# Tentukan Pod mana yang menggunakan AWS Fargate saat diluncurkan
Sebelum Anda menjadwalkan Pod di Fargate di klaster Anda, Anda harus menentukan setidaknya satu profil Fargate yang menentukan Pod mana yang menggunakan Fargate saat diluncurkan.
Sebagai administrator, Anda dapat menggunakan profil Fargate untuk mendeklarasikan Pod mana yang berjalan di Fargate. Anda dapat melakukan ini melalui pemilih profil. Anda dapat menambahkan hingga lima pemilih ke setiap profil. Setiap pemilih harus berisi namespace. Pemilih juga dapat menyertakan label. Bidang label terdiri dari beberapa pasangan nilai kunci opsional. Pod yang cocok dengan pemilih dijadwalkan di Fargate. Pod dicocokkan menggunakan namespace dan label yang ditentukan dalam pemilih. Jika pemilih namespace didefinisikan tanpa label, Amazon EKS mencoba menjadwalkan semua Pod yang berjalan di namespace tersebut ke Fargate menggunakan profil tersebut. Jika to-be-scheduled Pod cocok dengan salah satu pemilih di profil Fargate, maka Pod tersebut dijadwalkan di Fargate.
Jika sebuah Pod cocok dengan beberapa profil Fargate, Anda dapat menentukan profil mana yang digunakan Pod dengan menambahkan label Kubernetes berikut ke spesifikasi Pod:. `eks.amazonaws.com/fargate-profile: my-fargate-profile` Pod harus cocok dengan pemilih dalam profil tersebut untuk dijadwalkan ke Fargate. Aturan afinitas/anti-afinitas Kubernetes tidak berlaku dan tidak diperlukan dengan Pod Fargate Amazon EKS.
Saat Anda membuat profil Fargate, Anda harus menentukan peran eksekusi Pod. Peran eksekusi ini untuk komponen Amazon EKS yang berjalan di infrastruktur Fargate menggunakan profil. Ini ditambahkan ke Kubernetes [Role Based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) cluster untuk otorisasi. Dengan begitu, `kubelet` yang berjalan pada infrastruktur Fargate dapat mendaftar dengan cluster Amazon EKS Anda dan muncul di cluster Anda sebagai node. Peran eksekusi Pod juga memberikan izin IAM ke infrastruktur Fargate untuk memungkinkan akses baca ke repositori image Amazon ECR. Untuk informasi selengkapnya, lihat [Peran IAM eksekusi Pod Amazon EKS](pod-execution-role.md).
Profil Fargate tidak dapat diubah. Namun, Anda dapat membuat profil baru yang diperbarui untuk mengganti profil yang ada, dan kemudian menghapus yang asli.
**catatan**
Pod apa pun yang berjalan menggunakan profil Fargate akan dihentikan dan dimasukkan ke dalam status tertunda saat profil dihapus.
Jika ada profil Fargate dalam klaster dalam `DELETING` status, Anda harus menunggu sampai setelah profil Fargate dihapus sebelum Anda membuat profil lain di cluster itu.
**catatan**
Fargate saat ini tidak mendukung Kubernetes. [topologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)
Amazon EKS dan Fargate menyebarkan Pod di setiap subnet yang ditentukan dalam profil Fargate. Namun, Anda mungkin berakhir dengan penyebaran yang tidak merata. Jika Anda harus memiliki spread yang merata, gunakan dua profil Fargate. Bahkan spread penting dalam skenario di mana Anda ingin menerapkan dua replika dan tidak ingin downtime. Kami merekomendasikan bahwa setiap profil hanya memiliki satu subnet.
## Komponen profil Fargate
Komponen-komponen berikut yang terkandung dalam profil Fargate.
**Peran eksekusi pod**
Saat klaster Anda membuat Pod di AWS Fargate, `kubelet` yang berjalan di infrastruktur Fargate harus melakukan panggilan atas nama Anda. AWS APIs Misalnya, perlu melakukan panggilan untuk menarik gambar kontainer dari Amazon ECR. Peran eksekusi Amazon EKS Pod memberikan izin IAM untuk melakukan ini.
Saat Anda membuat profil Fargate, Anda harus menentukan peran eksekusi Pod yang akan digunakan dengan Pod Anda. Peran ini ditambahkan ke Kubernetes [Role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) klaster untuk otorisasi. Ini agar yang berjalan di infrastruktur Fargate dapat mendaftar dengan cluster Amazon EKS Anda dan muncul di cluster Anda sebagai node. `kubelet` Untuk informasi selengkapnya, lihat [Peran IAM eksekusi Pod Amazon EKS](pod-execution-role.md).
**Subnet**
Subnet untuk meluncurkan Pod ke dalamnya menggunakan profil ini. IDs Saat ini, Pod yang berjalan di Fargate tidak diberi alamat IP publik. Oleh karena itu, hanya subnet pribadi tanpa rute langsung ke Internet Gateway yang diterima untuk parameter ini.
**Selektor**
Selector untuk mencocokkan Pod untuk menggunakan profil Fargate ini. Anda dapat menentukan hingga lima pemilih dalam profil Fargate. Penyeleksi memiliki komponen-komponen berikut:
+ **Namespace** – Anda harus menentukan namespace untuk pemilih. Selector hanya cocok dengan Pod yang dibuat di namespace ini. Namun, Anda dapat membuat beberapa penyeleksi untuk menargetkan beberapa ruang nama.
+ **Label** — Anda dapat menentukan label Kubernetes untuk dicocokkan dengan pemilih. Pemilih hanya cocok dengan Pod yang memiliki semua label yang ditentukan dalam pemilih.
## Wildcard profil Fargate
Selain karakter yang diizinkan oleh Kubernetes, Anda diizinkan untuk menggunakan `*` dan `?` dalam kriteria pemilih untuk namespace, kunci label, dan nilai label:
+ `*`mewakili tidak ada, satu, atau beberapa karakter. Misalnya, `prod*` dapat mewakili `prod` dan`prod-metrics`.
+ `?`mewakili satu karakter (misalnya, `value?` dapat mewakili`valuea`). Namun, itu tidak dapat mewakili `value` dan`value-a`, karena hanya `?` dapat mewakili tepat satu karakter.
Karakter wildcard ini dapat digunakan dalam posisi apa pun dan dalam kombinasi (misalnya,, `prod*``*dev`, dan`frontend*?`). Wildcard lain dan bentuk pencocokan pola, seperti ekspresi reguler, tidak didukung.
Jika ada beberapa profil yang cocok untuk namespace dan label dalam spesifikasi Pod, Fargate mengambil profil berdasarkan pengurutan alfanumerik berdasarkan nama profil. Misalnya, jika kedua profil A (dengan nama`beta-workload`) dan profil B (dengan nama`prod-workload`) memiliki pemilih yang cocok untuk Pod yang akan diluncurkan, Fargate memilih profil A `beta-workload` () untuk Pod. Pod memiliki label dengan profil A pada Pod (misalnya,`eks.amazonaws.com/fargate-profile=beta-workload`).
Jika Anda ingin memigrasikan Pod Fargate yang ada ke profil baru yang menggunakan wildcard, ada dua cara untuk melakukannya:
+ Buat profil baru dengan penyeleksi yang cocok, lalu hapus profil lama. Pod yang diberi label dengan profil lama dijadwal ulang ke profil baru yang cocok.
+ Jika Anda ingin memigrasikan beban kerja tetapi tidak yakin label Fargate pada setiap Pod Fargate, Anda dapat menggunakan metode berikut. Buat profil baru dengan nama yang mengurutkan secara alfanumerik terlebih dahulu di antara profil di cluster yang sama. Kemudian, daur ulang Pod Fargate yang perlu dimigrasikan ke profil baru.
## Buat profil Fargate
Bagian ini menjelaskan cara membuat profil Fargate. Anda juga harus telah membuat peran eksekusi Pod untuk digunakan untuk profil Fargate Anda. Untuk informasi selengkapnya, lihat [Peran IAM eksekusi Pod Amazon EKS](pod-execution-role.md). Pod yang berjalan di Fargate hanya didukung pada subnet pribadi dengan akses [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) ke AWS layanan, tetapi bukan rute langsung ke Internet Gateway. Ini agar VPC cluster Anda harus memiliki subnet pribadi yang tersedia.
Anda dapat membuat profil dengan yang berikut ini:
+ [`eksctl`](#eksctl_create_a_fargate_profile)
+ [Konsol Manajemen AWS](#console_create_a_fargate_profile)
## `eksctl`
**Untuk membuat profil Fargate dengan `eksctl`**
Buat profil Fargate Anda dengan `eksctl` perintah berikut, ganti setiap nilai contoh dengan nilai Anda sendiri. Anda diminta untuk menentukan namespace. Namun, `--labels` opsi tidak diperlukan.
```
eksctl create fargateprofile \
--cluster my-cluster \
--name my-fargate-profile \
--namespace my-kubernetes-namespace \
--labels key=value
```
Anda dapat menggunakan wildcard tertentu untuk `my-kubernetes-namespace` dan `key=value` label. Untuk informasi selengkapnya, lihat [Wildcard profil Fargate](#fargate-profile-wildcards).
## Konsol Manajemen AWS
**Untuk membuat profil Fargate dengan Konsol Manajemen AWS **
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih klaster untuk membuat profil Fargate untuk.
1. Pilih tab **Compute**.
1. Di bawah **Profil Fargate**, pilih **Tambahkan profil Fargate**.
1. Pada halaman **profil Konfigurasi Fargate**, lakukan hal berikut:
1. Untuk **Nama**, masukkan nama unik untuk profil Fargate Anda, seperti `my-profile`.
1. Untuk **peran eksekusi Pod**, pilih peran eksekusi Pod yang akan digunakan dengan profil Fargate Anda. Hanya peran IAM dengan kepala `eks-fargate-pods.amazonaws.com` layanan yang ditampilkan. Jika Anda tidak melihat peran apa pun yang terdaftar, Anda harus membuatnya. Untuk informasi selengkapnya, lihat [Peran IAM eksekusi Pod Amazon EKS](pod-execution-role.md).
1. Ubah **Subnet** yang dipilih sesuai kebutuhan.
**catatan**
Hanya subnet pribadi yang didukung untuk Pod yang berjalan di Fargate.
1. Untuk **Tandai**, Anda dapat menandai profil Fargate Anda secara opsional. Tag ini tidak menyebar ke sumber daya lain yang terkait dengan profil, seperti Pod.
1. Pilih **Berikutnya**.
1. Pada halaman **pemilihan Configure Pod**, lakukan hal berikut:
1. Untuk **Namespace**, masukkan namespace yang cocok dengan Pod.
+ Anda dapat menggunakan ruang nama tertentu untuk mencocokkan, seperti `kube-system` atau. `default`
+ Anda dapat menggunakan wildcard tertentu (misalnya,`prod-*`) untuk mencocokkan beberapa ruang nama (misalnya, `prod-deployment` dan). `prod-test` Untuk informasi selengkapnya, lihat [Wildcard profil Fargate](#fargate-profile-wildcards).
1. (Opsional) Tambahkan label Kubernetes ke pemilih. Secara khusus, tambahkan ke salah satu yang harus dicocokkan dengan Pod di namespace tertentu.
+ Anda dapat menambahkan label `infrastructure: fargate` ke pemilih sehingga hanya Pod di namespace tertentu yang juga memiliki label `infrastructure: fargate` Kubernetes yang cocok dengan pemilih.
+ Anda dapat menggunakan wildcard tertentu (misalnya,`key?: value?`) untuk mencocokkan beberapa ruang nama (misalnya, `keya: valuea` dan). `keyb: valueb` Untuk informasi selengkapnya, lihat [Wildcard profil Fargate](#fargate-profile-wildcards).
1. Pilih **Berikutnya**.
1. Pada halaman **Periksa dan buat**, tinjau informasi untuk profil Fargate Anda dan pilih **Buat**.
# Hapus profil Fargate
Topik ini menjelaskan cara menghapus profil Fargate. Saat Anda menghapus profil Fargate, semua Pod yang dijadwalkan ke Fargate dengan profil akan dihapus. Jika Pod tersebut cocok dengan profil Fargate lainnya, maka mereka dijadwalkan di Fargate dengan profil itu. Jika mereka tidak lagi cocok dengan profil Fargate, maka mereka tidak dijadwalkan ke Fargate dan mungkin tetap tertunda.
Hanya satu profil Fargate dalam sebuah klaster yang dapat memiliki status `DELETING` pada satu waktu. Tunggu profil Fargate selesai dihapus sebelum Anda dapat menghapus profil lain di cluster itu.
Anda dapat menghapus profil dengan salah satu alat berikut:
+ [`eksctl`](#eksctl_delete_a_fargate_profile)
+ [Konsol Manajemen AWS](#console_delete_a_fargate_profile)
+ [AWS CLI](#awscli_delete_a_fargate_profile)
## `eksctl`
**Hapus profil Fargate dengan `eksctl`**
Gunakan perintah berikut untuk menghapus profil dari klaster. Ganti setiap *example value* dengan nilai-nilai Anda sendiri.
```
eksctl delete fargateprofile --name my-profile --cluster my-cluster
```
## Konsol Manajemen AWS
**Hapus profil Fargate dengan Konsol Manajemen AWS **
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pada panel navigasi sebelah kiri, pilih **Klaster**. Dalam daftar cluster, pilih cluster tempat Anda ingin menghapus profil Fargate.
1. Pilih tab **Compute**.
1. **Pilih profil Fargate untuk dihapus, lalu pilih Hapus.**
1. **Pada halaman **Hapus profil Fargate**, masukkan nama profil, lalu pilih Hapus.**
## AWS CLI
**Hapus profil Fargate dengan CLI AWS **
Gunakan perintah berikut untuk menghapus profil dari klaster. Ganti setiap *example value* dengan nilai-nilai Anda sendiri.
```
aws eks delete-fargate-profile --fargate-profile-name my-profile --cluster-name my-cluster
```
# Memahami detail konfigurasi Fargate Pod
Bagian ini menjelaskan beberapa detail konfigurasi Pod yang unik untuk menjalankan Pod Kubernetes di Fargate. AWS
## Pod CPU dan memori
Dengan Kubernetes, Anda dapat menentukan permintaan, jumlah minimum vCPU, dan sumber daya memori yang dialokasikan ke setiap kontainer dalam sebuah Pod. Pod dijadwalkan oleh Kubernetes untuk memastikan bahwa setidaknya sumber daya yang diminta untuk setiap Pod tersedia di sumber daya komputasi. Untuk informasi lebih lanjut, lihat [Mengelola sumber daya komputasi untuk kontainer](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) dalam dokumentasi Kubernetes.
**catatan**
Karena Amazon EKS Fargate hanya menjalankan satu Pod per node, skenario penggusuran Pod jika sumber daya lebih sedikit tidak terjadi. Semua Pod Amazon EKS Fargate berjalan dengan prioritas terjamin, sehingga CPU dan memori yang diminta harus sama dengan batas untuk semua container. Untuk informasi selengkapnya, lihat [Mengkonfigurasi Kualitas Layanan untuk Pod](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) dalam dokumentasi Kubernetes.
Ketika Pod dijadwalkan di Fargate, reservasi vCPU dan memori dalam spesifikasi Pod menentukan berapa banyak CPU dan memori yang akan disediakan untuk Pod.
+ Permintaan maksimum dari setiap kontainer Init digunakan untuk menentukan permintaan Init vCPU dan memori persyaratan.
+ Permintaan untuk semua kontainer berjalan lama ditambahkan untuk menentukan lama berjalan permintaan vCPU dan memori persyaratan.
+ Nilai yang lebih besar dari dua nilai sebelumnya dipilih untuk vCPU dan permintaan memori yang akan digunakan untuk Pod Anda.
+ Fargate menambahkan 256 MB ke setiap reservasi memori Pod untuk komponen Kubernetes yang diperlukan (`kubelet`,, dan). `kube-proxy` `containerd`
Fargate membulatkan ke konfigurasi komputasi berikut yang paling cocok dengan jumlah permintaan vCPU dan memori untuk memastikan Pod selalu memiliki sumber daya yang mereka butuhkan untuk menjalankannya.
Jika Anda tidak menentukan kombinasi vCPU dan memori, maka kombinasi terkecil yang tersedia digunakan (0,25 vCPU dan memori 0,5 GB).
Tabel berikut menunjukkan kombinasi vCPU dan memori yang tersedia untuk Pod yang berjalan di Fargate.
| Nilai vCPU | Nilai memori |
| --- | --- |
| 0,25 vCPU | 0,5 GB, 1 GB, 2 GB |
| 0,5 vCPU | 1 GB, 2 GB, 3 GB, 4 GB |
| 1 vCPU | 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB |
| 2 vCPU | Antara 4 GB dan 16 GB dalam kenaikan 1-GB |
| 4 vCPU | Antara 8 GB dan 30 GB dalam tambahan 1-GB |
| 8 vCPU | Antara 16 GB dan 60 GB dengan peningkatan 4-GB |
| 16 vCPU | Antara 32 GB dan 120 GB dengan peningkatan 8-GB |
Memori tambahan yang disediakan untuk komponen Kubernetes dapat menyebabkan tugas Fargate dengan lebih banyak v CPUs dari yang diminta untuk disediakan. Misalnya, permintaan untuk 1 vCPU dan memori 8 GB akan memiliki 256 MB yang ditambahkan ke permintaan memorinya, dan akan menyediakan tugas Fargate dengan memori 2 v CPUs dan 9 GB, karena tidak ada tugas dengan 1 vCPU dan memori 9 GB yang tersedia.
Tidak ada korelasi antara ukuran Pod yang berjalan di Fargate dan ukuran node yang dilaporkan oleh Kubernetes dengan. `kubectl get nodes` Ukuran node yang dilaporkan seringkali lebih besar dari kapasitas Pod. Anda dapat memverifikasi kapasitas Pod dengan perintah berikut. Ganti *default* dengan namespace Pod Anda dan *pod-name* dengan nama Pod Anda.
```
kubectl describe pod --namespace default pod-name
```
Contoh output adalah sebagai berikut.
```
[...]
annotations:
CapacityProvisioned: 0.25vCPU 0.5GB
[...]
```
`CapacityProvisioned`Anotasi tersebut mewakili kapasitas Pod yang diberlakukan dan menentukan biaya Pod Anda yang berjalan di Fargate. [Untuk informasi harga untuk konfigurasi komputasi, lihat Harga Fargate AWS .](https://aws.amazon.com/fargate/pricing/)
## Penyimpanan Fargate
Pod yang berjalan di Fargate secara otomatis memasang sistem file Amazon EFS, tanpa memerlukan langkah penginstalan driver manual. Anda tidak dapat menggunakan penyediaan volume persisten dinamis dengan node Fargate, tetapi Anda dapat menggunakan penyediaan statis. Untuk informasi selengkapnya, lihat [Driver Amazon EFS CSI](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md) di GitHub.
Saat disediakan, setiap Pod yang berjalan di Fargate menerima penyimpanan sementara 20 GiB default. Jenis penyimpanan ini dihapus setelah Pod berhenti. Pod baru yang diluncurkan ke Fargate memiliki enkripsi volume penyimpanan sementara yang diaktifkan secara default. Penyimpanan Pod sementara dienkripsi dengan algoritma enkripsi AES-256 menggunakan kunci terkelola Fargate. AWS
**catatan**
Penyimpanan default yang dapat digunakan untuk Amazon EKS Pods yang berjalan di Fargate kurang dari 20 GiB. Ini karena beberapa ruang digunakan oleh modul Kubernetes `kubelet` dan modul Kubernetes lainnya yang dimuat di dalam Pod.
Anda dapat meningkatkan jumlah total penyimpanan sementara hingga maksimum 175 GiB. Untuk mengkonfigurasi ukuran dengan Kubernetes, tentukan permintaan `ephemeral-storage` sumber daya untuk setiap kontainer dalam sebuah Pod. Ketika Kubernetes menjadwalkan Pod, Kubernetes memastikan bahwa jumlah permintaan sumber daya untuk setiap Pod kurang dari kapasitas tugas Fargate. Untuk informasi selengkapnya, lihat [Manajemen Sumber Daya untuk Pod dan Container](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) di dokumentasi Kubernetes.
Amazon EKS Fargate menyediakan lebih banyak penyimpanan sementara daripada yang diminta untuk tujuan penggunaan sistem. Misalnya, permintaan 100 GiB akan menyediakan tugas Fargate dengan penyimpanan sementara 115 GiB.
# Tetapkan tindakan untuk AWS acara patching OS Fargate
Amazon EKS secara berkala menambal OS untuk node AWS Fargate agar tetap aman. Sebagai bagian dari proses patching, kami mendaur ulang node untuk menginstal patch OS. Pembaruan dicoba dengan cara yang menciptakan dampak paling kecil pada layanan Anda. Namun, jika Pod tidak berhasil diusir, ada kalanya Pod tersebut harus dihapus. Berikut ini adalah tindakan yang dapat Anda lakukan untuk meminimalkan potensi gangguan:
+ Tetapkan anggaran gangguan Pod (PDBs) yang sesuai untuk mengontrol jumlah Pod yang turun secara bersamaan.
+ Buat EventBridge aturan Amazon untuk menangani penggusuran yang gagal sebelum Pod dihapus.
+ Mulai ulang pod Anda yang terpengaruh secara manual sebelum tanggal penggusuran diposting di notifikasi yang Anda terima.
+ Buat konfigurasi notifikasi di Pemberitahuan AWS Pengguna.
Amazon EKS bekerja sama dengan komunitas Kubernetes untuk membuat perbaikan bug dan patch keamanan tersedia secepat mungkin. Semua Pod Fargate dimulai pada versi patch Kubernetes terbaru, yang tersedia dari Amazon EKS untuk versi Kubernetes dari klaster Anda. Jika Anda memiliki Pod dengan versi patch yang lebih lama, Amazon EKS mungkin mendaur ulangnya untuk memperbaruinya ke versi terbaru. Ini memastikan bahwa Pod Anda dilengkapi dengan pembaruan keamanan terbaru. Dengan begitu, jika ada masalah [Common Vulnerabilities and Exposures](https://cve.mitre.org/) (CVE) yang kritis, Anda tetap up to date untuk mengurangi risiko keamanan.
Saat OS AWS Fargate diperbarui, Amazon EKS akan mengirimkan pemberitahuan yang menyertakan sumber daya yang terpengaruh dan tanggal penggusuran pod yang akan datang. Jika tanggal penggusuran yang diberikan tidak nyaman, Anda memiliki opsi untuk me-restart pod yang terpengaruh secara manual sebelum tanggal penggusuran yang diposting di notifikasi. Pod apa pun yang dibuat sebelum waktu Anda menerima notifikasi akan dikenakan penggusuran. Lihat [Dokumentasi Kubernetes](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/kubectl_rollout_restart) untuk petunjuk lebih lanjut tentang cara me-restart pod Anda secara manual.
Untuk membatasi jumlah Pod yang turun pada satu waktu ketika Pod didaur ulang, Anda dapat mengatur anggaran gangguan Pod (). PDBs Anda dapat menggunakan PDBs untuk menentukan ketersediaan minimum berdasarkan persyaratan masing-masing aplikasi Anda sambil tetap mengizinkan pembaruan terjadi. Ketersediaan minimum PDB Anda harus kurang dari 100%. Untuk informasi selengkapnya, lihat [Menentukan Anggaran Gangguan untuk Aplikasi Anda](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) di Dokumentasi Kubernetes.
Amazon EKS menggunakan [Eviction API](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/#eviction-api) untuk menguras Pod dengan aman sambil menghormati PDBs yang Anda tetapkan untuk aplikasi tersebut. Pod diusir oleh Availability Zone untuk meminimalkan dampak. Jika penggusuran berhasil, Pod baru mendapatkan patch terbaru dan tidak diperlukan tindakan lebih lanjut.
Ketika penggusuran Pod gagal, Amazon EKS mengirimkan peristiwa ke akun Anda dengan rincian tentang Pod yang gagal penggusuran. Anda dapat menindaklanjuti pesan sebelum waktu penghentian yang dijadwalkan. Waktu spesifik bervariasi berdasarkan urgensi tambalan. Ketika tiba waktunya, Amazon EKS mencoba untuk mengusir Pod lagi. Namun, kali ini acara baru tidak dikirim jika penggusuran gagal. Jika penggusuran gagal lagi, Pod Anda yang ada akan dihapus secara berkala sehingga Pod baru dapat memiliki patch terbaru.
Berikut ini adalah contoh peristiwa yang diterima ketika penggusuran Pod gagal. Ini berisi rincian tentang cluster, nama Pod, namespace Pod, profil Fargate, dan waktu terminasi yang dijadwalkan.
```
{
"version": "0",
"id": "12345678-90ab-cdef-0123-4567890abcde",
"detail-type": "EKS Fargate Pod Scheduled Termination",
"source": "aws.eks",
"account": "111122223333",
"time": "2021-06-27T12:52:44Z",
"region": "region-code",
"resources": [
"default/my-database-deployment"
],
"detail": {
"clusterName": "my-cluster",
"fargateProfileName": "my-fargate-profile",
"podName": "my-pod-name",
"podNamespace": "default",
"evictErrorMessage": "Cannot evict pod as it would violate the pod's disruption budget",
"scheduledTerminationTime": "2021-06-30T12:52:44.832Z[UTC]"
}
}
```
Selain itu, memiliki beberapa PDBs yang terkait dengan Pod dapat menyebabkan peristiwa kegagalan penggusuran. Acara ini mengembalikan pesan galat berikut.
```
"evictErrorMessage": "This pod has multiple PodDisruptionBudget, which the eviction subresource does not support",
```
Anda dapat membuat tindakan yang diinginkan berdasarkan acara ini. Misalnya, Anda dapat menyesuaikan anggaran gangguan Pod (PDB) untuk mengontrol cara Pod diusir. Lebih khusus lagi, misalkan Anda memulai dengan PDB yang menentukan persentase target Pod yang tersedia. Sebelum Pod dihentikan secara paksa selama upgrade, Anda dapat menyesuaikan PDB ke persentase Pod yang berbeda. Untuk menerima acara ini, Anda harus membuat EventBridge aturan Amazon di AWS akun dan AWS Wilayah tempat cluster tersebut berada. Aturan harus menggunakan **pola Kustom** berikut. Untuk informasi selengkapnya, lihat [Membuat EventBridge aturan Amazon yang bereaksi terhadap peristiwa](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) di *Panduan EventBridge Pengguna Amazon*.
```
{
"source": ["aws.eks"],
"detail-type": ["EKS Fargate Pod Scheduled Termination"]
}
```
Target yang sesuai dapat ditetapkan untuk acara untuk menangkapnya. Untuk daftar lengkap target yang tersedia, lihat [ EventBridge target Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) di *Panduan EventBridge Pengguna Amazon*. Anda juga dapat membuat konfigurasi notifikasi di Pemberitahuan AWS Pengguna. **Saat menggunakan Konsol Manajemen AWS untuk membuat notifikasi, di bawah **Aturan Acara**, pilih **Elastic Kubernetes Service (EKS) untuk **nama AWS layanan** dan EKS** **Fargate Pod Terjadwal Terminasi** untuk tipe Event.** Untuk informasi selengkapnya, lihat [Memulai Pemberitahuan AWS Pengguna](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html) di Panduan AWS Pengguna Pemberitahuan Pengguna.
Lihat [FAQs: Pemberitahuan penggusuran Fargate Pod di * AWS re:Post* untuk pertanyaan umum tentang Penggusuran](https://repost.aws/knowledge-center/fargate-pod-eviction-notice) Pod EKS.
# Kumpulkan aplikasi AWS Fargate dan metrik penggunaan
Anda dapat mengumpulkan metrik sistem dan metrik CloudWatch penggunaan untuk AWS Fargate.
## Metrik aplikasi
Untuk aplikasi yang berjalan di Amazon EKS dan AWS Fargate, Anda dapat menggunakan AWS Distro for OpenTelemetry (ADOT). ADOT memungkinkan Anda mengumpulkan metrik sistem dan mengirimkannya ke dasbor CloudWatch Container Insights. Untuk memulai ADOT untuk aplikasi yang berjalan di Fargate, [lihat CloudWatch Menggunakan Wawasan Kontainer AWS dengan Distro OpenTelemetry](https://aws-otel.github.io/docs/getting-started/container-insights) untuk dokumentasi ADOT.
## Metrik penggunaan
Anda dapat menggunakan metrik CloudWatch penggunaan untuk memberikan visibilitas ke dalam penggunaan sumber daya akun Anda. Gunakan metrik ini untuk memvisualisasikan penggunaan layanan Anda saat ini pada CloudWatch grafik dan dasbor.
AWS Metrik penggunaan Fargate sesuai dengan kuota layanan. AWS Anda dapat mengonfigurasi alarm yang memberi tahu Anda saat penggunaan mendekati kuota layanan. Untuk informasi lebih lanjut tentang kuota layanan Fargate, lihat [Lihat dan kelola kuota layanan Amazon EKS dan Fargate](service-quotas.md).
AWS Fargate menerbitkan metrik berikut di namespace. ` AWS/Usage`
| Metrik | Deskripsi |
| --- | --- |
| `ResourceCount` | Jumlah sumber daya tertentu yang berjalan di akun Anda. Sumber daya ditentukan oleh dimensi yang terkait dengan metrik. |
Dimensi berikut digunakan untuk menyempurnakan metrik penggunaan yang diterbitkan oleh AWS Fargate.
| Dimensi | Deskripsi |
| --- | --- |
| `Service` | Nama AWS layanan yang berisi sumber daya. Untuk metrik penggunaan AWS Fargate, nilai untuk dimensi ini adalah. `Fargate` |
| `Type` | Jenis entitas yang dilaporkan. Saat ini, satu-satunya nilai yang valid untuk metrik penggunaan AWS Fargate adalah. `Resource` |
| `Resource` | Jenis sumber daya yang sedang berjalan. Saat ini, AWS Fargate mengembalikan informasi tentang penggunaan Fargate On-Demand Anda. Nilai sumber daya untuk penggunaan Sesuai Permintaan Fargate adalah `OnDemand`. [CATATAN] ==== Penggunaan Fargate On-Demand menggabungkan Pod Amazon EKS menggunakan Fargate, tugas Amazon ECS menggunakan tipe peluncuran Fargate dan tugas Amazon ECS menggunakan penyedia kapasitas. `FARGATE` ==== |
| `Class` | Kelas sumber daya yang akan dilacak. Saat ini, AWS Fargate tidak menggunakan dimensi kelas. |
### Membuat CloudWatch alarm untuk memantau metrik penggunaan sumber daya Fargate
AWS Fargate menyediakan metrik CloudWatch penggunaan yang sesuai dengan kuota AWS layanan untuk penggunaan sumber daya Fargate On-Demand. Di konsol Service Quotas, Anda dapat memvisualisasikan penggunaan Anda pada grafik. Anda juga dapat mengonfigurasi alarm yang memberi tahu Anda ketika penggunaan mendekati kuota layanan. Untuk informasi selengkapnya, lihat [Kumpulkan aplikasi AWS Fargate dan metrik penggunaan](#monitoring-fargate-usage).
Gunakan langkah-langkah berikut untuk membuat CloudWatch alarm berdasarkan metrik penggunaan sumber daya Fargate.
1. Buka konsol Service Quotas di. https://console.aws.amazon.com/servicequotas/
1. Di panel navigasi kiri, pilih ** AWS layanan**.
1. Dari daftar ** AWS layanan**, cari dan pilih ** AWS Fargate**.
1. Dalam daftar **Kuota Layanan**, pilih kuota penggunaan Fargate yang ingin Anda buat alarm.
1. Di bagian CloudWatch alarm Amazon, pilih **Buat**.
1. Untuk **Ambang batas Alarm**, pilih persentase nilai kuota yang ingin Anda tetapkan sebagai nilai alarm.
1. Untuk **Nama alarm**, masukkan nama untuk alarm, lalu pilih **Buat**.
# Mulai pencatatan AWS Fargate untuk klaster Anda
Amazon EKS di Fargate menawarkan router log bawaan berdasarkan Fluent Bit. Ini berarti Anda tidak secara eksplisit menjalankan container Fluent Bit sebagai sespan, tetapi Amazon menjalankannya untuk Anda. Yang harus Anda lakukan adalah mengkonfigurasi router log. Konfigurasi terjadi melalui dedicated `ConfigMap` yang harus memenuhi kriteria berikut:
+ Bernama `aws-logging`
+ Dibuat di namespace khusus yang disebut `aws-observability`
+ Tidak dapat melebihi 5300 karakter.
Setelah Anda membuat`ConfigMap`, Amazon EKS di Fargate secara otomatis mendeteksi dan mengonfigurasi router log dengannya. Fargate menggunakan versi AWS untuk Fluent Bit, distribusi Fluent Bit yang sesuai dengan hulu yang dikelola oleh. AWS Untuk informasi lebih lanjut, lihat [AWS Fluent Bit](https://github.com/aws/aws-for-fluent-bit) on GitHub.
Router log memungkinkan Anda untuk menggunakan luasnya layanan di AWS untuk analisis log dan penyimpanan. Anda dapat melakukan streaming log dari Fargate langsung ke Amazon, CloudWatch Amazon OpenSearch Service. [Anda juga dapat melakukan streaming log ke tujuan seperti [Amazon S3](https://aws.amazon.com/s3/), [Amazon Kinesis Data Streams, dan alat mitra melalui Amazon Data](https://aws.amazon.com/kinesis/data-streams/) Firehose.](https://aws.amazon.com/kinesis/data-firehose/)
+ Profil Fargate yang sudah ada yang menentukan namespace Kubernetes yang sudah ada yang kamu gunakan untuk Pod Fargate. Untuk informasi selengkapnya, lihat [Langkah 3: Buat profil Fargate untuk cluster Anda](fargate-getting-started.md#fargate-gs-create-profile).
+ Peran eksekusi Fargate Pod yang ada. Untuk informasi selengkapnya, lihat [Langkah 2: Buat peran eksekusi Fargate Pod](fargate-getting-started.md#fargate-sg-pod-execution-role).
## Konfigurasi router log
**penting**
Agar log berhasil dipublikasikan, harus ada akses jaringan dari VPC tempat klaster Anda berada ke tujuan log. Ini terutama menyangkut pengguna yang menyesuaikan aturan jalan keluar untuk VPC mereka. Untuk contoh menggunakan CloudWatch, lihat [Menggunakan CloudWatch Log dengan titik akhir VPC antarmuka](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html) di Panduan Pengguna *Amazon CloudWatch Logs*.
Pada langkah-langkah berikut, ganti masing-masing *example value* dengan nilai Anda sendiri.
1. Buat namespace Kubernetes khusus bernama. `aws-observability`
1. Simpan konten berikut ini ke file bernama `aws-observability-namespace.yaml` pada komputer Anda. Nilai untuk `name` harus `aws-observability` dan `aws-observability: enabled` label diperlukan.
```
kind: Namespace
apiVersion: v1
metadata:
name: aws-observability
labels:
aws-observability: enabled
```
1. Buat namespace.
```
kubectl apply -f aws-observability-namespace.yaml
```
1. Buat `ConfigMap` dengan nilai `Fluent Conf` data untuk mengirimkan log kontainer ke tujuan. Fluent Conf adalah Fluent Bit, yang merupakan bahasa konfigurasi prosesor log yang cepat dan ringan yang digunakan untuk merutekan log kontainer ke tujuan log pilihan Anda. Untuk informasi lebih lanjut, lihat [File konfigurasi](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file) dalam dokumentasi Fluent Bit.
**penting**
Bagian utama yang termasuk dalam tipikal `Fluent Conf` adalah`Service`,`Input`,`Filter`, dan`Output`. Namun, router log Fargate hanya menerima:
`Output`Bagian `Filter` dan.
Sebuah `Parser` bagian.
Jika Anda memberikan bagian lain, mereka akan ditolak.
Router log Fargate mengelola bagian `Service` dan`Input`. Ini memiliki `Input` bagian berikut, yang tidak dapat dimodifikasi dan tidak diperlukan di Anda`ConfigMap`. Namun, Anda bisa mendapatkan wawasan darinya, seperti batas buffer memori dan tag yang diterapkan untuk log.
```
[INPUT]
Name tail
Buffer_Max_Size 66KB
DB /var/log/flb_kube.db
Mem_Buf_Limit 45MB
Path /var/log/containers/*.log
Read_From_Head On
Refresh_Interval 10
Rotate_Wait 30
Skip_Long_Lines On
Tag kube.*
```
Saat membuat`ConfigMap`, pertimbangkan aturan berikut yang digunakan Fargate untuk memvalidasi bidang:
+ `[FILTER]`,`[OUTPUT]`, dan seharusnya `[PARSER]` ditentukan di bawah setiap kunci yang sesuai. Contohnya, `[FILTER]` harus berada dalam `filters.conf`. Anda dapat memiliki satu atau lebih `[FILTER]` s di bawah`filters.conf`. `[PARSER]`Bagian `[OUTPUT]` dan juga harus berada di bawah kunci yang sesuai. Dengan menentukan beberapa `[OUTPUT]` bagian, Anda dapat merutekan log Anda ke tujuan yang berbeda secara bersamaan.
+ Fargate memvalidasi kunci yang diperlukan untuk setiap bagian. `Name` dan `match` diperlukan untuk setiap `[FILTER]` dan `[OUTPUT]`. `Name` dan `format` diperlukan untuk setiap `[PARSER]`. Kunci peka terhadap huruf besar dan kecil.
+ Variabel lingkungan seperti `${ENV_VAR}` tidak diizinkan di`ConfigMap`.
+ Indentasi harus sama dengan arahan atau pasangan nilai kunci dalam setiap `filters.conf`, `output.conf`, dan `parsers.conf`. Pasangan nilai kunci yang harus menjorok lebih dari arahan.
+ Fargate memvalidasi terhadap filter yang didukung berikut:`grep`,,`parser`,,`record_modifier`, `rewrite_tag` `throttle``nest`, `modify` dan. `kubernetes`
+ Fargate memvalidasi output yang didukung berikut: `es`, `firehose`, `kinesis_firehose`, `cloudwatch`, `cloudwatch_logs`, dan `kinesis`.
+ Setidaknya satu `Output` plugin yang didukung harus disediakan di `ConfigMap` untuk mengaktifkan logging. `Filter`dan `Parser` tidak diperlukan untuk mengaktifkan logging.
Anda juga dapat menjalankan Fluent Bit di Amazon EC2 menggunakan konfigurasi yang diinginkan untuk memecahkan masalah apa pun yang timbul dari validasi. Buat Anda `ConfigMap` menggunakan salah satu contoh berikut.
**penting**
Amazon EKS Fargate logging tidak mendukung konfigurasi dinamis file. `ConfigMap` Setiap perubahan pada a hanya `ConfigMap` diterapkan pada Pod baru. Perubahan tidak diterapkan pada Pod yang ada.
Buat `ConfigMap` menggunakan contoh untuk tujuan log yang Anda inginkan.
**catatan**
Anda juga dapat menggunakan Amazon Kinesis Data Streams untuk tujuan log Anda. Jika Anda menggunakan Kinesis Data Streams, pastikan bahwa peran eksekusi pod telah `kinesis:PutRecords` diberikan izin. Untuk informasi selengkapnya, lihat Izin Amazon Kinesis [Data](https://docs.fluentbit.io/manual/pipeline/outputs/kinesis#permissions) Streams *di Bit Lancar: Manual* Resmi.
**Example**
------
#### [ CloudWatch ]
Anda memiliki dua opsi output saat menggunakan CloudWatch:
+ [Plugin keluaran yang ditulis dalam C](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/cloudwatch)
+ [Plugin keluaran yang ditulis dalam Golang](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit)
Contoh berikut menunjukkan cara menggunakan `cloudwatch_logs` plugin untuk mengirim log ke CloudWatch.
1. Simpan konten berikut ini ke file bernama `aws-logging-cloudwatch-configmap.yaml`. Ganti *region-code* dengan AWS Wilayah tempat cluster Anda berada. Parameter di bawah `[OUTPUT]` diperlukan.
```
kind: ConfigMap
apiVersion: v1
metadata:
name: aws-logging
namespace: aws-observability
data:
flb_log_cw: "false" # Set to true to ship Fluent Bit process logs to CloudWatch.
filters.conf: |
[FILTER]
Name parser
Match *
Key_name log
Parser crio
[FILTER]
Name kubernetes
Match kube.*
Merge_Log On
Keep_Log Off
Buffer_Size 0
Kube_Meta_Cache_TTL 300s
output.conf: |
[OUTPUT]
Name cloudwatch_logs
Match kube.*
region region-code
log_group_name my-logs
log_stream_prefix from-fluent-bit-
log_retention_days 60
auto_create_group true
parsers.conf: |
[PARSER]
Name crio
Format Regex
Regex ^(?