**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. # Perbarui node yang dikelola sendiri untuk klaster Anda Saat AMI Amazon EKS baru yang dioptimalkan dirilis, pertimbangkan untuk mengganti node di grup node yang dikelola sendiri dengan AMI baru. Demikian juga, jika Anda telah memperbarui versi Kubernetes untuk cluster Amazon EKS Anda, perbarui node untuk menggunakan node dengan versi Kubernetes yang sama. **penting** Topik ini mencakup pembaruan simpul untuk simpul yang dikelola sendiri. Jika Anda menggunakan [grup node terkelola](managed-node-groups.md), lihat[Memperbarui grup node terkelola untuk klaster Anda](update-managed-node-group.md). Ada dua cara dasar untuk memperbarui grup simpul yang dikelola sendiri di klaster Anda untuk menggunakan AMI baru: **[Migrasikan aplikasi ke grup node baru](migrate-stack.md)** Buat grup node baru dan migrasi Pod Anda ke grup tersebut. Migrasi ke grup node baru lebih anggun daripada sekadar memperbarui ID AMI di tumpukan yang ada AWS CloudFormation . Ini karena proses migrasi [menodai](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) grup node lama `NoSchedule` dan menguras node setelah tumpukan baru siap menerima beban kerja Pod yang ada. **[Perbarui tumpukan AWS CloudFormation simpul](update-stack.md)** Perbarui AWS CloudFormation tumpukan untuk grup node yang ada untuk menggunakan AMI baru. Metode ini tidak didukung untuk grup node yang dibuat dengan`eksctl`. # Migrasikan aplikasi ke grup node baru Topik ini menjelaskan bagaimana Anda dapat membuat grup node baru, dengan anggun memigrasikan aplikasi yang ada ke grup baru, dan menghapus grup node lama dari cluster Anda. Anda dapat bermigrasi ke grup simpul baru menggunakan `eksctl` atau Konsol Manajemen AWS. + [`eksctl`](#eksctl_migrate_apps) + [Konsol Manajemen AWS dan AWS CLI](#console_migrate_apps) ## `eksctl` **Migrasikan aplikasi Anda ke grup node baru dengan `eksctl`** Untuk informasi selengkapnya tentang penggunaan eksctl untuk migrasi, lihat [Nodegroup tidak dikelola](https://eksctl.io/usage/nodegroup-unmanaged/) dalam dokumentasi. `eksctl` Prosedur ini membutuhkan `eksctl` versi `0.215.0` atau yang lebih baru. Anda dapat memeriksa versi Anda dengan perintah berikut: ``` eksctl version ``` Untuk petunjuk tentang cara menginstal atau meningkatkan`eksctl`, lihat [Instalasi](https://eksctl.io/installation) dalam `eksctl` dokumentasi. **catatan** Prosedur ini hanya bekerja untuk grup klaster dan simpul yang dibuat dengan `eksctl`. 1. Ambil nama grup node yang ada, ganti *my-cluster* dengan nama cluster Anda. ``` eksctl get nodegroups --cluster=my-cluster ``` Contoh output adalah sebagai berikut. ``` CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12 ``` 1. Luncurkan grup node baru `eksctl` dengan perintah berikut. Dalam perintah, ganti setiap *example value* dengan nilai Anda sendiri. Nomor versi tidak boleh lebih lambat dari versi Kubernetes untuk pesawat kontrol Anda. Selain itu, tidak boleh lebih dari dua versi minor lebih awal dari versi Kubernetes untuk pesawat kontrol Anda. Kami menyarankan Anda menggunakan versi yang sama dengan pesawat kontrol Anda. Sebaiknya blokir akses Pod ke IMDS jika kondisi berikut benar: + Anda berencana untuk menetapkan peran IAM ke semua akun layanan Kubernetes Anda sehingga Pod hanya memiliki izin minimum yang mereka butuhkan. + Tidak ada Pod dalam klaster yang memerlukan akses ke layanan metadata instans Amazon EC2 (IMDS) karena alasan lain, seperti mengambil Region saat ini. AWS Untuk informasi selengkapnya, lihat [Membatasi akses ke profil instance yang ditetapkan ke node pekerja](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). Untuk memblokir akses Pod ke IMDS, tambahkan `--disable-pod-imds` opsi ke perintah berikut. **catatan** Untuk lebih banyak flag yang tersedia dan deskripsinya, lihat https://eksctl.io/. ``` eksctl create nodegroup \ --cluster my-cluster \ --version 1.35 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false ``` 1. Setelah perintah sebelumnya selesai, verifikasi bahwa semua simpul Anda telah mencapai status `Ready` dengan perintah berikut: ``` kubectl get nodes ``` 1. Hapus grup node asli dengan perintah berikut. Dalam perintah, ganti setiap *example value* dengan nama grup cluster dan node Anda: ``` eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old ``` ## Konsol Manajemen AWS dan AWS CLI **Migrasikan aplikasi Anda ke grup node baru dengan Konsol Manajemen AWS dan CLI AWS ** 1. Luncurkan grup node baru dengan mengikuti langkah-langkah yang diuraikan dalam [Buat node Amazon Linux yang dikelola sendiri](launch-workers.md). 1. Setelah tumpukan Anda selesai dibuat, pilih tumpukan di konsol dan pilih **Outputs**. 1. Rekam **NodeInstanceRole**untuk grup node yang telah dibuat. Anda memerlukan ini untuk menambahkan simpul Amazon EKS baru ke klaster Anda. **catatan** Jika Anda melampirkan kebijakan IAM tambahan ke peran IAM grup node lama Anda, lampirkan kebijakan yang sama tersebut ke peran IAM grup node baru Anda untuk mempertahankan fungsionalitas tersebut pada grup baru. Ini berlaku bagi Anda jika Anda menambahkan izin untuk [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), misalnya. 1. Perbarui grup keamanan untuk kedua grup simpul sehingga mereka dapat berkomunikasi satu sama lain. Untuk informasi selengkapnya, lihat [Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md). 1. Rekam grup keamanan IDs untuk kedua grup node. Ini ditampilkan sebagai **NodeSecurityGroup**nilai dalam output AWS CloudFormation stack. Anda dapat menggunakan perintah AWS CLI berikut untuk mendapatkan grup keamanan IDs dari nama tumpukan. Dalam perintah ini, `oldNodes` adalah nama AWS CloudFormation tumpukan untuk tumpukan node lama Anda, dan `newNodes` merupakan nama tumpukan tempat Anda bermigrasi. Ganti setiap *example value* dengan nilai-nilai Anda sendiri. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) ``` 1. Tambahkan aturan masuk ke setiap grup keamanan simpul sehingga mereka menerima lalu lintas dari satu sama lain. Perintah AWS CLI berikut menambahkan aturan masuk ke setiap grup keamanan yang memungkinkan semua lalu lintas pada semua protokol dari grup keamanan lainnya. Konfigurasi ini memungkinkan Pod di setiap grup node untuk berkomunikasi satu sama lain saat Anda memigrasikan beban kerja Anda ke grup baru. ``` aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 authorize-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Edit configmap `aws-auth` untuk memetakan peran instans simpul baru di RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Tambahkan entri `mapRoles` baru untuk grup simpul baru. ``` apiVersion: v1 data: mapRoles: | - rolearn: ARN of instance role (not instance profile) username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes ``` Ganti *ARN of instance role (not instance profile)* cuplikan dengan **NodeInstanceRole**nilai yang Anda rekam pada langkah [sebelumnya](#node-instance-role-step). Kemudian, simpan dan tutup file untuk menerapkan configmap yang diperbarui. 1. Perhatikan status simpul Anda dan tunggu simpul baru Anda bergabung dengan klaster dan mencapai status `Ready` tersebut. ``` kubectl get nodes --watch ``` 1. (Opsional) Jika Anda menggunakan [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), turunkan skala deployment ke nol (0) replika untuk menghindari tindakan penskalaan yang bertentangan. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Gunakan perintah berikut untuk mencemari setiap node yang ingin Anda hapus. `NoSchedule` Hal ini agar Pod baru tidak dijadwalkan atau dijadwal ulang pada node yang Anda ganti. Untuk informasi selengkapnya, lihat [Taints and Tolerations dalam dokumentasi](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) Kubernetes. ``` kubectl taint nodes node_name key=value:NoSchedule ``` Jika Anda memutakhirkan node Anda ke versi Kubernetes baru, Anda dapat mengidentifikasi dan mencemari semua node dari versi Kubernetes tertentu (dalam hal ini,) dengan cuplikan kode berikut. `1.33` Nomor versi tidak boleh lebih lambat dari versi Kubernetes dari pesawat kontrol Anda. Ini juga tidak boleh lebih dari dua versi minor lebih awal dari versi Kubernetes dari pesawat kontrol Anda. Kami menyarankan Anda menggunakan versi yang sama dengan pesawat kontrol Anda. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Tainting $node" kubectl taint nodes $node key=value:NoSchedule done ``` 1. Tentukan penyedia DNS cluster Anda. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` Contoh output adalah sebagai berikut. Cluster ini menggunakan CoreDNS untuk resolusi DNS, tetapi klaster Anda dapat kembali sebagai gantinya): `kube-dns` ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Jika deployment Anda saat ini berjalan kurang dari dua replika, skalakan deployment menjadi dua replika. Ganti *coredns* dengan `kubedns` jika output perintah Anda sebelumnya mengembalikannya. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Keluarkan setiap simpul yang Anda ingin hapus dari klaster Anda dengan perintah berikut: ``` kubectl drain node_name --ignore-daemonsets --delete-local-data ``` Jika Anda memutakhirkan node Anda ke versi Kubernetes baru, identifikasi dan tiriskan semua node dari versi Kubernetes tertentu (dalam hal ini,*1.33*) dengan cuplikan kode berikut. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-local-data done ``` 1. Setelah node lama Anda selesai menguras, cabut aturan masuk grup keamanan yang Anda otorisasi sebelumnya. Kemudian, hapus AWS CloudFormation tumpukan untuk mengakhiri instance. **catatan** Jika Anda melampirkan kebijakan IAM tambahan apa pun ke peran IAM grup node lama Anda, seperti menambahkan izin untuk [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), lepaskan kebijakan tambahan tersebut dari peran tersebut sebelum Anda dapat menghapus tumpukan Anda. AWS CloudFormation 1. Cabut aturan masuk yang Anda buat untuk grup keamanan node Anda sebelumnya. Dalam perintah ini, `oldNodes` adalah nama AWS CloudFormation tumpukan untuk tumpukan node lama Anda, dan `newNodes` merupakan nama tumpukan tempat Anda bermigrasi. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 revoke-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Buka [konsol AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/). 1. Pilih tumpukan simpul lama Anda. 1. Pilih **Hapus**. 1. Di kotak dialog **Hapus tumpukan** konfirmasi, pilih **Hapus tumpukan**. 1. Edit `aws-auth` configmap untuk menghapus peran instans simpul lama dari RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Hapus `mapRoles` entri untuk grup simpul lama. ``` apiVersion: v1 data: mapRoles: | - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws: iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> ``` Simpan dan tutup file untuk menerapkan configmap yang diperbarui. 1. (Opsional) Jika Anda menggunakan [Autoscaler Klaster](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) Kubernetes, skalakan kembali deployment ke satu replika. **catatan** Anda juga harus menandai grup Auto Scaling baru Anda dengan tepat (misalnya,`k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`) dan memperbarui perintah untuk penerapan Cluster Autoscaler Anda untuk menunjuk ke grup Auto Scaling yang baru ditandai. Untuk informasi selengkapnya, lihat [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws) di. AWS ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Opsional) Verifikasi bahwa Anda menggunakan versi terbaru dari [plugin Amazon VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) untuk Kubernetes. Anda mungkin perlu memperbarui versi CNI untuk menggunakan jenis instans terbaru yang didukung. Untuk informasi selengkapnya, lihat [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md). 1. Jika klaster Anda menggunakan `kube-dns` resolusi DNS (lihat[[migrate-determine-dns-step]](#migrate-determine-dns-step)), skalakan `kube-dns` penerapan ke satu replika. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` # Perbarui tumpukan AWS CloudFormation simpul Topik ini menjelaskan bagaimana Anda dapat memperbarui tumpukan node yang AWS CloudFormation dikelola sendiri dengan AMI baru. Anda dapat menggunakan prosedur ini untuk memperbarui node Anda ke versi baru Kubernetes setelah pembaruan klaster. Jika tidak, Anda dapat memperbarui ke AMI Amazon EKS terbaru yang dioptimalkan untuk versi Kubernetes yang ada. **penting** Topik ini mencakup pembaruan simpul untuk simpul yang dikelola sendiri. Untuk informasi tentang penggunaan [Simplify node lifecycle dengan grup node terkelola](managed-node-groups.md), lihat. [Memperbarui grup node terkelola untuk klaster Anda](update-managed-node-group.md) AWS CloudFormation Template node Amazon EKS default terbaru dikonfigurasi untuk meluncurkan instance dengan AMI baru ke dalam klaster Anda sebelum menghapus yang lama, satu per satu. Konfigurasi ini memastikan bahwa Anda selalu memiliki jumlah instans aktif yang diinginkan grup Auto Scaling di klaster selama pembaruan bergulir. **catatan** Metode ini tidak didukung untuk grup simpul yang dibuat dengan`eksctl`. Jika Anda membuat grup klaster atau simpul dengan `eksctl`, lihat [Migrasikan aplikasi ke grup node baru](migrate-stack.md). 1. Tentukan penyedia DNS untuk klaster Anda. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` Contoh output adalah sebagai berikut. Cluster ini menggunakan CoreDNS untuk resolusi DNS, tetapi klaster Anda mungkin kembali. `kube-dns` Output Anda mungkin terlihat berbeda tergantung pada versi `kubectl` yang Anda gunakan. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Jika deployment Anda saat ini berjalan kurang dari dua replika, skalakan deployment menjadi dua replika. Ganti *coredns* dengan `kube-dns` jika output perintah Anda sebelumnya mengembalikannya. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. (Opsional) Jika Anda menggunakan Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), turunkan skala deployment ke nol (0) replika untuk menghindari tindakan penskalaan yang bertentangan. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Tentukan jenis instance dan jumlah instans yang diinginkan dari grup node Anda saat ini. Anda memasukkan nilai-nilai ini nanti ketika Anda memperbarui AWS CloudFormation template untuk grup. 1. Buka konsol Amazon EC2 di. https://console.aws.amazon.com/ec2/ 1. Di panel navigasi kiri, pilih **Luncurkan Konfigurasi**, dan catat jenis instans untuk konfigurasi peluncuran node yang ada. 1. **Di panel navigasi kiri, pilih Grup **Auto Scaling**, dan catat jumlah instans yang diinginkan untuk grup Auto Scaling node yang ada.** 1. Buka [konsol AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/). 1. Pilih tumpukan grup simpul Anda, dan kemudian pilih **Perbarui**. 1. Pilih **Ganti template saat ini** dan pilih **URL Amazon S3**. 1. Untuk **URL Amazon S3**, rekatkan URL berikut ke area teks untuk memastikan bahwa Anda menggunakan template node AWS CloudFormation versi terbaru. Kemudian, pilih **Berikutnya**: ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml ``` 1. Pada halaman **Menentukan detail tumpukan**, isilah parameter berikut dan pilih **Selanjutnya**: + **NodeAutoScalingGroupDesiredCapacity**— Masukkan jumlah instans yang diinginkan yang Anda rekam pada [langkah sebelumnya](#existing-worker-settings-step). Atau, masukkan jumlah node baru yang Anda inginkan untuk diskalakan saat tumpukan Anda diperbarui. + **NodeAutoScalingGroupMaxSize**— Masukkan jumlah maksimum node yang dapat diskalakan oleh grup Auto Scaling node Anda. Nilai ini harus setidaknya satu node lebih dari kapasitas yang Anda inginkan. Ini agar Anda dapat melakukan pembaruan bergulir dari node Anda tanpa mengurangi jumlah node Anda selama pembaruan. + **NodeInstanceType**— Pilih jenis instans yang Anda rekam di [langkah sebelumnya](#existing-worker-settings-step). Atau, pilih jenis instance yang berbeda untuk node Anda. Sebelum memilih jenis instans yang berbeda, tinjau [Pilih jenis instans node Amazon EC2 yang optimal](choosing-instance-type.md). Setiap jenis instans Amazon EC2 mendukung jumlah maksimum antarmuka jaringan elastis (antarmuka jaringan) dan setiap antarmuka jaringan mendukung jumlah maksimum alamat IP. Karena setiap node pekerja dan Pod, diberi alamat IP sendiri, penting untuk memilih jenis instance yang akan mendukung jumlah maksimum Pod yang ingin Anda jalankan di setiap node Amazon EC2. Untuk daftar jumlah antarmuka jaringan dan alamat IP yang didukung oleh jenis instans, lihat [alamat IP per antarmuka jaringan per jenis instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Misalnya, tipe `m5.large` instans mendukung maksimal 30 alamat IP untuk node pekerja dan Pod. **catatan** [Tipe instans yang didukung untuk versi terbaru [plugin Amazon VPC CNI untuk Kubernetes ditampilkan di vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s) on.](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) GitHub Anda mungkin perlu memperbarui plugin Amazon VPC CNI untuk versi Kubernetes untuk menggunakan jenis instans terbaru yang didukung. Untuk informasi selengkapnya, lihat [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md). **penting** Beberapa jenis instance mungkin tidak tersedia di semua AWS Wilayah. + **NodeImageIdSSMParam**— Parameter Amazon EC2 Systems Manager dari ID AMI yang ingin Anda perbarui. Nilai berikut menggunakan AMI Amazon EKS terbaru yang dioptimalkan untuk versi Kubernetes. `1.35` ``` /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id ``` Anda dapat mengganti *1.35* dengan [versi platform yang](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) sama. Atau, itu harus hingga satu versi lebih awal dari versi Kubernetes yang berjalan di bidang kontrol Anda. Kami rekomendasikan supaya Anda menyimpan simpul pada versi yang sama dengan bidang kendali Anda. Anda juga dapat mengganti *amazon-linux-2* dengan tipe AMI yang berbeda. Untuk informasi selengkapnya, lihat [Ambil AMI Amazon Linux yang direkomendasikan IDs](retrieve-ami-id.md). **catatan** Menggunakan parameter Amazon EC2 Systems Manager memungkinkan Anda memperbarui node di masa mendatang tanpa harus mencari dan menentukan ID AMI. Jika AWS CloudFormation tumpukan Anda menggunakan nilai ini, setiap pembaruan tumpukan selalu meluncurkan AMI terbaru yang dioptimalkan Amazon EKS yang dioptimalkan untuk versi Kubernetes yang Anda tentukan. Ini bahkan terjadi bahkan jika Anda tidak mengubah nilai apa pun di template. + **NodeImageId**— Untuk menggunakan AMI kustom Anda sendiri, masukkan ID untuk AMI yang akan digunakan. **penting** Nilai ini mengesampingkan nilai apa pun yang ditentukan untuk. **NodeImageIdSSMParam** Jika Anda ingin menggunakan **NodeImageIdSSMParam**nilainya, pastikan nilainya kosong. **NodeImageId** + **Nonaktifkan IMDSv1** — Secara default, setiap node mendukung Layanan Metadata Instans Versi 1 (IMDSv1) dan. IMDSv2 Namun, Anda dapat menonaktifkan IMDSv1. Pilih **true** jika Anda tidak ingin node atau Pod apa pun yang dijadwalkan dalam grup node untuk digunakan IMDSv1. Untuk informasi selengkapnya tentang IMDS, lihat [Mengonfigurasi layanan metadata instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Jika Anda telah menerapkan peran IAM untuk akun layanan, tetapkan izin yang diperlukan secara langsung ke semua Pod yang memerlukan akses ke layanan. AWS Dengan cara ini, tidak ada Pod di klaster Anda yang memerlukan akses ke IMDS karena alasan lain, seperti mengambil Region saat ini AWS . Kemudian, Anda juga dapat menonaktifkan akses ke IMDSv2 Pod yang tidak menggunakan jaringan host. Untuk informasi selengkapnya, lihat [Membatasi akses ke profil instance yang ditetapkan ke node pekerja](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). 1. (Opsional) Di halaman **Opsi**, tandai sumber daya tumpukan Anda. Pilih **Berikutnya**. 1. Pada halaman **Tinjauan**, tinjau informasi Anda, nyatakan bahwa tumpukan dapat membuat sumber daya IAM, kemudian pilih **Perbarui tumpukan**. **catatan** Pembaruan setiap simpul dalam klaster membutuhkan waktu beberapa menit. Tunggu pembaruan semua simpul selesai sebelum melakukan langkah berikutnya. 1. Jika penyedia DNS klaster Anda`kube-dns`, skalakan `kube-dns` penerapan ke satu replika. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` 1. (Opsional) Jika Anda menggunakan [Autoscaler Klaster](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) Kubernetes, skalakan kembali deployment ke jumlah replika yang Anda inginkan. ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Opsional) Verifikasi bahwa Anda menggunakan versi terbaru dari [plugin Amazon VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) untuk Kubernetes. Anda mungkin perlu memperbarui plugin Amazon VPC CNI untuk versi Kubernetes untuk menggunakan jenis instans terbaru yang didukung. Lihat informasi yang lebih lengkap di [Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md).