Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Praktik Terbaik untuk Upgrade Cluster **Tip** [Jelajahi](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) praktik terbaik melalui lokakarya Amazon EKS. Panduan ini menunjukkan kepada administrator klaster cara merencanakan dan menjalankan strategi peningkatan Amazon EKS mereka. Ini juga menjelaskan cara memutakhirkan node yang dikelola sendiri, grup node terkelola, node Karpenter, dan node Fargate. Ini tidak termasuk panduan tentang EKS Anywhere, Kubernetes yang dikelola sendiri, AWS Outposts, atau AWS Local Zones. ## Ikhtisar Versi Kubernetes mencakup bidang kontrol dan bidang data. Untuk memastikan kelancaran operasi, baik bidang kontrol dan bidang data harus menjalankan [versi minor Kubernetes yang sama, seperti](https://kubernetes.io/releases/version-skew-policy/#supported-versions) 1.24. Saat AWS mengelola dan memutakhirkan bidang kontrol, memperbarui node pekerja di bidang data adalah tanggung jawab Anda. + **Control plane** — Versi control plane ditentukan oleh server API Kubernetes. Di kluster Amazon EKS, AWS menangani pengelolaan komponen ini. Upgrade control plane dapat dimulai melalui AWS API. + **Data plane** — Versi data plane dikaitkan dengan versi Kubelet yang berjalan pada node individual Anda. Dimungkinkan untuk memiliki node di cluster yang sama yang menjalankan versi yang berbeda. Anda dapat memeriksa versi semua node dengan menjalankan`kubectl get nodes`. ## Sebelum Upgrade Jika Anda berencana untuk meningkatkan versi Kubernetes Anda di Amazon EKS, ada beberapa kebijakan, alat, dan prosedur penting yang harus Anda lakukan sebelum memulai peningkatan. + **Memahami Kebijakan Penghentian — Dapatkan pemahaman mendalam tentang cara kerja kebijakan penghentian** [Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/). Waspadai perubahan yang akan datang yang dapat memengaruhi aplikasi Anda yang ada. Versi Kubernetes yang lebih baru sering menghapus fitur tertentu APIs , berpotensi menyebabkan masalah untuk menjalankan aplikasi. + **Tinjau Log Perubahan Kubernetes — Tinjau log perubahan** [Kubernetes secara menyeluruh bersama versi [Amazon EKS Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) untuk memahami dampak apa pun yang mungkin terjadi pada klaster Anda, seperti melanggar perubahan](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) yang dapat memengaruhi beban kerja Anda. + **Menilai Kompatibilitas Add-On Cluster** — Amazon EKS tidak secara otomatis memperbarui add-on ketika versi baru dirilis atau setelah Anda memperbarui klaster Anda ke versi minor Kubernetes yang baru. Tinjau [Memperbarui add-on](https://docs.aws.amazon.com/eks/latest/userguide/managing-add-ons.html#updating-an-add-on) untuk memahami kompatibilitas add-on cluster yang ada dengan versi cluster yang ingin Anda tingkatkan. + **Aktifkan Pencatatan Pesawat Kontrol** [— Aktifkan pencatatan](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html) bidang kontrol untuk menangkap log, kesalahan, atau masalah yang dapat muncul selama proses peningkatan. Pertimbangkan untuk meninjau log ini untuk anomali apa pun. Uji peningkatan klaster di lingkungan non-produksi, atau integrasikan pengujian otomatis ke dalam alur kerja integrasi berkelanjutan Anda untuk menilai kompatibilitas versi dengan aplikasi, pengontrol, dan integrasi kustom Anda. + **Jelajahi eksctl untuk Manajemen Cluster — Pertimbangkan untuk** menggunakan [eksctl untuk mengelola kluster EKS](https://eksctl.io/) Anda. Ini memberi Anda kemampuan untuk [memperbarui bidang kontrol, mengelola add-on, dan menangani pembaruan out-of-the-box node pekerja](https://eksctl.io/usage/cluster-upgrade/). + **Pilih Mode Otomatis atau Grup Node Terkelola** — Merampingkan dan mengotomatiskan peningkatan node pekerja dengan menggunakan [Mode Otomatis](https://docs.aws.amazon.com/eks/latest/userguide/automode.html) atau grup node [terkelola EKS](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html). Opsi ini menyederhanakan proses dan mengurangi intervensi manual. + **Manfaatkan kubectl Convert Plugin — Manfaatkan plugin** [kubectl convert untuk memfasilitasi konversi file manifes Kubernetes](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-convert-plugin) di antara versi [API yang berbeda](https://kubernetes.io/docs/tasks/tools/included/kubectl-convert-overview/). Ini dapat membantu memastikan bahwa konfigurasi Anda tetap kompatibel dengan versi Kubernetes yang baru. ## Pertahankan cluster Anda up-to-date Tetap mengikuti pembaruan Kubernetes sangat penting untuk lingkungan EKS yang aman dan efisien, yang mencerminkan model tanggung jawab bersama di Amazon EKS. Dengan mengintegrasikan strategi ini ke dalam alur kerja operasional Anda, Anda memposisikan diri Anda untuk mempertahankan up-to-date, mengamankan klaster yang memanfaatkan sepenuhnya fitur dan peningkatan terbaru. Taktik: + **Kebijakan Versi yang Didukung** - Sejajar dengan komunitas Kubernetes, Amazon EKS biasanya menyediakan tiga versi Kubernetes yang aktif. Versi minor Kubernetes berada di bawah dukungan standar di Amazon EKS selama 14 bulan pertama setelah dirilis. Setelah versi melewati akhir tanggal dukungan standar, ia memasuki dukungan diperpanjang untuk 12 bulan ke depan. Pemberitahuan penghentian dikeluarkan setidaknya 60 hari sebelum versi mencapai akhir tanggal dukungan standar. Untuk detail selengkapnya, lihat dokumen [Siklus Hidup Versi EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). + **Kebijakan Upgrade Otomatis** - Kami sangat menyarankan untuk tetap sinkron dengan pembaruan Kubernetes di kluster EKS Anda. Cluster yang berjalan pada versi Kubernetes yang telah menyelesaikan siklus hidup 26 bulan (14 bulan dukungan standar ditambah 12 bulan dukungan diperpanjang) akan otomatis ditingkatkan ke versi berikutnya. Perhatikan bahwa Anda dapat [menonaktifkan dukungan yang diperluas](https://docs.aws.amazon.com/eks/latest/userguide/disable-extended-support.html). Kegagalan untuk memutakhirkan secara proaktif sebelum versi end-of-life memicu peningkatan otomatis, yang dapat mengganggu beban kerja dan sistem Anda. Untuk informasi tambahan, lihat [Versi EKS FAQs](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#version-faqs). + **Buat Runbook Upgrade** - Buat proses yang terdokumentasi dengan baik untuk mengelola peningkatan. Sebagai bagian dari pendekatan proaktif Anda, kembangkan runbook dan alat khusus yang disesuaikan dengan proses peningkatan Anda. Ini tidak hanya meningkatkan kesiapan Anda tetapi juga menyederhanakan transisi yang kompleks. Jadikan praktik standar untuk meningkatkan cluster Anda setidaknya setahun sekali. Praktik ini menyelaraskan Anda dengan kemajuan teknologi yang sedang berlangsung, sehingga meningkatkan efisiensi dan keamanan lingkungan Anda. ## Tinjau kalender rilis EKS [Tinjau kalender rilis EKS Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar) untuk mempelajari kapan versi baru akan datang, dan kapan dukungan untuk versi tertentu berakhir. Umumnya, EKS merilis tiga versi minor Kubernetes setiap tahunnya, dan setiap versi minor didukung selama sekitar 14 bulan. Selain itu, tinjau informasi rilis [Kubernetes](https://kubernetes.io/releases/) hulu. ## Memahami bagaimana model tanggung jawab bersama berlaku untuk peningkatan klaster Anda bertanggung jawab untuk memulai upgrade untuk kedua bidang kontrol cluster serta bidang data. [Pelajari cara memulai pemutakhiran.](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html) Saat Anda memulai pemutakhiran klaster, AWS mengelola pemutakhiran bidang kontrol cluster. [Anda bertanggung jawab untuk meningkatkan pesawat data, termasuk pod dan addon Fargate.](#upgrade-addons) Anda harus memvalidasi dan merencanakan peningkatan untuk beban kerja yang berjalan di klaster Anda untuk memastikan ketersediaan dan operasinya tidak terpengaruh setelah peningkatan klaster ## Tingkatkan cluster di tempat EKS mendukung strategi peningkatan cluster di tempat. Ini mempertahankan sumber daya klaster, dan menjaga konfigurasi klaster tetap konsisten (misalnya, titik akhir API, OIDC, ENIs, penyeimbang beban). Ini tidak terlalu mengganggu bagi pengguna klaster, dan akan menggunakan beban kerja dan sumber daya yang ada di klaster tanpa mengharuskan Anda menerapkan ulang beban kerja atau memigrasikan sumber daya eksternal (misalnya, DNS, penyimpanan). Saat melakukan peningkatan cluster di tempat, penting untuk dicatat bahwa hanya satu peningkatan versi minor yang dapat dijalankan pada satu waktu (misalnya, dari 1,24 hingga 1,25). Ini berarti bahwa jika Anda perlu memperbarui beberapa versi, serangkaian peningkatan berurutan akan diperlukan. Merencanakan peningkatan berurutan lebih rumit, dan memiliki risiko downtime yang lebih tinggi. Dalam situasi ini, lihat[Evaluasi Blue/Green Cluster sebagai alternatif untuk peningkatan klaster di tempat](#bluegreen). ## Tingkatkan bidang kontrol dan bidang data Anda secara berurutan Untuk memutakhirkan cluster, Anda perlu melakukan tindakan berikut: 1. [Tinjau catatan rilis Kubernetes dan EKS.](#usedocs) 1. [Ambil cadangan dari cluster. (opsional)](#backup-the-cluster-before-upgrading) 1. [Mengidentifikasi dan memulihkan penggunaan API yang tidak digunakan lagi dan dihapus di beban kerja Anda.](#identify-and-remediate-removed-api-usage-before-upgrading-the-control-plane) 1. [Pastikan Managed Node Groups, jika digunakan, berada pada versi Kubernetes yang sama dengan control plane.](#node-compatibility) Grup node dan node terkelola EKS yang dibuat oleh EKS Fargate Profiles mendukung 2 versi minor yang miring antara bidang kontrol dan bidang data untuk Kubernetes versi 1.27 ke bawah. Mulai 1,28 ke atas, grup node dan node yang dikelola EKS yang dibuat oleh EKS Fargate Profiles mendukung 3 versi minor miring antara bidang kontrol dan bidang data. Misalnya, jika versi bidang kontrol EKS Anda adalah 1,28, Anda dapat menggunakan versi kubelet dengan aman setua 1,25. Jika versi EKS Anda adalah 1.27, versi kubelet tertua yang dapat Anda gunakan adalah 1.25. 1. [Tingkatkan bidang kontrol cluster menggunakan konsol AWS atau cli.](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html) 1. [Tinjau kompatibilitas add-on.](#upgrade-addons) Tingkatkan add-on Kubernetes dan pengontrol kustom Anda, sesuai kebutuhan. 1. [Perbarui kubectl.](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) 1. [Tingkatkan bidang data cluster.](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html) Tingkatkan node Anda ke versi minor Kubernetes yang sama dengan klaster yang telah Anda upgrade. **Tip** Jika cluster Anda dibuat menggunakan Mode Otomatis EKS, Anda tidak perlu memutakhirkan bidang data cluster Anda. Setelah memutakhirkan bidang kontrol Anda, Mode Otomatis EKS akan mulai memperbarui node terkelola secara bertahap sambil menghormati semua anggaran gangguan pod. Pastikan untuk memantau pembaruan ini untuk memverifikasi kepatuhan terhadap persyaratan operasional Anda. ## Gunakan Dokumentasi EKS untuk membuat daftar periksa pemutakhiran [Dokumentasi versi](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) EKS Kubernetes mencakup daftar perubahan terperinci untuk setiap versi. Buat daftar periksa untuk setiap peningkatan. Untuk panduan peningkatan versi EKS tertentu, tinjau dokumentasi untuk perubahan dan pertimbangan penting untuk setiap versi. + [Tinjau catatan rilis untuk versi Kubernetes pada dukungan standar](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-standard.html) + [Tinjau catatan rilis untuk versi Kubernetes pada dukungan yang diperluas](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-extended.html) ## Upgrade add-on dan komponen menggunakan Kubernetes API Sebelum Anda meng-upgrade klaster, Anda harus memahami versi komponen Kubernetes yang Anda gunakan. Inventarisasi komponen klaster, dan identifikasi komponen yang menggunakan API Kubernetes secara langsung. Ini termasuk komponen kluster penting seperti agen pemantauan dan logging, autoscaler cluster, driver penyimpanan kontainer (misalnya [EBS CSI, [EFS CSI](https://docs.aws.amazon.com/eks/latest/userguide/efs-csi.html)),](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) pengontrol ingress, dan beban kerja atau add-on lainnya yang bergantung pada Kubernetes API secara langsung. **Tip** Komponen cluster kritis sering dipasang di `*-system` namespace ``` kubectl get ns | grep '-system' ``` Setelah Anda mengidentifikasi komponen yang mengandalkan API Kubernetes, periksa dokumentasi mereka untuk kompatibilitas versi dan persyaratan peningkatan. Misalnya, lihat dokumentasi [AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/deploy/installation/) untuk kompatibilitas versi. Beberapa komponen mungkin perlu ditingkatkan atau konfigurasi diubah sebelum melanjutkan dengan upgrade cluster. Beberapa komponen penting yang harus diperiksa termasuk [CoreDNS](https://github.com/coredns/coredns), [kube-proxy](https://kubernetes.io/docs/concepts/overview/components/#kube-proxy), [VPC](https://github.com/aws/amazon-vpc-cni-k8s) CNI, dan driver penyimpanan. Cluster sering berisi banyak beban kerja yang menggunakan API Kubernetes dan diperlukan untuk fungsionalitas beban kerja seperti pengontrol ingress, sistem pengiriman berkelanjutan, dan alat pemantauan. Saat Anda memutakhirkan kluster EKS, Anda juga harus meningkatkan add-on dan alat pihak ketiga untuk memastikannya kompatibel. Lihat contoh add-on umum berikut dan dokumentasi pemutakhiran yang relevan: + **Amazon VPC CNI:** Untuk versi yang direkomendasikan dari add-on Amazon VPC CNI untuk setiap versi cluster, lihat Memperbarui plugin [Amazon VPC CNI untuk add-on yang dikelola sendiri Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html). **Ketika diinstal sebagai Amazon EKS Add-on, itu hanya dapat ditingkatkan satu versi minor pada satu waktu.** + **kube-proxy:** Lihat [Memperbarui add-on yang dikelola sendiri kube-proxy Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/managing-kube-proxy.html). + **CoreDNS: Lihat [Memperbarui add-on yang dikelola sendiri CoreDNS](https://docs.aws.amazon.com/eks/latest/userguide/managing-coredns.html)**. + **AWS Load Balancer Controller:** AWS Load Balancer Controller harus kompatibel dengan versi EKS yang telah Anda gunakan. Lihat [panduan instalasi](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html) untuk informasi lebih lanjut. + Driver **Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI): Untuk informasi instalasi dan peningkatan, lihat Mengelola driver** [Amazon EBS CSI sebagai add-on Amazon](https://docs.aws.amazon.com/eks/latest/userguide/managing-ebs-csi.html) EKS. + Driver **Amazon Elastic File System (Amazon EFS) Container Storage Interface (CSI): Untuk informasi penginstalan dan peningkatan, lihat driver** [Amazon EFS CSI](https://docs.aws.amazon.com/eks/latest/userguide/efs-csi.html). + **Kubernetes Metrics Server:** [Untuk informasi selengkapnya, lihat metrics-server di.](https://kubernetes-sigs.github.io/metrics-server/) GitHub + **Kubernetes Cluster Autoscaler:** Untuk memutakhirkan versi Kubernetes Cluster Autoscaler, ubah versi gambar dalam penerapan. Cluster Autoscaler digabungkan erat dengan penjadwal Kubernetes. Anda akan selalu perlu untuk meng-upgrade ketika Anda meng-upgrade cluster. Tinjau [GitHub rilis](https://github.com/kubernetes/autoscaler/releases) untuk menemukan alamat rilis terbaru yang sesuai dengan versi minor Kubernetes Anda. + **Karpenter:** Untuk informasi instalasi dan peningkatan, lihat dokumentasi [Karpenter](https://karpenter.sh/docs/upgrading/). **Tip** Anda tidak perlu memutakhirkan kemampuan Amazon EKS Auto Mode secara manual, termasuk kemampuan penskalaan otomatis komputasi, penyimpanan blok, dan penyeimbangan beban. ## Verifikasi persyaratan EKS dasar sebelum meningkatkan AWS memerlukan sumber daya tertentu di akun Anda untuk menyelesaikan proses peningkatan. Jika sumber daya ini tidak ada, klaster tidak dapat ditingkatkan. Upgrade pesawat kontrol membutuhkan sumber daya berikut: 1. Alamat IP yang tersedia: Amazon EKS memerlukan hingga lima alamat IP yang tersedia dari subnet yang Anda tentukan saat membuat cluster untuk memperbarui cluster. Jika tidak, perbarui konfigurasi klaster Anda untuk menyertakan subnet klaster baru sebelum melakukan pembaruan versi. 1. Peran EKS IAM: Peran IAM bidang kontrol masih ada di akun dengan izin yang diperlukan. 1. Jika kluster Anda mengaktifkan enkripsi rahasia, pastikan peran IAM cluster memiliki izin untuk menggunakan kunci AWS Key Management Service (AWS KMS). ### Verifikasi alamat IP yang tersedia Untuk memperbarui klaster, Amazon EKS memerlukan hingga lima alamat IP yang tersedia dari subnet yang Anda tentukan saat membuat klaster. Untuk memverifikasi bahwa subnet Anda memiliki alamat IP yang cukup untuk meng-upgrade cluster, Anda dapat menjalankan perintah berikut: ``` CLUSTER= aws ec2 describe-subnets --subnet-ids \ $(aws eks describe-cluster --name ${CLUSTER} \ --query 'cluster.resourcesVpcConfig.subnetIds' \ --output text) \ --query 'Subnets[*].[SubnetId,AvailabilityZone,AvailableIpAddressCount]' \ --output table ---------------------------------------------------- | DescribeSubnets | +---------------------------+--------------+-------+ | subnet-067fa8ee8476abbd6 | us-east-1a | 8184 | | subnet-0056f7403b17d2b43 | us-east-1b | 8153 | | subnet-09586f8fb3addbc8c | us-east-1a | 8120 | | subnet-047f3d276a22c6bce | us-east-1b | 8184 | +---------------------------+--------------+-------+ ``` [Pembantu Metrik CNI VPC](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md) dapat digunakan untuk membuat dasbor CloudWatch metrik VPC. Amazon EKS merekomendasikan untuk memperbarui subnet cluster menggunakan "UpdateClusterConfiguration" API sebelum memulai upgrade versi Kubernetes jika Anda kehabisan alamat IP di subnet yang awalnya ditentukan selama pembuatan klaster. Harap verifikasi bahwa subnet baru Anda akan diberikan: + milik set yang sama AZs yang dipilih selama pembuatan cluster. + milik VPC yang sama yang disediakan selama pembuatan cluster Harap pertimbangkan untuk mengaitkan blok CIDR tambahan jika alamat IP di blok CIDR VPC yang ada habis. AWS memungkinkan asosiasi blok CIDR tambahan dengan VPC klaster Anda yang ada, yang secara efektif memperluas kumpulan alamat IP Anda. Ekspansi ini dapat dicapai dengan memperkenalkan rentang IP pribadi tambahan (RFC 1918) atau, jika perlu, rentang IP publik (non-RFC 1918). Anda harus menambahkan blok CIDR VPC baru dan mengizinkan penyegaran VPC selesai sebelum Amazon EKS dapat menggunakan CIDR baru. Setelah itu, Anda dapat memperbarui subnet berdasarkan blok CIDR yang baru disiapkan ke VPC. ### Verifikasi peran EKS IAM Untuk memverifikasi bahwa peran IAM tersedia dan memiliki kebijakan peran asumsi yang benar di akun Anda, Anda dapat menjalankan perintah berikut: ``` CLUSTER= ROLE_ARN=$(aws eks describe-cluster --name ${CLUSTER} \ --query 'cluster.roleArn' --output text) aws iam get-role --role-name ${ROLE_ARN##*/} \ --query 'Role.AssumeRolePolicyDocument' { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ## Migrasi ke Pengaya EKS Amazon EKS secara otomatis menginstal add-on seperti plugin Amazon VPC CNI untuk Kubernetes, `kube-proxy` dan CoreDNS untuk setiap cluster. Add-on dapat dikelola sendiri, atau diinstal sebagai Amazon EKS Add-on. Amazon EKS Add-ons adalah cara alternatif untuk mengelola add-on menggunakan EKS API. Anda dapat menggunakan Amazon EKS Add-on untuk memperbarui versi dengan satu perintah. Sebagai Contoh: ``` aws eks update-addon —cluster-name my-cluster —addon-name vpc-cni —addon-version version-number \ --service-account-role-arn arn:aws:iam::111122223333:role/role-name —configuration-values '{}' —resolve-conflicts PRESERVE ``` Periksa apakah Anda memiliki Pengaya EKS dengan: ``` aws eks list-addons --cluster-name ``` **Awas** Pengaya EKS tidak ditingkatkan secara otomatis selama upgrade pesawat kontrol. Anda harus memulai pembaruan add-on EKS, dan memilih versi yang diinginkan. + Anda bertanggung jawab untuk memilih versi yang kompatibel dari semua versi yang tersedia. [Tinjau panduan tentang kompatibilitas versi add-on.](#upgrade-addons) + Amazon EKS Add-on hanya dapat ditingkatkan satu versi minor pada satu waktu. [Pelajari lebih lanjut tentang komponen apa saja yang tersedia sebagai Pengaya EKS, dan cara memulainya.](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html) [Pelajari cara menyediakan konfigurasi kustom ke Add-on EKS.](https://aws.amazon.com/blogs/containers/amazon-eks-add-ons-advanced-configuration/) ## Mengidentifikasi dan memulihkan penggunaan API yang dihapus sebelum memutakhirkan bidang kontrol Anda harus mengidentifikasi penggunaan API yang dihapus APIs sebelum memutakhirkan bidang kontrol EKS Anda. Untuk melakukan itu, kami sarankan menggunakan alat yang dapat memeriksa cluster yang sedang berjalan atau file manifes Kubernetes statis yang dirender. Menjalankan pemeriksaan terhadap file manifes statis umumnya lebih akurat. Jika dijalankan terhadap klaster langsung, alat ini dapat mengembalikan positif palsu. Kubernetes API yang sudah usang tidak berarti API telah dihapus. Anda harus memeriksa [Kebijakan Penghentian Kubernetes untuk memahami bagaimana penghapusan](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) API memengaruhi beban kerja Anda. ### Wawasan Cluster [Cluster Insights](https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html) adalah fitur yang memberikan temuan tentang masalah yang dapat memengaruhi kemampuan untuk meningkatkan kluster EKS ke versi Kubernetes yang lebih baru. Temuan ini dikuratori dan dikelola oleh Amazon EKS dan menawarkan rekomendasi tentang cara memperbaikinya. Dengan memanfaatkan Cluster Insights, Anda dapat meminimalkan upaya yang dihabiskan untuk meningkatkan ke versi Kubernetes yang lebih baru. Untuk melihat wawasan cluster EKS, Anda dapat menjalankan perintah: ``` aws eks list-insights --region --cluster-name { "insights": [ { "category": "UPGRADE_READINESS", "name": "Deprecated APIs removed in Kubernetes v1.29", "insightStatus": { "status": "PASSING", "reason": "No deprecated API usage detected within the last 30 days." }, "kubernetesVersion": "1.29", "lastTransitionTime": 1698774710.0, "lastRefreshTime": 1700157422.0, "id": "123e4567-e89b-42d3-a456-579642341238", "description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes v1.29. Upgrading your cluster before migrating to the updated APIs supported by v1.29 could cause application impact." } ] } ``` Untuk keluaran yang lebih deskriptif tentang wawasan yang diterima, Anda dapat menjalankan perintah: ``` aws eks describe-insight --region --id --cluster-name ``` Anda juga memiliki opsi untuk melihat wawasan di [Konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). Setelah memilih klaster Anda dari daftar klaster, temuan wawasan terletak di bawah `Upgrade Insights` tab. Jika Anda menemukan wawasan cluster dengan`"status": ERROR`, Anda harus mengatasi masalah sebelum melakukan upgrade cluster. Jalankan `aws eks describe-insight` perintah yang akan membagikan saran remediasi berikut: Sumber daya yang terpengaruh: ``` "resources": [ { "insightStatus": { "status": "ERROR" }, "kubernetesResourceUri": "/apis/policy/v1beta1/podsecuritypolicies/null" } ] ``` APIs usang: ``` "deprecationDetails": [ { "usage": "/apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas", "replacedWith": "/apis/flowcontrol.apiserver.k8s.io/v1beta3/flowschemas", "stopServingVersion": "1.29", "clientStats": [], "startServingReplacementVersion": "1.26" } ] ``` Tindakan yang disarankan untuk diambil: ``` "recommendation": "Update manifests and API clients to use newer Kubernetes APIs if applicable before upgrading to Kubernetes v1.26." ``` Memanfaatkan wawasan cluster melalui Konsol EKS atau CLI membantu mempercepat proses peningkatan versi kluster EKS yang berhasil. Pelajari lebih lanjut dengan sumber daya berikut: \$1 [Dokumen EKS Resmi](https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html) \$1 Blog [peluncuran Cluster Insights](https://aws.amazon.com/blogs/containers/accelerate-the-testing-and-verification-of-amazon-eks-upgrades-with-upgrade-insights/). ### K ube-no-trouble [K ube-no-trouble](https://github.com/doitintl/kube-no-trouble) adalah utilitas baris perintah open source dengan perintah`kubent`. Ketika Anda menjalankan `kubent` tanpa argumen apa pun, itu akan menggunakan KubeConfig konteks Anda saat ini dan memindai cluster dan mencetak laporan dengan apa yang APIs akan ditinggalkan dan dihapus. ``` kubent 4:17PM INF >>> Kube No Trouble `kubent` <<< 4:17PM INF version 0.7.0 (git sha d1bb4e5fd6550b533b2013671aa8419d923ee042) 4:17PM INF Initializing collectors and retrieving data 4:17PM INF Target K8s version is 1.24.8-eks-ffeb93d 4:l INF Retrieved 93 resources from collector name=Cluster 4:17PM INF Retrieved 16 resources from collector name="Helm v3" 4:17PM INF Loaded ruleset name=custom.rego.tmpl 4:17PM INF Loaded ruleset name=deprecated-1-16.rego 4:17PM INF Loaded ruleset name=deprecated-1-22.rego 4:17PM INF Loaded ruleset name=deprecated-1-25.rego 4:17PM INF Loaded ruleset name=deprecated-1-26.rego 4:17PM INF Loaded ruleset name=deprecated-future.rego __________________________________________________________________________________________ >>> Deprecated APIs removed in 1.25 <<< ------------------------------------------------------------------------------------------ KIND NAMESPACE NAME API_VERSION REPLACE_WITH (SINCE) PodSecurityPolicy eks.privileged policy/v1beta1 (1.21.0) ``` Hal ini juga dapat digunakan untuk memindai file manifes statis dan paket helm. Disarankan untuk dijalankan `kubent` sebagai bagian dari proses integrasi berkelanjutan (CI) untuk mengidentifikasi masalah sebelum manifes digunakan. Manifestasi pemindaian juga lebih akurat daripada memindai cluster langsung. Kube-no-trouble menyediakan contoh [Akun Layanan dan Peran](https://github.com/doitintl/kube-no-trouble/blob/master/docs/k8s-sa-and-role-example.yaml) dengan izin yang sesuai untuk memindai klaster. ### Pluto Pilihan lain adalah [pluto](https://pluto.docs.fairwinds.com/) yang mirip dengan `kubent` karena mendukung pemindaian cluster langsung, file manifes, bagan helm dan memiliki GitHub Tindakan yang dapat Anda sertakan dalam proses CI Anda. ``` pluto detect-all-in-cluster NAME KIND VERSION REPLACEMENT REMOVED DEPRECATED REPL AVAIL eks.privileged PodSecurityPolicy policy/v1beta1 false true true ``` ### Sumber daya Untuk memverifikasi bahwa klaster Anda tidak menggunakan usang APIs sebelum pemutakhiran, Anda harus memantau: + metrik `apiserver_requested_deprecated_apis` sejak Kubernetes v1.19: ``` kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis apiserver_requested_deprecated_apis{group="policy",removed_release="1.25",resource="podsecuritypolicies",subresource="",version="v1beta1"} 1 ``` + peristiwa di [log audit](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html) dengan `k8s.io/deprecated` disetel ke`true`: ``` CLUSTER="" QUERY_ID=$(aws logs start-query \ --log-group-name /aws/eks/${CLUSTER}/cluster \ --start-time $(date -u --date="-30 minutes" "+%s") # or date -v-30M "+%s" on MacOS \ --end-time $(date "+%s") \ --query-string 'fields @message | filter `annotations.k8s.io/deprecated`="true"' \ --query queryId --output text) echo "Query started (query id: $QUERY_ID), please hold ..." && sleep 5 # give it some time to query aws logs get-query-results --query-id $QUERY_ID ``` Yang akan menampilkan baris jika usang APIs sedang digunakan: ``` { "results": [ [ { "field": "@message", "value": "{\"kind\":\"Event\",\"apiVersion\":\"audit.k8s.io/v1\",\"level\":\"Request\",\"auditID\":\"8f7883c6-b3d5-42d7-967a-1121c6f22f01\",\"stage\":\"ResponseComplete\",\"requestURI\":\"/apis/policy/v1beta1/podsecuritypolicies?allowWatchBookmarks=true\\u0026resourceVersion=4131\\u0026timeout=9m19s\\u0026timeoutSeconds=559\\u0026watch=true\",\"verb\":\"watch\",\"user\":{\"username\":\"system:apiserver\",\"uid\":\"8aabfade-da52-47da-83b4-46b16cab30fa\",\"groups\":[\"system:masters\"]},\"sourceIPs\":[\"::1\"],\"userAgent\":\"kube-apiserver/v1.24.16 (linux/amd64) kubernetes/af930c1\",\"objectRef\":{\"resource\":\"podsecuritypolicies\",\"apiGroup\":\"policy\",\"apiVersion\":\"v1beta1\"},\"responseStatus\":{\"metadata\":{},\"code\":200},\"requestReceivedTimestamp\":\"2023-10-04T12:36:11.849075Z\",\"stageTimestamp\":\"2023-10-04T12:45:30.850483Z\",\"annotations\":{\"authorization.k8s.io/decision\":\"allow\",\"authorization.k8s.io/reason\":\"\",\"k8s.io/deprecated\":\"true\",\"k8s.io/removed-release\":\"1.25\"}}" }, [...] ``` ## Perbarui beban kerja Kubernetes. Gunakan kubectl-convert untuk memperbarui manifes Setelah Anda mengidentifikasi beban kerja dan manifes apa yang perlu diperbarui, Anda mungkin perlu mengubah jenis sumber daya dalam file manifes Anda (misalnya PodSecurityPolicies ke PodSecurityStandards). Ini akan membutuhkan pembaruan spesifikasi sumber daya dan penelitian tambahan tergantung pada sumber daya apa yang sedang diganti. Jika jenis sumber daya tetap sama tetapi versi API perlu diperbarui, Anda dapat menggunakan `kubectl-convert` perintah untuk mengonversi file manifes secara otomatis. Misalnya, untuk mengonversi Deployment yang lebih lama menjadi`apps/v1`. Untuk informasi selengkapnya, lihat [Menginstal kubectl convert plugin](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-convert-plugin) di situs web Kubernetes. `kubectl-convert -f --output-version /` ## topologySpreadConstraints Konfigurasikan PodDisruptionBudgets dan untuk memastikan ketersediaan beban kerja Anda saat bidang data ditingkatkan Pastikan beban kerja Anda sesuai [PodDisruptionBudgets](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets)dan [topologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints)untuk memastikan ketersediaan beban kerja Anda saat bidang data ditingkatkan. Tidak setiap beban kerja membutuhkan tingkat ketersediaan yang sama sehingga Anda perlu memvalidasi skala dan persyaratan beban kerja Anda. Pastikan beban kerja tersebar di beberapa Availability Zone dan pada beberapa host dengan spread topologi akan memberikan tingkat kepercayaan yang lebih tinggi bahwa beban kerja akan bermigrasi ke bidang data baru secara otomatis tanpa insiden. Berikut adalah contoh beban kerja yang akan selalu memiliki 80% replika yang tersedia dan menyebarkan replika di seluruh zona dan host ``` apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: myapp spec: minAvailable: "80%" selector: matchLabels: app: myapp --- apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: replicas: 10 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - image: public.ecr.aws/eks-distro/kubernetes/pause:3.2 name: myapp resources: requests: cpu: "1" memory: 256M topologySpreadConstraints: - labelSelector: matchLabels: app: host-zone-spread maxSkew: 2 topologyKey: kubernetes.io/hostname whenUnsatisfiable: DoNotSchedule - labelSelector: matchLabels: app: host-zone-spread maxSkew: 2 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule ``` [AWS Resilience Hub](https://aws.amazon.com/resilience-hub/) telah menambahkan Amazon Elastic Kubernetes Service (Amazon EKS) sebagai sumber daya yang didukung. Resilience Hub menyediakan satu tempat untuk menentukan, memvalidasi, dan melacak ketahanan aplikasi Anda sehingga Anda dapat menghindari downtime yang tidak perlu yang disebabkan oleh gangguan perangkat lunak, infrastruktur, atau operasional. ## Gunakan Grup Node Terkelola atau Karpenter untuk menyederhanakan peningkatan pesawat data Grup Node Terkelola dan Karpenter keduanya menyederhanakan peningkatan node, tetapi mereka mengambil pendekatan yang berbeda. Grup node terkelola mengotomatiskan penyediaan dan manajemen siklus hidup node. Ini berarti Anda dapat membuat, memperbarui, atau menghentikan node secara otomatis dengan satu operasi. Dalam konfigurasi default, Karpenter secara otomatis membuat node baru menggunakan EKS Optimized AMI terbaru yang kompatibel. Saat EKS merilis EKS Optimized yang diperbarui AMIs atau cluster ditingkatkan, Karpenter akan secara otomatis mulai menggunakan gambar-gambar ini. [Karpenter juga mengimplementasikan Node Expiry untuk memperbarui node.](#enable-node-expiry-for-karpenter-managed-nodes) [Karpenter dapat dikonfigurasi untuk menggunakan kustom. AMIs](https://karpenter.sh/docs/concepts/nodeclasses/) Jika Anda menggunakan custom AMIs dengan Karpenter, Anda bertanggung jawab atas versi kubelet. ## Konfirmasikan kompatibilitas versi dengan node yang ada dan bidang kontrol Sebelum melanjutkan dengan upgrade Kubernetes di Amazon EKS, penting untuk memastikan kompatibilitas antara grup node terkelola, node yang dikelola sendiri, dan bidang kontrol. Kompatibilitas ditentukan oleh versi Kubernetes yang Anda gunakan, dan itu bervariasi berdasarkan skenario yang berbeda. Taktik: + **Kubernetes v1.28\$1** — **\$1 \$1** Mulai dari Kubernetes versi 1.28 dan seterusnya, ada kebijakan versi yang lebih lunak untuk komponen inti. Secara khusus, kemiringan yang didukung antara server API Kubernetes dan kubelet telah diperluas oleh satu versi minor, dari n-2 ke n-3. Misalnya, jika versi bidang kontrol EKS Anda adalah 1,28, Anda dapat menggunakan versi kubelet dengan aman setua 1,25. [Versi miring ini didukung di seluruh AWS [Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html), [grup node terkelola, dan node yang dikelola](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) sendiri.](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) Kami sangat menyarankan untuk menyimpan versi [Amazon Machine Image (AMI)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-amis.html) Anda up-to-date untuk alasan keamanan. Versi kubelet yang lebih lama mungkin menimbulkan risiko keamanan karena potensi Kerentanan Umum dan Eksposur (CVEs), yang bisa lebih besar daripada manfaat menggunakan versi kubelet yang lebih lama. + **Kubernetes < v1.28** - Jika Anda menggunakan versi yang lebih lama dari v1.28, kemiringan yang didukung antara server API dan kubelet adalah n-2. Misalnya, jika versi EKS Anda adalah 1.27, versi kubelet tertua yang dapat Anda gunakan adalah 1.25. [Kemiringan versi ini berlaku di seluruh AWS [Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html), [grup node terkelola, dan node yang dikelola](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) sendiri.](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) ## Aktifkan kedaluwarsa node untuk node terkelola Karpenter Salah satu cara Karpenter mengimplementasikan upgrade node adalah menggunakan konsep node expiry. Ini mengurangi perencanaan yang diperlukan untuk peningkatan node. Saat Anda menetapkan nilai untuk **ttlSecondsUntilExpired** di penyedia Anda, ini mengaktifkan kedaluwarsa node. Setelah node mencapai usia yang ditentukan dalam hitungan detik, node tersebut terkuras dan dihapus dengan aman. Ini benar bahkan jika sedang digunakan, memungkinkan Anda untuk mengganti node dengan instance upgrade yang baru disediakan. Ketika sebuah node diganti, Karpenter menggunakan EKS terbaru yang dioptimalkan. AMIs Untuk informasi lebih lanjut, lihat [Deprovisioning](https://karpenter.sh/docs/concepts/deprovisioning/#methods) di situs web Karpenter. Karpenter tidak secara otomatis menambahkan jitter ke nilai ini. Untuk mencegah gangguan beban kerja yang berlebihan, tentukan [anggaran gangguan pod](https://kubernetes.io/docs/tasks/run-application/configure-pdb/), seperti yang ditunjukkan dalam dokumentasi Kubernetes. Jika Anda mengonfigurasi **ttlSecondsUntilKedaluwarsa** pada penyedia, ini berlaku untuk node yang ada yang terkait dengan penyedia. ## Gunakan fitur Drift untuk node terkelola Karpenter [Fitur Drift Karpenter](https://karpenter.sh/docs/concepts/deprovisioning/#drift) dapat secara otomatis meningkatkan node yang disediakan Karpenter agar tetap sinkron dengan bidang kontrol EKS. [Karpenter Drift saat ini perlu diaktifkan menggunakan gerbang fitur.](https://karpenter.sh/docs/concepts/settings/#feature-gates) Konfigurasi default Karpenter menggunakan AMI terbaru yang dioptimalkan EKS untuk versi mayor dan minor yang sama dengan bidang kontrol kluster EKS. Setelah upgrade EKS Cluster selesai, fitur Drift Karpenter akan mendeteksi bahwa node yang disediakan Karpenter menggunakan EKS yang dioptimalkan AMIs untuk versi cluster sebelumnya, dan secara otomatis mengikat, menguras, dan mengganti node tersebut. Untuk mendukung pod pindah ke node baru, ikuti praktik terbaik Kubernetes dengan menetapkan [kuota sumber daya pod yang sesuai](https://kubernetes.io/docs/concepts/policy/resource-quotas/), dan menggunakan anggaran [gangguan pod](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) (PDB). Deprovisioning Karpenter akan melakukan pra-putaran node pengganti berdasarkan permintaan sumber daya pod, dan akan menghormati saat melakukan deprovisioning node. PDBs ## Gunakan eksctl untuk mengotomatiskan peningkatan untuk grup node yang dikelola sendiri Grup node yang dikelola sendiri adalah instans EC2 yang digunakan di akun Anda dan dilampirkan ke cluster di luar layanan EKS. Ini biasanya digunakan dan dikelola oleh beberapa bentuk perkakas otomatisasi. Untuk memutakhirkan grup node yang dikelola sendiri, Anda harus merujuk ke dokumentasi alat Anda. Misalnya, eksctl mendukung [penghapusan dan pengeringan node yang dikelola](https://eksctl.io/usage/managing-nodegroups/#deleting-and-draining) sendiri. Beberapa alat umum meliputi: + [eksctl](https://eksctl.io/usage/nodegroup-upgrade/) + [KOP](https://kops.sigs.k8s.io/operations/updates_and_upgrades/) + [Cetak Biru EKS](https://aws-ia.github.io/terraform-aws-eks-blueprints/node-groups/#self-managed-node-groups) ## Backup cluster sebelum upgrade Versi baru Kubernetes memperkenalkan perubahan signifikan pada klaster Amazon EKS Anda. Setelah Anda memutakhirkan klaster, Anda tidak dapat menurunkannya. [Velero](https://velero.io/) adalah alat sumber terbuka yang didukung komunitas yang dapat digunakan untuk mengambil cadangan cluster yang ada dan menerapkan cadangan ke cluster baru. Perhatikan bahwa Anda hanya dapat membuat cluster baru untuk versi Kubernetes yang saat ini didukung oleh EKS. Jika versi yang sedang dijalankan klaster Anda masih didukung dan pemutakhiran gagal, Anda dapat membuat klaster baru dengan versi asli dan memulihkan bidang data. Perhatikan bahwa sumber daya AWS, termasuk IAM, tidak disertakan dalam cadangan oleh Velero. Sumber daya ini perlu diciptakan kembali. ## Mulai ulang penerapan Fargate setelah memutakhirkan bidang kontrol Untuk memutakhirkan node bidang data Fargate, Anda perlu menerapkan kembali beban kerja. Anda dapat mengidentifikasi beban kerja mana yang berjalan pada node fargate dengan mencantumkan semua pod dengan opsi tersebut. `-o wide` Setiap nama node yang dimulai dengan `fargate-` perlu digunakan kembali di cluster. ## Evaluasi Blue/Green Cluster sebagai alternatif untuk peningkatan klaster di tempat Beberapa pelanggan lebih suka melakukan strategi blue/green upgrade. Ini dapat memiliki manfaat, tetapi juga termasuk kerugian yang harus dipertimbangkan. Manfaatnya meliputi: + Kemungkinan untuk mengubah beberapa versi EKS sekaligus (misalnya 1.23 ke 1.25) + Mampu beralih kembali ke cluster lama + Membuat cluster baru yang dapat dikelola dengan sistem yang lebih baru (misalnya terraform) + Beban kerja dapat dimigrasikan secara individual Beberapa kelemahan meliputi: + Titik akhir API dan perubahan OIDC yang memerlukan pembaruan konsumen (misalnya kubectl dan CI/CD) + Membutuhkan 2 cluster untuk dijalankan secara paralel selama migrasi, yang bisa mahal dan membatasi kapasitas wilayah + Diperlukan lebih banyak koordinasi jika beban kerja saling bergantung satu sama lain untuk dimigrasikan bersama + Load balancer dan DNS eksternal tidak dapat dengan mudah menjangkau beberapa cluster Meskipun strategi ini mungkin dilakukan, ini lebih mahal daripada peningkatan di tempat dan membutuhkan lebih banyak waktu untuk koordinasi dan migrasi beban kerja. Ini mungkin diperlukan dalam beberapa situasi dan harus direncanakan dengan hati-hati. Dengan otomatisasi tingkat tinggi dan sistem deklaratif seperti GitOps, ini mungkin lebih mudah dilakukan. Anda perlu mengambil tindakan pencegahan tambahan untuk beban kerja stateful sehingga data dicadangkan dan dimigrasikan ke cluster baru. Tinjau posting blog ini untuk informasi lebih lanjut: + [Peningkatan klaster Kubernetes: strategi penerapan biru-hijau](https://aws.amazon.com/blogs/containers/kubernetes-cluster-upgrade-the-blue-green-deployment-strategy/) + [Biru/Hijau atau Canary Amazon EKS mengelompokkan migrasi untuk beban kerja ArgoCD tanpa kewarganegaraan](https://aws.amazon.com/blogs/containers/blue-green-or-canary-amazon-eks-clusters-migration-for-stateless-argocd-workloads/) ## Lacak perubahan besar yang direncanakan dalam proyek Kubernetes — Pikirkan ke depan Jangan hanya melihat versi berikutnya. Tinjau versi baru Kubernetes saat dirilis, dan identifikasi perubahan besar. Misalnya, beberapa aplikasi langsung menggunakan docker API, dan dukungan untuk Container Runtime Interface (CRI) untuk Docker (juga dikenal sebagai Dockershim) telah dihapus di Kubernetes. `1.24` Perubahan semacam ini membutuhkan lebih banyak waktu untuk dipersiapkan. Tinjau semua perubahan terdokumentasi untuk versi yang Anda upgrade, dan perhatikan setiap langkah pemutakhiran yang diperlukan. Juga, perhatikan persyaratan atau prosedur apa pun yang khusus untuk klaster terkelola Amazon EKS. + [Changelog Kubernetes](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) ## Panduan Khusus tentang Penghapusan Fitur ### Penghapusan Dockershim di 1.25 - Gunakan Detektor untuk Docker Socket (DDS) EKS Optimized AMI untuk 1.25 tidak lagi menyertakan dukungan untuk Dockershim. Jika Anda memiliki ketergantungan pada Dockershim, misalnya Anda memasang soket Docker, Anda harus menghapus dependensi tersebut sebelum memutakhirkan node pekerja Anda ke 1,25. Temukan contoh di mana Anda memiliki ketergantungan pada soket Docker sebelum memutakhirkan ke 1,25. Sebaiknya gunakan [Detector for Docker Socket (DDS), sebuah plugin kubectl](https://github.com/aws-containers/kubectl-detector-for-docker-socket). . ### Penghapusan PodSecurityPolicy in 1.25 - Migrasi ke Standar Keamanan Pod atau solusi policy-as-code `PodSecurityPolicy`tidak digunakan [lagi di Kubernetes 1.21, dan telah dihapus di Kubernetes 1.25](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). Jika Anda menggunakan PodSecurityPolicy klaster Anda, maka Anda harus bermigrasi ke Kubernetes Pod Security Standards (PSS) bawaan atau ke policy-as-code solusi sebelum mengupgrade klaster Anda ke versi 1.25 untuk menghindari gangguan pada beban kerja Anda. AWS menerbitkan [FAQ terperinci dalam dokumentasi EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-security-policy-removal-faq.html). Tinjau praktik terbaik [Pod Security Standards (PSS) dan Pod Security Admission (PSA)](https://aws.github.io/aws-eks-best-practices/security/docs/pods/#pod-security-standards-pss-and-pod-security-admission-psa). Tinjau [posting blog PodSecurityPolicy Deprecation](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) di situs web Kubernetes. ### Pengakhiran Driver Penyimpanan In-Tree di 1.23 - Migrasi ke Driver Container Storage Interface (CSI) Container Storage Interface (CSI) dirancang untuk membantu Kubernetes mengganti mekanisme driver penyimpanan in-tree yang ada. Fitur migrasi antarmuka penyimpanan kontainer (CSI) Amazon EBS diaktifkan secara default di Amazon EKS `1.23` dan kluster yang lebih baru. Jika Anda memiliki pod yang berjalan pada versi `1.22` atau klaster sebelumnya, maka Anda harus menginstal [driver Amazon EBS CSI](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) sebelum memperbarui klaster Anda ke versi `1.23` untuk menghindari gangguan layanan. Tinjau [pertanyaan umum migrasi Amazon EBS CSI](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi-migration-faq.html). ## Sumber Daya Tambahan ### ClowdHaus Panduan Peningkatan EKS [ClowdHaus Panduan Peningkatan EKS](https://clowdhaus.github.io/eksup/) adalah CLI untuk membantu meningkatkan kluster Amazon EKS. Ini dapat menganalisis cluster untuk setiap masalah potensial untuk diperbaiki sebelum upgrade. ### GoNoGo [GoNoGo](https://github.com/FairwindsOps/GoNoGo)adalah alat tahap alfa untuk menentukan kepercayaan peningkatan add-on cluster Anda.