**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.
# Mengotomatiskan infrastruktur klaster dengan Mode Otomatis EKS
**Tip**
[Daftar](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) untuk lokakarya Amazon EKS Auto Mode mendatang.
EKS Auto Mode memperluas AWS pengelolaan klaster Kubernetes di luar klaster itu sendiri, AWS untuk memungkinkan juga menyiapkan dan mengelola infrastruktur yang memungkinkan kelancaran pengoperasian beban kerja Anda. Anda dapat mendelegasikan keputusan infrastruktur utama dan memanfaatkan keahlian AWS untuk day-to-day operasi. Infrastruktur klaster yang dikelola oleh AWS mencakup banyak kemampuan Kubernetes sebagai komponen inti, sebagai lawan dari add-on, seperti compute autoscaling, pod dan service networking, application load balancing, cluster DNS, block storage, dan dukungan GPU.
Untuk memulai, Anda dapat menerapkan kluster Mode Otomatis EKS baru atau mengaktifkan Mode Otomatis EKS pada cluster yang ada. Anda dapat menerapkan, meningkatkan, atau memodifikasi kluster Mode Otomatis EKS Anda menggunakan eksctl, AWS CLI, EKS, Konsol Manajemen AWS atau alat pilihan Anda. APIs infrastructure-as-code
Dengan Mode Otomatis EKS, Anda dapat terus menggunakan alat yang kompatibel dengan Kubernetes pilihan Anda. Mode Otomatis EKS terintegrasi dengan AWS layanan seperti Amazon EC2, Amazon EBS, dan ELB, AWS memanfaatkan sumber daya cloud yang mengikuti praktik terbaik. Sumber daya ini secara otomatis diskalakan, dioptimalkan biaya, dan diperbarui secara berkala untuk membantu meminimalkan biaya operasional dan overhead.
## Fitur
Mode Otomatis EKS menyediakan fitur tingkat tinggi berikut:
**Merampingkan Manajemen Cluster Kubernetes: Mode Otomatis EKS merampingkan manajemen** EKS dengan menyediakan klaster siap produksi dengan overhead operasional minimal. Dengan Mode Otomatis EKS, Anda dapat menjalankan beban kerja dinamis yang menuntut dengan percaya diri, tanpa memerlukan keahlian EKS yang mendalam.
**Ketersediaan Aplikasi**: Mode Otomatis EKS secara dinamis menambahkan atau menghapus node di kluster EKS Anda berdasarkan permintaan aplikasi Kubernetes Anda. Ini meminimalkan kebutuhan akan perencanaan kapasitas manual dan memastikan ketersediaan aplikasi.
**Efisiensi**: Mode Otomatis EKS dirancang untuk mengoptimalkan biaya komputasi sambil mematuhi fleksibilitas yang ditentukan oleh persyaratan Anda NodePool dan beban kerja. Ini juga menghentikan instance yang tidak digunakan dan mengkonsolidasikan beban kerja ke node lain untuk meningkatkan efisiensi biaya.
**Keamanan**: Penggunaan Mode Otomatis EKS AMIs yang diperlakukan sebagai tidak dapat diubah, untuk node Anda. Ini AMIs memberlakukan perangkat lunak terkunci, mengaktifkan kontrol akses SELinux wajib, dan menyediakan sistem file root read-only. Selain itu, node yang diluncurkan oleh EKS Auto Mode memiliki masa pakai maksimum 21 hari (yang dapat Anda kurangi), setelah itu mereka secara otomatis diganti dengan node baru. Pendekatan ini meningkatkan postur keamanan Anda dengan bersepeda node secara teratur, menyelaraskan dengan praktik terbaik yang telah diadopsi oleh banyak pelanggan.
**Upgrade Otomatis**: Mode Otomatis EKS membuat klaster Kubernetes, node, dan komponen terkait tetap up to date dengan patch terbaru, sembari menghormati Pod Disruption Budgets () dan Disruption Budgets () yang sudah dikonfigurasi. PDBs NodePool NDBs Hingga masa pakai maksimum 21 hari, intervensi mungkin diperlukan jika pemblokiran PDBs atau konfigurasi lain mencegah pembaruan.
**Komponen Terkelola**: Mode Otomatis EKS menyertakan Kubernetes dan fitur AWS cloud sebagai komponen inti yang seharusnya harus dikelola sebagai add-on. Ini termasuk dukungan bawaan untuk penetapan alamat IP Pod, kebijakan jaringan Pod, layanan DNS lokal, plug-in GPU, pemeriksa kesehatan, dan penyimpanan EBS CSI.
**Dapat disesuaikan NodePools dan NodeClasses**: Jika beban kerja Anda memerlukan perubahan pada konfigurasi penyimpanan, komputasi, atau jaringan, Anda dapat membuat kustom NodePools dan NodeClasses menggunakan Mode Otomatis EKS. Meskipun Anda tidak boleh mengedit default NodePools dan NodeClasses, Anda dapat menambahkan kustom baru NodePools atau NodeClasses di samping konfigurasi default untuk memenuhi persyaratan spesifik Anda.
## Komponen Otomatis
Mode Otomatis EKS merampingkan pengoperasian kluster Amazon EKS Anda dengan mengotomatiskan komponen infrastruktur utama. Mengaktifkan Mode Otomatis EKS semakin mengurangi tugas untuk mengelola kluster EKS Anda.
Berikut ini adalah daftar komponen bidang data yang otomatis:
+ **Komputasi**: Untuk banyak beban kerja, dengan Mode Otomatis EKS Anda dapat melupakan banyak aspek komputasi untuk kluster EKS Anda. Ini termasuk:
+ **Node**: Node Mode Otomatis EKS dirancang untuk diperlakukan seperti peralatan. Mode Otomatis EKS melakukan hal berikut:
+ Memilih AMI yang sesuai yang dikonfigurasi dengan banyak layanan yang diperlukan untuk menjalankan beban kerja Anda tanpa intervensi.
+ Mengunci akses ke file di AMI menggunakan mode SELinux penegakan dan sistem file root read-only.
+ Mencegah akses langsung ke node dengan melarang akses SSH atau SSM.
+ Termasuk dukungan GPU, dengan driver dan plugin kernel terpisah untuk NVIDIA dan Neuron GPUs, memungkinkan beban kerja berkinerja tinggi.
+ Secara otomatis menangani [pemberitahuan gangguan Instans Spot EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) dan peristiwa kesehatan Instans EC2
+ **Penskalaan otomatis: Mengandalkan** [penskalaan otomatis Karpenter](https://karpenter.sh/docs/), Mode Otomatis EKS memantau Pod yang tidak dapat dijadwalkan dan memungkinkan node baru digunakan untuk menjalankan pod tersebut. Saat beban kerja dihentikan, Mode Otomatis EKS secara dinamis mengganggu dan menghentikan node saat tidak lagi diperlukan, mengoptimalkan penggunaan sumber daya.
+ **Upgrade**: Mengambil kendali node Anda merampingkan kemampuan EKS Auto Mode untuk menyediakan patch keamanan dan sistem operasi dan upgrade komponen sesuai kebutuhan. Upgrade tersebut dirancang untuk memberikan gangguan minimal pada beban kerja Anda. Mode Otomatis EKS memberlakukan masa pakai node maksimum 21 hari untuk memastikan up-to-date perangkat lunak dan. APIs
+ **Load balancing**: EKS Auto Mode merampingkan load balancing dengan mengintegrasikan layanan Elastic Load Balancing Amazon, mengotomatiskan penyediaan dan konfigurasi load balancer untuk Layanan Kubernetes dan sumber daya Ingress. Ini mendukung fitur-fitur canggih untuk Application dan Network Load Balancer, mengelola siklus hidup mereka, dan menskalakannya agar sesuai dengan permintaan klaster. Integrasi ini menyediakan solusi penyeimbangan beban siap produksi yang mengikuti praktik AWS terbaik, memungkinkan Anda untuk fokus pada aplikasi daripada manajemen infrastruktur.
+ **Penyimpanan**: Mode Otomatis EKS mengonfigurasi penyimpanan sementara untuk Anda dengan menyiapkan jenis volume, ukuran volume, kebijakan enkripsi, dan kebijakan penghapusan setelah penghentian node.
+ **Networking**: EKS Auto Mode mengotomatiskan tugas-tugas jaringan penting untuk Pod dan konektivitas layanan. Ini termasuk IPv4/IPv6 dukungan dan penggunaan blok CIDR sekunder untuk memperluas ruang alamat IP.
+ **Identity and Access Management**: Anda tidak perlu menginstal EKS Pod Identity Agent pada kluster Mode Otomatis EKS.
Untuk informasi lebih lanjut tentang komponen ini, lihat[Pelajari cara kerja Mode Otomatis EKS](auto-reference.md).
## Konfigurasi
Meskipun Mode Otomatis EKS akan secara efektif mengelola sebagian besar layanan pesawat data Anda tanpa campur tangan Anda, mungkin ada saat-saat ketika Anda ingin mengubah perilaku beberapa layanan tersebut. Anda dapat memodifikasi konfigurasi kluster Mode Otomatis EKS Anda dengan cara berikut:
+ **Kubernetes DaemonSets**: Daripada memodifikasi layanan yang diinstal pada node Anda, Anda dapat menggunakan daemonset Kubernetes. Daemonset dirancang untuk dikelola oleh Kubernetes, tetapi berjalan di setiap node di cluster. Dengan cara ini, Anda dapat menambahkan layanan khusus untuk memantau atau mengawasi node Anda.
+ **Kustom NodePools dan NodeClasses**: Default NodePools dan NodeClasses dikonfigurasi oleh Mode Otomatis EKS dan Anda tidak boleh mengeditnya. Untuk menyesuaikan perilaku node, Anda dapat membuat tambahan NodePools atau NodeClasses untuk kasus penggunaan seperti:
+ Memilih jenis instans tertentu (misalnya, prosesor yang dipercepat atau instans EC2 Spot).
+ Mengisolasi beban kerja untuk tujuan keamanan atau pelacakan biaya.
+ Mengkonfigurasi pengaturan penyimpanan sementara seperti IOPS, ukuran, dan throughput.
+ **Load Balancing**: Beberapa layanan, seperti load balancing, yang dijalankan EKS Auto Mode sebagai objek Kubernetes, dapat dikonfigurasi langsung pada kluster Mode Otomatis EKS Anda.
Untuk informasi selengkapnya tentang opsi untuk mengonfigurasi Mode Otomatis EKS, lihat[Konfigurasikan pengaturan Mode Otomatis EKS](settings-auto.md).
## Model tanggung jawab bersama
Model Tanggung Jawab AWS Bersama mendefinisikan tanggung jawab keamanan dan kepatuhan antara AWS dan pelanggan. Gambar dan teks di bawah ini membandingkan dan membedakan perbedaan pelanggan dan AWS tanggung jawab antara Mode Otomatis EKS dan mode standar EKS.
![\[Model tanggung jawab bersama dengan Mode Otomatis EKS dan mode standar\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/eksautosrm.png)
Mode Otomatis EKS mengalihkan sebagian besar tanggung jawab bersama untuk infrastruktur Kubernetes dari pelanggan ke. AWS Dengan Mode Otomatis EKS, AWS mengambil lebih banyak tanggung jawab untuk keamanan cloud, yang dulunya merupakan tanggung jawab pelanggan dan sekarang dibagikan. Pelanggan sekarang dapat lebih fokus pada aplikasi mereka sambil AWS mengelola infrastruktur yang mendasarinya.
**Tanggung jawab pelanggan**
Di bawah Mode Otomatis EKS, pelanggan terus bertanggung jawab atas wadah aplikasi, termasuk ketersediaan, keamanan, dan pemantauan. Mereka juga mempertahankan kontrol atas infrastruktur VPC dan konfigurasi cluster EKS. Model ini memungkinkan pelanggan berkonsentrasi pada masalah khusus aplikasi sambil mendelegasikan manajemen infrastruktur klaster ke. AWS Fitur per-node opsional dapat dimasukkan dalam cluster melalui add-on. AWS
** AWS tanggung jawab**
Dengan Mode Otomatis EKS, AWS memperluas tanggung jawabnya untuk memasukkan pengelolaan beberapa komponen penting tambahan dibandingkan dengan yang sudah dikelola di kluster EKS yang tidak menggunakan Mode Otomatis. Secara khusus, Mode Otomatis EKS mengambil alih konfigurasi, manajemen, keamanan, dan penskalaan instans EC2 yang diluncurkan serta kemampuan cluster untuk penyeimbangan beban, manajemen alamat IP, kebijakan jaringan, dan penyimpanan blok. Komponen-komponen berikut dikelola oleh AWS dalam Mode Otomatis EKS:
+ Instans **EC2 yang diluncurkan Mode Otomatis: AWS menangani siklus hidup lengkap node dengan memanfaatkan instans** terkelola Amazon EC2. Instans terkelola EC2 bertanggung jawab atas konfigurasi sistem operasi, penambalan, pemantauan, dan pemeliharaan kesehatan. Dalam model ini, baik instance itu sendiri maupun sistem operasi tamu yang berjalan di atasnya adalah tanggung jawab AWS. Node menggunakan varian [Bottlerocket](https://aws.amazon.com/bottlerocket) AMIs yang dioptimalkan untuk menjalankan kontainer. Bottlerocket AMIs memiliki perangkat lunak terkunci, sistem file root yang tidak dapat diubah, dan akses jaringan yang aman (untuk mencegah komunikasi langsung melalui SSH atau SSM).
+ **Kemampuan Cluster**: AWS mengelola komputasi autoscaling, jaringan Pod dengan penegakan kebijakan jaringan, integrasi Elastic Load Balancing, dan konfigurasi driver penyimpanan.
+ **Cluster Control Plane**: AWS terus mengelola server API Kubernetes, cross-account ENIs, dan database etcd, seperti EKS standar.
+ **Layanan Foundation dan Infrastruktur Global**: AWS mempertahankan tanggung jawab atas layanan komputasi, penyimpanan, jaringan, dan pemantauan yang mendasarinya, serta infrastruktur global wilayah, zona lokal, dan lokasi tepi.
# Buat cluster dengan Amazon EKS Auto Mode
Bab ini menjelaskan cara membuat cluster Amazon EKS dengan Mode Otomatis diaktifkan menggunakan berbagai alat dan antarmuka. Mode Otomatis menyederhanakan pembuatan klaster dengan mengonfigurasi dan mengelola infrastruktur komputasi, jaringan, dan penyimpanan cluster secara otomatis. Anda akan belajar cara membuat cluster Mode Otomatis menggunakan AWS CLI, Konsol Manajemen AWS, atau alat baris perintah eksctl.
**catatan**
Mode Otomatis EKS membutuhkan Kubernetes versi 1.29 atau lebih tinggi.
Pilih alat pilihan Anda berdasarkan kebutuhan Anda: Konsol Manajemen AWS Ini menyediakan antarmuka visual yang ideal untuk mempelajari fitur Mode Otomatis EKS dan membuat cluster individual. AWS CLI paling cocok untuk tugas scripting dan otomatisasi, terutama saat mengintegrasikan pembuatan cluster ke dalam alur kerja atau pipeline yang ada. CI/CD CLI eksctl menawarkan pengalaman asli Kubernetes dan direkomendasikan bagi pengguna yang akrab dengan perkakas Kubernetes yang menginginkan operasi baris perintah yang disederhanakan dengan default yang masuk akal.
Sebelum memulai, pastikan Anda memiliki prasyarat yang diperlukan diinstal dan dikonfigurasi, termasuk izin IAM yang sesuai untuk membuat kluster EKS. Untuk mempelajari cara menginstal alat CLI seperti`kubectl`,, dan `aws``eksctl`, lihat. [Siapkan untuk menggunakan Amazon EKS](setting-up.md)
Anda dapat menggunakan AWS CLI, Konsol Manajemen AWS, atau eksctl CLI untuk membuat cluster dengan Amazon EKS Auto Mode.
**Topics**
+ [Buat Kluster Mode Otomatis EKS dengan CLI eksctl](automode-get-started-eksctl.md)
+ [Buat Kluster Mode Otomatis EKS dengan AWS CLI](automode-get-started-cli.md)
+ [Buat Kluster Mode Otomatis EKS dengan Konsol Manajemen AWS](automode-get-started-console.md)
# Buat Kluster Mode Otomatis EKS dengan CLI eksctl
Topik ini menunjukkan cara membuat cluster Amazon EKS Auto Mode menggunakan antarmuka baris perintah eksctl (CLI). Anda dapat membuat kluster Mode Otomatis baik dengan menjalankan satu perintah CLI atau dengan menerapkan file konfigurasi YAMAL. Kedua metode menyediakan fungsionalitas yang sama, dengan pendekatan YAMAL yang menawarkan kontrol yang lebih terperinci atas pengaturan cluster.
CLI eksctl menyederhanakan proses pembuatan dan pengelolaan kluster Mode Otomatis EKS dengan menangani pembuatan dan konfigurasi sumber daya yang mendasarinya. AWS Sebelum melanjutkan, pastikan Anda memiliki AWS kredensi dan izin yang diperlukan yang dikonfigurasi pada mesin lokal Anda. Panduan ini mengasumsikan Anda terbiasa dengan konsep dasar Amazon EKS dan telah menginstal alat CLI yang diperlukan.
**catatan**
Anda harus menginstal versi `0.195.0` atau lebih besar dari eksctl. Untuk informasi lebih lanjut, lihat rilis [eksctl](https://github.com/eksctl-io/eksctl/releases) di. GitHub
## Buat kluster Mode Otomatis EKS dengan perintah CLI
Anda harus memiliki `aws` dan `eksctl` alat yang diinstal. Anda harus masuk ke AWS CLI dengan izin yang cukup untuk mengelola AWS sumber daya termasuk: EC2 instance, EC2 jaringan, kluster EKS, dan peran IAM. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
Jalankan perintah berikut untuk membuat kluster Mode Otomatis EKS baru dengan
```
eksctl create cluster --name= --enable-auto-mode
```
## Buat kluster Mode Otomatis EKS dengan file YAMAL
Anda harus memiliki `aws` dan `eksctl` alat yang diinstal. Anda harus masuk ke AWS CLI dengan izin yang cukup untuk mengelola AWS sumber daya termasuk: EC2 instance, EC2 jaringan, kluster EKS, dan peran IAM. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
Tinjau opsi konfigurasi Mode Otomatis EKS dalam ClusterConfig sumber daya contoh di bawah ini. Untuk ClusterConfig spesifikasi lengkapnya, lihat dokumentasi [eksctl](https://eksctl.io/usage/creating-and-managing-clusters/).
AWS menyarankan mengaktifkan Mode Otomatis EKS. Jika ini adalah pertama kalinya Anda membuat kluster Mode Otomatis EKS, biarkan yang `nodeRoleARN` tidak ditentukan untuk membuat Peran IAM Node untuk Mode Otomatis EKS. Jika Anda sudah memiliki Peran IAM Node di AWS akun Anda, AWS sarankan untuk menggunakannya kembali.
AWS menyarankan untuk tidak menentukan nilai apa pun untuk`nodePools`. Mode Otomatis EKS akan membuat kumpulan node default. Anda dapat menggunakan API Kubernetes untuk membuat kumpulan node tambahan.
```
# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name:
region:
iam:
# ARN of the Cluster IAM Role
# optional, eksctl creates a new role if not supplied
# suggested to use one Cluster IAM Role per account
serviceRoleARN:
autoModeConfig:
# defaults to false
enabled: boolean
# optional, defaults to [general-purpose, system].
# suggested to leave unspecified
# To disable creation of nodePools, set it to the empty array ([]).
nodePools: []string
# optional, eksctl creates a new role if this is not supplied
# and nodePools are present.
nodeRoleARN: string
```
Simpan `ClusterConfig` file sebagai`cluster.yaml`, dan gunakan perintah berikut untuk membuat cluster:
```
eksctl create cluster -f cluster.yaml
```
# Buat Kluster Mode Otomatis EKS dengan AWS CLI
EKS Auto Mode Clusters mengotomatiskan tugas manajemen cluster rutin untuk komputasi, penyimpanan, dan jaringan. Misalnya, Kluster Mode Otomatis EKS secara otomatis mendeteksi kapan node tambahan diperlukan dan menyediakan instans EC2 baru untuk memenuhi tuntutan beban kerja.
Topik ini memandu Anda dalam membuat Kluster Mode Otomatis EKS baru menggunakan AWS CLI dan secara opsional menerapkan contoh beban kerja.
## Prasyarat
+ Versi terbaru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda. Untuk memeriksa versi Anda saat ini, gunakan`aws --version`. Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) dan [Konfigurasi cepat](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) dengan aws configure di Panduan Pengguna Antarmuka Baris AWS Perintah.
+ Masuk ke CLI dengan izin IAM yang cukup untuk membuat AWS sumber daya termasuk Kebijakan IAM, Peran IAM, dan Kluster EKS.
+ Alat baris perintah kubectl diinstal pada perangkat Anda. AWS menyarankan Anda menggunakan versi kubectl yang sama dengan versi Kubernetes dari EKS Cluster Anda. Untuk menginstal atau meng-upgrade kubectl, lihat. [Mengatur `kubectl` dan `eksctl`](install-kubectl.md)
## Tentukan subnet VPC
Mode Otomatis Amazon EKS menyebarkan node ke subnet VPC. Saat membuat cluster EKS, Anda harus menentukan subnet VPC tempat node akan digunakan. Anda dapat menggunakan subnet VPC default di AWS akun Anda atau membuat VPC khusus untuk beban kerja kritis.
+ AWS menyarankan untuk membuat VPC khusus untuk cluster Anda. Pelajari cara [Buat VPC Amazon untuk kluster Amazon EKS Anda](creating-a-vpc.md).
+ Konsol EKS membantu menciptakan VPC baru. Pelajari cara [Buat Kluster Mode Otomatis EKS dengan Konsol Manajemen AWS](automode-get-started-console.md).
+ Atau, Anda dapat menggunakan VPC default akun Anda AWS . Gunakan instruksi berikut untuk menemukan Subnet IDs.
### Untuk menemukan Subnet IDs dari VPC default Anda
**Menggunakan AWS CLI:**
1. Jalankan perintah berikut untuk membuat daftar VPC default dan subnetnya:
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$(aws ec2 describe-vpcs --query 'Vpcs[?IsDefault==`true`].VpcId' --output text)" --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone}' --output table
```
1. Simpan output dan perhatikan **Subnet IDs**.
Contoh output:
```
----------------------------------------
| DescribeSubnets |
----------------------------------------
| SubnetId | AvailabilityZone |
|--------------------|---------------------|
| subnet-012345678 | us-west-2a |
| subnet-234567890 | us-west-2b |
| subnet-345678901 | us-west-2c |
----------------------------------------
```
## Peran IAM untuk Kluster Mode Otomatis EKS
### Peran IAM Cluster
Mode Otomatis EKS memerlukan Peran IAM Cluster untuk melakukan tindakan di AWS akun Anda, seperti menyediakan instans EC2 baru. Anda harus membuat peran ini untuk memberikan EKS izin yang diperlukan. AWS merekomendasikan untuk melampirkan kebijakan AWS terkelola berikut ke Peran IAM Cluster:
+ [EKSComputeKebijakan Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [Amazon EKSBlock StoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [Amazon EKSLoad BalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingKebijakan Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterKebijakan Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
### Peran IAM Node
Saat Anda membuat kluster Mode Otomatis EKS, Anda menentukan Peran IAM Node. Ketika Mode Otomatis EKS membuat node untuk memproses beban kerja yang tertunda, setiap node instans EC2 baru diberi Peran IAM Node. Peran ini memungkinkan node untuk berkomunikasi dengan EKS tetapi umumnya tidak diakses oleh beban kerja yang berjalan pada node.
Jika Anda ingin memberikan izin untuk beban kerja yang berjalan pada sebuah node, gunakan EKS Pod Identity. Untuk informasi selengkapnya, lihat [Pelajari cara EKS Pod Identity memberikan akses Pod ke layanan AWS](pod-identities.md).
Anda harus membuat peran ini dan melampirkan kebijakan AWS terkelola berikut:
+ [Amazon EKSWorker NodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [Amazon EC2 ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
Mode Otomatis EKS juga memerlukan Peran Tertaut Layanan, yang secara otomatis dibuat dan dikonfigurasi oleh. AWS Untuk informasi lebih lanjut, lihat [AWSServiceRoleForAmazonEKS](using-service-linked-roles-eks.md).
## Membuat Peran IAM Kluster Mode Otomatis EKS
### Langkah 1: Buat Kebijakan Kepercayaan
Buat kebijakan kepercayaan yang memungkinkan layanan Amazon EKS untuk mengambil peran. Simpan kebijakan sebagai`trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### Langkah 2: Buat Peran IAM
Gunakan kebijakan kepercayaan untuk membuat Peran IAM Cluster:
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
### Langkah 3: Perhatikan Peran ARN
Ambil dan simpan ARN dari peran baru untuk digunakan dalam langkah-langkah selanjutnya:
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
### Langkah 4: Lampirkan Kebijakan yang Diperlukan
Lampirkan kebijakan AWS terkelola berikut ke Peran IAM Cluster untuk memberikan izin yang diperlukan:
**EKSClusterKebijakan Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
**EKSComputeKebijakan Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSComputePolicy
```
**Amazon EKSBlock StoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**Amazon EKSLoad BalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**EKSNetworkingKebijakan Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSNetworkingPolicy
```
## Buat Peran IAM Node Mode Otomatis EKS
### Langkah 1: Buat Kebijakan Kepercayaan
Buat kebijakan kepercayaan yang memungkinkan layanan Amazon EKS untuk mengambil peran. Simpan kebijakan sebagai`node-trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### Langkah 2: Buat Peran IAM Node
Gunakan **node-trust-policyfile.json** dari langkah sebelumnya untuk menentukan entitas mana yang dapat mengambil peran. Jalankan perintah berikut untuk membuat Peran IAM Node:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### Langkah 3: Perhatikan Peran ARN
Setelah membuat peran, ambil dan simpan ARN dari Peran IAM Node. Anda akan membutuhkan ARN ini pada langkah selanjutnya. Gunakan perintah berikut untuk mendapatkan ARN:
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### Langkah 4: Lampirkan Kebijakan yang Diperlukan
Lampirkan kebijakan AWS terkelola berikut ke Peran IAM Node untuk memberikan izin yang diperlukan:
**Amazon EKSWorker NodeMinimalPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**Amazon EC2 ContainerRegistryPullOnly**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
## Buat Kluster Mode Otomatis EKS
### Ikhtisar
Untuk membuat Kluster Mode Otomatis EKS menggunakan AWS CLI, Anda memerlukan parameter berikut:
+ `cluster-name`: Nama cluster.
+ `k8s-version`: Versi Kubernetes (mis., 1.31).
+ `subnet-ids`: Subnet IDs diidentifikasi pada langkah sebelumnya.
+ `cluster-role-arn`: ARN dari Peran IAM Cluster.
+ `node-role-arn`: ARN dari Peran IAM Node.
#### Konfigurasi Cluster Default
Tinjau nilai dan fitur default ini sebelum membuat cluster:
+ `nodePools`: Mode Otomatis EKS mencakup Pools Node standar tujuan umum dan sistem. Pelajari lebih lanjut tentang [Node Pools](create-node-pool.md).
**Catatan:** Kumpulan Node dalam Mode Otomatis EKS berbeda dari Grup Node Terkelola Amazon EKS tetapi dapat hidup berdampingan di cluster yang sama.
+ `computeConfig.enabled`: Mengotomatiskan tugas komputasi rutin, seperti membuat dan menghapus instans EC2.
+ `kubernetesNetworkConfig.elasticLoadBalancing.enabled`: Mengotomatiskan tugas penyeimbangan beban, termasuk membuat dan menghapus Elastic Load Balancer.
+ `storageConfig.blockStorage.enabled`: Mengotomatiskan tugas penyimpanan, seperti membuat dan menghapus volume Amazon EBS.
+ `accessConfig.authenticationMode`: Memerlukan entri akses EKS. Pelajari lebih lanjut tentang [mode otentikasi EKS](grant-k8s-access.md).
#### Jalankan Perintah
Gunakan perintah berikut untuk membuat cluster:
```
aws eks create-cluster \
--region ${AWS_REGION} \
--cli-input-json \
"{
\"name\": \"${CLUSTER_NAME}\",
\"version\": \"${K8S_VERSION}\",
\"roleArn\": \"${CLUSTER_ROLE_ARN}\",
\"resourcesVpcConfig\": {
\"subnetIds\": ${SUBNETS_JSON},
\"endpointPublicAccess\": true,
\"endpointPrivateAccess\": true
},
\"computeConfig\": {
\"enabled\": true,
\"nodeRoleArn\":\"${NODE_ROLE_ARN}\",
\"nodePools\": [\"general-purpose\", \"system\"]
},
\"kubernetesNetworkConfig\": {
\"elasticLoadBalancing\": {
\"enabled\": true
}
},
\"storageConfig\": {
\"blockStorage\": {
\"enabled\": true
}
},
\"accessConfig\": {
\"authenticationMode\": \"API\"
}
}"
```
### Periksa Status Cluster
#### Langkah 1: Verifikasi Pembuatan Cluster
Jalankan perintah berikut untuk memeriksa status cluster Anda. Pembuatan cluster biasanya memakan waktu sekitar 15 menit:
```
aws eks describe-cluster --name "${CLUSTER_NAME}" --output json
```
#### Langkah 2: Perbarui kubeconfig
Setelah cluster siap, perbarui file kubeconfig lokal Anda `kubectl` untuk mengaktifkan komunikasi dengan cluster. Konfigurasi ini menggunakan AWS CLI untuk otentikasi.
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
#### Langkah 3: Verifikasi Node Pools
Buat daftar Node Pools di cluster Anda menggunakan perintah berikut:
```
kubectl get nodepools
```
## Langkah Berikutnya
+ Pelajari cara [menerapkan beban kerja sampel](automode-workload.md) ke kluster Mode Otomatis EKS baru Anda.
# Buat Kluster Mode Otomatis EKS dengan Konsol Manajemen AWS
Membuat kluster Mode Otomatis EKS di Konsol Manajemen AWS memerlukan konfigurasi yang lebih sedikit daripada opsi lain. EKS terintegrasi dengan AWS IAM dan VPC Networking untuk membantu Anda membuat sumber daya yang terkait dengan cluster EKS.
Anda memiliki dua opsi untuk membuat cluster di konsol:
+ Konfigurasi cepat (dengan Mode Otomatis EKS)
+ Konfigurasi kustom
Dalam topik ini, Anda akan belajar cara membuat kluster Mode Otomatis EKS menggunakan opsi konfigurasi Cepat.
## Buat Mode Otomatis EKS menggunakan opsi konfigurasi cepat
Anda harus masuk ke Konsol Manajemen AWS dengan izin yang cukup untuk mengelola AWS sumber daya termasuk: EC2 instance, EC2 jaringan, kluster EKS, dan peran IAM.
1. Arahkan ke Konsol EKS
1. Klik **Buat klaster**
1. Konfirmasikan opsi **konfigurasi Cepat** dipilih
1. Tentukan nilai-nilai berikut, atau gunakan default untuk cluster uji.
+ **Nama** Cluster
+ Versi Kubernetes
1. Pilih Peran IAM Cluster. Jika ini adalah pertama kalinya Anda membuat kluster Mode Otomatis EKS, gunakan opsi **Buat peran yang direkomendasikan**.
+ Secara opsional, Anda dapat menggunakan kembali satu Peran IAM Cluster di AWS akun Anda untuk semua kluster Mode Otomatis EKS.
+ Peran IAM Cluster mencakup izin yang diperlukan untuk Mode Otomatis EKS untuk mengelola sumber daya termasuk EC2 instans, volume EBS, dan penyeimbang beban. EC2
+ Opsi **Buat peran yang direkomendasikan** mengisi semua bidang dengan nilai yang disarankan. Pilih **Berikutnya** dan kemudian **Buat**. Peran akan menggunakan `AmazonEKSAutoClusterRole` nama yang disarankan.
+ Jika Anda baru saja membuat peran baru, gunakan ikon **Refresh** untuk memuat ulang tarik-turun pemilihan peran.
1. Pilih Peran IAM Node. Jika ini adalah pertama kalinya Anda membuat kluster Mode Otomatis EKS, gunakan opsi **Buat peran yang direkomendasikan**.
+ Secara opsional, Anda dapat menggunakan kembali satu Peran IAM Node di AWS akun Anda untuk semua kluster Mode Otomatis EKS.
+ Peran IAM Node menyertakan izin yang diperlukan untuk node Mode Otomatis untuk terhubung ke cluster. Peran IAM Node harus menyertakan izin untuk mengambil gambar ECR untuk kontainer Anda.
+ Opsi **Buat peran yang direkomendasikan** mengisi semua bidang dengan nilai yang disarankan. Pilih **Berikutnya** dan kemudian **Buat**. Peran akan menggunakan `AmazonEKSAutoNodeRole` nama yang disarankan.
+ Jika Anda baru saja membuat peran baru, gunakan ikon **Refresh** untuk memuat ulang tarik-turun pemilihan peran.
1. Pilih VPC untuk kluster Mode Otomatis EKS Anda. Pilih **Create VPC untuk membuat VPC** baru untuk EKS, atau pilih VPC yang sebelumnya Anda buat untuk EKS.
+ Jika Anda menggunakan Konsol VPC untuk membuat VPC baru, AWS sarankan Anda membuat setidaknya satu Gateway NAT per Availability Zone. Jika tidak, Anda dapat menggunakan semua default lainnya.
+ Untuk informasi selengkapnya dan detail persyaratan IPv6 klaster, lihat[Buat VPC Amazon untuk kluster Amazon EKS Anda](creating-a-vpc.md).
1. (opsional) Mode Otomatis EKS secara otomatis mengisi subnet pribadi untuk VPC pilihan Anda. Anda dapat menghapus subnet yang tidak diinginkan.
+ EKS secara otomatis memilih subnet pribadi dari VPC mengikuti praktik terbaik. Anda dapat memilih subnet tambahan dari VPC, seperti subnet publik.
1. (opsional) Pilih **Lihat default konfigurasi cepat** untuk meninjau semua nilai konfigurasi untuk cluster baru. Tabel menunjukkan beberapa nilai tidak dapat diedit setelah cluster dibuat.
1. Pilih **Buat klaster**. Perhatikan bahwa mungkin diperlukan waktu lima belas menit untuk menyelesaikan pembuatan klaster.
## Langkah Berikutnya
+ Pelajari cara [Menerapkan Beban Kerja Sampel ke kluster Mode Otomatis EKS](sample-storage-workload.md)
# Aktifkan Mode Otomatis EKS pada kluster EKS yang ada
Anda dapat mengaktifkan Mode Otomatis EKS pada Kluster EKS yang ada.
** AWS mendukung migrasi berikut:**
+ Bermigrasi dari Karpenter ke node Mode Otomatis EKS. Untuk informasi selengkapnya, lihat [Migrasi dari Karpenter ke Mode Otomatis EKS menggunakan kubectl](auto-migrate-karpenter.md).
+ Bermigrasi dari Grup Node Terkelola EKS ke node Mode Otomatis EKS. Untuk informasi selengkapnya, lihat [Migrasi dari Grup Node Terkelola EKS ke Mode Otomatis EKS](auto-migrate-mng.md).
+ Bermigrasi dari EKS Fargate ke Mode Otomatis EKS. Untuk informasi selengkapnya, lihat [Bermigrasi dari EKS Fargate ke Mode Otomatis EKS](auto-migrate-fargate.md).
** AWS tidak mendukung migrasi berikut:**
+ Migrasi volume dari pengontrol EBS CSI (menggunakan add-on Amazon EKS) ke pengontrol EKS Auto Mode EBS CSI (dikelola oleh Mode Otomatis EKS). PVCs dibuat dengan satu tidak dapat dipasang oleh yang lain, karena mereka menggunakan dua penyedia volume Kubernetes yang berbeda.
+ Proyek [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool)(AWS Labs) memungkinkan migrasi antara standar EBS CSI StorageClass (`ebs.csi.aws.com`) dan EKS Auto EBS StorageClass CSI (). `ebs.csi.eks.amazonaws.com` Perhatikan bahwa migrasi memerlukan penghapusan dan pembuatan ulang PersistentVolumeClaim/PersistentVolume sumber daya yang ada, jadi validasi di lingkungan non-produksi sangat penting sebelum implementasi.
+ Migrasi load balancer dari Load Balancer Controller ke AWS Mode Otomatis EKS
Anda dapat menginstal AWS Load Balancer Controller pada kluster Mode Otomatis Amazon EKS. Gunakan `loadBalancerClass` opsi `IngressClass` atau untuk mengaitkan sumber daya Service dan Ingress dengan Load Balancer Controller atau EKS Auto Mode.
+ Migrasi kluster EKS dengan konfigurasi jaringan alternatif CNIs atau lainnya yang tidak didukung
## Referensi migrasi
Gunakan referensi migrasi berikut untuk mengonfigurasi sumber daya Kubernetes yang akan dimiliki oleh pengontrol yang dikelola sendiri atau Mode Otomatis EKS.
| Kemampuan | Sumber Daya | Bidang | Dikelola Sendiri | Mode Otomatis EKS |
| --- | --- | --- | --- | --- |
| Penyimpanan blok | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| Penyeimbangan beban | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| Penyeimbangan beban | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| Penyeimbangan beban | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Penyeimbangan beban | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Komputasi | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## Migrasi volume EBS
Saat memigrasikan beban kerja ke Mode Otomatis EKS, Anda perlu menangani migrasi volume EBS karena penyedia driver CSI yang berbeda:
+ Penyedia Mode Otomatis EKS: `ebs.csi.eks.amazonaws.com`
+ Penyedia EBS CSI sumber terbuka: `ebs.csi.aws.com`
Ikuti langkah-langkah berikut untuk memigrasikan volume persisten Anda:
1. **Ubah kebijakan retensi volume**: Ubah versi platform (PV) yang ada `persistentVolumeReclaimPolicy` `Retain` untuk memastikan volume EBS yang mendasarinya tidak dihapus.
1. **Hapus PV dari Kubernetes**: Hapus sumber daya PV lama sambil menjaga volume EBS yang sebenarnya tetap utuh.
1. **Buat PV baru dengan penyediaan statis: Buat PV baru yang mereferensikan** volume EBS yang sama tetapi berfungsi dengan driver CSI target.
1. **Mengikat ke PVC baru: Buat PVC baru** yang secara khusus mereferensikan PV Anda menggunakan `volumeName` bidang.
### Pertimbangan
+ Pastikan aplikasi Anda dihentikan sebelum memulai migrasi ini.
+ Cadangkan data Anda sebelum memulai proses migrasi.
+ Proses ini perlu dilakukan untuk setiap volume persisten.
+ Beban kerja harus diperbarui untuk menggunakan PVC baru.
## Migrasi penyeimbang beban
Anda tidak dapat langsung mentransfer penyeimbang beban yang ada dari pengontrol penyeimbang AWS beban yang dikelola sendiri ke Mode Otomatis EKS. Sebagai gantinya, Anda harus menerapkan strategi penyebaran biru-hijau. Ini melibatkan mempertahankan konfigurasi penyeimbang beban yang ada saat membuat penyeimbang beban baru di bawah pengontrol terkelola.
Untuk meminimalkan gangguan layanan, kami merekomendasikan pendekatan perpindahan lalu lintas berbasis DNS. Pertama, buat penyeimbang beban baru dengan menggunakan Mode Otomatis EKS sambil menjaga konfigurasi yang ada tetap beroperasi. Kemudian, gunakan perutean DNS (seperti Route 53) untuk secara bertahap mengalihkan lalu lintas dari penyeimbang beban lama ke yang baru. Setelah lalu lintas berhasil dimigrasi dan Anda telah memverifikasi konfigurasi baru, Anda dapat menonaktifkan penyeimbang beban lama dan pengontrol yang dikelola sendiri.
# Aktifkan Mode Otomatis EKS pada cluster yang ada
Topik ini menjelaskan cara mengaktifkan Mode Otomatis Amazon EKS di kluster Amazon EKS Anda yang ada. Mengaktifkan Mode Otomatis pada cluster yang ada memerlukan pembaruan izin IAM dan mengonfigurasi pengaturan Mode Otomatis EKS inti. Setelah diaktifkan, Anda dapat mulai memigrasikan beban kerja komputasi yang ada untuk memanfaatkan operasi Mode Otomatis yang disederhanakan dan manajemen infrastruktur otomatis.
**penting**
Pastikan Anda memiliki versi minimum yang diperlukan dari Add-on Amazon EKS tertentu yang diinstal sebelum mengaktifkan Mode Otomatis EKS. Untuk informasi selengkapnya, lihat [Versi add-on yang diperlukan](#auto-addons-required).
Sebelum memulai, pastikan Anda memiliki akses administrator ke klaster Amazon EKS dan izin untuk mengubah peran IAM. Langkah-langkah dalam topik ini memandu Anda melalui mengaktifkan Mode Otomatis menggunakan AWS CLI Konsol Manajemen AWS atau.
## Konsol Manajemen AWS
Anda harus masuk ke AWS konsol dengan izin untuk mengelola IAM, EKS, dan EC2 sumber daya.
**catatan**
Peran IAM Cluster dari EKS Cluster tidak dapat diubah setelah cluster dibuat. Mode Otomatis EKS memerlukan izin tambahan pada peran ini. Anda harus melampirkan kebijakan tambahan ke peran saat ini.
### Perbarui peran IAM Cluster
1. Buka halaman ikhtisar cluster Anda di Konsol Manajemen AWS.
1. Di bawah **ARN peran IAM Cluster**, **pilih Lihat** di IAM.
1. **Dari tarik-turun **Tambahkan Izin**, pilih Lampirkan Kebijakan.**
1. Gunakan kotak **Pencarian** untuk menemukan dan memilih kebijakan berikut:
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. Pilih **Tambahkan izin**
1. Dari tab **Hubungan kepercayaan**, pilih **Edit kebijakan kepercayaan**
1. Masukkan kebijakan kepercayaan Peran IAM Cluster berikut, lalu pilih **Perbarui** kebijakan
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### Aktifkan Mode Otomatis EKS
1. Buka halaman ikhtisar cluster Anda di Konsol Manajemen AWS.
1. Di bawah **Mode Otomatis EKS** pilih **Kelola**
1. Alihkan **Mode Otomatis EKS ke aktif**.
1. Dari dropdown **EKS Node Pool**, pilih kumpulan node default yang ingin Anda buat.
+ Pelajari lebih lanjut tentang Node Pools dalam Mode Otomatis EKS. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
1. Jika sebelumnya Anda telah membuat peran IAM Node Mode Otomatis EKS di AWS akun ini, pilih di dropdown **Peran IAM Node**. Jika Anda belum membuat peran ini sebelumnya, pilih **Buat Peran yang direkomendasikan** dan ikuti langkah-langkahnya.
## AWS CLI
### Prasyarat
+ Peran IAM Cluster dari Kluster EKS yang ada harus menyertakan izin yang cukup untuk Mode Otomatis EKS, seperti kebijakan berikut:
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ Peran IAM Cluster harus memiliki kebijakan kepercayaan yang diperbarui termasuk `sts:TagSession` tindakan. Untuk informasi selengkapnya tentang membuat Peran IAM Cluster, lihat[Buat Kluster Mode Otomatis EKS dengan AWS CLI](automode-get-started-cli.md).
+ `aws`CLI diinstal, masuk, dan versi yang cukup. Anda harus memiliki izin untuk mengelola IAM, EKS, dan EC2 sumber daya. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
### Prosedur
Gunakan perintah berikut untuk mengaktifkan Mode Otomatis EKS pada cluster yang ada.
**catatan**
Kemampuan komputasi, penyimpanan blok, dan penyeimbangan beban semuanya harus diaktifkan atau dinonaktifkan dalam permintaan yang sama.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## Versi add-on yang diperlukan
Jika Anda berencana untuk mengaktifkan Mode Otomatis EKS pada klaster yang ada, Anda mungkin perlu memperbarui add-on tertentu. Harap dicatat:
+ Ini hanya berlaku untuk klaster yang ada yang beralih ke Mode Otomatis EKS.
+ Cluster baru yang dibuat dengan Mode Otomatis EKS diaktifkan tidak memerlukan pembaruan ini.
Jika Anda memiliki salah satu add-on berikut yang diinstal, pastikan mereka setidaknya pada versi minimum yang ditentukan:
| Nama add-on | Versi minimum yang diperlukan |
| --- | --- |
| Plugin Amazon VPC CNI untuk Kubernetes | v1.19.0-eksbuild.1 |
| Proksi Kube | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/auto-enable-existing.html) |
| Driver CSI Amazon EBS | v1.37.0-eksbuild.1 |
| Pengontrol snapshot CSI | v8.1.0-eksbuild.2 |
| Agen Identitas EKS Pod | v1.3.4-eksbuild.1 |
Untuk informasi selengkapnya, lihat [Perbarui add-on Amazon EKS](updating-an-add-on.md).
## Langkah Berikutnya
+ Untuk memigrasikan beban kerja Kelola Grup Node, lihat. [Migrasi dari Grup Node Terkelola EKS ke Mode Otomatis EKS](auto-migrate-mng.md)
+ Untuk bermigrasi dari Karpenter yang Dikelola Sendiri, lihat. [Migrasi dari Karpenter ke Mode Otomatis EKS menggunakan kubectl](auto-migrate-karpenter.md)
# Migrasi dari Karpenter ke Mode Otomatis EKS menggunakan kubectl
Topik ini memandu Anda melalui proses migrasi beban kerja dari Karpenter ke Amazon EKS Auto Mode menggunakan kubectl. Migrasi dapat dilakukan secara bertahap, memungkinkan Anda untuk memindahkan beban kerja dengan kecepatan Anda sendiri sambil menjaga stabilitas klaster dan ketersediaan aplikasi selama transisi.
step-by-stepPendekatan yang diuraikan di bawah ini memungkinkan Anda menjalankan Mode Otomatis Karpenter dan EKS secara berdampingan selama periode migrasi. Strategi operasi ganda ini membantu memastikan transisi yang mulus dengan memungkinkan Anda memvalidasi perilaku beban kerja pada Mode Otomatis EKS sebelum sepenuhnya menonaktifkan Karpenter. Anda dapat memigrasikan aplikasi secara individu atau dalam kelompok, memberikan fleksibilitas untuk mengakomodasi persyaratan operasional spesifik dan toleransi risiko Anda.
## Prasyarat
Sebelum memulai migrasi, pastikan Anda memiliki:
+ Karpenter v1.1 atau yang lebih baru diinstal pada cluster Anda. Untuk informasi selengkapnya, lihat [Memutakhirkan ke 1.1.0\$1](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110) di dokumen Karpenter.
+ `kubectl`diinstal dan terhubung ke cluster Anda. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
Topik ini mengasumsikan Anda akrab dengan Karpenter dan. NodePools Untuk informasi lebih lanjut, lihat Dokumentasi [Karpenter](https://karpenter.sh/).
## Langkah 1: Aktifkan Mode Otomatis EKS di cluster
Aktifkan Mode Otomatis EKS di cluster Anda yang ada menggunakan AWS CLI atau Management Console. Untuk informasi selengkapnya, lihat [Aktifkan Mode Otomatis EKS pada cluster yang ada](auto-enable-existing.md).
**catatan**
Saat mengaktifkan Mode Otomatis EKS, jangan aktifkan `general purpose` nodepool pada tahap ini selama transisi. Kumpulan node ini tidak selektif.
Untuk informasi selengkapnya, lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
## Langkah 2: Buat Mode Otomatis EKS yang tercemar NodePool
Buat yang baru NodePool untuk Mode Otomatis EKS dengan noda. Ini memastikan bahwa pod yang ada tidak akan secara otomatis menjadwalkan pada node Mode Otomatis EKS yang baru. Kumpulan node ini menggunakan Mode Otomatis EKS `default` `NodeClass` bawaan. Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md).
Contoh kumpulan node dengan taint:
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
taints:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
Perbarui persyaratan untuk kumpulan node agar sesuai dengan konfigurasi Karpenter tempat Anda bermigrasi. Anda membutuhkan setidaknya satu persyaratan.
## Langkah 3: Perbarui beban kerja untuk migrasi
Identifikasi dan perbarui beban kerja yang ingin Anda migrasi ke Mode Otomatis EKS. Tambahkan toleransi dan pemilih node ke beban kerja ini:
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
Perubahan ini memungkinkan beban kerja dijadwalkan pada node Mode Otomatis EKS yang baru.
Mode Otomatis EKS menggunakan label yang berbeda dari Karpenter. Label yang terkait dengan instance EC2 terkelola dimulai dengan`eks.amazonaws.com`. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
## Langkah 4: Migrasikan beban kerja secara bertahap
Ulangi Langkah 3 untuk setiap beban kerja yang ingin Anda migrasikan. Ini memungkinkan Anda untuk memindahkan beban kerja secara individu atau dalam kelompok, berdasarkan persyaratan dan toleransi risiko Anda.
## Langkah 5: Hapus Karpenter asli NodePool
Setelah semua beban kerja dimigrasikan, Anda dapat menghapus Karpenter asli: NodePool
```
kubectl delete nodepool
```
## Langkah 6: Hapus noda dari Mode Otomatis EKS NodePool (Opsional)
Jika Anda ingin Mode Otomatis EKS menjadi default untuk beban kerja baru, Anda dapat menghapus noda dari Mode Otomatis EKS: NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
# Remove the taints section
```
## Langkah 7: Hapus pemilih node dari beban kerja (Opsional)
Jika Anda telah menghapus noda dari Mode Otomatis EKS NodePool, Anda dapat secara opsional menghapus pemilih node dari beban kerja Anda, karena Mode Otomatis EKS sekarang menjadi default:
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
# Remove the nodeSelector section
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
## Langkah 8: Uninstall Karpenter dari cluster Anda
Langkah-langkah untuk menghapus Karpenter tergantung pada bagaimana Anda menginstalnya. Untuk informasi lebih lanjut, lihat petunjuk [pemasangan Karpenter](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter).
# Migrasi dari Grup Node Terkelola EKS ke Mode Otomatis EKS
Saat mentransisikan klaster Amazon EKS untuk menggunakan mode otomatis EKS, Anda dapat dengan lancar memigrasikan beban kerja yang ada dari grup node terkelola (MNGs) menggunakan alat CLI eksctl. Proses ini memastikan ketersediaan aplikasi berkelanjutan sementara mode otomatis EKS mengoptimalkan sumber daya komputasi Anda. Migrasi dapat dilakukan dengan gangguan minimal pada aplikasi yang sedang berjalan.
Topik ini memandu Anda melalui langkah-langkah untuk menguras pod dengan aman dari grup node terkelola yang ada dan memungkinkan mode otomatis EKS untuk menjadwalkannya kembali pada instance yang baru disediakan. Dengan mengikuti prosedur ini, Anda dapat memanfaatkan konsolidasi beban kerja cerdas mode otomatis EKS sambil mempertahankan ketersediaan aplikasi Anda selama migrasi.
## Prasyarat
+ Cluster dengan Mode Otomatis EKS diaktifkan
+ `eksctl`CLI diinstal dan terhubung ke cluster Anda. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
+ Karpenter tidak diinstal pada cluster.
## Prosedur
Gunakan perintah `eksctl` CLI berikut untuk memulai pengeringan pod dari instance grup node terkelola yang ada. Mode Otomatis EKS akan membuat node baru untuk mendukung pod yang dipindahkan.
```
eksctl delete nodegroup --cluster= --name=
```
Anda harus menjalankan perintah ini untuk setiap grup node terkelola di cluster Anda.
Untuk informasi selengkapnya tentang perintah ini, lihat [Menghapus dan menguras nodegroup](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) di dokumen eksctl.
# Bermigrasi dari EKS Fargate ke Mode Otomatis EKS
Topik ini memandu Anda melalui proses migrasi beban kerja dari EKS Fargate ke Amazon EKS Auto Mode menggunakan. `kubectl` Migrasi dapat dilakukan secara bertahap, memungkinkan Anda untuk memindahkan beban kerja dengan kecepatan Anda sendiri sambil menjaga stabilitas klaster dan ketersediaan aplikasi selama transisi.
step-by-stepPendekatan yang diuraikan di bawah ini memungkinkan Anda menjalankan EKS Fargate dan Mode Otomatis EKS berdampingan selama periode migrasi. Strategi operasi ganda ini membantu memastikan transisi yang mulus dengan memungkinkan Anda memvalidasi perilaku beban kerja pada Mode Otomatis EKS sebelum sepenuhnya menonaktifkan EKS Fargate. Anda dapat memigrasikan aplikasi secara individu atau dalam kelompok, memberikan fleksibilitas untuk mengakomodasi persyaratan operasional spesifik dan toleransi risiko Anda.
## Membandingkan Amazon EKS Auto Mode dan EKS dengan AWS Fargate
Amazon EKS dengan AWS Fargate tetap menjadi pilihan bagi pelanggan yang ingin menjalankan EKS, tetapi Amazon EKS Auto Mode adalah pendekatan yang disarankan untuk bergerak maju. Mode Otomatis EKS sepenuhnya sesuai dengan Kubernetes, mendukung semua primitif Kubernetes hulu dan alat platform seperti Istio, yang tidak dapat didukung Fargate. Mode Otomatis EKS juga sepenuhnya mendukung semua opsi pembelian runtime EC2, termasuk instans GPU dan Spot, memungkinkan pelanggan untuk memanfaatkan diskon EC2 yang dinegosiasikan dan mekanisme penghematan lainnya Kemampuan ini tidak tersedia saat menggunakan EKS dengan Fargate.
Selain itu, Mode Otomatis EKS memungkinkan pelanggan untuk mencapai model isolasi yang sama dengan Fargate, menggunakan kemampuan penjadwalan Kubernetes standar untuk memastikan setiap instans EC2 menjalankan satu wadah aplikasi. Dengan mengadopsi Amazon EKS Auto Mode, pelanggan dapat membuka manfaat penuh dari menjalankan Kubernetes AWS — platform Kubernetes-Conformant sepenuhnya yang memberikan fleksibilitas untuk memanfaatkan seluruh luas EC2 dan opsi pembelian sambil mempertahankan kemudahan penggunaan dan abstraksi dari manajemen infrastruktur yang disediakan Fargate.
### Mencapai isolasi seperti Fargate dalam Mode Otomatis EKS
Untuk mereplikasi model isolasi pod Fargate di mana setiap pod berjalan pada instance dedikasinya sendiri, Anda dapat menggunakan kendala penyebaran topologi Kubernetes. Ini adalah pendekatan yang direkomendasikan untuk mengendalikan distribusi pod di seluruh node:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: isolated-app
minDomains: 1
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
Dalam konfigurasi ini:
+ `maxSkew: 1`memastikan bahwa perbedaan jumlah pod antara dua node paling banyak 1, secara efektif mendistribusikan satu pod per node
+ `topologyKey: kubernetes.io/hostname`mendefinisikan node sebagai domain topologi
+ `whenUnsatisfiable: DoNotSchedule`mencegah penjadwalan jika kendala tidak dapat dipenuhi
+ `minDomains: 1`memastikan setidaknya satu domain (node) ada sebelum penjadwalan
Mode Otomatis EKS akan secara otomatis menyediakan instans EC2 baru sesuai kebutuhan untuk memenuhi kendala ini, menyediakan model isolasi yang sama dengan Fargate sambil memberi Anda akses ke berbagai jenis instans EC2 dan opsi pembelian.
Atau, Anda dapat menggunakan aturan anti-afinitas pod untuk isolasi yang lebih ketat:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- isolated-app
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
`podAntiAffinity`Aturan dengan `requiredDuringSchedulingIgnoredDuringExecution` memastikan bahwa tidak ada dua pod dengan label yang `app: isolated-app` dapat dijadwalkan pada node yang sama. Pendekatan ini memberikan jaminan isolasi keras yang mirip dengan Fargate.
## Prasyarat
Sebelum memulai migrasi, pastikan Anda memiliki
+ Siapkan cluster dengan Fargate. Untuk informasi selengkapnya, lihat [Memulai AWS Fargate untuk klaster Anda](fargate-getting-started.md).
+ Diinstal dan terhubung `kubectl` ke cluster Anda. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
## Langkah 1: Periksa cluster Fargate
1. Periksa apakah cluster EKS dengan Fargate sedang berjalan:
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. Periksa pod yang sedang berjalan:
```
kubectl get pod -A
```
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m
```
1. Buat penyebaran dalam file bernama`deployment_fargate.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: fargate
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Terapkan penyebaran:
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. Periksa pod dan penerapan:
```
kubectl get pod,deploy
```
```
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5c7479459b-6trtm 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-g8ssb 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-mq4mf 1/1 Running 0 61s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 61s
```
1. Periksa simpul:
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal Ready 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## Langkah 2: Aktifkan Mode Otomatis EKS di cluster
1. Aktifkan Mode Otomatis EKS pada klaster Anda yang ada menggunakan AWS CLI atau Management Console. Untuk informasi selengkapnya, lihat [Aktifkan Mode Otomatis EKS pada cluster yang ada](auto-enable-existing.md).
1. Periksa nodepool:
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## Langkah 3: Perbarui beban kerja untuk migrasi
Identifikasi dan perbarui beban kerja yang ingin Anda migrasikan ke Mode Otomatis EKS.
Untuk memigrasikan beban kerja dari Fargate ke Mode Otomatis EKS, terapkan anotasi. `eks.amazonaws.com/compute-type: ec2` Ini memastikan bahwa beban kerja tidak akan dijadwalkan oleh Fargate, terlepas dari profil Fargate, dan akan terjebak oleh Mode Otomatis EKS. NodePool Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
1. Ubah penerapan Anda (misalnya, `deployment_fargate.yaml` file) untuk mengubah jenis komputasi menjadi: `ec2`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Terapkan penyebaran. Perubahan ini memungkinkan beban kerja dijadwalkan pada node Mode Otomatis EKS yang baru:
```
kubectl apply -f deployment_fargate.yaml
```
1. Periksa apakah penerapan berjalan di kluster Mode Otomatis EKS:
```
kubectl get pod -o wide
```
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-97967b68d-ffxxh 1/1 Running 0 3m31s 192.168.43.240 i-0845aafcb51630ffb
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. Pastikan tidak ada node Fargate yang berjalan dan penerapan yang berjalan di node terkelola Mode Otomatis EKS:
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 3m30s v1.30.8-eks-3c20087 192.168.41.125 3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129 containerd://1.7.25+bottlerocket
```
## Langkah 4: Migrasikan beban kerja secara bertahap
Ulangi Langkah 3 untuk setiap beban kerja yang ingin Anda migrasikan. Ini memungkinkan Anda untuk memindahkan beban kerja secara individu atau dalam kelompok, berdasarkan persyaratan dan toleransi risiko Anda.
## Langkah 5: Hapus profil fargate asli
Setelah semua beban kerja telah dimigrasikan, Anda dapat menghapus profil asli`fargate`. Ganti ** dengan nama profil Fargate Anda:
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## Langkah 6: Turunkan CoreDNS
Karena mode EKS Auto menangani CoreDNS, Anda menskalakan penerapan `coredns` ke 0:
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```
# Jalankan beban kerja sampel di kluster Mode Otomatis EKS
Bab ini memberikan contoh cara menerapkan berbagai jenis beban kerja ke kluster Amazon EKS yang berjalan dalam Mode Otomatis. Contoh menunjukkan pola beban kerja utama termasuk aplikasi sampel, aplikasi web yang seimbang beban, beban kerja stateful menggunakan penyimpanan persisten, dan beban kerja dengan persyaratan penempatan node tertentu. Setiap contoh mencakup manifes lengkap dan instruksi step-by-step penerapan yang dapat Anda gunakan sebagai templat untuk aplikasi Anda sendiri.
Sebelum melanjutkan dengan contoh, pastikan bahwa Anda memiliki kluster EKS yang berjalan dalam Mode Otomatis dan bahwa Anda telah menginstal CLI dan AWS kubectl. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md). Contohnya mengasumsikan keakraban dasar dengan konsep Kubernetes dan perintah kubectl.
Anda dapat menggunakan sampel berbasis kasus penggunaan ini untuk menjalankan beban kerja di kluster Mode Otomatis EKS.
[Menerapkan sampel beban kerja inflate ke klaster Mode Otomatis Amazon EKS](automode-workload.md)
Menunjukkan cara menerapkan beban kerja sampel ke kluster Mode Otomatis EKS menggunakan `kubectl` perintah.
[Menerapkan Beban Kerja Load Balancer Sampel ke Mode Otomatis EKS](auto-elb-example.md)
Menunjukkan cara menerapkan versi kontainer dari game 2048 di Amazon EKS.
[Menerapkan contoh beban kerja stateful ke Mode Otomatis EKS](sample-storage-workload.md)
Menunjukkan cara menerapkan contoh aplikasi stateful ke kluster Mode Otomatis EKS.
[Menerapkan beban kerja yang dipercepat](auto-accelerated.md)
Menunjukkan cara menerapkan beban kerja yang dipercepat perangkat keras ke node yang dikelola oleh Mode Otomatis EKS.
[Kontrol jika beban kerja diterapkan pada node Mode Otomatis EKS](associate-workload.md)
Menunjukkan cara menggunakan anotasi untuk mengontrol jika beban kerja diterapkan ke node yang dikelola oleh Mode Otomatis EKS.
# Menerapkan sampel beban kerja inflate ke klaster Mode Otomatis Amazon EKS
Dalam tutorial ini, Anda akan mempelajari cara menerapkan beban kerja sampel ke cluster Mode Otomatis EKS dan mengamati bagaimana ia secara otomatis menyediakan sumber daya komputasi yang diperlukan. Anda akan menggunakan `kubectl` perintah untuk melihat perilaku klaster dan melihat secara langsung bagaimana Mode Otomatis menyederhanakan operasi Kubernetes. AWS Pada akhir tutorial ini, Anda akan memahami bagaimana EKS Auto Mode merespons penerapan beban kerja dengan secara otomatis mengelola sumber daya komputasi yang mendasarinya, tanpa memerlukan konfigurasi grup node manual.
## Prasyarat
+ Cluster Mode Otomatis Amazon EKS. Perhatikan nama dan AWS wilayah cluster.
+ Prinsipal IAM, seperti pengguna atau peran, dengan izin yang cukup untuk mengelola jaringan, komputasi, dan sumber daya EKS.
+ Untuk informasi selengkapnya, lihat [Membuat peran dan melampirkan kebijakan di Panduan Pengguna IAM di Panduan Pengguna](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) IAM.
+ `aws`CLI diinstal dan dikonfigurasi dengan identitas IAM.
+ `kubectl`CLI diinstal dan terhubung ke cluster.
+ Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
## Langkah 1: Tinjau sumber daya komputasi yang ada (opsional)
Pertama, gunakan `kubectl` untuk membuat daftar kumpulan node di cluster Anda.
```
kubectl get nodepools
```
Keluaran sampel:
```
general-purpose
```
Dalam tutorial ini, kita akan menyebarkan beban kerja yang dikonfigurasi untuk menggunakan `general-purpose` node pool. Kumpulan node ini dibangun ke dalam Mode Otomatis EKS, dan mencakup default yang wajar untuk beban kerja umum, seperti layanan mikro dan aplikasi web. Anda dapat membuat kumpulan node Anda sendiri. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
Kedua, gunakan `kubectl` untuk membuat daftar node yang terhubung ke cluster Anda.
```
kubectl get nodes
```
Jika Anda baru saja membuat kluster Mode Otomatis EKS, Anda tidak akan memiliki node.
Dalam tutorial ini Anda akan menyebarkan beban kerja sampel. Jika Anda tidak memiliki node, atau beban kerja tidak dapat muat pada node yang ada, Mode Otomatis EKS akan menyediakan node baru.
## Langkah 2: Menyebarkan aplikasi sampel ke cluster
Tinjau Deployment Kubernetes berikut dan simpan sebagai `inflate.yaml`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
Perhatikan bahwa `eks.amazonaws.com/compute-type: auto` pemilih mengharuskan beban kerja diterapkan pada node Mode Otomatis Amazon EKS.
Terapkan Deployment ke cluster Anda.
```
kubectl apply -f inflate.yaml
```
## Langkah 3: Tonton Acara Kubernetes
Gunakan perintah berikut untuk menonton peristiwa Kubernetes, termasuk membuat node baru. Gunakan `ctrl+c` untuk berhenti menonton acara.
```
kubectl get events -w --sort-by '.lastTimestamp'
```
Gunakan `kubectl` untuk membuat daftar node yang terhubung ke cluster Anda lagi. Perhatikan node yang baru dibuat.
```
kubectl get nodes
```
## Langkah 4: Lihat node dan instance di konsol AWS
Anda dapat melihat Node Mode Otomatis EKS di konsol EKS, dan EC2 instance terkait di EC2 konsol.
EC2 Instans yang digunakan oleh Mode Otomatis EKS dibatasi. Anda tidak dapat menjalankan perintah arbitrer pada node Mode Otomatis EKS.
## Langkah 5: Hapus penyebaran
Gunakan `kubectl` untuk menghapus penyebaran sampel
```
kubectl delete -f inflate.yaml
```
Jika Anda tidak memiliki beban kerja lain yang diterapkan ke cluster Anda, node yang dibuat oleh Mode Otomatis EKS akan kosong.
Dalam konfigurasi default, Mode Otomatis EKS mendeteksi node yang telah kosong selama tiga puluh detik, dan menghentikannya.
Gunakan `kubectl` atau EC2 konsol untuk mengonfirmasi instance terkait telah dihapus.
# Menerapkan Beban Kerja Load Balancer Sampel ke Mode Otomatis EKS
Panduan ini memandu Anda melalui penerapan versi kontainer dari game 2048 di Amazon EKS, lengkap dengan penyeimbangan beban dan aksesibilitas internet.
## Prasyarat
+ Kluster Mode Otomatis EKS
+ `kubectl`dikonfigurasi untuk berinteraksi dengan cluster Anda
+ Izin IAM yang sesuai untuk membuat sumber daya ALB
## Langkah 1: Buat Namespace
Pertama, buat namespace khusus untuk aplikasi game 2048.
Buat file bernama `01-namespace.yaml`:
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
Terapkan konfigurasi namespace:
```
kubectl apply -f 01-namespace.yaml
```
## Langkah 2: Menyebarkan Aplikasi
Aplikasi ini menjalankan beberapa replika dari kontainer game 2048.
Buat file bernama `02-deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**catatan**
Jika Anda menerima kesalahan saat memuat gambar`public.ecr.aws/l6m2t8p7/docker-2048:latest`, konfirmasikan peran IAM Node Anda memiliki izin yang cukup untuk menarik gambar dari ECR. Untuk informasi selengkapnya, lihat [IAM role simpul](auto-learn-iam.md#auto-learn-node-iam-role). Juga, `docker-2048` gambar dalam contoh adalah `x86_64` gambar dan tidak akan berjalan pada arsitektur lain.
**Komponen kunci:**
+ Menyebarkan 5 replika aplikasi
+ Menggunakan gambar ECR publik
+ Meminta 0,5 inti CPU per pod
+ Mengekspos port 80 untuk lalu lintas HTTP
Terapkan penyebaran:
```
kubectl apply -f 02-deployment.yaml
```
## Langkah 3: Buat Layanan
Layanan mengekspos penyebaran ke jaringan cluster.
Buat file bernama `03-service.yaml`:
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**Komponen kunci:**
+ Menciptakan NodePort layanan
+ Memetakan port 80 ke port kontainer 80
+ Menggunakan pemilih label untuk menemukan pod
Terapkan layanan:
```
kubectl apply -f 03-service.yaml
```
## Langkah 4: Konfigurasikan Load Balancing
Anda akan mengatur ingress untuk mengekspos aplikasi ke internet.
Pertama, buat`IngressClass`. Buat file bernama `04-ingressclass.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**catatan**
Mode Otomatis EKS memerlukan tag subnet untuk mengidentifikasi subnet publik dan pribadi.
Jika Anda membuat cluster Anda dengan`eksctl`, Anda sudah memiliki tag ini.
Pelajari cara [Tag subnet untuk Mode Otomatis EKS](tag-subnets-auto.md).
Kemudian buat sumber daya Ingress. Buat file bernama `05-ingress.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**Komponen kunci:**
+ Menciptakan ALB yang menghadap ke internet
+ Menggunakan tipe target IP untuk routing pod langsung
+ Rutekan semua lalu lintas (/) ke layanan game
Terapkan konfigurasi ingress:
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## Langkah 5: Verifikasi Deployment
1. Periksa apakah semua pod berjalan:
```
kubectl get pods -n game-2048
```
1. Verifikasi layanan dibuat:
```
kubectl get svc -n game-2048
```
1. Dapatkan titik akhir ALB:
```
kubectl get ingress -n game-2048
```
Bidang ADDRESS pada keluaran ingress akan menampilkan endpoint ALB Anda. Tunggu 2-3 menit hingga ALB menyediakan dan mendaftarkan semua target.
## Langkah 6: Akses Game
Buka browser web Anda dan telusuri URL endpoint ALB dari langkah sebelumnya. Anda akan melihat antarmuka game 2048.
## Langkah 7: Pembersihan
Untuk menghapus semua sumber daya yang dibuat dalam tutorial ini:
```
kubectl delete namespace game-2048
```
Ini akan menghapus semua sumber daya di namespace, termasuk penerapan, layanan, dan sumber daya ingress.
## Apa yang Terjadi Di Balik Layar
1. Deployment menciptakan 5 pod yang menjalankan game 2048
1. Layanan ini menyediakan akses jaringan yang stabil ke pod ini
1. Mode Otomatis EKS:
+ Membuat Application Load Balancer di AWS
+ Mengonfigurasi grup target untuk pod
+ Menyiapkan aturan perutean untuk mengarahkan lalu lintas ke layanan
## Pemecahan Masalah
Jika game tidak dimuat:
+ Pastikan semua pod berjalan: `kubectl get pods -n game-2048`
+ Periksa status masuknya: `kubectl describe ingress -n game-2048`
+ Verifikasi pemeriksaan kesehatan ALB: Periksa kesehatan grup target di Konsol AWS
# Menerapkan contoh beban kerja stateful ke Mode Otomatis EKS
Tutorial ini akan memandu Anda melalui penerapan contoh aplikasi stateful ke kluster Mode Otomatis EKS Anda. Aplikasi ini menulis stempel waktu ke volume persisten, mendemonstrasikan penyediaan volume EBS otomatis dan kemampuan persistensi EKS Auto Mode.
## Prasyarat
+ Kluster Mode Otomatis EKS
+ AWS CLI dikonfigurasi dengan izin yang sesuai
+ `kubectl`diinstal dan dikonfigurasi
+ Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
## Langkah 1: Konfigurasikan lingkungan Anda
1. Tetapkan variabel lingkungan Anda:
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. Perbarui kubeconfig Anda:
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## Langkah 2: Buat kelas penyimpanan
Ini `StorageClass` menentukan bagaimana Mode Otomatis EKS akan menyediakan volume EBS.
Mode Otomatis EKS tidak membuat `StorageClass` untuk Anda. Anda harus membuat `StorageClass` referensi `ebs.csi.eks.amazonaws.com` untuk menggunakan kemampuan penyimpanan Mode Otomatis EKS.
1. Buat file bernama `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. Terapkan`StorageClass`:
```
kubectl apply -f storage-class.yaml
```
**Komponen kunci:**
+ `provisioner: ebs.csi.eks.amazonaws.com`- Menggunakan Mode Otomatis EKS
+ `volumeBindingMode: WaitForFirstConsumer`- Menunda pembuatan volume hingga pod membutuhkannya
+ `type: gp3`- Menentukan jenis volume EBS
+ `encrypted: "true"`- EBS akan menggunakan `aws/ebs` kunci default untuk mengenkripsi volume yang dibuat dengan kelas ini. Ini memang opsional, tetapi direkomendasikan.
+ `storageclass.kubernetes.io/is-default-class: "true"`- Kubernetes akan menggunakan kelas penyimpanan ini secara default, kecuali Anda menentukan kelas volume yang berbeda pada klaim volume persisten. Berhati-hatilah saat menyetel nilai ini jika Anda bermigrasi dari pengontrol penyimpanan lain. (opsional)
## Langkah 3: Buat klaim volume persisten
PVC meminta penyimpanan dari`StorageClass`.
1. Buat file bernama `pvc.yaml`:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. Terapkan PVC:
```
kubectl apply -f pvc.yaml
```
**Komponen kunci:**
+ `accessModes: ReadWriteOnce`- Volume dapat dipasang oleh satu node pada satu waktu
+ `storage: 8Gi`- Meminta volume 8 GiB
+ `storageClassName: auto-ebs-sc`- Referensi yang `StorageClass` kami buat
## Langkah 4: Menyebarkan Aplikasi
Deployment menjalankan container yang menulis stempel waktu ke volume persisten.
1. Buat file bernama `deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. Terapkan Deployment:
```
kubectl apply -f deployment.yaml
```
**Komponen kunci:**
+ Kontainer bash sederhana yang menulis stempel waktu ke file
+ Memasang PVC di `/data`
+ Permintaan 1 inti CPU
+ Menggunakan pemilih node untuk node terkelola EKS
## Langkah 5: Verifikasi Pengaturan
1. Periksa apakah pod sedang berjalan:
```
kubectl get pods -l app=inflate-stateful
```
1. Verifikasi PVC terikat:
```
kubectl get pvc auto-ebs-claim
```
1. Periksa volume EBS:
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. Verifikasi data sedang ditulis:
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## Langkah 6: Pembersihan
Jalankan perintah berikut untuk menghapus semua sumber daya yang dibuat dalam tutorial ini:
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## Apa yang Terjadi Di Balik Layar
1. PVC meminta penyimpanan dari `StorageClass`
1. Saat Pod dijadwalkan:
1. Mode Otomatis EKS menyediakan volume EBS
1. Menciptakan PersistentVolume
1. Menempelkan volume ke node
1. Pod memasang volume dan mulai menulis stempel waktu
## Pengontrol Snapshot
EKS Auto Mode kompatibel dengan Kubernetes CSI Snapshotter, juga dikenal sebagai pengontrol snapshot. Namun, Mode Otomatis EKS tidak menyertakan pengontrol snapshot. Anda bertanggung jawab untuk menginstal dan mengkonfigurasi pengontrol snapshot. Untuk informasi selengkapnya, lihat [Aktifkan fungsionalitas snapshot untuk volume CSI](csi-snapshot-controller.md).
Tinjau hal-hal berikut `VolumeSnapshotClass` yang mereferensikan kemampuan penyimpanan Mode Otomatis EKS.
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[Pelajari lebih lanjut tentang Snapshotter CSI Kubernetes.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# Menerapkan beban kerja yang dipercepat
Tutorial ini menunjukkan bagaimana Amazon EKS Auto Mode menyederhanakan peluncuran beban kerja yang dipercepat perangkat keras. Amazon EKS Auto Mode merampingkan operasi di luar klaster itu sendiri dengan mengotomatiskan komponen infrastruktur utama yang menyediakan kemampuan komputasi, jaringan, penyeimbangan beban, penyimpanan, dan Akses Identitas dan Manajemen di luar kotak.
Amazon EKS Auto Mode menyertakan driver dan plugin perangkat yang diperlukan untuk jenis instans tertentu, seperti driver NVIDIA dan AWS Neuron. Anda tidak perlu menginstal atau memperbarui komponen ini.
Mode Otomatis EKS secara otomatis mengelola driver untuk akselerator ini:
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inferensia](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [NVIDIA GPUs di Amazon EC2 mempercepat instans](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**catatan**
Mode Otomatis EKS menyertakan plugin perangkat NVIDIA untuk Kubernetes. Plugin ini berjalan secara otomatis dan tidak terlihat sebagai daemon yang disetel di cluster Anda.
Dukungan jaringan tambahan:
+ [Adaptor Kain Elastis (EFA)](https://aws.amazon.com/hpc/efa/)
Amazon EKS Auto Mode menghilangkan kerja keras driver akselerator dan manajemen plugin perangkat.
Anda juga bisa mendapatkan keuntungan dari penghematan biaya dengan menskalakan cluster ke nol. Anda dapat mengonfigurasi Mode Otomatis EKS untuk menghentikan instance saat tidak ada beban kerja yang berjalan. Ini berguna untuk beban kerja inferensi berbasis batch.
Berikut ini memberikan contoh cara meluncurkan beban kerja yang dipercepat dengan Amazon EKS Auto Mode.
## Prasyarat
+ Cluster Kubernetes dengan Amazon EKS Auto Mode dikonfigurasi.
+ Kelas `default` EKS Node seperti yang dibuat saat `general-purpose` atau `system` Managed Node Pools diaktifkan.
## Langkah 1: Menyebarkan beban kerja GPU
Dalam contoh ini, Anda akan membuat beban kerja berbasis NVIDIA NodePool untuk yang membutuhkan memori GPU 45GB. Dengan Mode Otomatis EKS, Anda menggunakan batasan penjadwalan Kubernetes untuk menentukan persyaratan instans Anda.
Untuk menerapkan Amazon EKS Auto Mode `NodePool` dan sampel`workload`, tinjau definisi berikut NodePool dan Pod dan simpan sebagai `nodepool-gpu.yaml` dan`pod.yaml`:
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Perhatikan bahwa `eks.amazonaws.com/compute-type: auto` pemilih mengharuskan beban kerja diterapkan pada node Mode Otomatis Amazon EKS. Ini NodePool juga menetapkan taint yang hanya memungkinkan pod dengan toleransi untuk Nvidia GPUs dijadwalkan.
Terapkan NodePool dan beban kerja ke cluster Anda.
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
Anda akan melihat output berikut:
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
Tunggu beberapa detik, dan periksa node di cluster Anda. Anda sekarang akan melihat node baru yang disediakan di kluster Mode Otomatis Amazon EKS Anda:
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## Langkah 2: Validasi
Anda dapat melihat Amazon EKS Auto Mode meluncurkan a, `g6e.2xlarge` bukan `g6.2xlarge` karena beban kerja memerlukan instance dengan l40s`GPU`, menurut batasan penjadwalan Kubernetes berikut:
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
Sekarang, lihat log kontainer, dengan menjalankan perintah berikut:
```
kubectl logs nvidia-smi
```
Contoh output:
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
Anda dapat melihat bahwa penampung telah mendeteksi itu berjalan pada instance dengan `NVIDIA` GPU dan Anda tidak perlu menginstal driver perangkat apa pun, karena ini dikelola oleh Amazon EKS Auto Mode.
## Langkah 3: Membersihkan
Untuk menghapus semua objek yang dibuat, gunakan `kubectl` untuk menghapus penyebaran sampel NodePool sehingga node dihentikan:
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## Contoh NodePools Referensi
### Buat NVIDIA NodePool
Berikut ini NodePool mendefinisikan:
+ Hanya meluncurkan contoh `g6e` dan keluarga `g6`
+ Konsolidasikan node saat kosong selama 1 jam
+ Nilai 1 jam untuk `consolodateAfter` mendukung beban kerja runcing dan mengurangi churn node. Anda dapat menyetel `consolidateAfter` berdasarkan persyaratan beban kerja Anda.
**Contoh NodePool dengan keluarga instans GPU dan konsolidasi**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
Alih-alih menyetel yang mungkin `eks.amazonaws.com/instance-gpu-name` Anda gunakan `eks.amazonaws.com/instance-family` untuk menentukan keluarga instance. Untuk label terkenal lainnya yang memengaruhi tinjauan penjadwalan, lihat[Label yang Didukung Mode Otomatis EKS](create-node-pool.md#auto-supported-labels).
Jika Anda memiliki persyaratan penyimpanan khusus, Anda dapat menyetel penyimpanan singkat node`iops`, `size` dan `throughput` dengan membuat sendiri [NodeClass](create-node-class.md)untuk referensi di. NodePool Pelajari lebih lanjut tentang [ NodeClass opsi yang dapat dikonfigurasi](create-node-class.md).
**Contoh konfigurasi penyimpanan untuk NodeClass**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### Tentukan AWS Trainium dan AWS Inferensia NodePool
Berikut ini NodePool memiliki `eks.amazonaws.com/instance-category` satu set yang mengatakan, hanya meluncurkan contoh keluarga Inferentia dan Trainium:
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```
# Konfigurasikan pengaturan Mode Otomatis EKS
Bab ini menjelaskan cara mengonfigurasi aspek-aspek tertentu dari kluster Mode Otomatis Amazon Elastic Kubernetes Service (EKS) Anda. Sementara Mode Otomatis EKS mengelola sebagian besar komponen infrastruktur secara otomatis, Anda dapat menyesuaikan fitur tertentu untuk memenuhi persyaratan beban kerja Anda.
Dengan menggunakan opsi konfigurasi yang dijelaskan dalam topik ini, Anda dapat mengubah pengaturan jaringan, menghitung sumber daya, dan perilaku penyeimbangan beban sambil mempertahankan manfaat manajemen infrastruktur otomatis. Sebelum membuat perubahan konfigurasi, tinjau opsi yang tersedia di bagian berikut untuk menentukan pendekatan mana yang paling sesuai dengan kebutuhan Anda.
| Fitur apa yang ingin Anda konfigurasikan? | Opsi Konfigurasi |
| --- | --- |
| **Jaringan dan penyimpanan node** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Buat Kelas Node untuk Amazon EKS](create-node-class.md) |
| **Sumber daya komputasi node** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md) |
| **Kolam simpul berkapasitas statis** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Kolam Node Kapasitas Statis dalam Mode Otomatis EKS](auto-static-capacity.md) |
| **Pengaturan Application Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Buat IngressClass untuk mengkonfigurasi Application Load Balancer](auto-configure-alb.md) |
| **Pengaturan Network Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Gunakan Anotasi Layanan untuk mengonfigurasi Network Load Balancers](auto-configure-nlb.md) |
| **Pengaturan Kelas Penyimpanan** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Buat kelas penyimpanan](create-storage-class.md) |
| **Kontrol Penggunaan ODCR** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Kontrol penyebaran beban kerja ke Reservasi Kapasitas dengan Mode Otomatis EKS](auto-odcr.md) |
| **Node keamanan tingkat lanjut** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Konfigurasikan pengaturan keamanan lanjutan untuk node](auto-advanced-security.md) |
# Buat Kelas Node untuk Amazon EKS
Amazon EKS Node Classes adalah template yang menawarkan kontrol granular atas konfigurasi node terkelola Mode Otomatis EKS Anda. Kelas Node mendefinisikan pengaturan tingkat infrastruktur yang berlaku untuk grup node di kluster EKS Anda, termasuk konfigurasi jaringan, pengaturan penyimpanan, dan penandaan sumber daya. Topik ini menjelaskan cara membuat dan mengkonfigurasi Kelas Node untuk memenuhi persyaratan operasional spesifik Anda.
Saat Anda perlu menyesuaikan cara Mode Otomatis EKS menyediakan dan mengonfigurasi instans EC2 di luar pengaturan default, membuat Kelas Node memberi Anda kontrol yang tepat atas parameter infrastruktur penting. Misalnya, Anda dapat menentukan penempatan subnet pribadi untuk keamanan yang ditingkatkan, mengonfigurasi penyimpanan sementara instance untuk beban kerja yang sensitif terhadap kinerja, atau menerapkan penandaan khusus untuk alokasi biaya.
## Buat Kelas Node
Untuk membuat`NodeClass`, ikuti langkah-langkah ini:
1. Buat file YAMM (misalnya,`nodeclass.yaml`) dengan konfigurasi Kelas Node Anda
1. Terapkan konfigurasi ke cluster Anda menggunakan `kubectl`
1. Referensi Kelas Node dalam konfigurasi Node Pool Anda. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
Anda perlu `kubectl` diinstal dan dikonfigurasi. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
### Contoh Kelas Node Dasar
Berikut adalah contoh Kelas Node:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
Ini NodeClass meningkatkan jumlah penyimpanan fana pada node.
Terapkan konfigurasi ini dengan menggunakan:
```
kubectl apply -f nodeclass.yaml
```
Selanjutnya, referensi Kelas Node dalam konfigurasi Node Pool Anda. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
## Buat entri akses kelas node
Jika Anda membuat kelas node kustom, Anda perlu membuat Entri Akses EKS untuk mengizinkan node bergabung dengan cluster. EKS secara otomatis membuat entri akses saat Anda menggunakan kelas node dan kumpulan node bawaan.
Untuk informasi tentang cara kerja Entri Akses, lihat[Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md).
Saat membuat entri akses untuk kelas node Mode Otomatis EKS, Anda perlu menggunakan jenis entri `EC2` akses.
### Buat entri akses dengan CLI
**Untuk membuat entri akses untuk node EC2 dan mengaitkan Kebijakan Node Otomatis EKS:**
Perbarui perintah CLI berikut dengan nama cluster Anda, dan peran node ARN. Peran node ARN ditentukan dalam kelas node YAMM.
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### Buat entri akses dengan CloudFormation
**Untuk membuat entri akses untuk node EC2 dan mengaitkan Kebijakan Node Otomatis EKS:**
Perbarui yang berikut ini CloudFormation dengan nama cluster Anda, dan peran node ARN. Peran node ARN ditentukan dalam kelas node YAMM.
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
Untuk informasi tentang menerapkan CloudFormation tumpukan, lihat [Memulai CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
## Spesifikasi Kelas Node
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws: kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## Pertimbangan-pertimbangan
+ Jika Anda ingin memverifikasi berapa banyak penyimpanan lokal yang dimiliki sebuah instans, Anda dapat menjelaskan node untuk melihat sumber daya penyimpanan sementara.
+ **Enkripsi Volume** - EKS menggunakan kunci KMS kustom yang dikonfigurasi untuk mengenkripsi volume root read-only dari instance dan volume data. read/write
+ **Ganti peran IAM node** - Jika Anda mengubah peran IAM node yang terkait dengan a`NodeClass`, Anda harus membuat Entri Akses baru. EKS secara otomatis membuat Entri Akses untuk peran IAM node selama pembuatan cluster. Peran IAM node memerlukan Kebijakan Akses `AmazonEKSAutoNodePolicy` EKS. Untuk informasi selengkapnya, lihat [Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md).
+ **Kepadatan Pod maksimum** - EKS membatasi jumlah maksimum Pod pada sebuah node menjadi 110. Batas ini diterapkan setelah perhitungan Max Pod yang ada. Untuk informasi selengkapnya, lihat [Pilih jenis instans node Amazon EC2 yang optimal](choosing-instance-type.md).
+ **Tag** - Jika Anda ingin menyebarkan tag dari Kubernetes ke EC2, Anda perlu mengonfigurasi izin IAM tambahan. Untuk informasi selengkapnya, lihat [Pelajari tentang identitas dan akses dalam Mode Otomatis EKS](auto-learn-iam.md).
+ **Kelas node default** - Jangan beri nama kelas node kustom Anda`default`. Ini karena Mode Otomatis EKS menyertakan `NodeClass` panggilan `default` yang secara otomatis disediakan ketika Anda mengaktifkan setidaknya satu built-in. `NodePool` Untuk informasi tentang mengaktifkan bawaan`NodePools`, lihat[Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
+ **`subnetSelectorTerms`perilaku dengan beberapa subnet** - Jika ada beberapa subnet yang cocok dengan `subnetSelectorTerms` kondisi atau yang Anda berikan oleh ID, Mode Otomatis EKS membuat node yang didistribusikan di seluruh subnet.
+ Jika subnet berada di Availability Zones (AZs) yang berbeda, Anda dapat menggunakan fitur Kubernetes seperti [kendala penyebaran topologi Pod dan Topology Aware Routing untuk menyebarkan](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) [Pod](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) dan lalu lintas di seluruh zona.
+ Jika ada beberapa subnet *dalam AZ yang sama yang* cocok dengan`subnetSelectorTerms`, Mode Otomatis EKS membuat Pod pada setiap node yang didistribusikan di seluruh subnet di AZ tersebut. Mode Otomatis EKS membuat antarmuka jaringan sekunder pada setiap node di subnet lain di AZ yang sama. Ini memilih berdasarkan jumlah alamat IP yang tersedia di setiap subnet, untuk menggunakan subnet lebih efisien. Namun, Anda tidak dapat menentukan subnet EKS Auto Mode mana yang digunakan untuk setiap Pod; jika Anda membutuhkan Pod untuk berjalan di subnet tertentu, gunakan [Pisahkan subnet dan grup keamanan untuk Pod](#pod-subnet-selector) saja.
## Pisahkan subnet dan grup keamanan untuk Pod
`podSecurityGroupSelectorTerms`Bidang `podSubnetSelectorTerms` and memungkinkan konfigurasi jaringan tingkat lanjut dengan memungkinkan Pod menggunakan subnet dan grup keamanan yang berbeda dari node mereka. Kedua bidang harus ditentukan bersama. Pemisahan ini memberikan kontrol yang ditingkatkan atas perutean lalu lintas jaringan dan kebijakan keamanan.
**catatan**
Fitur ini berbeda dengan fitur [Security Groups for Pods](security-groups-for-pods.md) (SGPP) yang digunakan dengan AWS VPC CNI untuk komputasi Mode Otomatis non-EKS. SGPP tidak didukung dalam Mode Otomatis EKS. Sebagai gantinya, gunakan `podSecurityGroupSelectorTerms` in `NodeClass` untuk menerapkan grup keamanan terpisah ke lalu lintas Pod. Grup keamanan berlaku pada `NodeClass` level tersebut, artinya semua Pod pada node yang `NodeClass` menggunakan grup keamanan Pod yang sama.
### Cara kerjanya
Saat Anda mengkonfigurasi `podSubnetSelectorTerms` dan`podSecurityGroupSelectorTerms`:
1. ENI primer node menggunakan subnet dan grup keamanan dari `subnetSelectorTerms` dan`securityGroupSelectorTerms`. Hanya alamat IP node sendiri yang ditetapkan ke antarmuka ini.
1. Mode Otomatis EKS menciptakan sekunder ENIs dalam pencocokan subnet`podSubnetSelectorTerms`, dengan grup keamanan dari `podSecurityGroupSelectorTerms` terpasang. Alamat IP Pod dialokasikan dari sekunder ini ENIs menggunakan awalan /28 secara default, dengan fallback otomatis ke sekunder IPs (/32) ketika blok awalan yang berdekatan tidak tersedia. Jika `ipv4PrefixSize` diatur ke `"32"` in`advancedNetworking`, hanya sekunder IPs yang digunakan.
1. Grup keamanan yang ditentukan `podSecurityGroupSelectorTerms` berlaku untuk lalu lintas Pod di dalam VPC. Untuk lalu lintas yang ditujukan di luar VPC, Pod menggunakan ENI primer node (dan grup keamanannya) karena terjemahan alamat jaringan sumber (SNAT) menerjemahkan IP Pod ke IP node. Anda dapat mengubah perilaku ini dengan `snatPolicy` bidang di`NodeClass`.
### Kasus penggunaan
Gunakan `podSubnetSelectorTerms` dan `podSecurityGroupSelectorTerms` kapan Anda perlu:
+ Terapkan grup keamanan yang berbeda untuk mengontrol lalu lintas node dan Pod secara terpisah.
+ Pisahkan lalu lintas infrastruktur (node-to-node komunikasi) dari lalu lintas aplikasi (Pod-to-Pod komunikasi).
+ Menerapkan konfigurasi jaringan yang berbeda ke subnet node daripada subnet Pod.
+ Konfigurasikan proxy terbalik atau pemfilteran jaringan khusus untuk lalu lintas node tanpa memengaruhi lalu lintas Pod. Gunakan `advancedNetworking` dan `certificateBundles` untuk menentukan proxy terbalik Anda dan sertifikat yang ditandatangani sendiri atau pribadi untuk proxy.
### Contoh konfigurasi
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### Pertimbangan untuk subnet Pod dan grup keamanan terpisah
+ **Lingkup grup keamanan**: Grup keamanan dari `podSecurityGroupSelectorTerms` dilampirkan ke sekunder ENIs dan berlaku untuk lalu lintas Pod di dalam VPC. Ketika SNAT diaktifkan (default`snatPolicy: Random`), lalu lintas yang meninggalkan VPC diterjemahkan ke alamat IP ENI utama node, sehingga grup `securityGroupSelectorTerms` keamanan node diterapkan ke lalu lintas itu sebagai gantinya. Jika Anda mengatur`snatPolicy: Disabled`, Pod menggunakan alamat IP mereka sendiri untuk semua lalu lintas, dan Anda harus memastikan bahwa routing dan grup keamanan dikonfigurasi sesuai dengan itu.
+ **NodeClass-level granularity**: Grup keamanan Pod berlaku untuk semua Pod yang dijadwalkan pada node menggunakan. `NodeClass` Untuk menerapkan grup keamanan yang berbeda ke beban kerja yang berbeda, buat `NodePool` sumber daya terpisah `NodeClass` dan gunakan taint, toleransi, atau pemilih node untuk menjadwalkan beban kerja ke node yang sesuai.
+ **Mengurangi kepadatan Pod**: Lebih sedikit Pod yang dapat berjalan pada setiap node karena antarmuka jaringan utama node dicadangkan untuk IP node dan tidak dapat digunakan untuk Pod.
+ **Batasan pemilih subnet**: Standar `subnetSelectorTerms` dan `securityGroupSelectorTerms` konfigurasi tidak berlaku untuk subnet Pod atau pemilihan grup keamanan.
+ **Perencanaan jaringan**: Pastikan ruang alamat IP yang memadai di subnet node dan Pod untuk mendukung kebutuhan beban kerja Anda.
+ **Konfigurasi routing**: Verifikasi bahwa tabel rute dan Network Access Control List (ACL) dari subnet Pod dikonfigurasi dengan benar untuk komunikasi antara subnet node dan Pod.
+ **Availability Zones**: Verifikasi bahwa Anda telah membuat subnet Pod di beberapa AZs subnet. Jika Anda menggunakan subnet Pod tertentu, subnet tersebut harus berada di AZ yang sama dengan subnet node AZ.
## Mode IP Sekunder untuk Pod
`ipv4PrefixSize`Bidang ini memungkinkan konfigurasi jaringan lanjutan dengan mengalokasikan hanya alamat IP sekunder ke node. Fitur ini tidak mengalokasikan awalan (/28) ke node dan hanya mempertahankan satu IP sekunder sebagai Minimal. IPTarget
### Kasus penggunaan
Gunakan `ipv4PrefixSize` saat Anda perlu:
+ **Pengurangan pemanfaatan IP**: Hanya satu alamat IP yang akan dihangatkan di setiap node.
+ **Tingkat churning pod yang lebih rendah**: Kecepatan pembuatan pod bukanlah masalah utama.
+ **Tidak ada fragmentasi awalan: Fragmentasi** yang disebabkan oleh awalan adalah perhatian utama atau pemblokir untuk menggunakan Mode Otomatis.
### Contoh konfigurasi
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### Pertimbangan untuk mode IP sekunder
+ **Kecepatan pembuatan Pod yang berkurang**: Karena hanya satu IP sekunder yang dihangatkan, layanan IPAM membutuhkan lebih banyak waktu untuk menyediakan IPs ketika lebih banyak pod dibuat.
## IPv4 Nonaktifkan jalan keluar dari IPv6 pod dalam IPv6 cluster.
`enableV4Egress`Bidang ini secara `true` default. Untuk IPv6 kluster Mode Otomatis, fitur ini dapat dinonaktifkan sehingga Mode Otomatis tidak akan membuat antarmuka khusus egres untuk pod IPv4 . IPv6 Ini penting karena antarmuka jalan IPv4 keluar tidak tunduk pada penegakan Kebijakan Jaringan. Kebijakan jaringan hanya diberlakukan pada antarmuka utama Pod (eth0).
### Kasus penggunaan
Gunakan `enableV4Egress` saat Anda perlu:
+ **Gunakan IPv6 Cluster** IPv4 : lalu lintas keluar diizinkan secara default.
+ **Gunakan Kebijakan Jaringan**: Saat ini Kebijakan Jaringan EKS tidak mendukung tumpukan ganda. Menonaktifkan `enableV4Egress` dapat mencegah lalu lintas pod keluar secara tak terduga. IPv4
### Contoh konfigurasi
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### Pertimbangan untuk menonaktifkan EnableV4eGress
+ **Kebijakan Jaringan di IPv6 Cluster: IPv6 cluster** mengizinkan IPv4 lalu lintas secara default. Pengaturan `enableV4Egress: false` memblokir IPv4 lalu lintas keluar, memberikan keamanan yang ditingkatkan terutama ketika digunakan dengan Kebijakan Jaringan.
# Buat Node Pool untuk Mode Otomatis EKS
Kumpulan node Amazon EKS menawarkan cara yang fleksibel untuk mengelola sumber daya komputasi di klaster Kubernetes Anda. Topik ini menunjukkan cara membuat dan mengkonfigurasi kumpulan node dengan menggunakan Karpenter, alat penyediaan node yang membantu mengoptimalkan penskalaan cluster dan pemanfaatan sumber daya. Dengan NodePool sumber daya Karpenter, Anda dapat menentukan persyaratan spesifik untuk sumber daya komputasi Anda, termasuk jenis instans, zona ketersediaan, arsitektur, dan jenis kapasitas.
Anda tidak dapat memodifikasi kumpulan bawaan `system` dan `general-purpose` node. Anda hanya dapat mengaktifkan atau menonaktifkannya. Untuk informasi selengkapnya, lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
NodePool Spesifikasi ini memungkinkan kontrol halus atas sumber daya komputasi kluster EKS Anda melalui berbagai label dan persyaratan yang didukung. Ini termasuk opsi untuk menentukan kategori EC2 instance, konfigurasi CPU, zona ketersediaan, arsitektur (ARM64/AMD64), dan jenis kapasitas (spot atau on-demand). Anda juga dapat menetapkan batas sumber daya untuk penggunaan CPU dan memori, memastikan klaster Anda tetap berada dalam batas operasional yang diperlukan.
Mode Otomatis EKS memanfaatkan label Kubernetes yang terkenal untuk memberikan cara yang konsisten dan terstandarisasi dalam mengidentifikasi karakteristik node. Label ini, seperti `topology.kubernetes.io/zone` untuk zona ketersediaan dan `kubernetes.io/arch` arsitektur CPU, mengikuti konvensi Kubernetes yang telah ditetapkan. Selain itu, label khusus EKS (diawali dengan`eks.amazonaws.com/`) memperluas fungsionalitas ini dengan atribut AWS-spesifik seperti tipe instance, produsen CPU, kemampuan GPU, dan spesifikasi jaringan. Sistem pelabelan standar ini memungkinkan integrasi tanpa batas dengan alat Kubernetes yang ada sambil menyediakan integrasi infrastruktur yang mendalam. AWS
## Buat NodePool
Ikuti langkah-langkah berikut NodePool untuk membuat klaster Amazon EKS Anda:
1. Buat file YAMB bernama `nodepool.yaml` dengan NodePool konfigurasi yang Anda butuhkan. Anda dapat menggunakan konfigurasi sampel di bawah ini.
1. Terapkan NodePool ke cluster Anda:
```
kubectl apply -f nodepool.yaml
```
1. Verifikasi bahwa NodePool telah berhasil dibuat:
```
kubectl get nodepools
```
1. (Opsional) Pantau NodePool status:
```
kubectl describe nodepool default
```
Pastikan NodePool referensi Anda valid NodeClass yang ada di cluster Anda. NodeClass Mendefinisikan konfigurasi AWS-spesifik untuk sumber daya komputasi Anda. Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md).
## Sampel NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## Label yang Didukung Mode Otomatis EKS
Mode Otomatis EKS mendukung label terkenal berikut ini.
**catatan**
Mode Otomatis EKS menggunakan label yang berbeda dari Karpenter. Label yang terkait dengan instance EC2 terkelola dimulai dengan`eks.amazonaws.com`.
| Label | Contoh | Deskripsi |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-timur-2a | AWS wilayah |
| node.kubernetes.io/instance-type | g4dn.8xlarge | AWS jenis contoh |
| kubernetes.io/lengkungan | amd64 | Arsitektur didefinisikan oleh [nilai-nilai GOARCH](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) pada instance |
| karpenter.sh/tipe kapasitas | melihat | Jenis kapasitas meliputi`spot`, `on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | Jenis instans yang menggunakan hypervisor tertentu |
| eks.amazonaws.com/compute-type | auto | Mengidentifikasi node terkelola Mode Otomatis EKS |
| eks.amazonaws.com/ -didukung instance-encryption-in-transit | true | Jenis instans yang mendukung (atau tidak) enkripsi dalam transit |
| eks.amazonaws.com/instance-category | g | Jenis instance dari kategori yang sama, biasanya string sebelum nomor generasi |
| eks.amazonaws.com/instance-generation | 4 | Nomor generasi tipe instans dalam kategori instance |
| eks.amazonaws.com/instance-family | g4dn | Jenis instance dari properti serupa tetapi jumlah sumber daya yang berbeda |
| eks.amazonaws.com/instance-size | 8xlarge | Jenis contoh dari jumlah sumber daya yang sama tetapi properti yang berbeda |
| eks.amazonaws.com/instance-cpu | 32 | Jumlah CPUs pada instance |
| eks.amazonaws.com/ instance-cpu-manufacturer | `aws` | Nama produsen CPU |
| eks.amazonaws.com/instance-memory | 131072 | Jumlah mebibytes memori pada instance |
| eks.amazonaws.com/ instance-ebs-bandwidth | 9500 | Jumlah [maksimum megabit](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) EBS yang tersedia pada instans |
| eks.amazonaws.com/ instance-network-bandwidth | 131072 | Jumlah [megabit dasar yang tersedia pada instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) |
| eks.amazonaws.com/ instance-gpu-name | t4 | Nama GPU pada instance, jika tersedia |
| eks.amazonaws.com/ instance-gpu-manufacturer | nvidia | Nama produsen GPU |
| eks.amazonaws.com/ instance-gpu-count | 1 | Jumlah GPUs pada instance |
| eks.amazonaws.com/ instance-gpu-memory | 16384 | Jumlah mebibytes memori pada GPU |
| eks.amazonaws.com/ instance-local-nvme | 900 | Jumlah gibibyte penyimpanan nvme lokal pada instance |
**catatan**
Mode Otomatis EKS hanya mendukung instance tertentu, dan memiliki persyaratan ukuran minimum. Untuk informasi selengkapnya, lihat [Referensi instans yang didukung Mode Otomatis EKS](automode-learn-instances.md#auto-supported-instances).
## Mode Otomatis EKS Tidak Didukung Label
Mode Otomatis EKS tidak mendukung label berikut.
+ Mode Otomatis EKS hanya mendukung Linux
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## Nonaktifkan kolam node bawaan
Jika Anda membuat kumpulan node kustom, Anda dapat menonaktifkan kumpulan node bawaan. Untuk informasi selengkapnya, lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
## Cluster tanpa kolam node bawaan
Anda dapat membuat cluster tanpa kumpulan node bawaan. Ini sangat membantu ketika organisasi Anda telah membuat kumpulan node yang disesuaikan.
**catatan**
Saat Anda membuat cluster tanpa kumpulan node bawaan, cluster tidak `default` NodeClass disediakan secara otomatis. Anda harus membuat kustom NodeClass. Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md).
**Ikhtisar:**
1. Buat cluster EKS dengan keduanya `nodePools` dan `nodeRoleArn` nilai kosong.
+ Contoh `autoModeConfig` eksctl:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
Untuk informasi selengkapnya, lihat [Buat Kluster Mode Otomatis EKS dengan CLI eksctl](automode-get-started-eksctl.md)
1. Buat kelas node kustom dengan peran node ARN
+ Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md)
1. Buat entri akses untuk kelas node kustom
+ Untuk informasi selengkapnya, lihat [Buat entri akses kelas node](create-node-class.md#auto-node-access-entry)
1. Buat kumpulan node kustom, seperti dijelaskan di atas.
## Gangguan
Anda dapat mengonfigurasi Mode Otomatis EKS untuk mengganggu Node melalui Anda NodePool dalam berbagai cara. Anda dapat menggunakan`spec.disruption.consolidationPolicy`,`spec.disruption.consolidateAfter`, atau`spec.template.spec.expireAfter`. Anda juga dapat menilai batas gangguan Mode Otomatis EKS melalui NodePool's. `spec.disruption.budgets` Anda juga dapat mengontrol jendela waktu dan jumlah Node simultan yang terganggu. Untuk petunjuk tentang mengonfigurasi perilaku ini, lihat [Gangguan](https://karpenter.sh/docs/concepts/disruption/) dalam Dokumentasi Karpenter.
Anda dapat mengonfigurasi gangguan untuk kumpulan node menjadi:
+ Identifikasi kapan instance kurang dimanfaatkan, dan konsolidasikan beban kerja.
+ Buat anggaran gangguan kumpulan node untuk menilai penghentian node batas karena penyimpangan, kekosongan, dan konsolidasi.
Secara default, Mode Otomatis EKS:
+ Mengkonsolidasikan instance yang kurang dimanfaatkan.
+ Mengakhiri instance setelah 336 jam.
+ Menetapkan anggaran gangguan tunggal 10% dari node.
+ Memungkinkan Node diganti karena drift ketika AMI Mode Otomatis baru dirilis, yang terjadi kira-kira sekali per minggu.
## Masa Tenggang Penghentian
Ketika a tidak `terminationGracePeriod` didefinisikan secara eksplisit pada EKS Auto NodePool, sistem secara otomatis menerapkan masa tenggang penghentian 24 jam default ke yang terkait. NodeClaim Meskipun pelanggan EKS Auto tidak akan melihat `terminationGracePeriod` default dalam NodePool konfigurasi kustom mereka, mereka akan mengamati nilai default ini di. NodeClaim Fungsionalitas tetap konsisten apakah masa tenggang ditetapkan secara eksplisit pada NodePool atau default pada NodeClaim, memastikan perilaku penghentian node yang dapat diprediksi di seluruh cluster.
# Kolam Node Kapasitas Statis dalam Mode Otomatis EKS
Amazon EKS Auto Mode mendukung kumpulan node kapasitas statis yang mempertahankan jumlah node tetap terlepas dari permintaan pod. Kumpulan node kapasitas statis berguna untuk beban kerja yang memerlukan kapasitas yang dapat diprediksi, instance cadangan, atau persyaratan kepatuhan khusus di mana Anda perlu mempertahankan jejak infrastruktur yang konsisten.
Tidak seperti kumpulan node dinamis yang menskalakan berdasarkan permintaan penjadwalan pod, kumpulan node kapasitas statis mempertahankan jumlah node yang telah Anda konfigurasikan.
## Konfigurasikan kumpulan node kapasitas statis
Untuk membuat kumpulan node kapasitas statis, atur `replicas` bidang dalam NodePool spesifikasi Anda. `replicas`Bidang mendefinisikan jumlah pasti node yang akan dipertahankan oleh kumpulan node. Lihat [Contoh](#static-capacity-examples) cara mengkonfigurasi`replicas`.
## Pertimbangan kumpulan node kapasitas statis
Pool node kapasitas statis memiliki beberapa kendala dan perilaku penting:
**Kendala konfigurasi:**
+ **Tidak dapat beralih mode**: Setelah Anda mengatur `replicas` kumpulan node, Anda tidak dapat menghapusnya. Kumpulan node tidak dapat beralih antara mode statis dan dinamis.
+ **Batas sumber daya terbatas**: Hanya `limits.nodes` bidang yang didukung di bagian batas. Batas CPU dan memori tidak berlaku.
+ **Tidak ada bidang berat**: `weight` Bidang tidak dapat diatur pada kumpulan node kapasitas statis karena pemilihan node tidak didasarkan pada prioritas.
**Perilaku operasional:**
+ **Tidak ada konsolidasi**: Node dalam kumpulan kapasitas statis tidak dipertimbangkan untuk konsolidasi.
+ **Operasi penskalaan**: Operasi skala melewati anggaran gangguan node tetapi masih menghormati. PodDisruptionBudgets
+ **Penggantian node**: Node masih diganti untuk drift (seperti pembaruan AMI) dan kedaluwarsa berdasarkan konfigurasi Anda.
## Praktik terbaik
**Perencanaan kapasitas:**
+ Tetapkan `limits.nodes` lebih tinggi daripada `replicas` untuk memungkinkan penskalaan sementara selama operasi penggantian node.
+ Pertimbangkan kapasitas maksimum yang diperlukan selama node drift atau pembaruan AMI saat menetapkan batas.
**Pemilihan instans:**
+ Gunakan jenis instans tertentu ketika Anda memiliki Instans Cadangan atau persyaratan perangkat keras tertentu.
+ Hindari persyaratan yang terlalu ketat yang mungkin membatasi ketersediaan instance selama penskalaan.
**Manajemen gangguan:**
+ Konfigurasikan anggaran gangguan yang sesuai untuk menyeimbangkan ketersediaan dengan operasi pemeliharaan.
+ Pertimbangkan toleransi aplikasi Anda untuk penggantian node saat menetapkan persentase anggaran.
**Pemantauan** :
+ Pantau `status.nodes` lapangan secara teratur untuk memastikan kapasitas yang Anda inginkan tetap terjaga.
+ Siapkan peringatan ketika jumlah node sebenarnya menyimpang dari replika yang diinginkan.
**Distribusi zona:**
+ Untuk ketersediaan tinggi, sebarkan kapasitas statis di beberapa Availability Zone.
+ Saat Anda membuat kumpulan node kapasitas statis yang mencakup beberapa zona ketersediaan, Mode Otomatis EKS mendistribusikan node di seluruh zona yang ditentukan, tetapi distribusinya tidak dijamin genap.
+ Untuk distribusi yang dapat diprediksi dan merata di seluruh zona ketersediaan, buat kumpulan node kapasitas statis terpisah, masing-masing disematkan ke zona ketersediaan tertentu menggunakan `topology.kubernetes.io/zone` persyaratan.
+ Jika Anda membutuhkan 12 node yang didistribusikan secara merata di tiga zona, buat tiga kumpulan node dengan masing-masing 4 replika, bukan satu kumpulan node dengan 12 replika di tiga zona.
## Menskalakan kumpulan node kapasitas statis
Anda dapat mengubah jumlah replika dalam kumpulan node kapasitas statis menggunakan `kubectl scale` perintah:
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
Saat menurunkan skala, Mode Otomatis EKS akan menghentikan node dengan anggun, menghormati PodDisruptionBudgets dan memungkinkan pod yang sedang berjalan dijadwalkan ulang ke node yang tersisa.
## Pantau kolam simpul kapasitas statis
Gunakan perintah berikut untuk memantau kumpulan node kapasitas statis Anda:
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
`status.nodes`Bidang menunjukkan jumlah node saat ini yang dikelola oleh kumpulan node, yang harus sesuai dengan `replicas` jumlah yang Anda inginkan dalam kondisi normal.
## Pemecahan masalah
**Node tidak mencapai replika yang diinginkan:**
+ Periksa apakah `limits.nodes` nilainya cukup
+ Verifikasi bahwa persyaratan Anda tidak terlalu membatasi pemilihan instans
+ Tinjau kuota AWS layanan untuk jenis dan wilayah instans yang Anda gunakan
**Penggantian node terlalu lama:**
+ Sesuaikan anggaran gangguan untuk memungkinkan penggantian lebih bersamaan
+ Periksa PodDisruptionBudgets apakah mencegah penghentian simpul
**Penghentian simpul yang tidak terduga:**
+ Tinjau `expireAfter` dan `terminationGracePeriod` pengaturan
+ Periksa penghentian node manual atau acara AWS pemeliharaan
## Contoh
### Kolam simpul kapasitas statis dasar
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### Kapasitas statis dengan tipe instans tertentu
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### Kolam simpul kapasitas statis multi-zona
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### Kapasitas statis dengan reservasi kapasitas
Contoh berikut menunjukkan cara menggunakan kolam node kapasitas statis dengan Reservasi Kapasitas EC2. Untuk informasi selengkapnya tentang penggunaan Reservasi Kapasitas EC2 dengan Mode Otomatis EKS, lihat. [Kontrol penyebaran beban kerja ke Reservasi Kapasitas dengan Mode Otomatis EKS](auto-odcr.md)
`NodeClass`mendefinisikan `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool`mereferensikan hal di atas `NodeClass` dan menggunakan`karpenter.sh/capacity-type: reserved`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# Buat IngressClass untuk mengkonfigurasi Application Load Balancer
Mode Otomatis EKS mengotomatiskan tugas rutin untuk penyeimbangan beban, termasuk mengekspos aplikasi cluster ke internet.
AWS menyarankan menggunakan Application Load Balancers (ALB) untuk melayani lalu lintas HTTP dan HTTPS. Application Load Balancers dapat merutekan permintaan berdasarkan konten permintaan. Untuk informasi selengkapnya tentang Application Load Balancer, lihat [Apa itu Elastic](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) Load Balancing?
EKS Auto Mode membuat dan mengkonfigurasi Application Load Balancers (). ALBs Misalnya, Mode Otomatis EKS membuat penyeimbang beban saat Anda membuat objek `Ingress` Kubernetes dan mengonfigurasinya untuk merutekan lalu lintas ke beban kerja klaster Anda.
**Ikhtisar**
1. Buat beban kerja yang ingin Anda ekspos ke internet.
1. Buat `IngressClassParams` sumber daya, tentukan nilai konfigurasi AWS tertentu seperti sertifikat yang akan digunakan untuk SSL/TLS dan Subnet VPC.
1. Buat `IngressClass` sumber daya, tentukan bahwa Mode Otomatis EKS akan menjadi pengontrol untuk sumber daya.
1. Buat `Ingress` sumber daya yang mengaitkan jalur HTTP dan port dengan beban kerja cluster.
Mode Otomatis EKS akan membuat Application Load Balancer yang menunjuk ke beban kerja yang ditentukan dalam `Ingress` sumber daya, menggunakan konfigurasi penyeimbang beban yang ditentukan dalam sumber daya. `IngressClassParams`
## Prasyarat
+ Mode Otomatis EKS Diaktifkan di Amazon EKS Cluster
+ Kubectl dikonfigurasi untuk terhubung ke klaster Anda
+ Anda dapat menggunakan `kubectl apply -f ` untuk menerapkan konfigurasi sampel file YAMAL di bawah ini ke cluster Anda.
**catatan**
Mode Otomatis EKS memerlukan tag subnet untuk mengidentifikasi subnet publik dan pribadi.
Jika Anda membuat cluster Anda dengan`eksctl`, Anda sudah memiliki tag ini.
Pelajari cara [Tag subnet untuk Mode Otomatis EKS](tag-subnets-auto.md).
## Langkah 1: Buat beban kerja
Untuk memulai, buat beban kerja yang ingin Anda ekspos ke internet. Ini bisa berupa sumber daya Kubernetes yang melayani lalu lintas HTTP, seperti Deployment atau Service.
Contoh ini menggunakan layanan HTTP sederhana `service-2048` yang disebut yang mendengarkan pada port`80`. Buat layanan ini dan penyebarannya dengan menerapkan manifes berikut,`2048-deployment-service.yaml`:
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
Terapkan konfigurasi ke cluster Anda:
```
kubectl apply -f 2048-deployment-service.yaml
```
Sumber daya yang tercantum di atas akan dibuat di namespace default. Anda dapat memverifikasi ini dengan menjalankan perintah berikut:
```
kubectl get all -n default
```
## Langkah 2: Buat IngressClassParams
Buat `IngressClassParams` objek untuk menentukan opsi konfigurasi AWS tertentu untuk Application Load Balancer. Dalam contoh ini, kami membuat `IngressClassParams` sumber daya bernama `alb` (yang akan Anda gunakan pada langkah berikutnya) yang menentukan skema penyeimbang beban seperti `internet-facing` dalam file bernama. `alb-ingressclassparams.yaml`
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
Terapkan konfigurasi ke cluster Anda:
```
kubectl apply -f alb-ingressclassparams.yaml
```
## Langkah 3: Buat IngressClass
Buat `IngressClass` yang mereferensikan nilai konfigurasi AWS tertentu yang ditetapkan dalam `IngressClassParams` sumber daya dalam file bernama`alb-ingressclass.yaml`. Perhatikan nama`IngressClass`. Dalam contoh ini, keduanya `IngressClass` dan `IngressClassParams` diberi nama`alb`.
Gunakan `is-default-class` anotasi untuk mengontrol apakah `Ingress` sumber daya harus menggunakan kelas ini secara default.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
Untuk informasi selengkapnya tentang opsi konfigurasi, lihat[IngressClassParams Referensi](#ingress-reference).
Terapkan konfigurasi ke cluster Anda:
```
kubectl apply -f alb-ingressclass.yaml
```
## Langkah 4: Buat Ingress
Buat `Ingress` sumber daya dalam file bernama`alb-ingress.yaml`. Tujuan dari sumber daya ini adalah untuk mengaitkan path dan port pada Application Load Balancer dengan beban kerja di cluster Anda. Untuk contoh ini, kami membuat `Ingress` sumber daya bernama `2048-ingress` yang merutekan lalu lintas ke layanan bernama `service-2048` pada port 80.
Untuk informasi selengkapnya tentang mengonfigurasi resource ini, lihat [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) di Dokumentasi Kubernetes.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
Terapkan konfigurasi ke cluster Anda:
```
kubectl apply -f alb-ingress.yaml
```
## Langkah 5: Periksa Status
Gunakan `kubectl` untuk menemukan status`Ingress`. Diperlukan beberapa menit agar penyeimbang beban tersedia.
Gunakan nama `Ingress` sumber daya yang Anda tetapkan pada langkah sebelumnya. Contoh:
```
kubectl get ingress 2048-ingress
```
Setelah sumber daya siap, ambil nama domain penyeimbang beban.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
Untuk melihat layanan di browser web, tinjau port dan jalur yang ditentukan dalam `Ingress` penyelamatan.
## Langkah 6: Pembersihan
Untuk membersihkan penyeimbang beban, gunakan perintah berikut:
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
Mode Otomatis EKS akan secara otomatis menghapus penyeimbang beban terkait di AWS akun Anda.
## IngressClassParams Referensi
Tabel di bawah ini adalah referensi cepat untuk opsi konfigurasi yang umum digunakan.
| Bidang | Deskripsi | Nilai contoh |
| --- | --- | --- |
| `scheme` | Mendefinisikan apakah ALB bersifat internal atau berhadapan dengan internet | `internet-facing` |
| `namespaceSelector` | Membatasi ruang nama mana yang dapat menggunakan ini IngressClass | `environment: prod` |
| `group.name` | Kelompokkan beberapa Ingress untuk berbagi satu ALB | `retail-apps` |
| `ipAddressType` | Menetapkan jenis alamat IP untuk ALB | `dualstack` |
| `subnets.ids` | Daftar subnet IDs untuk penyebaran ALB | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | Tag filter untuk memilih subnet untuk ALB | `Environment: prod` |
| `certificateARNs` | ARNs Sertifikat SSL untuk digunakan | ` arn:aws: acm:region:account:certificate/id` |
| `tags` | Tag khusus untuk AWS sumber daya | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | Atribut khusus penyeimbang beban | `idle_timeout.timeout_seconds: 60` |
## Pertimbangan-pertimbangan
+ Anda tidak dapat menggunakan Anotasi pada IngressClass untuk mengonfigurasi penyeimbang beban dengan Mode Otomatis EKS. IngressClass konfigurasi harus dilakukan melalui IngressClassParams. Namun, Anda dapat menggunakan anotasi pada sumber daya Ingress individual untuk mengonfigurasi perilaku penyeimbang beban (seperti `alb.ingress.kubernetes.io/security-group-prefix-lists` atau). `alb.ingress.kubernetes.io/conditions.*`
+ Anda tidak dapat mengatur [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)dengan Mode Otomatis EKS.
+ Anda harus memperbarui Peran IAM Cluster untuk mengaktifkan propagasi tag dari Kubernetes ke sumber daya Load AWS Balancer. Untuk informasi selengkapnya, lihat [AWS Tag khusus untuk sumber daya EKS Auto](auto-learn-iam.md#tag-prop).
+ Untuk informasi tentang mengaitkan sumber daya dengan Mode Otomatis EKS atau Pengontrol Load AWS Balancer yang dikelola sendiri, lihat. [Referensi migrasi](migrate-auto.md#migration-reference)
+ Untuk informasi tentang memperbaiki masalah dengan penyeimbang beban, lihat. [Memecahkan Masalah Mode Otomatis EKS](auto-troubleshoot.md)
+ Untuk pertimbangan lebih lanjut tentang penggunaan kemampuan load balancing dari Mode Otomatis EKS, lihat. [Penyeimbangan beban](auto-networking.md#auto-lb-consider)
Tabel berikut memberikan perbandingan rinci perubahan, anotasi Ingress IngressClassParams, dan TargetGroupBinding konfigurasi untuk Mode Otomatis EKS. Tabel ini menyoroti perbedaan utama antara kemampuan penyeimbangan beban Mode Otomatis EKS dan pengontrol penyeimbang beban sumber terbuka, termasuk perubahan versi API, fitur yang tidak digunakan lagi, dan nama parameter yang diperbarui.
### IngressClassParams
| Sebelumnya | Baru | Deskripsi |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Perubahan versi API |
| `spec.certificateArn` | `spec.certificateARNs` | Support untuk beberapa sertifikat ARNs |
| `spec.subnets.tags` | `spec.subnets.matchTags` | Skema pencocokan subnet yang diubah |
| `spec.listeners.listenerAttributes` | Tidak didukung | Belum didukung oleh Mode Otomatis EKS |
### Anotasi masuk
| Sebelumnya | Baru | Deskripsi |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | Tidak didukung | Gunakan `spec.ingressClassName` pada objek Ingress |
| `alb.ingress.kubernetes.io/group.name` | Tidak didukung | Tentukan grup IngressClass hanya |
| `alb.ingress.kubernetes.io/waf-acl-id` | Tidak didukung | Gunakan WAF v2 sebagai gantinya |
| `alb.ingress.kubernetes.io/web-acl-id` | Tidak didukung | Gunakan WAF v2 sebagai gantinya |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | Tidak didukung | Integrasi Shield dinonaktifkan |
| `alb.ingress.kubernetes.io/auth-type: oidc` | Tidak didukung | Jenis Auth OIDC saat ini tidak didukung |
### TargetGroupBinding
| Sebelumnya | Baru | Deskripsi |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Perubahan versi API |
| `spec.targetType`opsional | `spec.targetType`diperlukan | Spesifikasi tipe target eksplisit |
| `spec.networking.ingress.from` | Tidak didukung | Tidak lagi mendukung NLB tanpa grup keamanan |
Untuk menggunakan TargetGroupBinding fitur kustom, Anda harus menandai grup target dengan eks-cluster-name tag eks: dengan nama cluster untuk memberikan pengontrol izin IAM yang diperlukan. Ketahuilah bahwa pengontrol akan menghapus grup target saat TargetGroupBinding sumber daya atau cluster dihapus.
# Gunakan Anotasi Layanan untuk mengonfigurasi Network Load Balancers
Pelajari cara mengonfigurasi Network Load Balancers (NLB) di Amazon EKS menggunakan anotasi layanan Kubernetes. Topik ini menjelaskan anotasi yang didukung oleh Mode Otomatis EKS untuk menyesuaikan perilaku NLB, termasuk aksesibilitas internet, pemeriksaan kesehatan, SSL/TLS penghentian, dan mode penargetan IP.
Ketika Anda membuat layanan Kubernetes dari tipe `LoadBalancer` dalam Mode Otomatis EKS, EKS secara otomatis menyediakan dan mengonfigurasi AWS Network Load Balancer berdasarkan anotasi yang Anda tentukan. Pendekatan deklaratif ini memungkinkan Anda untuk mengelola konfigurasi penyeimbang beban secara langsung melalui manifes Kubernetes Anda, mempertahankan infrastruktur sebagai praktik kode.
Mode Otomatis EKS menangani penyediaan Network Load Balancer secara default untuk semua jenis layanan LoadBalancer - tidak diperlukan instalasi atau konfigurasi pengontrol tambahan. `loadBalancerClass: eks.amazonaws.com/nlb`Spesifikasi secara otomatis ditetapkan sebagai default cluster, merampingkan proses penerapan sambil mempertahankan kompatibilitas dengan beban kerja Kubernetes yang ada.
**catatan**
Mode Otomatis EKS memerlukan tag subnet untuk mengidentifikasi subnet publik dan pribadi.
Jika Anda membuat cluster Anda dengan`eksctl`, Anda sudah memiliki tag ini.
Pelajari cara [Tag subnet untuk Mode Otomatis EKS](tag-subnets-auto.md).
## Layanan Sampel
Untuk informasi selengkapnya tentang `Service` sumber daya Kubernetes, lihat Dokumentasi Kubernetes[.](https://kubernetes.io/docs/concepts/services-networking/service/)
Tinjau `Service` sumber daya sampel di bawah ini:
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## Anotasi yang umum digunakan
Tabel berikut mencantumkan anotasi yang umum digunakan yang didukung oleh Mode Otomatis EKS. Perhatikan bahwa Mode Otomatis EKS mungkin tidak mendukung semua anotasi.
**Tip**
Semua anotasi berikut harus diawali dengan `service.beta.kubernetes.io/`
| Bidang | Deskripsi | Contoh |
| --- | --- | --- |
| `aws-load-balancer-type` | Menentukan jenis penyeimbang beban. Gunakan `external` untuk penerapan baru. | `external` |
| `aws-load-balancer-nlb-target-type` | Menentukan apakah akan merutekan lalu lintas ke instance node atau langsung ke pod. IPs Gunakan `instance` untuk penerapan standar atau `ip` untuk routing pod langsung. | `instance` |
| `aws-load-balancer-scheme` | Mengontrol apakah penyeimbang beban internal atau menghadap ke internet. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | Protokol pemeriksaan kesehatan untuk kelompok sasaran. Opsi umum adalah `TCP` (default) atau`HTTP`. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | Jalur HTTP untuk pemeriksaan kesehatan saat menggunakan HTTP/HTTPS protokol. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | Pelabuhan yang digunakan untuk pemeriksaan kesehatan. Bisa berupa nomor port tertentu atau`traffic-port`. | `traffic-port` |
| `aws-load-balancer-subnets` | Menentukan subnet mana untuk membuat penyeimbang beban di. Dapat menggunakan subnet IDs atau nama. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | ARN sertifikat SSL dari Certificate Manager untuk AWS HTTPS/TLS. | ` arn:aws: acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | Menentukan port mana yang harus menggunakan SSL/TLS. | `443, 8443` |
| `load-balancer-source-ranges` | Rentang CIDR diizinkan untuk mengakses penyeimbang beban. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | AWS Tag tambahan untuk diterapkan ke penyeimbang beban dan sumber daya terkait. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | Menentukan apakah penyeimbang beban menggunakan IPv4 atau dual-stack (\$1). IPv4 IPv6 | `ipv4` atau `dualstack` |
## Pertimbangan-pertimbangan
+ Anda harus memperbarui Peran IAM Cluster untuk mengaktifkan propagasi tag dari Kubernetes ke sumber daya Load AWS Balancer. Untuk informasi selengkapnya, lihat [AWS Tag khusus untuk sumber daya EKS Auto](auto-learn-iam.md#tag-prop).
+ Untuk informasi tentang mengaitkan sumber daya dengan Mode Otomatis EKS atau Pengontrol Load AWS Balancer yang dikelola sendiri, lihat. [Referensi migrasi](migrate-auto.md#migration-reference)
+ Untuk informasi tentang memperbaiki masalah dengan penyeimbang beban, lihat. [Memecahkan Masalah Mode Otomatis EKS](auto-troubleshoot.md)
+ Untuk pertimbangan lebih lanjut tentang penggunaan kemampuan load balancing dari Mode Otomatis EKS, lihat. [Penyeimbangan beban](auto-networking.md#auto-lb-consider)
Saat bermigrasi ke Mode Otomatis EKS untuk penyeimbangan beban, beberapa perubahan dalam anotasi layanan dan konfigurasi sumber daya diperlukan. Tabel berikut menguraikan perbedaan utama antara implementasi sebelumnya dan baru, termasuk opsi yang tidak didukung dan alternatif yang direkomendasikan.
### Anotasi layanan
| Sebelumnya | Baru | Deskripsi |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | Tidak didukung | Gunakan `spec.loadBalancerSourceRanges` pada Layanan |
| `service.beta.kubernetes.io/aws-load-balancer-type` | Tidak didukung | Gunakan `spec.loadBalancerClass` pada Layanan |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` sebagai gantinya |
| Berbagai atribut penyeimbang beban | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-attributes` sebagai gantinya |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-attributes` sebagai gantinya |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-attributes` sebagai gantinya |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-attributes` sebagai gantinya |
Untuk bermigrasi dari anotasi atribut load balancer yang tidak digunakan lagi, konsolidasikan setelan ini ke dalam anotasi. `service.beta.kubernetes.io/aws-load-balancer-attributes` Anotasi ini menerima daftar pasangan kunci-nilai yang dipisahkan koma untuk berbagai atribut penyeimbang beban. Misalnya, untuk menentukan pencatatan akses, dan penyeimbangan beban lintas zona, gunakan format berikut:
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
Format konsolidasi ini menyediakan cara yang lebih konsisten dan fleksibel untuk mengonfigurasi atribut penyeimbang beban sekaligus mengurangi jumlah anotasi individual yang diperlukan. Tinjau konfigurasi Layanan yang ada dan perbarui untuk menggunakan format gabungan ini.
### TargetGroupBinding
| Sebelumnya | Baru | Deskripsi |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Perubahan versi API |
| `spec.targetType`opsional | `spec.targetType`diperlukan | Spesifikasi tipe target eksplisit |
| `spec.networking.ingress.from` | Tidak didukung | Tidak lagi mendukung NLB tanpa grup keamanan |
Catatan: Untuk menggunakan TargetGroupBinding fitur kustom, Anda harus menandai grup target dengan `eks:eks-cluster-name` tag dengan nama cluster untuk memberikan pengontrol izin IAM yang diperlukan. Ketahuilah bahwa pengontrol akan menghapus grup target saat TargetGroupBinding sumber daya atau cluster dihapus.
# Buat kelas penyimpanan
A `StorageClass` di Amazon EKS Auto Mode mendefinisikan bagaimana volume Amazon EBS secara otomatis disediakan ketika aplikasi meminta penyimpanan persisten. Halaman ini menjelaskan cara membuat dan mengonfigurasi `StorageClass` yang berfungsi dengan Mode Otomatis Amazon EKS untuk menyediakan volume EBS.
Dengan mengonfigurasi a`StorageClass`, Anda dapat menentukan pengaturan default untuk volume EBS Anda termasuk jenis volume, enkripsi, IOPS, dan parameter penyimpanan lainnya. Anda juga dapat mengkonfigurasi `StorageClass` untuk menggunakan kunci AWS KMS untuk manajemen enkripsi.
Mode Otomatis EKS tidak membuat `StorageClass` untuk Anda. Anda harus membuat `StorageClass` referensi `ebs.csi.eks.amazonaws.com` untuk menggunakan kemampuan penyimpanan Mode Otomatis EKS.
Pertama, buat file bernama`storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
Kedua, terapkan kelas penyimpanan ke cluster Anda.
```
kubectl apply -f storage-class.yaml
```
**Komponen kunci:**
+ `provisioner: ebs.csi.eks.amazonaws.com`- Menggunakan Mode Otomatis EKS
+ `allowedTopologies`- Menentukan `matchLabelExpressions` untuk mencocokkan `eks.amazonaws.com/compute-type:auto` akan memastikan bahwa jika pod Anda membutuhkan volume untuk secara otomatis disediakan menggunakan Mode Otomatis maka pod tidak akan dijadwalkan pada node non-Otomatis.
+ `volumeBindingMode: WaitForFirstConsumer`- Menunda pembuatan volume hingga pod membutuhkannya
+ `type: gp3`- Menentukan jenis volume EBS
+ `encrypted: "true"`- EBS akan mengenkripsi volume apa pun yang dibuat menggunakan file. `StorageClass` EBS akan menggunakan alias `aws/ebs` kunci default. Untuk informasi selengkapnya, lihat [Cara kerja enkripsi Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html) di Panduan Pengguna Amazon EBS. Nilai ini opsional tetapi disarankan.
+ `storageclass.kubernetes.io/is-default-class: "true"`- Kubernetes akan menggunakan kelas penyimpanan ini secara default, kecuali jika Anda menentukan kelas volume yang berbeda pada klaim volume persisten. Nilai ini bersifat opsional. Berhati-hatilah saat menyetel nilai ini jika Anda bermigrasi dari pengontrol penyimpanan yang berbeda.
## Gunakan kunci KMS yang dikelola sendiri untuk mengenkripsi volume EBS
Untuk menggunakan kunci KMS yang dikelola sendiri untuk mengenkripsi volume EBS yang diotomatisasi oleh Mode Otomatis EKS, Anda perlu:
1. Buat kunci KMS yang dikelola sendiri.
+ Untuk informasi selengkapnya, lihat [Membuat kunci KMS enkripsi simetris atau Cara](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) [Amazon Elastic Block Store (Amazon EBS) menggunakan](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html) KMS di Panduan Pengguna KMS.
1. Buat kebijakan baru yang mengizinkan akses ke kunci KMS.
+ Gunakan contoh kebijakan IAM di bawah ini untuk membuat kebijakan. Masukkan ARN dari kunci KMS yang dikelola sendiri yang baru. Untuk informasi selengkapnya, lihat [Membuat peran dan melampirkan kebijakan (konsol)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) di Panduan Pengguna AWS IAM.
1. Lampirkan kebijakan ke Peran Kluster EKS.
+ Gunakan AWS konsol untuk menemukan ARN dari EKS Cluster Role. Informasi peran terlihat di bagian **Ikhtisar**. Untuk informasi selengkapnya, lihat [IAM role klaster Amazon EKS](cluster-iam-role.md).
1. Perbarui `StorageClass` untuk mereferensikan ID Kunci KMS di `parameters.kmsKeyId` lapangan.
### Contoh Kebijakan IAM KMS yang dikelola sendiri
Perbarui nilai-nilai berikut dalam kebijakan di bawah ini:
+ ``ID AWS akun Anda, seperti `111122223333`
+ ``— AWS Wilayah cluster Anda, seperti `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Contoh KMS yang dikelola sendiri `StorageClass`
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## `StorageClass`Parameter Referensi
Untuk informasi umum tentang `StorageClass` sumber daya Kubernetes, lihat [Kelas Penyimpanan](https://kubernetes.io/docs/concepts/storage/storage-classes/) di Dokumentasi Kubernetes.
THe `parameters`bagian dari `StorageClass` sumber daya khusus untuk AWS. Gunakan tabel berikut untuk meninjau opsi yang tersedia.
| Parameter | Nilai | Default | Deskripsi |
| --- | --- | --- | --- |
| “csi.storage.k8s.io/fstype” | xfs, ext2, ext3, ext4 | ext4 | Jenis sistem file yang akan diformat selama pembuatan volume. Parameter ini peka huruf besar/kecil\$1 |
| “ketik” | io1, io2, gp2, gp3, sc1, st1, standar, sbp1, sbg1 | gp3 | Jenis volume EBS. |
| “iOpsPerGB” | | | Operasi I/O per detik per GiB. Dapat ditentukan untuk IO1, IO2, dan GP3 volume. |
| “AllowAuto IOPSPerGBIncrease” | benar, salah | false | Ketika`"true"`, driver CSI meningkatkan IOPS untuk volume ketika `iopsPerGB * ` terlalu rendah untuk masuk ke dalam rentang IOPS yang didukung oleh. AWS Hal ini memungkinkan penyediaan dinamis untuk selalu berhasil, bahkan ketika pengguna menentukan kapasitas atau nilai PVC yang terlalu kecil. `iopsPerGB` Di sisi lain, ini mungkin menimbulkan biaya tambahan, karena volume tersebut memiliki IOPS yang lebih tinggi daripada yang diminta. `iopsPerGB` |
| “iops” | | | Operasi I/O per detik. Dapat ditentukan untuk IO1, IO2, dan GP3 volume. |
| “throughput” | | 125 | Throughput dalam MIB/s. Hanya efektif ketika tipe volume gp3 ditentukan. |
| “dienkripsi” | benar, salah | false | Apakah volume harus dienkripsi atau tidak. Nilai yang valid adalah “benar” atau “salah”. |
| “BlockExpress” | benar, salah | false | Memungkinkan pembuatan volume Blok Ekspres io2. |
| "kmsKeyId" | | | ARN penuh dari kunci untuk digunakan saat mengenkripsi volume. Jika tidak ditentukan, AWS akan menggunakan kunci KMS default untuk wilayah volume berada. Ini akan menjadi kunci yang dibuat secara otomatis yang disebut `/aws/ebs` jika tidak diubah. |
| “BlockSize” | | | Ukuran blok yang akan digunakan saat memformat sistem file yang mendasarinya. Hanya didukung pada node linux dan dengan fstype`ext2`,, `ext3``ext4`, atau. `xfs` |
| “InodeSize” | | | Ukuran inode yang digunakan saat memformat sistem file yang mendasarinya. Hanya didukung pada node linux dan dengan fstype`ext2`,, `ext3``ext4`, atau. `xfs` |
| "bytesPerInode" | | | Yang `bytes-per-inode` digunakan saat memformat sistem file yang mendasarinya. Hanya didukung pada node linux dan dengan fstype`ext2`,,`ext3`. `ext4` |
| "numberOfInodes" | | | Yang `number-of-inodes` digunakan saat memformat sistem file yang mendasarinya. Hanya didukung pada node linux dan dengan fstype`ext2`,,`ext3`. `ext4` |
| “BigAllocext4" | benar, salah | false | Mengubah sistem `ext4` file untuk menggunakan alokasi blok berkerumun dengan mengaktifkan opsi pemformatan. `bigalloc` Peringatan: `bigalloc` mungkin tidak sepenuhnya didukung dengan kernel Linux node Anda. |
| “ClusterSizeext4" | | | Ukuran cluster yang akan digunakan saat memformat sistem `ext4` file saat fitur diaktifkan. `bigalloc` Catatan: `ext4BigAlloc` Parameter harus diatur ke true. |
Untuk informasi selengkapnya, lihat [Driver AWS EBS CSI](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md) di. GitHub
## Pertimbangan-pertimbangan
**catatan**
Anda hanya dapat menerapkan beban kerja tergantung pada Mode Otomatis EKS StorageClasses pada node Mode Otomatis EKS. Jika Anda memiliki cluster dengan tipe node campuran, Anda perlu mengonfigurasi beban kerja Anda agar berjalan hanya pada node Mode Otomatis EKS. Untuk informasi selengkapnya, lihat [Kontrol jika beban kerja diterapkan pada node Mode Otomatis EKS](associate-workload.md).
Kemampuan penyimpanan blok EKS Auto Mode berbeda dari EBS CSI Driver.
+ Penyediaan Statis
+ Jika Anda ingin menggunakan volume EBS yang dibuat secara eksternal dengan Mode Otomatis EKS, Anda perlu menambahkan AWS tag secara manual dengan kunci `eks:eks-cluster-name` dan nilai nama cluster.
+ Noda Startup Node
+ Anda tidak dapat menggunakan fitur taint startup node untuk mencegah penjadwalan pod sebelum kesiapan kemampuan penyimpanan
+ Tag Kustom pada Volume yang Disediakan Secara Dinamis
+ Anda tidak dapat menggunakan flag CLI tag ekstra untuk mengonfigurasi tag khusus pada volume EBS yang disediakan secara dinamis
+ Anda dapat menggunakan `StorageClass` penandaan untuk menambahkan tag khusus. Mode Otomatis EKS akan menambahkan tag ke AWS sumber daya terkait. Anda perlu memperbarui Peran IAM Cluster untuk tag khusus. Untuk informasi selengkapnya, lihat [AWS Tag khusus untuk sumber daya EKS Auto](auto-learn-iam.md#tag-prop).
+ Metrik Kinerja Terperinci EBS
+ Anda tidak dapat mengakses metrik Prometheus untuk performa rinci EBS
## Instal add-on CSI Snapshot Controller
Mode Otomatis EKS kompatibel dengan add-on CSI Snapshot Controller Amazon EKS.
AWS menyarankan Anda mengonfigurasi add-on ini untuk berjalan di kumpulan `system` node bawaan.
Untuk informasi lebih lanjut, lihat:
+ [Jalankan add-on penting pada instance khusus](critical-workload.md)
+ [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md)
+ [Aktifkan fungsionalitas snapshot untuk volume CSI](csi-snapshot-controller.md)
### Untuk menginstal pengontrol snapshot di kumpulan node sistem
1. Buka kluster EKS Anda di AWS konsol
1. Dari tab **Add-ons**, pilih **Dapatkan lebih banyak** add-on
1. **Pilih **CSI Snapshot Controller** dan kemudian Berikutnya**
1. Pada halaman **Konfigurasi pengaturan add-on yang dipilih, pilih Pengaturan** **konfigurasi opsional** untuk melihat skema konfigurasi **Add-on**
1. Masukkan yaml berikut untuk mengaitkan pengontrol snapshot dengan kumpulan `system` node. Pengontrol snapshot mencakup toleransi terhadap noda. `CriticalAddonsOnly`
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. Pilih **Berikutnya**
1. **Tinjau konfigurasi add-on dan kemudian pilih Buat**
# Nonaktifkan Mode Otomatis EKS
Anda dapat menonaktifkan Mode Otomatis EKS pada Kluster EKS yang ada. Ini adalah operasi yang merusak.
+ EKS akan menghentikan semua EC2 instans yang dioperasikan oleh Mode Otomatis EKS.
+ EKS akan menghapus semua Load Balancer yang dioperasikan oleh EKS Auto Mode.
+ EKS **tidak** akan menghapus volume EBS yang disediakan oleh Mode Otomatis EKS.
Mode Otomatis EKS dirancang untuk sepenuhnya mengelola sumber daya yang dibuatnya. Intervensi manual dapat mengakibatkan Mode Otomatis EKS gagal membersihkan sumber daya tersebut sepenuhnya saat dinonaktifkan. Misalnya, jika Anda merujuk ke Grup Keamanan terkelola dari aturan Grup Keamanan eksternal, dan lupa untuk menghapus referensi tersebut sebelum Anda menonaktifkan Mode Otomatis EKS untuk klaster, Grup Keamanan terkelola akan bocor (tidak dihapus). Langkah-langkah di bawah ini menjelaskan cara menghapus Grup Keamanan yang bocor jika itu terjadi.
## Nonaktifkan Mode Otomatis EKS (AWS Konsol)
1. Buka halaman ikhtisar cluster Anda di Konsol Manajemen AWS.
1. Di bawah **Mode Otomatis EKS** pilih **Kelola**
1. Alihkan **Mode Otomatis EKS** ke. `off`
Jika ada Grup Keamanan terkelola yang tidak dihapus pada akhir proses ini, Anda dapat menghapusnya secara manual menggunakan deskripsi dari [Hapus grup keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html).
## Nonaktifkan Mode Otomatis EKS (AWS CLI)
Gunakan perintah berikut untuk menonaktifkan Mode Otomatis EKS pada cluster yang ada.
Anda harus menginstal `aws` CLI, dan masuk dengan izin yang cukup untuk mengelola kluster EKS. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
**catatan**
Kemampuan komputasi, penyimpanan blok, dan penyeimbangan beban semuanya harus diaktifkan atau dinonaktifkan dalam permintaan yang sama.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
Anda dapat memeriksa apakah Grup Keamanan Mode Otomatis EKS yang bocor gagal dihapus setelah menonaktifkan Mode Otomatis EKS sebagai berikut:
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
Untuk kemudian menghapus Grup Keamanan:
```
aws ec2 delete-security-group --group-name=
```
# Memperbarui versi Kubernetes dari kluster Mode Otomatis EKS
Topik ini menjelaskan cara memperbarui versi Kubernetes dari kluster Mode Otomatis Anda. Mode Otomatis menyederhanakan proses pembaruan versi dengan menangani koordinasi pembaruan bidang kontrol dengan penggantian node, sambil mempertahankan ketersediaan beban kerja melalui anggaran gangguan pod.
Saat memutakhirkan kluster Mode Otomatis, banyak komponen yang secara tradisional memerlukan pembaruan manual sekarang dikelola sebagai bagian dari layanan. Memahami aspek otomatis dari proses peningkatan dan tanggung jawab Anda membantu memastikan transisi versi yang lancar untuk klaster Anda.
## Pelajari tentang pembaruan dengan Mode Otomatis EKS
Setelah Anda memulai upgrade control plane, EKS Auto Mode akan meng-upgrade node di cluster Anda. Saat node kedaluwarsa, Mode Otomatis EKS akan menggantinya dengan node baru. Node baru memiliki versi Kubernetes baru yang sesuai. Mode Otomatis EKS mengamati anggaran gangguan pod saat memutakhirkan node.
Selain itu, Anda tidak perlu lagi memperbarui komponen seperti:
+ Amazon VPC CNI
+ AWS Pengontrol Load Balancer
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS Pengemudi EBS CSI
Mode Otomatis EKS menggantikan komponen ini dengan fungsionalitas layanan.
Anda masih bertanggung jawab untuk memperbarui:
+ Aplikasi dan beban kerja yang diterapkan ke kluster Anda
+ Pengaya dan pengontrol yang dikelola sendiri
+ Pengaya Amazon EKS
+ Pelajari cara [Perbarui add-on Amazon EKS](updating-an-add-on.md)
Pelajari [Praktik Terbaik untuk Upgrade Cluster](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## Mulai Pembaruan Cluster
Untuk memulai pembaruan cluster, lihat[Perbarui klaster yang ada ke versi Kubernetes baru](update-cluster.md).
# Aktifkan atau Nonaktifkan Built-in NodePools
Mode Otomatis EKS memiliki dua built-in NodePools. Anda dapat mengaktifkan atau menonaktifkannya NodePools menggunakan AWS konsol, CLI, atau API.
## NodePool Referensi bawaan
+ `system`
+ Ini NodePool memiliki `CriticalAddonsOnly` noda. Banyak add-on EKS, seperti CoreDNS, mentolerir noda ini. Gunakan kumpulan node sistem ini untuk memisahkan aplikasi kluster-kritis.
+ Mendukung keduanya `amd64` dan `arm64` arsitektur.
+ `general-purpose`
+ Ini NodePool memberikan dukungan untuk meluncurkan node untuk beban kerja tujuan umum di klaster Anda.
+ Hanya menggunakan `amd64` arsitektur.
Keduanya built-in NodePools:
+ Gunakan EKS default NodeClass
+ Gunakan hanya kapasitas sesuai permintaan EC2
+ Gunakan keluarga EC2 instance C, M, dan R
+ Memerlukan generasi 5 atau instance yang lebih baru EC2
**catatan**
Mengaktifkan setidaknya satu built-in NodePool diperlukan untuk EKS untuk menyediakan “default”. NodeClass Jika Anda menonaktifkan semua bawaan NodePools, Anda harus membuat kustom NodeClass dan mengonfigurasi a NodePool untuk menggunakannya. Untuk informasi lebih lanjut tentang NodeClasses, lihat[Buat Kelas Node untuk Amazon EKS](create-node-class.md).
## Prosedur
### Prasyarat
+ Versi terbaru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda. Untuk memeriksa versi Anda saat ini, gunakan`aws --version`. Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) dan [Konfigurasi cepat](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) dengan aws configure di Panduan Pengguna Antarmuka Baris AWS Perintah.
+ Masuk ke CLI dengan izin IAM yang cukup untuk membuat AWS sumber daya termasuk Kebijakan IAM, Peran IAM, dan Kluster EKS.
### Aktifkan dengan AWS CLI
Gunakan perintah berikut untuk mengaktifkan keduanya bawaan NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
Anda dapat memodifikasi perintah untuk mengaktifkan secara selektif. NodePools
### Nonaktifkan dengan AWS CLI
Gunakan perintah berikut untuk menonaktifkan keduanya bawaan NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# Kontrol jika beban kerja diterapkan pada node Mode Otomatis EKS
Saat menjalankan beban kerja di klaster EKS dengan Mode Otomatis EKS, Anda mungkin perlu mengontrol apakah beban kerja tertentu berjalan pada node Mode Otomatis EKS atau jenis komputasi lainnya. Topik ini menjelaskan cara menggunakan pemilih node dan aturan afinitas untuk memastikan beban kerja Anda dijadwalkan pada infrastruktur komputasi yang dimaksud.
Contoh dalam topik ini menunjukkan cara menggunakan `eks.amazonaws.com/compute-type` label untuk meminta atau mencegah penyebaran beban kerja pada node Mode Otomatis EKS. Ini sangat berguna dalam cluster mode campuran tempat Anda menjalankan Mode Otomatis EKS dan jenis komputasi lainnya, seperti penyedia Karpenter yang dikelola sendiri atau Grup Node Terkelola EKS.
Node Mode Otomatis EKS telah menetapkan nilai label `eks.amazonaws.com/compute-type` ke`auto`. Anda dapat menggunakan label ini untuk mengontrol jika beban kerja diterapkan ke node yang dikelola oleh Mode Otomatis EKS.
## Memerlukan beban kerja diterapkan ke node Mode Otomatis EKS
**catatan**
`nodeSelector`Nilai ini tidak diperlukan untuk Mode Otomatis EKS. `nodeSelector`Nilai ini hanya relevan jika Anda menjalankan cluster dalam mode campuran, tipe node tidak dikelola oleh Mode Otomatis EKS. Misalnya, Anda mungkin memiliki kapasitas komputasi statis yang diterapkan ke klaster Anda dengan Grup Node Terkelola EKS, dan memiliki kapasitas komputasi dinamis yang dikelola oleh Mode Otomatis EKS.
Anda dapat menambahkan ini `nodeSelector` ke Deployment atau beban kerja lainnya agar Kubernetes menjadwalkannya ke node Mode Otomatis EKS.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## Memerlukan beban kerja tidak diterapkan ke node Mode Otomatis EKS
Anda dapat menambahkan ini `nodeAffinity` ke Deployment atau beban kerja lainnya agar Kubernetes **tidak** menjadwalkannya ke node Mode Otomatis EKS.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# Jalankan add-on penting pada instance khusus
Dalam topik ini, Anda akan belajar bagaimana menerapkan beban kerja dengan `CriticalAddonsOnly` toleransi sehingga Mode Otomatis EKS akan menjadwalkannya ke kumpulan node. `system`
Kumpulan `system` node bawaan EKS Auto Mode dirancang untuk menjalankan add-on penting pada instance khusus. Pemisahan ini memastikan komponen penting memiliki sumber daya khusus dan terisolasi dari beban kerja umum, meningkatkan stabilitas dan kinerja klaster secara keseluruhan.
Panduan ini menunjukkan cara menerapkan add-on ke kumpulan `system` node dengan memanfaatkan `CriticalAddonsOnly` toleransi dan pemilih node yang sesuai. Dengan mengikuti langkah-langkah ini, Anda dapat memastikan bahwa aplikasi penting Anda dijadwalkan ke `system` node khusus, memanfaatkan manfaat isolasi dan alokasi sumber daya yang disediakan oleh struktur kumpulan node khusus EKS Auto Mode.
Mode Otomatis EKS memiliki dua kumpulan node bawaan: `general-purpose` dan`system`. Untuk informasi selengkapnya, lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
Tujuan dari kumpulan `system` node adalah untuk memisahkan add-on kritis ke node yang berbeda. Node yang disediakan oleh kumpulan `system` node memiliki taint `CriticalAddonsOnly` Kubernetes. Kubernetes hanya akan menjadwalkan pod ke node ini jika mereka memiliki toleransi yang sesuai. Untuk informasi selengkapnya, lihat [Taints and Tolerations dalam dokumentasi](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) Kubernetes.
## Prasyarat
+ EKS Auto Mode Cluster dengan kumpulan `system` node bawaan diaktifkan. Untuk informasi selengkapnya, silakan lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md)
+ `kubectl`diinstal dan dikonfigurasi. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
## Prosedur
Tinjau contoh yaml di bawah ini. Perhatikan konfigurasi berikut:
+ `nodeSelector`— Ini mengaitkan beban kerja dengan kumpulan `system` node bawaan. Kumpulan node ini harus diaktifkan dengan AWS API. Untuk informasi selengkapnya, lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
+ `tolerations`— Toleransi ini mengatasi `CriticalAddonsOnly` noda pada node di kumpulan node. `system`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
Untuk memperbarui beban kerja agar berjalan di kumpulan `system` node, Anda perlu:
1. Perbarui beban kerja yang ada untuk menambahkan konfigurasi berikut yang dijelaskan di atas:
+ `nodeSelector`
+ `tolerations`
1. Terapkan beban kerja yang diperbarui ke cluster Anda dengan `kubectl apply`
Setelah memperbarui beban kerja, itu akan berjalan pada node khusus.
# Gunakan Kebijakan Jaringan dengan Mode Otomatis EKS
## Ikhtisar
Ketika pelanggan menskalakan lingkungan aplikasi mereka menggunakan EKS, isolasi lalu lintas jaringan menjadi semakin mendasar untuk mencegah akses tidak sah ke sumber daya di dalam dan di luar cluster. Ini sangat penting dalam lingkungan multi-penyewa dengan beberapa beban kerja yang tidak terkait berjalan berdampingan di cluster. Kebijakan jaringan Kubernetes memungkinkan Anda untuk meningkatkan postur keamanan jaringan untuk beban kerja Kubernetes Anda, dan integrasinya dengan endpoint cluster-eksternal. Mode Otomatis EKS mendukung berbagai jenis kebijakan jaringan.
### Isolasi lapisan 3 dan 4
Kebijakan jaringan Kubernetes standar beroperasi pada lapisan 3 dan 4 dari model jaringan OSI dan memungkinkan Anda untuk mengontrol arus lalu lintas di alamat IP atau tingkat port dalam cluster Amazon EKS Anda.
#### Kasus penggunaan
+ Segmentasikan lalu lintas jaringan antar beban kerja untuk memastikan bahwa hanya aplikasi terkait yang dapat berbicara satu sama lain.
+ Mengisolasi penyewa di tingkat namespace menggunakan kebijakan untuk menegakkan pemisahan jaringan.
### Penegakan berbasis DNS
Pelanggan biasanya menyebarkan beban kerja di EKS yang merupakan bagian dari lingkungan terdistribusi yang lebih luas, beberapa di antaranya harus berkomunikasi dengan sistem dan layanan di luar cluster (lalu lintas utara). Sistem dan layanan ini dapat berada di AWS cloud atau di luar AWS sama sekali. Kebijakan berbasis Domain Name System (DNS) memungkinkan Anda untuk memperkuat postur keamanan Anda dengan mengadopsi pendekatan yang lebih stabil dan dapat diprediksi untuk mencegah akses tidak sah dari Pod ke sumber daya eksternal cluster atau endpoint. Mekanisme ini menghilangkan kebutuhan untuk melacak dan mengizinkan daftar alamat IP tertentu secara manual. Dengan mengamankan sumber daya dengan pendekatan berbasis DNS, Anda juga memiliki lebih banyak fleksibilitas untuk memperbarui infrastruktur eksternal tanpa harus melonggarkan postur keamanan Anda atau memodifikasi kebijakan jaringan di tengah perubahan pada server dan host hulu. Anda dapat memfilter lalu lintas keluar ke titik akhir eksternal menggunakan Nama Domain Berkualitas Penuh (FQDN), atau pola yang cocok untuk nama domain DNS. Ini memberi Anda fleksibilitas tambahan untuk memperluas akses ke beberapa subdomain yang terkait dengan titik akhir cluster-eksternal tertentu.
#### Kasus penggunaan
+ Standarisasi pada pendekatan berbasis DNS untuk memfilter akses dari lingkungan Kubernetes ke endpoint cluster-eksternal.
+ Akses aman ke AWS layanan di lingkungan multi-penyewa.
+ Kelola akses jaringan dari pod ke beban kerja on-prem di lingkungan cloud Hybrid Anda.
### Aturan admin (atau cakupan cluster)
Dalam beberapa kasus, seperti skenario multi-tenant, pelanggan mungkin memiliki persyaratan untuk menegakkan standar keamanan jaringan yang berlaku untuk seluruh cluster. Alih-alih mendefinisikan dan mempertahankan kebijakan yang berbeda secara berulang untuk setiap namespace, Anda dapat menggunakan satu kebijakan untuk mengelola kontrol akses jaringan secara terpusat untuk beban kerja yang berbeda di klaster, terlepas dari namespace mereka. Jenis kebijakan ini memungkinkan Anda memperluas cakupan penegakan aturan pemfilteran jaringan yang diterapkan pada lapisan 3, lapisan 4, dan saat menggunakan aturan DNS.
#### Kasus penggunaan
+ Kelola kontrol akses jaringan secara terpusat untuk semua (atau sebagian dari) beban kerja di kluster EKS Anda.
+ Tentukan postur keamanan jaringan default di seluruh cluster.
+ Memperluas standar keamanan organisasi ke ruang lingkup cluster dengan cara yang lebih efisien secara operasional.
## Memulai
### Prasyarat
+ Cluster Amazon EKS dengan Mode Otomatis EKS diaktifkan
+ kubectl dikonfigurasi untuk terhubung ke klaster Anda
### Langkah 1: Aktifkan Pengontrol Kebijakan Jaringan
Untuk menggunakan kebijakan jaringan dengan Mode Otomatis EKS, pertama-tama Anda harus mengaktifkan Network Policy Controller dengan menerapkan a ConfigMap ke cluster Anda.
1. Buat file bernama `enable-network-policy.yaml` dengan konten berikut:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Terapkan ConfigMap ke cluster Anda:
```
kubectl apply -f enable-network-policy.yaml
```
### Langkah 2: Buat dan uji kebijakan jaringan
Kluster Mode Otomatis EKS Anda sekarang dikonfigurasi untuk mendukung kebijakan jaringan Kubernetes. Anda dapat menguji ini dengan[Bintang demo kebijakan jaringan untuk Amazon EKS](network-policy-stars-demo.md).
### Langkah 3: Sesuaikan konfigurasi Agen Kebijakan Jaringan di Kelas Node (Opsional)
Anda dapat membuat Kelas Node baru secara opsional untuk mengubah perilaku default Agen Kebijakan Jaringan pada node atau mengaktifkan pencatatan peristiwa Kebijakan Jaringan. Untuk melakukannya, ikuti langkah-langkah berikut:
1. Membuat atau mengedit file YAMM Kelas Node (misalnya,`nodeclass-network-policy.yaml`) dengan konten berikut:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. Terapkan konfigurasi Node Class ke cluster Anda:
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. Verifikasi bahwa Kelas Node telah dibuat:
```
kubectl get nodeclass network-policy-config
```
1. Perbarui Node Pool Anda untuk menggunakan Kelas Node ini. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
## Bagaimana cara kerjanya?
### Kebijakan jaringan berbasis DNS
![\[Ilustrasi alur kerja saat kebijakan berbasis DNS diterapkan di EKS Auto\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[llustrasi alur kerja saat kebijakan berbasis DNS diterapkan di EKS Auto\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/apply-dns-policy-2.png)
1. Tim platform menerapkan kebijakan berbasis DNS ke cluster EKS.
1. Network Policy Controller bertanggung jawab untuk memantau pembuatan kebijakan dalam klaster dan kemudian merekonsiliasi titik akhir kebijakan. Dalam kasus penggunaan ini, pengontrol kebijakan jaringan menginstruksikan agen node untuk memfilter permintaan DNS berdasarkan domain yang terdaftar izinkan dalam kebijakan yang dibuat. Nama domain diijinkan menggunakan FQDN atau nama domain yang cocok dengan pola yang ditentukan dalam konfigurasi sumber daya Kubernetes.
1. Workload Sebuah upaya untuk menyelesaikan IP untuk titik akhir cluster-eksternal. Permintaan DNS pertama kali melalui proxy yang memfilter permintaan tersebut berdasarkan daftar izinkan yang diterapkan melalui kebijakan jaringan.
1. Setelah permintaan DNS melewati daftar izinkan filter DNS, itu diproksi ke CoreDNS,
1. CoreDNS pada gilirannya mengirimkan permintaan ke Resolver DNS Eksternal (Amazon Route 53 Resolver) untuk mendapatkan daftar alamat IP di belakang nama domain.
1. Yang diselesaikan IPs dengan TTL dikembalikan sebagai respons terhadap permintaan DNS. Ini kemudian IPs ditulis dalam peta eBPF yang digunakan pada langkah berikutnya untuk penegakan lapisan IP.
1. Probe eBPF yang terpasang pada antarmuka Pod veth kemudian akan memfilter lalu lintas keluar dari Workload A ke endpoint cluster-eksternal berdasarkan aturan yang berlaku. Ini memastikan pod hanya dapat mengirim lalu lintas cluster-eksternal ke domain yang diizinkan IPs yang terdaftar. Validitas ini IPs didasarkan pada TTL yang diambil dari Resolver DNS Eksternal (Amazon Route 53 Resolver).
#### Menggunakan Kebijakan Jaringan Aplikasi
`ApplicationNetworkPolicy`Ini menggabungkan kemampuan kebijakan jaringan Kubernetes standar dengan pemfilteran berbasis DNS pada tingkat namespace menggunakan Custom Resource Definition (CRD) tunggal. Oleh karena itu, `ApplicationNetworkPolicy` dapat digunakan untuk:
1. Mendefinisikan pembatasan pada lapisan 3 dan 4 dari tumpukan jaringan menggunakan blok IP dan nomor port.
1. Mendefinisikan aturan yang beroperasi pada lapisan 7 dari tumpukan jaringan dan memungkinkan Anda memfilter lalu lintas berdasarkan FQDNs.
**penting**
Aturan berbasis DNS yang ditentukan menggunakan hanya berlaku untuk beban kerja `ApplicationNetworkPolicy` yang berjalan di instans EC2 yang diluncurkan Mode Otomatis EKS. `ApplicationNetworkPolicy`mendukung semua bidang Kubernetes standar`NetworkPolicy`, dengan filter FQDN tambahan untuk aturan jalan keluar.
**Awas**
Jangan gunakan nama yang sama untuk `ApplicationNetworkPolicy` dan a `NetworkPolicy` dalam namespace yang sama. Jika nama bertabrakan, `PolicyEndpoints` objek yang dihasilkan mungkin tidak mencerminkan salah satu kebijakan dengan benar. Kedua sumber daya diterima tanpa kesalahan, membuat masalah ini sulit didiagnosis.
Untuk mengatasi konflik penamaan, ganti nama `ApplicationNetworkPolicy` atau `NetworkPolicy` jadi mereka unik dalam namespace, lalu verifikasi bahwa `PolicyEndpoints` objek yang sesuai diperbarui dengan benar.
#### Contoh
Anda memiliki beban kerja di kluster Mode Otomatis EKS Anda yang perlu berkomunikasi dengan aplikasi on-prem yang berada di belakang penyeimbang beban dengan nama DNS. Anda dapat mencapai ini menggunakan kebijakan jaringan berikut:
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
**Pada tingkat jaringan Kubernetes, ini akan memungkinkan jalan keluar dari setiap pod di namespace “galaksi” yang diberi label `role: backend` untuk terhubung ke nama domain myapp.mydomain.com pada port TCP 8080.** Selain itu, Anda perlu mengatur konektivitas jaringan untuk lalu lintas keluar dari VPC Anda ke pusat data perusahaan Anda.
![\[llustrasi beban kerja di EKS Auto berkomunikasi dengan aplikasi di prem\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### Kebijakan jaringan admin (atau cluster)
![\[llustrasi urutan evaluasi untuk kebijakan jaringan di EKS\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/evaluation-order.png)
#### Menggunakan Kebijakan Jaringan Cluster
Saat menggunakan`ClusterNetworkPolicy`, kebijakan tingkat Admin dievaluasi terlebih dahulu dan tidak dapat diganti. Ketika kebijakan tingkat Admin telah dievaluasi, kebijakan cakupan namespace standar digunakan untuk menjalankan aturan segmentasi jaringan yang diterapkan. Hal ini dapat dicapai dengan menggunakan salah satu `ApplicationNetworkPolicy` atau`NetworkPolicy`. Terakhir, aturan tingkat dasar yang menentukan batasan jaringan default untuk beban kerja klaster akan diberlakukan. Aturan tingkat dasar ini **dapat** diganti dengan kebijakan cakupan namespace jika diperlukan.
#### Contoh
Anda memiliki aplikasi di cluster Anda yang ingin Anda isolasi dari beban kerja penyewa lainnya. Anda dapat secara eksplisit memblokir lalu lintas klaster dari ruang nama lain untuk mencegah akses jaringan ke namespace beban kerja yang sensitif.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Pertimbangan-pertimbangan
### Memahami urutan evaluasi kebijakan
Kemampuan kebijakan jaringan yang didukung di EKS dievaluasi dalam urutan tertentu untuk memastikan manajemen lalu lintas yang dapat diprediksi dan aman. Oleh karena itu, penting untuk memahami alur evaluasi untuk merancang postur keamanan jaringan yang efektif untuk lingkungan Anda.
1. **Kebijakan tingkat admin (dievaluasi terlebih dahulu)**: Semua tingkat Admin ClusterNetworkPolicies dievaluasi sebelum kebijakan lainnya. Dalam tingkat Admin, kebijakan diproses dalam urutan prioritas (nomor prioritas terendah terlebih dahulu). Jenis tindakan menentukan apa yang terjadi selanjutnya.
+ **Tindakan tolak (prioritas tertinggi)**: Ketika kebijakan Admin dengan tindakan Tolak cocok dengan lalu lintas, lalu lintas tersebut segera diblokir terlepas dari kebijakan lainnya. Tidak ada lebih lanjut ClusterNetworkPolicy atau NetworkPolicy aturan yang diproses. Ini memastikan bahwa kontrol keamanan di seluruh organisasi tidak dapat diganti oleh kebijakan tingkat ruang nama.
+ **Izinkan tindakan**: Setelah aturan Tolak dievaluasi, kebijakan Admin dengan tindakan Izinkan diproses dalam urutan prioritas (nomor prioritas terendah terlebih dahulu). Ketika tindakan Izinkan cocok, lalu lintas diterima dan tidak ada evaluasi kebijakan lebih lanjut yang terjadi. Kebijakan ini dapat memberikan akses di beberapa ruang nama berdasarkan pemilih label, memberikan kontrol terpusat atas beban kerja mana yang dapat mengakses sumber daya tertentu.
+ **Lulus tindakan**: Melewati tindakan dalam kebijakan tingkat Admin mendelegasikan pengambilan keputusan ke tingkat yang lebih rendah. Ketika lalu lintas cocok dengan aturan Pass, evaluasi melewatkan semua aturan tingkat Admin yang tersisa untuk lalu lintas tersebut dan melanjutkan langsung ke tingkat. NetworkPolicy Hal ini memungkinkan administrator untuk secara eksplisit mendelegasikan kontrol untuk pola lalu lintas tertentu ke tim aplikasi. Misalnya, Anda dapat menggunakan aturan Pass untuk mendelegasikan manajemen lalu lintas intra-namespace ke administrator namespace sambil mempertahankan kontrol ketat atas akses eksternal.
1. **Tingkat kebijakan jaringan**: Jika tidak ada kebijakan tingkat Admin yang cocok dengan Tolak atau Izinkan, atau jika tindakan Pass dicocokkan, sumber daya cakupan nama dan sumber daya tradisional akan dievaluasi berikutnya ApplicationNetworkPolicy . NetworkPolicy Kebijakan ini memberikan kontrol halus dalam ruang nama individu dan dikelola oleh tim aplikasi. Kebijakan dengan cakupan ruang nama hanya bisa lebih ketat daripada kebijakan Admin. Mereka tidak dapat mengesampingkan keputusan Tolak kebijakan Admin, tetapi mereka dapat membatasi lalu lintas yang diizinkan atau disahkan oleh kebijakan Admin.
1. **Kebijakan Admin tingkat dasar: Jika tidak ada kebijakan** dengan cakupan Admin atau ruang nama yang cocok dengan lalu lintas, tingkat dasar akan dievaluasi. ClusterNetworkPolicies Ini memberikan postur keamanan default yang dapat diganti dengan kebijakan cakupan ruang nama, memungkinkan administrator untuk menetapkan default di seluruh organisasi sambil memberi tim fleksibilitas untuk menyesuaikan sesuai kebutuhan. Kebijakan dasar dievaluasi dalam urutan prioritas (nomor prioritas terendah terlebih dahulu).
1. **Penyangkalan default (jika tidak ada kebijakan yang cocok)**: deny-by-default Perilaku ini memastikan bahwa hanya koneksi yang diizinkan secara eksplisit yang diizinkan, mempertahankan postur keamanan yang kuat.
### Menerapkan prinsip hak istimewa paling sedikit
+ **Mulailah dengan kebijakan restriktif dan tambahkan izin secara bertahap sesuai kebutuhan** - Mulailah dengan menerapkan deny-by-default kebijakan di tingkat klaster, lalu tambahkan aturan izin secara bertahap saat Anda memvalidasi persyaratan konektivitas yang sah. Pendekatan ini memaksa tim untuk secara eksplisit membenarkan setiap koneksi eksternal, menciptakan lingkungan yang lebih aman dan dapat diaudit.
+ **Secara teratur mengaudit dan menghapus aturan kebijakan yang tidak digunakan** - Kebijakan jaringan dapat terakumulasi dari waktu ke waktu seiring berkembangnya aplikasi, meninggalkan aturan usang yang tidak perlu memperluas permukaan serangan Anda. Terapkan proses peninjauan rutin untuk mengidentifikasi dan menghapus aturan kebijakan yang tidak lagi diperlukan, memastikan postur keamanan Anda tetap ketat dan dapat dipelihara.
+ **Gunakan nama domain tertentu daripada pola luas bila memungkinkan** - Meskipun pola wildcard seperti `*.amazonaws.com` memberikan kenyamanan, mereka juga memberikan akses ke berbagai layanan. Bila memungkinkan, tentukan nama domain yang tepat seperti `s3.us-west-2.amazonaws.com` membatasi akses hanya ke layanan spesifik yang dibutuhkan aplikasi Anda, mengurangi risiko pergerakan lateral jika beban kerja terganggu.
### Menggunakan kebijakan berbasis DNS di EKS
+ Aturan berbasis DNS yang ditentukan menggunakan hanya berlaku untuk beban kerja `ApplicationNetworkPolicy` yang berjalan di instans EC2 yang diluncurkan Mode Otomatis EKS. Jika Anda menjalankan cluster mode campuran (terdiri dari node pekerja EKS Auto dan non EKS Auto), aturan berbasis DNS Anda hanya efektif di node pekerja mode EKS Auto (instans terkelola EC2).
### Memvalidasi kebijakan DNS Anda
+ **Gunakan klaster pementasan yang mencerminkan topologi jaringan produksi untuk pengujian** - Lingkungan pementasan Anda harus mereplikasi arsitektur jaringan, dependensi eksternal, dan pola konektivitas produksi untuk memastikan pengujian kebijakan yang akurat. Ini termasuk pencocokan konfigurasi VPC, perilaku resolusi DNS, dan akses ke layanan eksternal yang sama yang dibutuhkan oleh beban kerja produksi Anda.
+ **Terapkan pengujian otomatis untuk jalur jaringan kritis** - Buat pengujian otomatis yang memvalidasi konektivitas ke layanan eksternal penting sebagai bagian dari CI/CD pipeline Anda. Tes ini harus memverifikasi bahwa arus lalu lintas yang sah diizinkan sementara koneksi yang tidak sah diblokir, memberikan validasi berkelanjutan bahwa kebijakan jaringan Anda mempertahankan postur keamanan yang benar saat infrastruktur Anda berkembang.
+ **Pantau perilaku aplikasi setelah perubahan kebijakan** - Setelah menerapkan kebijakan jaringan baru atau yang dimodifikasi ke produksi, pantau log aplikasi, tingkat kesalahan, dan metrik kinerja dengan cermat untuk mengidentifikasi masalah konektivitas apa pun dengan cepat. Tetapkan prosedur rollback yang jelas sehingga Anda dapat dengan cepat mengembalikan perubahan kebijakan jika menyebabkan perilaku aplikasi atau gangguan layanan yang tidak terduga.
### Interaksi dengan Amazon Route 53 DNS firewall
Kebijakan Admin dan Jaringan EKS dievaluasi terlebih dahulu pada tingkat pod saat lalu lintas dimulai. Jika kebijakan jaringan EKS mengizinkan jalan keluar ke domain tertentu, pod akan melakukan query DNS yang mencapai Route 53 Resolver. Pada titik ini, aturan Route 53 DNS Firewall dievaluasi. Jika DNS Firewall memblokir kueri domain, resolusi DNS gagal dan koneksi tidak dapat dibuat, meskipun kebijakan jaringan EKS mengizinkannya. Ini menciptakan lapisan keamanan yang saling melengkapi: Kebijakan jaringan berbasis DNS EKS memberikan kontrol jalan keluar tingkat pop untuk persyaratan akses khusus aplikasi dan batas keamanan multi-penyewa, sementara DNS Firewall memberikan perlindungan luas VPC terhadap domain berbahaya yang diketahui dan memberlakukan blokir di seluruh organisasi.
# Tag subnet untuk Mode Otomatis EKS
Jika Anda menggunakan kemampuan load balancing dari Mode Otomatis EKS, Anda perlu menambahkan AWS tag ke subnet VPC Anda.
## Latar Belakang
Tag ini mengidentifikasi subnet yang terkait dengan cluster, dan yang lebih penting jika subnet bersifat publik atau pribadi.
Subnet publik memiliki akses internet langsung melalui gateway internet. Mereka digunakan untuk sumber daya yang perlu diakses publik seperti penyeimbang beban.
Subnet pribadi tidak memiliki akses internet langsung dan menggunakan gateway NAT untuk lalu lintas keluar. Mereka digunakan untuk sumber daya internal seperti node EKS yang tidak membutuhkan publik IPs.
Untuk mempelajari selengkapnya tentang gateway NAT dan gateway Internet, lihat [Menyambungkan VPC ke jaringan lain](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) di Panduan Pengguna Amazon Virtual Private Cloud (VPC).
## Persyaratan
Pada saat ini, subnet yang digunakan untuk penyeimbangan beban oleh Mode Otomatis EKS diharuskan memiliki salah satu tag berikut.
### Subnet publik
Subnet publik digunakan untuk penyeimbang beban yang menghadap ke internet. Subnet ini harus memiliki tag berikut:
| Key | Nilai |
| --- | --- |
| `kubernetes.io/role/elb` | `1`atau `` |
### Subnet privat
Subnet pribadi digunakan untuk penyeimbang beban internal. Subnet ini harus memiliki tag berikut:
| Key | Nilai |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1`atau `` |
## Prosedur
Sebelum Anda mulai, identifikasi subnet mana yang bersifat publik (dengan akses Internet Gateway) dan mana yang pribadi (menggunakan NAT Gateway). Anda memerlukan izin untuk memodifikasi sumber daya VPC.
### Konsol Manajemen AWS
1. **Buka konsol Amazon VPC dan navigasikan ke Subnet.**
1. Pilih subnet yang akan diberi tag.
1. Pilih tab **Tag** dan pilih **Tambahkan tag**.
1. Tambahkan tag yang sesuai:
+ Untuk subnet publik: Key= `kubernetes.io/role/elb`
+ Untuk subnet pribadi: Key= `kubernetes.io/role/internal-elb`
1. Tetapkan **Nilai** ke `1` atau biarkan kosong.
1. Simpan dan ulangi untuk subnet yang tersisa.
### AWS CLI
Untuk subnet publik:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
Untuk subnet pribadi:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
Ganti `subnet-ID` dengan subnet ID Anda yang sebenarnya.
# Buat laporan kepatuhan CIS dari node Kubernetes menggunakan debug kubectl
Topik ini menjelaskan cara membuat laporan kepatuhan CIS (Center for Internet Security) untuk node Amazon EKS menggunakan `kubectl debug` perintah. Perintah ini memungkinkan Anda untuk membuat kontainer debugging sementara pada node Kubernetes dan menjalankan pemeriksaan kepatuhan CIS menggunakan alat ini. `apiclient` `apiclient`Alat ini adalah bagian dari Bottlerocket OS, OS yang digunakan oleh node Mode Otomatis EKS.
## Prasyarat
Sebelum Anda mulai, pastikan Anda memiliki:
+ Akses ke kluster Amazon EKS dengan `kubectl` konfigurasi (versi minimal harus v1.32.0; ketik `kubectl version` untuk memeriksa).
+ Izin IAM yang sesuai untuk men-debug node.
+ Profil valid yang memungkinkan operasi debug (misalnya,`sysadmin`).
Untuk informasi selengkapnya tentang menggunakan profil debugging`kubectl`, lihat [Debugging Pod atau Node saat menerapkan profil dalam dokumentasi](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles) Kubernetes.
## Prosedur
1. Tentukan ID AWS Instance dari node yang ingin Anda jalankan laporannya. Gunakan perintah berikut untuk daftar node dalam cluster. ID instance ditemukan di kolom nama, dan dimulai dengan`i-`:
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. Jalankan perintah berikut, ganti `` dengan ID instance dari node yang ingin Anda kueri:
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
Komponen perintah ini meliputi:
+ `kubectl debug node/`— Membuat sesi debugging pada ID instans EC2 yang ditentukan.
+ `-it`— Mengalokasikan TTY (shell baris perintah) dan membuat stdin tetap terbuka untuk penggunaan interaktif.
+ `--profile=sysadmin`— Menggunakan `kubectl` profil yang ditentukan dengan izin yang sesuai.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023`- Digunakan `amazonlinux:2023` sebagai gambar kontainer untuk debugging.
+ `bash -c "…"`— Mengeksekusi perintah berikut dalam bash shell:
+ `yum install -q -y util-linux-core`— Diam-diam menginstal paket utilitas yang diperlukan.
+ `nsenter -t 1 -m`— Berjalan `nsenter` untuk memasuki namespace dari proses host (PID 1).
+ `apiclient report cis --level 1 --format text`— Menjalankan laporan kepatuhan CIS di level 1 dengan output teks.
1. Tinjau keluaran teks laporan.
## Menafsirkan output
Perintah menghasilkan laporan berbasis teks yang menunjukkan status kepatuhan berbagai kontrol CIS. Outputnya meliputi:
+ Kontrol CIS individu IDs
+ Deskripsi setiap kontrol
+ Status Lulus, Gagal, atau Lewati untuk setiap pemeriksaan
+ Detail yang menjelaskan masalah kepatuhan apa pun
Berikut adalah contoh output dari laporan yang dijalankan pada instance Bottlerocket:
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
Untuk informasi tentang benchmark, lihat [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) dari Center for Internet Security (CIS).
## Sumber daya terkait
+ [Tolok Ukur CIS Bottlerocket](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/) dalam Dokumentasi OS Bottlerocket.
+ [Debug Running Pod dalam Dokumentasi](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/) Kubernetes.
+ [Benchmark Kubernetes](https://www.cisecurity.org/benchmark/kubernetes/) dari Pusat Keamanan Internet (CIS)
# Aktifkan Enkripsi Volume EBS dengan Kunci KMS yang Dikelola Pelanggan untuk Mode Otomatis EKS
Anda dapat mengenkripsi volume root sementara untuk instans Mode Otomatis EKS dengan kunci KMS yang dikelola pelanggan.
Amazon EKS Auto Mode menggunakan peran terkait layanan untuk mendelegasikan izin ke AWS layanan lain saat mengelola volume EBS terenkripsi untuk klaster Kubernetes Anda. Topik ini menjelaskan cara menyiapkan kebijakan kunci yang Anda perlukan saat menentukan kunci terkelola pelanggan untuk enkripsi Amazon EBS dengan Mode Otomatis EKS.
Pertimbangan:
+ Mode Otomatis EKS tidak memerlukan otorisasi tambahan untuk menggunakan kunci AWS terkelola default untuk melindungi volume terenkripsi di akun Anda.
+ Topik ini mencakup mengenkripsi volume fana, volume root untuk instance. EC2 Untuk informasi selengkapnya tentang mengenkripsi volume data yang digunakan untuk beban kerja, lihat. [Buat kelas penyimpanan](create-storage-class.md)
## Gambaran umum
Kunci AWS KMS berikut dapat digunakan untuk enkripsi volume root Amazon EBS saat Mode Otomatis EKS meluncurkan instance:
+ ** AWS kunci terkelola** — Kunci enkripsi di akun Anda yang dibuat, dimiliki, dan dikelola Amazon EBS. Ini adalah kunci enkripsi default untuk akun baru.
+ **Kunci terkelola pelanggan** — Kunci enkripsi khusus yang Anda buat, miliki, dan kelola.
**catatan**
Kuncinya harus simetris. Amazon EBS tidak mendukung kunci yang dikelola pelanggan asimetris.
## Langkah 1: Konfigurasikan kebijakan kunci
Kunci KMS Anda harus memiliki kebijakan kunci yang memungkinkan Mode Otomatis EKS meluncurkan instans dengan volume Amazon EBS yang dienkripsi dengan kunci yang dikelola pelanggan.
Konfigurasikan kebijakan kunci Anda dengan struktur berikut:
**catatan**
Kebijakan ini hanya mencakup izin untuk Mode Otomatis EKS. Kebijakan kunci mungkin memerlukan izin tambahan jika identitas lain perlu menggunakan kunci atau mengelola hibah.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
Pastikan untuk mengganti `` dengan ID AWS akun Anda yang sebenarnya.
Saat mengonfigurasi kebijakan kunci:
+ `ClusterServiceRole`Harus memiliki izin IAM yang diperlukan untuk menggunakan kunci KMS untuk operasi enkripsi
+ `kms:GrantIsForAWSResource`Kondisi ini memastikan bahwa hibah hanya dapat dibuat untuk layanan AWS
## Langkah 2: Konfigurasikan NodeClass dengan kunci yang dikelola pelanggan Anda
Setelah mengonfigurasi kebijakan kunci, rujuk kunci KMS dalam konfigurasi Mode NodeClass Otomatis EKS Anda:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws: kms:::key/"
```
Ganti nilai placeholder dengan nilai aktual Anda:
+ ``dengan AWS wilayah Anda
+ ``dengan ID AWS akun Anda
+ ``dengan ID kunci KMS Anda
Anda dapat menentukan kunci KMS menggunakan salah satu format berikut:
+ ID Kunci KMS: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ ARN Kunci KMS: ` arn:aws: kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ Nama Alias Kunci: `alias/eks-auto-mode-key`
+ Kunci Alias ARN: ` arn:aws: kms:us-west-2:111122223333:alias/eks-auto-mode-key`
Terapkan NodeClass konfigurasi menggunakan kubectl:
```
kubectl apply -f nodeclass.yaml
```
## Sumber Daya Terkait
+ [Buat Kelas Node untuk Amazon EKS](create-node-class.md)
+ Lihat informasi selengkapnya di Panduan Pengembang Layanan Manajemen AWS Utama
+ [Izin untuk AWS layanan dalam kebijakan utama](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [Mengubah kebijakan utama](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Hibah di AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# Perbarui kontrol organisasi untuk Mode Otomatis EKS
Beberapa kontrol organisasi dapat mencegah Mode Otomatis EKS berfungsi dengan benar. Jika demikian, Anda harus memperbarui kontrol ini agar Mode Otomatis EKS memiliki izin yang diperlukan untuk mengelola instans EC2 atas nama Anda.
Mode Otomatis EKS menggunakan peran layanan untuk meluncurkan Instans EC2 yang mendukung Node Mode Otomatis EKS. Peran layanan adalah peran [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) yang dibuat di akun Anda yang diasumsikan oleh layanan untuk melakukan tindakan atas nama Anda. [Kebijakan Kontrol Layanan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) selalu berlaku untuk tindakan yang dilakukan dengan peran layanan. Hal ini memungkinkan SCP untuk menghambat operasi Mode Otomatis. Kejadian yang paling umum adalah ketika SCP digunakan untuk membatasi Amazon Machine Images (AMIs) yang dapat diluncurkan. Untuk memungkinkan Mode Otomatis EKS berfungsi, ubah SCP untuk mengizinkan peluncuran AMIs dari akun Mode Otomatis EKS.
Anda juga dapat menggunakan AMIs fitur [EC2 Allowed](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) untuk membatasi visibilitas AMIs di akun lain. Jika Anda menggunakan fitur ini, Anda harus memperluas kriteria gambar untuk juga menyertakan akun AMI Mode Otomatis EKS di wilayah yang diminati.
## Contoh SCP untuk memblokir semua AMIs kecuali untuk Mode Otomatis EKS AMIs
SCP di bawah ini mencegah panggilan `ec2:RunInstances` kecuali AMI milik akun AMI Mode Otomatis EKS untuk us-west-2 atau us-east-1.
**catatan**
Penting untuk **tidak** menggunakan kunci `ec2:Owner` konteks. Amazon memiliki akun AMI Mode Otomatis EKS dan nilai untuk kunci ini akan `amazon` selalu ada. Membangun SCP yang memungkinkan peluncuran AMIs jika `ec2:Owner` is `amazon` akan memungkinkan peluncuran AMI milik Amazon, bukan hanya untuk Mode Otomatis EKS. \$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## Akun AMI Mode Otomatis EKS
AWS akun yang bervariasi menurut wilayah host EKS Auto Mode publik AMIs.
| | |
| --- |--- |
| AWS Wilayah | Akun |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-timur-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-tenggara 6 | 905418310314 |
| ap-tenggara 7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-pusat-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## Alamat IP Publik Asosiasi
Kapan `ec2:RunInstances` dipanggil `AssociatePublicIpAddress` bidang untuk peluncuran instance ditentukan secara otomatis oleh jenis subnet tempat instance diluncurkan. SCP dapat digunakan untuk menegakkan bahwa nilai ini secara eksplisit disetel ke false, terlepas dari jenis subnet yang diluncurkan. Dalam hal ini NodeClass bidang juga `spec.advancedNetworking.associatePublicIPAddress` dapat diatur ke false untuk memenuhi persyaratan SCP.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# Kontrol penyebaran beban kerja ke Reservasi Kapasitas dengan Mode Otomatis EKS
Anda dapat mengontrol penyebaran beban kerja ke Reservasi [Kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). Mode Otomatis EKS mendukung EC2 On-Demand Capacity Reservations (ODCR), dan Blok Kapasitas EC2 untuk ML.
**Tip**
Secara default, Mode Otomatis EKS dapat diluncurkan ke open ODCRs melalui pencocokan terbuka, tetapi tidak memprioritaskannya. Instans yang diluncurkan melalui pencocokan terbuka diberi label`karpenter.sh/capacity-type: on-demand`, bukan. `reserved` Untuk memprioritaskan penggunaan ODCR dan memiliki instance berlabel`karpenter.sh/capacity-type: reserved`, konfigurasikan dalam definisi. `capacityReservationSelectorTerms` NodeClass Blok Kapasitas untuk ML selalu membutuhkan `capacityReservationSelectorTerms` dan tidak digunakan secara otomatis.
## Reservasi Kapasitas Sesuai Permintaan EC2 () ODCRs
EC2 On-Demand Capacity Reservations (ODCR) memungkinkan Anda untuk memesan kapasitas komputasi untuk instans Amazon EC2 Anda di Availability Zone tertentu untuk durasi berapa pun. Saat menggunakan Mode Otomatis EKS, Anda mungkin ingin mengontrol apakah beban kerja Kubernetes Anda diterapkan ke instans cadangan ini untuk memaksimalkan pemanfaatan kapasitas yang telah dibeli sebelumnya atau untuk memastikan beban kerja kritis memiliki akses ke sumber daya yang terjamin.
Secara default, Mode Otomatis EKS secara otomatis diluncurkan ke terbuka ODCRs. Namun, dengan mengonfigurasi `capacityReservationSelectorTerms` pada a NodeClass, Anda dapat secara eksplisit mengontrol beban kerja yang ODCRs Anda gunakan. Node yang disediakan menggunakan konfigurasi ODCRs akan memiliki `karpenter.sh/capacity-type: reserved` dan akan diprioritaskan daripada on-demand dan spot. Setelah fitur ini diaktifkan, Mode Otomatis EKS tidak akan lagi secara otomatis menggunakan open ODCRs —mereka harus dipilih secara eksplisit oleh a NodeClass, memberi Anda kontrol yang tepat atas penggunaan reservasi kapasitas di seluruh cluster Anda.
**Awas**
Jika Anda mengonfigurasi `capacityReservationSelectorTerms` di NodeClass dalam cluster, Mode Otomatis EKS tidak akan lagi secara otomatis menggunakan open ODCRs untuk *apa pun* NodeClass di cluster.
### Contoh NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Contoh ini NodeClass menunjukkan dua pendekatan untuk memilih ODCRs. Metode pertama secara langsung mereferensikan ODCR tertentu dengan ID ()`cr-56fac701cc1951b03`. Metode kedua menggunakan pemilihan berbasis tag, menargetkan ODCRs dengan tag. `Name: "targeted-odcr"` Anda juga dapat memfilter secara opsional berdasarkan AWS akun yang memiliki reservasi, yang sangat berguna dalam skenario lintas akun atau saat bekerja dengan reservasi kapasitas bersama.
## Blok Kapasitas EC2 untuk ML
Blok Kapasitas untuk MS mencadangkan instans komputasi akselerasi berbasis GPU di masa mendatang untuk mendukung beban kerja machine learning (ML) berdurasi pendek Anda. Instans yang berjalan di dalam Blok Kapasitas secara otomatis ditempatkan berdekatan di dalam Amazon UltraClusters EC2, untuk jaringan latensi rendah, skala petabit, dan non-pemblokiran.
Untuk informasi selengkapnya tentang platform dan jenis instans yang didukung, lihat [Blok Kapasitas untuk ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) di Panduan Pengguna EC2.
Anda dapat membuat Mode Otomatis EKS NodeClass yang menggunakan Blok Kapasitas untuk ML, mirip dengan ODCR (dijelaskan sebelumnya).
Contoh definisi berikut membuat tiga sumber daya:
1. A NodeClass yang mereferensikan reservasi Blok Kapasitas Anda
1. A NodePool yang menggunakan NodeClass dan menerapkan noda
1. Spesifikasi Pod yang mentolerir taint dan meminta sumber daya GPU
### Contoh NodeClass
Ini NodeClass mereferensikan Blok Kapasitas tertentu untuk ML dengan ID reservasi. Anda dapat memperoleh ID ini dari konsol EC2.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md).
### Contoh NodePool
Ini NodePool mereferensikan `gpu` NodeClass dan menentukan konfigurasi penting:
+ Ini **hanya** menggunakan kapasitas cadangan dengan pengaturan `karpenter.sh/capacity-type: reserved`
+ Ini meminta keluarga instance GPU tertentu yang sesuai untuk beban kerja ML
+ Ini menerapkan `nvidia.com/gpu` noda untuk memastikan hanya beban kerja GPU yang dijadwalkan pada node ini
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
### Contoh Pod
Contoh pod ini menunjukkan cara mengonfigurasi beban kerja untuk dijalankan pada node Blok Kapasitas Anda:
+ Ini menggunakan **NodeSelector** untuk menargetkan jenis GPU tertentu (dalam hal ini, H200) GPUs
+ Ini termasuk **toleransi** untuk `nvidia.com/gpu` noda yang diterapkan oleh NodePool
+ Ini secara eksplisit **meminta sumber daya GPU menggunakan tipe sumber daya** `nvidia.com/gpu`
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Untuk informasi selengkapnya, lihat [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) dalam dokumentasi Kubernetes.
### Sumber Daya Terkait
+ [Blok Kapasitas untuk ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) di Panduan Pengguna Amazon EC2
+ [Temukan dan beli Blok Kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) di Panduan Pengguna Amazon EC2
+ [Mengelola sumber daya komputasi untuk AI/ML beban kerja di Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [Optimalisasi Sumber Daya GPU dan Manajemen Biaya](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) dalam Panduan Praktik Terbaik EKS
# Menerapkan node Mode Otomatis EKS ke Local Zones
Mode Otomatis EKS menyediakan manajemen cluster yang disederhanakan dengan penyediaan node otomatis. AWS Local Zones memperluas AWS infrastruktur ke lokasi geografis yang lebih dekat dengan pengguna akhir Anda, mengurangi latensi untuk aplikasi yang sensitif terhadap latensi. Panduan ini memandu Anda melalui proses penerapan node Mode Otomatis EKS ke AWS Local Zones, memungkinkan Anda menjalankan aplikasi kontainer dengan latensi yang lebih rendah untuk pengguna di area geografis tertentu.
Panduan ini juga menunjukkan cara menggunakan taint dan toleransi Kubernetes untuk memastikan bahwa hanya beban kerja tertentu yang berjalan di node Zona Lokal Anda, membantu Anda mengontrol biaya dan mengoptimalkan penggunaan sumber daya.
## Prasyarat
Sebelum Anda mulai menerapkan node Mode Otomatis EKS ke Local Zones, pastikan Anda memiliki prasyarat berikut:
+ [Kluster Mode Otomatis EKS yang ada](create-auto.md)
+ [Memilih untuk masuk ke zona lokal di akun Anda AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## Langkah 1: Buat Subnet Zona Lokal
Langkah pertama dalam menerapkan node Mode Otomatis EKS ke Zona Lokal adalah membuat subnet di Zona Lokal itu. Subnet ini menyediakan infrastruktur jaringan untuk node Anda dan memungkinkan mereka untuk berkomunikasi dengan seluruh VPC Anda. Ikuti instruksi [subnet Buat Zona Lokal](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (dalam Panduan Pengguna AWS Local Zones) untuk membuat subnet di Zona Lokal pilihan Anda.
**Tip**
Catat nama subnet zona lokal Anda.
## Langkah 2: Buat NodeClass untuk Subnet Zona Lokal
Setelah membuat subnet Zona Lokal Anda, Anda perlu menentukan NodeClass yang mereferensikan subnet ini. NodeClass Ini adalah sumber daya kustom Kubernetes yang menentukan atribut infrastruktur untuk node Anda, termasuk subnet, grup keamanan, dan konfigurasi penyimpanan mana yang akan digunakan. Dalam contoh di bawah ini, kita membuat NodeClass disebut “local-zone” yang menargetkan subnet zona lokal berdasarkan namanya. Anda juga dapat menggunakan subnet ID. Anda harus menyesuaikan konfigurasi ini untuk menargetkan subnet Zona Lokal Anda.
Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md).
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## Langkah 3: Buat NodePool dengan NodeClass dan Taint
Dengan NodeClass konfigurasi Anda, Anda sekarang perlu membuat NodePool yang menggunakan ini NodeClass. A NodePool mendefinisikan karakteristik komputasi node Anda, termasuk tipe instance. NodePool Menggunakan NodeClass sebagai referensi untuk menentukan di mana untuk meluncurkan instance.
Dalam contoh di bawah ini, kami membuat referensi NodePool yang merujuk “zona lokal” kami. NodeClass Kami juga menambahkan taint ke node untuk memastikan bahwa hanya pod dengan toleransi yang cocok yang dapat dijadwalkan pada node Local Zone ini. Ini sangat penting untuk node Zona Lokal, yang biasanya memiliki biaya lebih tinggi dan hanya boleh digunakan oleh beban kerja yang secara khusus mendapat manfaat dari pengurangan latensi.
Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
Taint dengan kunci `aws.amazon.com/local-zone` dan efek `NoSchedule` memastikan bahwa pod tanpa toleransi yang cocok tidak akan dijadwalkan pada node ini. Ini mencegah beban kerja reguler berjalan secara tidak sengaja di Zona Lokal, yang dapat menyebabkan biaya yang tidak terduga.
## Langkah 4: Terapkan Beban Kerja dengan Tolerasi dan Afinitas Node
Untuk kontrol optimal atas penempatan beban kerja pada node Local Zone, gunakan keduanya taints/tolerations dan afinitas node bersama-sama. Pendekatan gabungan ini memberikan manfaat sebagai berikut:
1. **Pengendalian Biaya**: Taint memastikan bahwa hanya pod dengan toleransi eksplisit yang dapat menggunakan sumber daya Zona Lokal yang berpotensi mahal.
1. **Penempatan Terjamin**: Afinitas node memastikan bahwa aplikasi sensitif latensi Anda berjalan secara eksklusif di Zona Lokal, bukan pada node cluster biasa.
Berikut adalah contoh Deployment yang dikonfigurasi untuk dijalankan secara khusus pada node Local Zone:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
Deployment ini memiliki dua konfigurasi penjadwalan utama:
1. **Toleransi** memungkinkan pod dijadwalkan pada node dengan `aws.amazon.com/local-zone` taint.
1. Persyaratan **afinitas node** memastikan pod ini hanya akan berjalan pada node dengan label`node-type: local-zone`.
Bersama-sama, ini memastikan bahwa aplikasi sensitif latensi Anda hanya berjalan pada node Zona Lokal, dan aplikasi reguler tidak menggunakan sumber daya Zona Lokal kecuali secara eksplisit dikonfigurasi untuk melakukannya.
## Langkah 5: Verifikasi dengan AWS Konsol
Setelah menyiapkan NodeClass, NodePool, dan Deployment, Anda harus memverifikasi bahwa node sedang disediakan di Zona Lokal Anda seperti yang diharapkan dan bahwa beban kerja Anda berjalan pada mereka. Anda dapat menggunakan AWS Management Console untuk memverifikasi bahwa EC2 instance sedang diluncurkan di subnet Zona Lokal yang benar.
Selain itu, Anda dapat memeriksa daftar node Kubernetes menggunakan `kubectl get nodes -o wide` untuk mengonfirmasi bahwa node bergabung dengan cluster Anda dengan label dan taint yang benar:
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
Anda juga dapat memverifikasi bahwa Pod beban kerja Anda dijadwalkan pada node Zona Lokal:
```
kubectl get pods -o wide
```
Pendekatan ini memastikan bahwa hanya beban kerja yang secara khusus mentolerir noda Zona Lokal yang akan dijadwalkan pada node ini, membantu Anda mengontrol biaya dan memanfaatkan sumber daya Zona Lokal Anda dengan seefisien mungkin.
# Konfigurasikan pengaturan keamanan lanjutan untuk node
Topik ini menjelaskan cara mengonfigurasi pengaturan keamanan lanjutan untuk node Mode Otomatis Amazon EKS menggunakan `advancedSecurity` spesifikasi di Kelas Node Anda.
## Prasyarat
Sebelum Anda mulai, pastikan Anda memiliki:
+ Cluster Mode Otomatis Amazon EKS. Untuk informasi selengkapnya, lihat [Buat cluster dengan Amazon EKS Auto Mode](create-auto.md).
+ `kubectl`diinstal dan dikonfigurasi. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
+ Memahami konfigurasi Kelas Node. Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md).
## Konfigurasikan pengaturan keamanan lanjutan
Untuk mengonfigurasi pengaturan keamanan lanjutan untuk node Anda, atur `advancedSecurity` bidang dalam spesifikasi Kelas Node Anda:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
Terapkan konfigurasi ini:
```
kubectl apply -f nodeclass.yaml
```
Referensi Kelas Node ini dalam konfigurasi Node Pool Anda. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
## Deskripsi bidang
+ `fips`(boolean, opsional): Ketika diatur ke`true`, ketentuan node menggunakan AMIs dengan modul kriptografi yang divalidasi FIPS 140-2. Pengaturan ini memilih FIPS-compliant AMIs; pelanggan bertanggung jawab untuk mengelola persyaratan kepatuhan mereka. Untuk informasi selengkapnya, lihat [kepatuhan AWS FIPS](https://aws.amazon.com/compliance/fips/). Default: `false`.
+ `kernelLockdown`(string, opsional): Mengontrol mode modul keamanan penguncian kernel. Nilai yang diterima:
+ `integrity`: Memblokir metode untuk menimpa memori kernel atau memodifikasi kode kernel. Mencegah pemuatan modul kernel yang tidak ditandatangani.
+ `none`: Menonaktifkan perlindungan penguncian kernel.
Untuk informasi selengkapnya, lihat [dokumentasi penguncian kernel Linux](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html).
## Pertimbangan-pertimbangan
+ Sesuai FIPS AMIs tersedia di Wilayah Timur/Barat AWS AS, ( AWS GovCloud AS), dan Kanada AWS (Tengah/Barat). Untuk informasi selengkapnya, lihat [kepatuhan AWS FIPS](https://aws.amazon.com/compliance/fips/).
+ Saat menggunakan`kernelLockdown: "integrity"`, pastikan beban kerja Anda tidak memerlukan pemuatan modul kernel yang tidak ditandatangani atau memodifikasi memori kernel.
## Sumber daya terkait
+ [Buat Kelas Node untuk Amazon EKS](create-node-class.md)- Panduan konfigurasi Kelas Node Lengkap
+ [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md)- Konfigurasi Node Pool
# Pelajari cara kerja Mode Otomatis EKS
Gunakan chapter ini untuk mempelajari cara kerja komponen cluster Amazon EKS Auto Mode.
**Topics**
+ [Pelajari tentang instans Terkelola Mode Otomatis Amazon EKS](automode-learn-instances.md)
+ [Pelajari tentang identitas dan akses dalam Mode Otomatis EKS](auto-learn-iam.md)
+ [Pelajari tentang Jaringan VPC dan Load Balancing dalam Mode Otomatis EKS](auto-networking.md)
# Pelajari tentang instans Terkelola Mode Otomatis Amazon EKS
Topik ini menjelaskan cara Amazon EKS Auto Mode mengelola EC2 instans Amazon di klaster EKS Anda. Saat Anda mengaktifkan Mode Otomatis EKS, sumber daya komputasi klaster Anda secara otomatis disediakan dan dikelola oleh EKS, mengubah cara Anda berinteraksi dengan EC2 instance yang berfungsi sebagai node di cluster Anda.
Memahami cara Amazon EKS Auto Mode mengelola instans sangat penting untuk merencanakan strategi penerapan beban kerja dan prosedur operasional Anda. Tidak seperti EC2 instans tradisional atau grup node terkelola, instance ini mengikuti model siklus hidup yang berbeda di mana EKS memikul tanggung jawab untuk banyak aspek operasional, sementara membatasi jenis akses dan penyesuaian tertentu.
Amazon EKS Auto Mode mengotomatiskan tugas rutin untuk membuat EC2 Instans baru, dan melampirkannya sebagai node ke kluster EKS Anda. Mode Otomatis EKS mendeteksi ketika beban kerja tidak dapat masuk ke node yang ada, dan membuat Instance baru EC2 .
Amazon EKS Auto Mode bertanggung jawab untuk membuat, menghapus, dan menambal Instans EC2 . Anda bertanggung jawab atas kontainer dan pod yang digunakan pada instance.
EC2 Instans yang dibuat oleh EKS Auto Mode berbeda dari EC2 Instans lain, mereka adalah instance terkelola. Instans terkelola ini dimiliki oleh EKS dan lebih dibatasi. Anda tidak dapat langsung mengakses atau menginstal perangkat lunak pada instans yang dikelola oleh Mode Otomatis EKS.
AWS menyarankan menjalankan Mode Otomatis EKS atau Karpenter yang dikelola sendiri. Anda dapat menginstal keduanya selama migrasi atau dalam konfigurasi lanjutan. Jika Anda telah menginstal keduanya, konfigurasikan kumpulan node Anda sehingga beban kerja dikaitkan dengan Karpenter atau Mode Otomatis EKS.
Untuk informasi selengkapnya, lihat [instans EC2 terkelola Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html) di panduan EC2 pengguna Amazon.
## Tabel perbandingan
| EC2 Instans Standar | Contoh terkelola Mode Otomatis EKS |
| --- | --- |
| Anda bertanggung jawab untuk menambal dan memperbarui instance. | AWS secara otomatis menambal dan memperbarui instance. |
| EKS tidak bertanggung jawab atas perangkat lunak pada instance. | EKS bertanggung jawab atas perangkat lunak tertentu pada instance, seperti`kubelet`, runtime kontainer, dan sistem operasi. |
| Anda dapat menghapus EC2 Instance menggunakan EC2 API. | EKS menentukan jumlah instans yang digunakan di akun Anda. Jika Anda menghapus beban kerja, EKS akan mengurangi jumlah instance di akun Anda. |
| Anda dapat menggunakan SSH untuk mengakses EC2 Instance. | Anda dapat menerapkan pod dan kontainer ke instance terkelola. |
| Anda menentukan sistem operasi dan gambar (AMI). | AWS menentukan sistem operasi dan gambar. |
| Anda dapat menerapkan beban kerja yang mengandalkan fungsionalitas Windows atau Ubuntu. | Anda dapat menyebarkan kontainer berbasis Linux, tetapi tanpa dependensi OS tertentu. |
| Anda menentukan jenis instance dan keluarga apa yang akan diluncurkan. | AWS menentukan jenis instance dan keluarga apa yang akan diluncurkan. Anda dapat menggunakan Node Pool untuk membatasi jenis instance EKS Auto Mode memilih dari. |
Fungsionalitas berikut berfungsi untuk instans Terkelola dan instans Standar EC2 :
+ Anda dapat melihat instance di AWS konsol.
+ Anda dapat menggunakan penyimpanan instance sebagai penyimpanan sementara untuk beban kerja.
### AMI Support
Dengan Mode Otomatis EKS, AWS tentukan image (AMI) yang digunakan untuk node komputasi Anda. AWS memantau peluncuran versi AMI Mode Otomatis EKS baru. Jika Anda mengalami masalah beban kerja yang terkait dengan versi AMI, buat kasus dukungan. Untuk informasi selengkapnya, lihat [Membuat kasus dukungan dan manajemen kasus](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) di Panduan Pengguna AWS Support.
Umumnya, EKS merilis AMI baru setiap minggu yang berisi CVE dan perbaikan keamanan.
## Referensi instans yang didukung Mode Otomatis EKS
Mode Otomatis EKS hanya membuat instance tipe yang didukung, dan memenuhi persyaratan ukuran minimum.
Mode Otomatis EKS mendukung jenis contoh berikut:
| Rangkaian | Tipe instans |
| --- | --- |
| Komputasi Dioptimalkan (C) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7g, c7gn, c7gd, c7i, c7i-fleksibel, c6a, c6g, c6i, c6gn, c6id, c6in, c6gd, c5, c5a, c5d, c5ad, c5n, c4 |
| Tujuan Umum (M) | m8i, m8i-flex, m8a, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7gd, m7i-flex, m6a, m6i, m6in, m6g, m6idn, m6id, m6gd, m5, m5a, m5ad, m5n, m5dn, m5d, m5zn, m4 |
| Memori Dioptimalkan (R) | r8i, r8i-flex, r8gn, r8gb, r8gd, r8g, r7a, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5n, r5a, r5dn, r5b, r5ad, r5d, r4 |
| Burstable (T) | t4g, t3, t3a, t2 |
| Memori Tinggi (Z/X) | z1d, x8g, x2gd |
| Penyimpanan Dioptimalkan (I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn |
| Komputasi yang Dipercepat (P/G/Inf/Trn) | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n |
| Komputasi Kinerja Tinggi (X2) | x2iezn, x2iedn, x2idn |
Selain itu, Mode Otomatis EKS hanya akan membuat EC2 instance yang memenuhi persyaratan berikut:
+ Lebih dari 1 CPU
+ Ukuran instans tidak nano, mikro atau kecil
Untuk informasi selengkapnya, lihat [konvensi penamaan jenis EC2 instans Amazon](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html).
## Layanan Metadata Instans
+ Mode Otomatis EKS diberlakukan IMDSv2 dengan batas lompatan 1 secara default, mengikuti praktik terbaik AWS keamanan.
+ Konfigurasi default ini tidak dapat diubah dalam Mode Otomatis.
+ Untuk add-on yang biasanya memerlukan akses IMDS, berikan parameter (seperti AWS wilayah) selama instalasi untuk menghindari pencarian IMDS. Untuk informasi selengkapnya, lihat [Tentukan bidang yang dapat Anda sesuaikan untuk add-on Amazon EKS](kubernetes-field-management.md).
+ Jika sebuah Pod benar-benar membutuhkan akses IMDS ketika berjalan dalam Mode Otomatis, Pod harus dikonfigurasi untuk dijalankan. `hostNetwork: true` Hal ini memungkinkan Pod untuk mengakses layanan metadata instance secara langsung.
+ Pertimbangkan implikasi keamanan saat memberikan akses Pod ke metadata instance.
*Untuk informasi selengkapnya tentang Amazon EC2 Instance Metadata Service (IMDS), lihat [Mengonfigurasi opsi Layanan Metadata Instans di Panduan Pengguna](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) Amazon. EC2 *
## Pertimbangan-pertimbangan
+ Jika penyimpanan sementara yang dikonfigurasi di dalam NodeClass lebih kecil dari penyimpanan NVMe lokal untuk instance, Mode Otomatis EKS menghilangkan kebutuhan untuk konfigurasi manual dengan secara otomatis mengambil tindakan berikut:
+ Menggunakan volume data Amazon EBS yang lebih kecil (20 GiB) untuk mengurangi biaya.
+ Memformat dan mengkonfigurasi penyimpanan NVMe lokal untuk penggunaan data sementara. Ini termasuk menyiapkan array RAID 0 jika ada beberapa NVMe drive.
+ Ketika `ephemeralStorage.size` sama atau melebihi NVMe kapasitas lokal, tindakan berikut terjadi:
+ Mode Otomatis melewatkan volume EBS kecil.
+ NVMe Drive diekspos langsung untuk beban kerja Anda.
+ Amazon EKS Auto Mode tidak mendukung tindakan Layanan Injeksi AWS Kesalahan berikut:
+ `ec2:RebootInstances`
+ `ec2:SendSpotInstanceInterruptions`
+ `ec2:StartInstances`
+ `ec2:StopInstances`
+ `ec2:TerminateInstances`
+ `ec2:PauseVolumeIO`
+ Amazon EKS Auto Mode mendukung tindakan AWS Fault Injection Service EKS Pod. Untuk informasi selengkapnya, lihat [Mengelola eksperimen Layanan Injeksi Kesalahan](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) dan [Menggunakan tindakan AWS FIS aws:eks:pod](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account) di Panduan Pengguna Resilience Hub. AWS
+ Anda tidak perlu menginstal node Mode Otomatis EKS. `Neuron Device Plugin`
Jika Anda memiliki jenis node lain di cluster Anda, Anda perlu mengonfigurasi plugin Perangkat Neuron agar tidak berjalan di node Mode Otomatis. Lihat informasi yang lebih lengkap di [Kontrol jika beban kerja diterapkan pada node Mode Otomatis EKS](associate-workload.md).
# Pelajari tentang identitas dan akses dalam Mode Otomatis EKS
Topik ini menjelaskan peran dan izin Identity and Access Management (IAM) and Access Management (IAM) yang diperlukan untuk menggunakan Mode Otomatis EKS. Mode Otomatis EKS menggunakan dua peran IAM utama: Peran IAM Cluster dan Peran IAM Node. Peran ini bekerja sama dengan EKS Pod Identity dan entri akses EKS untuk menyediakan manajemen akses komprehensif untuk kluster EKS Anda.
Saat Anda mengonfigurasi Mode Otomatis EKS, Anda perlu mengatur peran IAM ini dengan izin khusus yang memungkinkan AWS layanan berinteraksi dengan sumber daya cluster Anda. Ini termasuk izin untuk mengelola sumber daya komputasi, volume penyimpanan, penyeimbang beban, dan komponen jaringan. Memahami konfigurasi peran ini sangat penting untuk operasi dan keamanan klaster yang tepat.
Dalam Mode Otomatis EKS, peran AWS IAM secara otomatis dipetakan ke izin Kubernetes melalui entri akses EKS, menghilangkan kebutuhan untuk konfigurasi manual atau binding kustom. `aws-auth` ConfigMaps Saat Anda membuat kluster mode otomatis baru, EKS secara otomatis membuat izin Kubernetes yang sesuai menggunakan entri Access, memastikan bahwa AWS layanan dan komponen klaster memiliki tingkat akses yang sesuai di dalam sistem otorisasi Kubernetes dan Kubernetes. AWS Integrasi otomatis ini mengurangi kompleksitas konfigurasi dan membantu mencegah masalah terkait izin yang biasanya terjadi saat mengelola kluster EKS.
## IAM role klaster
Peran IAM Cluster adalah peran AWS Identity and Access Management (IAM) yang digunakan oleh Amazon EKS untuk mengelola izin klaster Kubernetes. Peran ini memberikan Amazon EKS izin yang diperlukan untuk berinteraksi dengan AWS layanan lain atas nama klaster Anda, dan secara otomatis dikonfigurasi dengan izin Kubernetes menggunakan entri akses EKS.
+ Anda harus melampirkan kebijakan AWS IAM ke peran ini.
+ Mode Otomatis EKS melampirkan izin Kubernetes ke peran ini secara otomatis menggunakan entri akses EKS.
+ Dengan Mode Otomatis EKS, AWS sarankan untuk membuat Peran IAM Cluster tunggal per AWS akun.
+ AWS menyarankan penamaan peran ini`AmazonEKSAutoClusterRole`.
+ Peran ini memerlukan izin untuk beberapa AWS layanan untuk mengelola sumber daya termasuk volume EBS, Elastic Load Balancers, dan instance. EC2
+ Konfigurasi yang disarankan untuk peran ini mencakup beberapa kebijakan IAM AWS terkelola, terkait dengan berbagai kemampuan Mode Otomatis EKS.
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
Untuk informasi selengkapnya tentang Peran IAM Cluster dan kebijakan IAM AWS terkelola, lihat:
+ [AWS kebijakan terkelola untuk Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [IAM role klaster Amazon EKS](cluster-iam-role.md)
Untuk informasi selengkapnya tentang akses Kubernetes, lihat:
+ [Tinjau izin kebijakan akses](access-policy-permissions.md)
## IAM role simpul
Peran Node IAM adalah peran AWS Identity and Access Management (IAM) yang digunakan oleh Amazon EKS untuk mengelola izin bagi node pekerja di klaster Kubernetes. Peran ini memberikan EC2 instans yang berjalan sebagai node Kubernetes izin yang diperlukan untuk berinteraksi dengan AWS layanan dan sumber daya, dan secara otomatis dikonfigurasi dengan izin Kubernetes RBAC menggunakan entri akses EKS.
+ Anda harus melampirkan kebijakan AWS IAM ke peran ini.
+ Mode Otomatis EKS melampirkan izin Kubernetes RBAC ke peran ini secara otomatis menggunakan entri akses EKS.
+ AWS menyarankan penamaan peran ini`AmazonEKSAutoNodeRole`.
+ Dengan Mode Otomatis EKS, AWS menyarankan untuk membuat Peran IAM Node tunggal per AWS akun.
+ Peran ini memiliki izin terbatas. Izin utama termasuk mengasumsikan Peran Identitas Pod, dan menarik gambar dari ECR.
+ AWS menyarankan kebijakan IAM AWS terkelola berikut:
+ `AmazonEKSWorkerNodeMinimalPolicy`
+ `AmazonEC2ContainerRegistryPullOnly`
Untuk informasi selengkapnya tentang Peran IAM Cluster dan kebijakan IAM AWS terkelola, lihat:
+ [AWS kebijakan terkelola untuk Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [IAM role simpul Amazon EKS](create-node-role.md)
Untuk informasi selengkapnya tentang akses Kubernetes, lihat:
+ [Tinjau izin kebijakan akses](access-policy-permissions.md)
## Peran tertaut layanan
Amazon EKS menggunakan peran terkait layanan (SLR) untuk operasi tertentu. Peran tertaut layanan adalah jenis IAM role unik yang terkait langsung dengan Amazon EKS. Peran terkait layanan telah ditentukan sebelumnya oleh Amazon EKS dan menyertakan semua izin yang diperlukan layanan untuk memanggil AWS layanan lain atas nama Anda.
AWS secara otomatis membuat dan mengkonfigurasi SLR. Anda dapat menghapus SLR hanya setelah pertama kali menghapus sumber daya terkait mereka. Ini melindungi sumber daya Amazon EKS Anda karena Anda tidak dapat secara tidak sengaja menghapus izin untuk mengakses sumber daya.
Kebijakan SLR memberikan izin Amazon EKS untuk mengamati dan menghapus komponen infrastruktur inti: EC2 sumber daya (instance, antarmuka jaringan, grup keamanan), sumber daya ELB (penyeimbang beban, grup target), CloudWatch kemampuan (logging dan metrik), dan peran IAM dengan awalan “eks”. Ini juga memungkinkan jaringan titik akhir pribadi melalui asosiasi VPC/hosted zona dan mencakup izin untuk EventBridge pemantauan dan pembersihan sumber daya yang ditandai EKS.
Untuk informasi lebih lanjut, lihat:
+ [AWS kebijakan terkelola: Amazon EKSService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy)
+ [Izin peran tertaut layanan untuk Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)
## AWS Tag khusus untuk sumber daya EKS Auto
Secara default, kebijakan terkelola yang terkait dengan Mode Otomatis EKS tidak mengizinkan penerapan tag yang ditentukan pengguna ke sumber daya yang disediakan AWS Mode Otomatis. Jika ingin menerapkan tag yang ditentukan pengguna ke AWS sumber daya, Anda harus melampirkan izin tambahan ke Peran IAM Cluster dengan izin yang cukup untuk membuat dan memodifikasi tag pada sumber daya. AWS Di bawah ini adalah contoh kebijakan yang memungkinkan akses penandaan tidak terbatas:
### Lihat contoh kebijakan tag kustom
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Compute",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplate"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-node-class-name": "*",
"aws:RequestTag/eks:kubernetes-node-pool-name": "*"
}
}
},
{
"Sid": "Storage",
"Effect": "Allow",
"Action": [
"ec2:CreateVolume",
"ec2:CreateSnapshot"
],
"Resource": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:snapshot/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "Networking",
"Effect": "Allow",
"Action": "ec2:CreateNetworkInterface",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-cni-node-name": "*"
}
}
},
{
"Sid": "LoadBalancer",
"Effect": "Allow",
"Action": [
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateRule",
"ec2:CreateSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldProtection",
"Effect": "Allow",
"Action": [
"shield:CreateProtection"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldTagResource",
"Effect": "Allow",
"Action": [
"shield:TagResource"
],
"Resource": "arn:aws:shield::*:protection/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
}
]
}
```
## Referensi Kebijakan Akses
Untuk informasi selengkapnya tentang izin Kubernetes yang digunakan oleh Mode Otomatis EKS, lihat. [Tinjau izin kebijakan akses](access-policy-permissions.md)
# Pelajari tentang Jaringan VPC dan Load Balancing dalam Mode Otomatis EKS
Topik ini menjelaskan cara mengonfigurasi jaringan Virtual Private Cloud (VPC) dan fitur load balancing di Mode Otomatis EKS. Sementara EKS Auto Mode mengelola sebagian besar komponen jaringan secara otomatis, Anda masih dapat menyesuaikan aspek-aspek tertentu dari konfigurasi jaringan cluster Anda melalui `NodeClass` sumber daya dan anotasi penyeimbang beban.
Saat Anda menggunakan Mode Otomatis EKS, AWS mengelola konfigurasi VPC Container Network Interface (CNI) dan penyediaan penyeimbang beban untuk klaster Anda. Anda dapat memengaruhi perilaku jaringan dengan mendefinisikan `NodeClass` objek dan menerapkan anotasi spesifik ke sumber daya Layanan dan Ingress Anda, sambil mempertahankan model operasional otomatis yang disediakan oleh Mode Otomatis EKS.
## Kemampuan jaringan
EKS Auto Mode memiliki kemampuan jaringan baru yang menangani jaringan node dan pod. Anda dapat mengonfigurasinya dengan membuat objek `NodeClass` Kubernetes.
Opsi konfigurasi untuk AWS VPC CNI sebelumnya tidak akan berlaku untuk Mode Otomatis EKS.
### Konfigurasikan jaringan dengan `NodeClass`
`NodeClass`Sumber daya dalam Mode Otomatis EKS memungkinkan Anda untuk menyesuaikan aspek-aspek tertentu dari kemampuan jaringan. Melalui`NodeClass`, Anda dapat menentukan pilihan grup keamanan, mengontrol penempatan node di seluruh subnet VPC, mengatur kebijakan SNAT, mengonfigurasi kebijakan jaringan, dan mengaktifkan pencatatan peristiwa jaringan. Pendekatan ini mempertahankan model operasional otomatis dari Mode Otomatis EKS sambil memberikan fleksibilitas untuk kustomisasi jaringan.
Anda dapat menggunakan a `NodeClass` untuk:
+ Pilih Grup Keamanan untuk Node
+ Kontrol bagaimana node ditempatkan pada Subnet VPC
+ Mengatur Kebijakan SNAT Node ke `random` atau `disabled`
+ Aktifkan kebijakan *jaringan* Kubernetes termasuk:
+ Setel Kebijakan Jaringan ke Default Deny atau Default Allow
+ Aktifkan Network Event Logging ke file.
+ Mengisolasi lalu lintas pod dari lalu lintas node dengan melampirkan pod ke subnet yang berbeda.
Pelajari cara [Membuat Amazon EKS NodeClass](create-node-class.md).
### Pertimbangan-pertimbangan
Mode Otomatis EKS mendukung:
+ Kebijakan Jaringan EKS.
+ `HostNetwork`Opsi `HostPort` dan untuk Kubernetes Pods.
+ Node dan Pod di subnet publik atau pribadi.
+ Menyimpan kueri DNS pada node.
Mode Otomatis EKS **tidak** mendukung:
+ Grup Keamanan per Pod (SGPP). Untuk menerapkan grup keamanan terpisah ke lalu lintas Pod dalam Mode Otomatis, gunakan `podSecurityGroupSelectorTerms` `NodeClass` sebagai gantinya. Untuk informasi selengkapnya, lihat [Pisahkan subnet dan grup keamanan untuk Pod](create-node-class.md#pod-subnet-selector).
+ Jaringan Kustom di`ENIConfig`. Anda dapat menempatkan pod di beberapa subnet atau secara eksklusif mengisolasinya dari lalu lintas node dengan. [Pisahkan subnet dan grup keamanan untuk Pod](create-node-class.md#pod-subnet-selector)
+ IP hangat, awalan hangat, dan konfigurasi ENI hangat.
+ Konfigurasi target IP minimum.
+ Konfigurasi lain yang didukung oleh AWS VPC CNI open source.
+ Konfigurasi Kebijakan Jaringan seperti penyesuaian timer conntrack (default adalah 300s).
+ Mengekspor log peristiwa jaringan ke CloudWatch.
### Manajemen Sumber Daya Jaringan
Mode Otomatis EKS menangani awalan, pengalamatan IP, dan manajemen antarmuka jaringan dengan memantau NodeClass sumber daya untuk konfigurasi jaringan. Layanan ini melakukan beberapa operasi utama secara otomatis:
**Delegasi Awalan**
EKS Auto Mode default menggunakan prefix delegation (/28 prefixes) untuk jaringan pod dan mempertahankan kumpulan sumber daya IP hangat yang telah ditentukan sebelumnya yang menskalakan berdasarkan jumlah pod terjadwal. Ketika fragmentasi subnet pod terdeteksi, Mode Otomatis menyediakan alamat IP sekunder (/32). Karena algoritma jaringan pod default ini, Mode Otomatis menghitung pod maks per node berdasarkan jumlah ENIs dan IPs didukung per jenis instance (dengan asumsi kasus fragmentasi terburuk). Untuk informasi selengkapnya tentang jenis Maks ENIs dan IPs per instans, lihat [Alamat IP maksimum per antarmuka jaringan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) di Panduan Pengguna EC2. Keluarga instance generasi yang lebih baru (Nitro v6 dan yang lebih baru) umumnya telah meningkat ENIs dan IPs per tipe instans, dan Mode Otomatis menyesuaikan perhitungan pod maks yang sesuai.
Untuk IPv6 cluster, hanya delegasi awalan yang digunakan, dan Mode Otomatis selalu menggunakan batas maksimum pod 110 pod per node.
**Manajemen Cooldown**
Layanan ini mengimplementasikan kumpulan cooldown untuk awalan atau IPv4 alamat sekunder yang tidak lagi digunakan. Setelah periode cooldown berakhir, sumber daya ini dilepaskan kembali ke VPC. Namun, jika pod menggunakan kembali sumber daya ini selama periode cooldown, mereka dipulihkan dari kolam cooldown.
**IPv6 Support**
Untuk IPv6 cluster, Mode Otomatis EKS menyediakan `/80` IPv6 awalan per node pada antarmuka jaringan utama. Saat menggunakan`podSubnetSelectorTerms`, awalan dialokasikan pada antarmuka jaringan sekunder di subnet pod sebagai gantinya.
Layanan ini juga memastikan manajemen yang tepat dan pengumpulan sampah dari semua antarmuka jaringan.
## Penyeimbangan beban
Anda mengonfigurasi AWS Elastic Load Balancer yang disediakan oleh Mode Otomatis EKS menggunakan anotasi pada resource Service dan Ingress.
Untuk informasi selengkapnya, lihat [Buat IngressClass untuk mengkonfigurasi Application Load Balancer](auto-configure-alb.md) atau [Gunakan Anotasi Layanan untuk mengonfigurasi Network Load Balancers](auto-configure-nlb.md).
### Pertimbangan untuk penyeimbangan beban dengan Mode Otomatis EKS
+ Mode penargetan default adalah Mode IP, bukan Mode Instance.
+ Mode Otomatis EKS hanya mendukung Mode Grup Keamanan untuk Network Load Balancer.
+ AWS tidak mendukung migrasi penyeimbang beban dari pengontrol penyeimbang AWS beban yang dikelola sendiri ke manajemen dengan Mode Otomatis EKS.
+ `networking.ingress.ipBlock`Bidang dalam `TargetGroupBinding` spesifikasi tidak didukung.
+ Jika node pekerja Anda menggunakan grup keamanan khusus (bukan pola `eks-cluster-sg- ` penamaan), peran klaster Anda memerlukan izin IAM tambahan. Kebijakan default yang dikelola EKS hanya mengizinkan EKS untuk memodifikasi grup keamanan bernama. `eks-cluster-sg-` Tanpa izin untuk memodifikasi grup keamanan kustom Anda, EKS tidak dapat menambahkan aturan masuk yang diperlukan yang memungkinkan ALB/NLB lalu lintas mencapai pod Anda.
#### Pertimbangan CoreDNS
Mode Otomatis EKS tidak menggunakan penerapan CoreDNS tradisional untuk memberikan resolusi DNS di dalam cluster. Sebagai gantinya, node Mode Otomatis menggunakan CoreDNS yang berjalan sebagai layanan sistem langsung pada setiap node. Jika mentransisikan klaster tradisional ke Mode Otomatis, Anda dapat menghapus penerapan CoreDNS dari klaster setelah beban kerja Anda dipindahkan ke node Mode Otomatis.
**penting**
Jika Anda berencana untuk memelihara klaster dengan node Mode Otomatis dan Mode non-Otomatis, Anda harus mempertahankan penerapan CoreDNS. Node Mode Non-Otomatis mengandalkan pod CoreDNS tradisional untuk resolusi DNS, karena mereka tidak dapat mengakses layanan DNS tingkat node yang disediakan Mode Otomatis.
# Observabilitas untuk Mode Otomatis EKS
Gunakan bagian ini untuk mempelajari opsi observabilitas untuk klaster Mode Otomatis Amazon EKS.
**Topics**
+ [Akses AWS-Log Komponen Terkelola Untuk EKS Auto](auto-managed-component-logs.md)
# Akses AWS-Log Komponen Terkelola Untuk EKS Auto
Anda dapat mengakses log komponen yang AWS dikelola dari Mode Otomatis EKS untuk mendapatkan pengamatan yang lebih dalam ke operasi klaster Anda. Mode Otomatis EKS mendukung log untuk sumber berikut:
+ Hitung penskalaan otomatis - Karpenter
+ Penyimpanan blok - EBS CSI
+ Load balancing - AWS Load Balancer Controller
+ Jaringan Pod - Manajemen Alamat IP VPC CNI
Log dapat dikirim ke [tujuan pengiriman](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) pilihan Anda.
Saat Anda membuat kluster EKS Auto, Anda memiliki opsi untuk mengaktifkan logging bidang kontrol (server API, Audit, Authenticator, Controller manager, Scheduler). Log komponen yang dikelola EKS Auto (seperti Compute, Block storage, Load balancing, dan IPAM) memerlukan konfigurasi terpisah melalui pengiriman log.
## Menyiapkan pengiriman log
Untuk mengonfigurasi pengiriman log komponen yang AWS dikelola untuk kluster Mode Otomatis EKS Anda, gunakan Amazon CloudWatch Logs API. Untuk petunjuk penyiapan terperinci, lihat [Mengaktifkan pencatatan dari AWS layanan](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html) di Panduan Pengguna CloudWatch Log Amazon. Setiap kemampuan Mode Otomatis dapat dikonfigurasi sebagai sumber pengiriman CloudWatch Vended Logs individual, memungkinkan Anda memilih log mana yang ingin Anda akses.
Mode Otomatis EKS mendukung jenis log berikut:
+ **AUTO\$1MODE\$1COMPUTE\$1LOGS**
+ **AUTO\$1MODE\$1BLOCK\$1STORAGE\$1LOGS**
+ **AUTO\$1MODE\$1LOAD\$1BALANCING\$1LOGS**
+ **AUTO\$1MODE\$1IPAM\$1LOGS**
### Menggunakan Amazon CloudWatch APIs
Menyiapkan logging membutuhkan tiga langkah:
1. Buat sumber pengiriman untuk kemampuan menggunakan CloudWatch PutDeliverySource API
1. Buat tujuan pengiriman menggunakan PutDeliveryDestination
1. Buat pengiriman untuk menghubungkan sumber dan tujuan menggunakan CreateDelivery
Anda dapat mengonfigurasi detail tujuan untuk log Mode Otomatis menggunakan deliveryDestinationConfiguration objek di CloudWatch PutDeliveryDestination API. Dibutuhkan ARN dari grup CloudWatch log, bucket S3, atau aliran pengiriman Kinesis Data Firehose.
Anda dapat mengonfigurasi kemampuan Mode Otomatis tunggal (sumber pengiriman) untuk mengirim log ke beberapa tujuan dengan membuat beberapa pengiriman. Anda juga dapat membuat beberapa pengiriman untuk mengonfigurasi beberapa sumber pengiriman untuk mengirim log ke tujuan pengiriman yang sama.
### Izin IAM
Bergantung pada tujuan yang dipilih, Anda mungkin perlu mengonfigurasi Kebijakan atau Peran IAM untuk grup CloudWatch log, bucket S3, dan Firehose Data Kinesis untuk memastikan pengiriman log berhasil. Selain itu, jika mengirim log ke seluruh AWS akun, Anda harus menggunakan PutDeliveryDestinationPolicy API untuk mengonfigurasi kebijakan IAM yang memungkinkan pengiriman ke tujuan. Lihat [dokumentasi izin CloudWatch Log Penjual untuk informasi](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs) tambahan.
## Melihat log Anda
Setelah pengiriman log dikonfigurasi, log akan dikirimkan ke tujuan yang Anda tentukan. Metode untuk mengakses log tergantung pada jenis tujuan yang Anda pilih:
+ **CloudWatch Log** - Lihat log di konsol CloudWatch Log, gunakan perintah AWS CLI, atau kueri dengan CloudWatch Wawasan Log
+ **Amazon S3** - Akses log sebagai objek di bucket S3 Anda melalui konsol S3, AWS CLI, atau alat analitik seperti Amazon Athena
+ **Amazon Data Firehose** - Log dialirkan ke target Firehose yang dikonfigurasi (seperti S3, OpenSearch Service, Redshift, dll)
## Harga
CloudWatch Biaya Vended Logs berlaku untuk pengiriman dan penyimpanan log berdasarkan tujuan pengiriman yang Anda pilih. CloudWatch Vded Logs memungkinkan pengiriman log yang andal dan aman dengan AWS otentikasi dan otorisasi bawaan dengan harga yang lebih murah dibandingkan dengan Log standar. CloudWatch Lihat [bagian Vended Logs di halaman CloudWatch harga](https://aws.amazon.com/cloudwatch/pricing/) untuk detail selengkapnya.
### Sumber Daya Terkait
+ [Amazon EKS mengontrol pencatatan pesawat](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
+ [PutDeliverySource API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) di Referensi API CloudWatch Log
+ [PutDeliveryDestination API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) di Referensi API CloudWatch Log
+ [CreateDelivery API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) di Referensi API CloudWatch Log
# Memecahkan Masalah Mode Otomatis EKS
Dengan Mode Otomatis EKS, AWS Anda akan bertanggung jawab lebih besar atas Instans EC2 di akun Anda. AWS EKS bertanggung jawab atas runtime kontainer pada node, sistem operasi pada node, dan pengontrol tertentu. Ini termasuk pengontrol penyimpanan blok, pengontrol penyeimbang beban, dan pengontrol komputasi.
Anda harus menggunakan AWS dan Kubernetes APIs untuk memecahkan masalah node. Anda dapat:
+ Gunakan `NodeDiagnostic` sumber daya Kubernetes untuk mengambil log node dengan menggunakan file. [Agen pemantauan simpul](#auto-node-monitoring-agent) Untuk langkah lebih lanjut, lihat[Mengambil log node untuk node terkelola menggunakan kubectl dan S3](auto-get-logs.md).
+ Gunakan `get-console-output` perintah AWS EC2 CLI untuk mengambil output konsol dari node. Untuk langkah lebih lanjut, lihat[Dapatkan output konsol dari instans terkelola EC2 dengan menggunakan AWS EC2 CLI](#auto-node-console).
+ Gunakan *kontainer debugging* Kubernetes untuk mengambil log node. Untuk langkah lebih lanjut, lihat[Dapatkan log node dengan menggunakan *kontainer debug* dan CLI `kubectl`](#auto-node-debug-logs).
**catatan**
Mode Otomatis EKS menggunakan instans terkelola EC2. Anda tidak dapat langsung mengakses instans terkelola EC2, termasuk oleh SSH.
Anda mungkin memiliki masalah berikut yang memiliki solusi khusus untuk komponen Mode Otomatis EKS:
+ Pod terjebak dalam `Pending` status, yang tidak dijadwalkan ke node Mode Otomatis. Untuk solusi lihat[Memecahkan masalah Pod yang gagal menjadwalkan ke node Mode Otomatis](#auto-troubleshoot-schedule).
+ Instance terkelola EC2 yang tidak bergabung dengan cluster sebagai node Kubernetes. Untuk solusi lihat[Memecahkan masalah node yang tidak bergabung dengan cluster](#auto-troubleshoot-join).
+ Kesalahan dan masalah dengan`NodePools`,`PersistentVolumes`, dan `Services` yang menggunakan pengontrol yang disertakan dalam Mode Otomatis EKS. Untuk solusi lihat[Memecahkan masalah pengontrol yang disertakan dalam Mode Otomatis](#auto-troubleshoot-controllers).
+ Keamanan Pod yang ditingkatkan mencegah berbagi volume di seluruh Pod. Untuk solusi lihat[Berbagi Volume di Seluruh Pod](#auto-troubleshoot-share-pod-volumes).
Anda dapat menggunakan metode berikut untuk memecahkan masalah komponen Mode Otomatis EKS:
+ [Dapatkan output konsol dari instans terkelola EC2 dengan menggunakan AWS EC2 CLI](#auto-node-console)
+ [Dapatkan log node dengan menggunakan *kontainer debug* dan CLI `kubectl`](#auto-node-debug-logs)
+ [Melihat sumber daya yang terkait dengan Mode Otomatis EKS di AWS Konsol](#auto-node-ec2-web)
+ [Lihat Kesalahan IAM di akun Anda AWS](#auto-node-iam)
+ [Mendeteksi masalah konektivitas node dengan `VPC Reachability Analyzer`](#auto-node-reachability)
## Agen pemantauan simpul
Mode Otomatis EKS mencakup agen pemantauan simpul Amazon EKS. Anda dapat menggunakan agen ini untuk melihat pemecahan masalah dan debugging informasi tentang node. Agen pemantauan node menerbitkan Kubernetes `events` dan node. `conditions` Untuk informasi selengkapnya, lihat [Mendeteksi masalah kesehatan node dan mengaktifkan perbaikan node otomatis](node-health.md).
## Dapatkan output konsol dari instans terkelola EC2 dengan menggunakan AWS EC2 CLI
Prosedur ini membantu mengatasi masalah waktu boot atau masalah tingkat kernel.
Pertama, Anda perlu menentukan ID Instans EC2 dari instance yang terkait dengan beban kerja Anda. Kedua, gunakan AWS CLI untuk mengambil output konsol.
1. Konfirmasikan bahwa Anda telah `kubectl` menginstal dan terhubung ke cluster Anda
1. (Opsional) Gunakan nama Deployment Kubernetes untuk membuat daftar pod terkait.
```
kubectl get pods -l app=
```
1. Gunakan nama Pod Kubernetes untuk menentukan ID instans EC2 dari node terkait.
```
kubectl get pod -o wide
```
1. Gunakan ID instans EC2 untuk mengambil output konsol.
```
aws ec2 get-console-output --instance-id --latest --output text
```
## Dapatkan log node dengan menggunakan *kontainer debug* dan CLI `kubectl`
Cara yang disarankan untuk mengambil log dari node Mode Otomatis EKS adalah dengan menggunakan `NodeDiagnostic` sumber daya. Untuk langkah-langkah ini, lihat[Mengambil log node untuk node terkelola menggunakan kubectl dan S3](auto-get-logs.md).
Namun, Anda dapat melakukan streaming log secara langsung dari sebuah instance dengan menggunakan `kubectl debug node` perintah. Perintah ini meluncurkan Pod baru pada node yang ingin Anda debug yang kemudian dapat Anda gunakan secara interaktif.
1. Luncurkan wadah debug. Perintah berikut menggunakan `i-01234567890123456` ID instance node, `-it` mengalokasikan a `tty` dan melampirkan `stdin` untuk penggunaan interaktif, dan menggunakan `sysadmin` profil dari file kubeconfig.
```
kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023
```
Contoh output adalah sebagai berikut.
```
Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
If you don't see a command prompt, try pressing enter.
bash-5.2#
```
1. Dari shell, Anda sekarang dapat menginstal `util-linux-core` yang menyediakan `nsenter` perintah. Gunakan `nsenter` untuk memasukkan namespace mount PID 1 (`init`) pada host, dan jalankan `journalctl` perintah untuk mengalirkan log dari: `kubelet`
```
yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet
```
Untuk keamanan, image container Amazon Linux tidak menginstal banyak binari secara default. Anda dapat menggunakan `yum whatprovides` perintah untuk mengidentifikasi paket yang harus diinstal untuk menyediakan biner yang diberikan.
```
yum whatprovides ps
```
```
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : @System
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : amazonlinux
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
```
## Melihat sumber daya yang terkait dengan Mode Otomatis EKS di AWS Konsol
Anda dapat menggunakan AWS konsol untuk melihat status sumber daya yang terkait dengan kluster Mode Otomatis EKS Anda.
+ [Volume EBS](https://console.aws.amazon.com/ec2/home#Volumes)
+ Lihat volume Mode Otomatis EKS dengan mencari kunci tag `eks:eks-cluster-name`
+ [Penyeimbang Beban](https://console.aws.amazon.com/ec2/home#LoadBalancers)
+ Lihat penyeimbang beban Mode Otomatis EKS dengan mencari kunci tag `eks:eks-cluster-name`
+ [Instans EC2](https://console.aws.amazon.com/ec2/home#Instances)
+ Lihat contoh Mode Otomatis EKS dengan mencari kunci tag `eks:eks-cluster-name`
## Lihat Kesalahan IAM di akun Anda AWS
1. Arahkan ke CloudTrail konsol
1. Pilih “Riwayat Acara” dari panel navigasi kiri
1. Terapkan filter kode kesalahan:
+ AccessDenied
+ UnauthorizedOperation
+ InvalidClientTokenId
Cari kesalahan yang terkait dengan kluster EKS Anda. Gunakan pesan kesalahan untuk memperbarui entri akses EKS, peran IAM cluster, atau peran IAM node. Anda mungkin perlu melampirkan kebijakan baru ke peran ini dengan izin untuk Mode Otomatis EKS.
## Memecahkan masalah Pod yang gagal menjadwalkan ke node Mode Otomatis
Jika pod tetap dalam `Pending` status dan tidak dijadwalkan ke node mode otomatis, verifikasi apakah pod atau manifes penerapan Anda memiliki `nodeSelector` file. Jika `nodeSelector` ada, pastikan bahwa itu digunakan `eks.amazonaws.com/compute-type: auto` untuk dijadwalkan pada node yang dibuat oleh EKS Auto Mode. Untuk informasi selengkapnya tentang label node yang digunakan oleh Mode Otomatis EKS, lihat[Kontrol jika beban kerja diterapkan pada node Mode Otomatis EKS](associate-workload.md).
## Memecahkan masalah node yang tidak bergabung dengan cluster
Mode Otomatis EKS secara otomatis mengonfigurasi instans EC2 baru dengan informasi yang benar untuk bergabung dengan cluster, termasuk titik akhir cluster dan otoritas sertifikat klaster (CA). Namun, instance ini masih bisa gagal untuk bergabung dengan cluster EKS sebagai node. Jalankan perintah berikut untuk mengidentifikasi instance yang tidak bergabung dengan cluster:
1. `kubectl get nodeclaim`Jalankan untuk memeriksa `NodeClaims` itu`Ready = False`.
```
kubectl get nodeclaim
```
1. Jalankan `kubectl describe nodeclaim ` dan lihat di bawah **Status** untuk menemukan masalah apa pun yang mencegah node bergabung dengan cluster.
```
kubectl describe nodeclaim
```
**Pesan kesalahan umum:**
`Error getting launch template configs`
Anda mungkin menerima kesalahan ini jika Anda menyetel tag kustom `NodeClass` dengan izin peran IAM cluster default. Lihat [Pelajari tentang identitas dan akses dalam Mode Otomatis EKS](auto-learn-iam.md).
`Error creating fleet`
Mungkin ada beberapa masalah otorisasi dengan memanggil `RunInstances` panggilan dari EC2 API. AWS CloudTrail Periksa kesalahan dan lihat [Peran IAM kluster Mode Otomatis Amazon EKS](auto-cluster-iam-role.md) izin IAM yang diperlukan.
### Mendeteksi masalah konektivitas node dengan `VPC Reachability Analyzer`
**catatan**
Anda dikenakan biaya untuk setiap analisis yang menjalankan VPC Reachability Analyzer. Untuk detail harga, lihat Harga [Amazon VPC](https://aws.amazon.com/vpc/pricing/).
Salah satu alasan mengapa instance tidak bergabung dengan cluster adalah masalah konektivitas jaringan yang mencegah mereka mencapai server API. Untuk mendiagnosis masalah ini, Anda dapat menggunakan [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) untuk melakukan analisis konektivitas antara node yang gagal bergabung dengan cluster dan server API. Anda akan membutuhkan dua informasi:
+ **ID instance** dari node yang tidak dapat bergabung dengan cluster
+ Alamat IP dari titik akhir server **API Kubernetes**
Untuk mendapatkan **ID instans**, Anda harus membuat beban kerja di cluster untuk menyebabkan Mode Otomatis EKS meluncurkan instans EC2. Ini juga membuat `NodeClaim` objek di cluster Anda yang akan memiliki ID instance. Jalankan `kubectl get nodeclaim -o yaml` untuk mencetak semua yang `NodeClaims` ada di cluster Anda. Masing-masing `NodeClaim` berisi ID instance sebagai bidang dan lagi di providerId:
```
kubectl get nodeclaim -o yaml
```
Contoh output adalah sebagai berikut.
```
nodeName: i-01234567890123456
providerID: aws:///us-west-2a/i-01234567890123456
```
Anda dapat menentukan titik **akhir server API Kubernetes dengan menjalankannya**. `kubectl get endpoint kubernetes -o yaml` Alamatnya ada di bidang alamat:
```
kubectl get endpoints kubernetes -o yaml
```
Contoh output adalah sebagai berikut.
```
apiVersion: v1
kind: Endpoints
metadata:
name: kubernetes
namespace: default
subsets:
- addresses:
- ip: 10.0.143.233
- ip: 10.0.152.17
ports:
- name: https
port: 443
protocol: TCP
```
Dengan dua informasi ini, Anda dapat melakukan analisis s. Pertama-tama navigasikan ke VPC Reachability Analyzer di file. Konsol Manajemen AWS
1. Klik “Buat dan Analisis Jalur”
1. Berikan nama untuk analisis (misalnya “Node Join Failure”)
1. Untuk “Jenis Sumber” pilih “Instans”
1. Masukkan ID instance dari Node yang gagal sebagai “Sumber”
1. Untuk “Path Destination” pilih “IP Address”
1. Masukkan salah satu alamat IP untuk server API sebagai “Alamat Tujuan”
1. Perluas “Bagian Konfigurasi Header Paket Tambahan”
1. Masukkan “Port Tujuan” dari 443
1. Pilih “Protocol” sebagai TCP jika belum dipilih
1. Klik “Buat dan Analisis Jalur”
1. Analisis mungkin memakan waktu beberapa menit untuk menyelesaikannya. Jika hasil analisis menunjukkan kemampuan jangkauan yang gagal, itu akan menunjukkan di mana kegagalan berada di jalur jaringan sehingga Anda dapat menyelesaikan masalah.
## Berbagi Volume di Seluruh Pod
Node Mode Otomatis EKS dikonfigurasi dengan SELinux mode penegakan yang memberikan lebih banyak isolasi antara Pod yang berjalan pada Node yang sama. Ketika SELinux diaktifkan, sebagian besar pod yang tidak memiliki hak istimewa akan secara otomatis memiliki label keamanan multi-kategori (MCS) mereka sendiri yang diterapkan padanya. Label MCS ini unik per Pod, dan dirancang untuk memastikan bahwa proses dalam satu Pod tidak dapat memanipulasi proses di Pod lain atau pada host. Bahkan jika Pod berlabel berjalan sebagai root dan memiliki akses ke sistem file host, ia tidak akan dapat memanipulasi file, membuat panggilan sistem sensitif pada host, mengakses runtime container, atau mendapatkan materi kunci rahasia kubelet.
Karena itu, Anda mungkin mengalami masalah saat mencoba berbagi data antar Pod. Misalnya, `PersistentVolumeClaim` dengan mode akses masih tidak `ReadWriteOnce` akan mengizinkan beberapa Pod untuk mengakses volume secara bersamaan.
Untuk mengaktifkan berbagi antar Pod ini, Anda dapat menggunakan Pod `seLinuxOptions` untuk mengonfigurasi label MCS yang sama pada Pod tersebut. Dalam contoh ini, kita menetapkan tiga kategori `c123,c456,c789` ke Pod. Ini tidak akan bertentangan dengan kategori apa pun yang ditetapkan ke Pod pada node secara otomatis, karena mereka hanya akan diberikan dua kategori.
```
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"
```
## Lihat peristiwa Karpenter di log pesawat kontrol
Untuk klaster EKS dengan log bidang kontrol diaktifkan, Anda dapat memperoleh wawasan tentang tindakan dan proses pengambilan keputusan Karpenter dengan menanyakan log. Ini dapat sangat berguna untuk memecahkan masalah Mode Otomatis EKS yang terkait dengan penyediaan node, penskalaan, dan penghentian. Untuk melihat peristiwa terkait Karpenter, gunakan kueri Wawasan CloudWatch Log berikut:
```
fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc
```
Kueri ini memfilter untuk [kejadian terkait Karpenter](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go) tertentu di log audit kube-apiserver. Peristiwa tersebut mencakup berbagai status gangguan, kegagalan penjadwalan, masalah kapasitas, dan masalah terkait simpul. Dengan menganalisis log ini, Anda dapat memperoleh pemahaman yang lebih baik tentang:
+ Mengapa Karpenter mengambil tindakan tertentu.
+ Masalah apa pun yang mencegah penyediaan, penskalaan, atau penghentian node yang tepat.
+ Potensi kapasitas atau masalah kompatibilitas dengan jenis instans.
+ Peristiwa siklus hidup node seperti gangguan, penggusuran, atau penghentian.
Untuk menggunakan kueri ini:
1. Arahkan ke CloudWatch konsol
1. Pilih “Wawasan Log” dari panel navigasi kiri
1. Pilih grup log untuk log bidang kontrol kluster EKS Anda
1. Tempelkan kueri ke editor kueri
1. Sesuaikan rentang waktu sesuai kebutuhan
1. Jalankan kueri
Hasilnya akan menunjukkan kepada Anda garis waktu peristiwa terkait Karpenter, membantu Anda memecahkan masalah, dan memahami perilaku Mode Otomatis EKS di cluster Anda. Untuk meninjau tindakan Karpenter pada node tertentu, Anda dapat menambahkan filter baris di bawah ini yang menentukan ID instance ke kueri yang disebutkan di atas:
```
|filter @message like /[.replaceable]`i-12345678910123456`/
```
**catatan**
Untuk menggunakan kueri ini, pencatatan bidang kontrol harus diaktifkan di kluster EKS Anda. Jika Anda belum melakukan ini, silakan merujuk ke[Kirim log pesawat kontrol ke CloudWatch Log](control-plane-logs.md).
## Memecahkan masalah pengontrol yang disertakan dalam Mode Otomatis
Jika Anda memiliki masalah dengan pengontrol, Anda harus meneliti:
+ Jika sumber daya yang terkait dengan pengontrol itu diformat dengan benar dan valid.
+ Jika sumber daya AWS IAM dan Kubernetes RBAC dikonfigurasi dengan benar untuk klaster Anda. Untuk informasi selengkapnya, lihat [Pelajari tentang identitas dan akses dalam Mode Otomatis EKS](auto-learn-iam.md).
## Sumber daya terkait
Gunakan artikel ini dari AWS re:Post untuk langkah-langkah pemecahan masalah lanjutan:
+ [Bagaimana cara mengatasi masalah penskalaan umum di Mode Otomatis EKS?](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ)
+ [Bagaimana cara memecahkan masalah penyediaan nodepool dan nodeclass khusus di Amazon EKS Auto Mode?](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ)
+ [Bagaimana cara memecahkan masalah kumpulan node bawaan Mode Otomatis EKS dengan Status Tidak Dikenal?](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)
# Tinjau catatan rilis Mode Otomatis EKS
Halaman ini mendokumentasikan pembaruan ke Mode Otomatis Amazon EKS. Anda dapat memeriksa halaman ini secara berkala untuk pengumuman tentang fitur, perbaikan bug, masalah yang diketahui, dan fungsionalitas yang tidak digunakan lagi.
Untuk menerima pemberitahuan semua perubahan file sumber ke halaman dokumentasi khusus ini, Anda dapat berlangganan URL berikut dengan pembaca RSS:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom
```
## Februari 2, 2026
**Fitur**: Menambahkan dukungan untuk menonaktifkan lalu lintas V4eGress dari IPv6 pod di kluster Mode Otomatis EKS. IPv6 Untuk informasi selengkapnya, lihat [IPv4 Nonaktifkan jalan keluar dari IPv6 pod dalam IPv6 cluster.](create-node-class.md#enableV4Egress).
## Desember 19, 2025
**Fitur**: Menambahkan dukungan untuk mode IP sekunder yang menyediakan alamat IP sekunder alih-alih awalan ke node Otomatis. Mode ini mempertahankan satu IP sekunder sebagai Minimal IPTarget dan menyimpan sumber daya IP untuk pelanggan yang tidak perlu melakukan pemanasan lebih sekunder IPs atau awalan. Untuk informasi selengkapnya, lihat [Spesifikasi Kelas Node](create-node-class.md#auto-node-class-spec) dan [Mode IP Sekunder untuk Pod](create-node-class.md#secondary-IP-mode).
## November 19, 2025
**Fitur**: Aktifkan Seekable OCI (SOCI) parallel pull and unpack untuk instance keluarga G, P, dan Trn dengan penyimpanan lokal. NVMe SOCI parallel pull and unpack selalu digunakan untuk keluarga instance ini dengan Mode Otomatis EKS dan tidak ada perubahan konfigurasi yang diperlukan untuk mengaktifkannya. Untuk informasi lebih lanjut tentang SOCI, lihat [blog peluncuran](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/).
## November 19, 2025
**Fitur**: Menambahkan dukungan untuk kumpulan node berkapasitas statis yang mempertahankan jumlah node tetap. Untuk informasi selengkapnya, lihat [Kolam Node Kapasitas Statis dalam Mode Otomatis EKS](auto-static-capacity.md).
## Oktober 23, 2025
**Fitur:** Pengguna dengan cluster di wilayah AS sekarang dapat meminta untuk menggunakan FIPS yang kompatibel AMIs dengan menentukan definisi `spec.advancedSecurity.fips` mereka. NodeClass
## Oktober 1, 2025
**Fitur:** Mode Otomatis EKS sekarang mendukung penerapan node ke AWS Local Zones. Untuk informasi selengkapnya, lihat [Menerapkan node Mode Otomatis EKS ke Local Zones](auto-local-zone.md).
## September 30, 2025
**Fitur:** Menambahkan dukungan untuk InstanceProfile ke yang saling eksklusif NodeClass `spec.instanceProfile` dari lapangan. `spec.role`
## September 29, 2025
DRA saat ini tidak didukung oleh Mode Otomatis EKS.
## September 10, 2025
**Tugas:** Peristiwa yang diaktifkan dari pengontrol Komputasi Mode Otomatis sekarang akan menggunakan nama `eks-auto-mode/compute` alih-alih. `karpenter`
## Agustus 24, 2025
**Perbaikan Bug:** VPCs yang menggunakan opsi DHCP yang disetel dengan nama domain khusus yang berisi huruf kapital akan menyebabkan Node gagal bergabung dengan cluster karena menghasilkan nama host yang tidak valid. Ini telah diselesaikan dan nama domain dengan huruf kapital sekarang berfungsi dengan benar.
## Agustus 15, 2025
**Perbaikan Bug:** Agen Identitas Pod sekarang hanya akan mendengarkan alamat IPv4 Link Local di klaster IPv4 EKS untuk menghindari masalah di mana Pod tidak dapat mencapai IPv6 alamat tersebut.
## Agustus 6, 2025
**Fitur:** Menambahkan konfigurasi baru NodeClass `spec.advancedNetworking.associatePublicIPAddress` yang dapat digunakan untuk mencegah alamat IP publik ditetapkan ke Node Mode Otomatis EKS
## Juni 30, 2025
**Fitur:** Mode Otomatis NodeClass sekarang menggunakan kunci KMS kustom yang dikonfigurasi untuk mengenkripsi volume root read-only instance, selain volume data. read/write Sebelumnya, kunci KMS khusus hanya digunakan untuk mengenkripsi volume data.
## Juni 20, 2025
**Fitur:** Dukungan untuk mengontrol penyebaran beban kerja ke EC2 On-Demand Capacity Reservations (). ODCRs Ini menambahkan kunci opsional `capacityReservationSelectorTerms` ke NodeClass, memungkinkan Anda untuk secara eksplisit mengontrol beban kerja ODCRs Anda yang digunakan. Untuk informasi selengkapnya, lihat [Kontrol penyebaran beban kerja ke Reservasi Kapasitas dengan Mode Otomatis EKS](auto-odcr.md).
## Juni 13, 2025
**Fitur:** Support untuk subnet pod terpisah di file. `NodeClass` Ini menambahkan kunci opsional ``podSubnetSelectorTerms` dan `podSecurityGroupSelectorTerms` untuk mengatur subnet dan grup keamanan untuk pod. Untuk informasi selengkapnya, lihat [Pisahkan subnet dan grup keamanan untuk Pod](create-node-class.md#pod-subnet-selector).
## April 30, 2025
**Fitur:** Support untuk proxy jaringan maju di. `NodeClass` Ini menambahkan kunci opsional `advancedNetworking` untuk mengatur proxy HTTPS Anda. Untuk informasi selengkapnya, lihat [Spesifikasi Kelas Node](create-node-class.md#auto-node-class-spec).
## April 18, 2025
**Fitur:** Dukungan untuk menyelesaikan domain.local (biasanya dicadangkan untuk Multicast DNS) melalui DNS unicast.
## April 11, 2025
**Fitur:** Ditambahkan `certificateBundles` dan `ephemeralStorage.kmsKeyID` ke`NodeClass`. Untuk informasi selengkapnya, lihat [Spesifikasi Kelas Node](create-node-class.md#auto-node-class-spec).
**Fitur:** Peningkatan kecepatan tarik gambar, terutama untuk tipe instance dengan penyimpanan instans lokal yang dapat memanfaatkan dekompresi gambar yang lebih cepat.
**Perbaikan Bug:** Menyelesaikan kondisi balapan yang menyebabkan FailedCreatePodSandBox , Kesalahan saat melakukan panggilan: dial tcp 127.0.0. 1:50051: connect: koneksi terkadang ditolak untuk penjadwalan Pod ke Node segera saat startup.
## April 4, 2025
**Fitur:** Tingkatkan `registryPullQPS` dari 5 menjadi 25 dan `registryBurst` dari 10 menjadi 50 untuk mengurangi pelambatan tarik gambar yang diterapkan klien () `Failed to pull image xyz: pull QPS exceeded`
## Maret 31, 2025
**Perbaikan Bug: Memperbaiki** masalah di mana jika Core DNS Pod berjalan pada node Mode Otomatis, kueri DNS dari Pod pada node akan mengenai Core DNS Pod alih-alih server DNS lokal node. Kueri DNS dari Pod pada node Mode Otomatis akan selalu masuk ke DNS lokal node.
## Maret 21, 2025
**Perbaikan Bug:** Node Mode Otomatis sekarang diselesaikan `kube-dns.kube-system.svc.cluster.local` dengan benar ketika tidak ada `kube-dns` layanan yang diinstal di cluster. Mengatasi GitHub masalah [\$12546](https://github.com/aws/containers-roadmap/issues/2546).
## Maret 14, 2025
**Fitur**: `IPv4` jalan keluar diaktifkan dalam `IPv6` cluster. `IPv4`lalu lintas yang keluar dari kluster Mode `IPv6` Otomatis sekarang akan secara otomatis diterjemahkan ke `v4` alamat ENI primer simpul.