

 **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.

# Pelajari cara kerja Mode Otomatis EKS
<a name="auto-reference"></a>

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
<a name="automode-learn-instances"></a>

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
<a name="_comparison_table"></a>


|  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
<a name="_ami_support"></a>

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
<a name="auto-supported-instances"></a>

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
<a name="_instance_metadata_service"></a>
+ 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
<a name="_considerations"></a>
+ 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
<a name="auto-learn-iam"></a>

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
<a name="auto-learn-cluster-iam-role"></a>

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
<a name="auto-learn-node-iam-role"></a>

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
<a name="_service_linked_role"></a>

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
<a name="tag-prop"></a>

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
<a name="auto-tag-policy"></a>

```
{
    "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
<a name="_access_policy_reference"></a>

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
<a name="auto-networking"></a>

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
<a name="_networking_capability"></a>

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`
<a name="_configure_networking_with_a_nodeclass"></a>

`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
<a name="_considerations"></a>

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
<a name="_network_resource_management"></a>

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
<a name="auto-lb-consider"></a>

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
<a name="_considerations_for_load_balancing_with_eks_auto_mode"></a>
+ 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
<a name="dns-consider"></a>

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.