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

Panduan ini menunjukkan kepada administrator cluster 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.

Gambaran umum

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 1.24. Sementara AWS mengelola dan meningkatkan bidang kontrol, memperbarui node pekerja di bidang data adalah tanggung jawab Anda.

Sebelum Meningkatkan

Jika Anda berencana untuk meningkatkan versi Kubernetes Anda di Amazon EKS, ada beberapa kebijakan, alat, dan prosedur penting yang harus Anda terapkan sebelum memulai peningkatan.

Jaga agar cluster Anda selalu terbarui

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 untuk mempertahankan cluster aman dan terbaru yang memanfaatkan sepenuhnya fitur dan peningkatan terbaru. Taktik:

Tinjau kalender rilis EKS

Tinjau kalender rilis EKS Kubernetes untuk mengetahui kapan versi baru akan datang, dan kapan dukungan untuk versi tertentu berakhir. Umumnya, EKS merilis tiga versi minor Kubernetes setiap tahun, dan setiap versi minor didukung selama sekitar 14 bulan.

Selain itu, tinjau informasi rilis Kubernetes hulu.

Memahami bagaimana model tanggung jawab bersama diterapkan pada peningkatan cluster

Anda bertanggung jawab untuk memulai peningkatan untuk kedua bidang kontrol cluster serta bidang data. Pelajari cara memulai upgrade. Saat Anda memulai peningkatan cluster, AWS mengelola peningkatan bidang kontrol cluster. Anda bertanggung jawab untuk meningkatkan bidang data, termasuk pod dan add ons Fargate. Anda harus memvalidasi dan merencanakan peningkatan untuk beban kerja yang berjalan di cluster Anda untuk memastikan ketersediaan dan operasinya tidak terpengaruh setelah peningkatan cluster

Tingkatkan cluster di tempat

EKS mendukung strategi peningkatan cluster di tempat. Ini mempertahankan sumber daya cluster, dan menjaga konfigurasi cluster tetap konsisten (misalnya, titik akhir API, OIDC, ENI, penyeimbang beban). Ini tidak terlalu mengganggu bagi pengguna cluster, dan akan menggunakan beban kerja dan sumber daya yang ada di cluster tanpa mengharuskan Anda untuk menyebarkan 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 ke 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, lihatMengevaluasi Blue/Green Cluster sebagai alternatif untuk peningkatan cluster di tempat.

Tingkatkan bidang kontrol dan bidang data Anda secara berurutan

Untuk meng-upgrade cluster, Anda harus mengambil tindakan berikut:

Gunakan Dokumentasi EKS untuk membuat daftar periksa peningkatan

Dokumentasi versi EKS Kubernetes menyer takan 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.

Tingkatkan add-on dan komponen menggunakan API Kubernetes

Sebelum Anda memutakhirkan cluster, Anda harus memahami versi komponen Kubernetes apa yang Anda gunakan. Komponen cluster inventaris, dan mengidentifikasi komponen yang menggunakan API Kubernetes secara langsung. Ini termasuk komponen cluster penting seperti agen pemantauan dan pencatatan, penskalaan otomatis cluster, driver penyimpanan kontainer (misalnya EBS CSI, EFS CSI), pengendali masuk, dan beban kerja atau add-on lainnya yang bergantung pada API Kubernetes secara langsung.

kubectl get ns | grep '-system'

Setelah Anda mengidentifikasi komponen yang mengandalkan API Kubernetes, periksa dokumentasinya untuk kompatibilitas versi dan persyaratan peningkatan. Misalnya, lihat dokumentasi AWS Load Balancer Controller untuk kompatibilitas versi. Beberapa komponen mungkin perlu ditingkatkan atau konfigurasi diubah sebelum melanjutkan dengan peningkatan cluster. Beberapa komponen penting untuk diperiksa termasuk CoreDNS, kube-proxy, VPC C NI, dan driver penyimpanan.

Cluster sering berisi banyak beban kerja yang menggunakan API Kubernetes dan diperlukan untuk fungsionalitas beban kerja seperti pengendali masuk, sistem pengiriman berkelanjutan, dan alat pemantauan. Saat Anda meng-upgrade cluster 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:

Verifikasi persyaratan EKS dasar sebelum meningkatkan

AWS memerlukan sumber daya tertentu di akun Anda untuk menyelesaikan proses peningkatan. Jika sumber daya ini tidak ada, cluster tidak dapat ditingkatkan. Peningkatan pesawat kontrol membutuhkan sumber daya berikut:

Verifikasi alamat IP yang tersedia

Untuk memperbarui cluster, Amazon EKS memerlukan hingga lima alamat IP yang tersedia dari subnet yang Anda tentukan saat membuat cluster.

Untuk memverifikasi bahwa subnet Anda memiliki alamat IP yang cukup untuk meng-upgrade cluster, Anda dapat menjalankan perintah berikut:

CLUSTER=<cluster name>
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 |
+---------------------------+--------------+-------+

VPC CNI Metrics Helper dapat digunakan untuk membuat CloudWatch dasbor untuk metrik VPC. Amazon EKS merekomendasikan memperbarui subnet cluster menggunakan "UpdateClusterConfiguration" API sebelum memulai peningkatan versi Kubernetes jika Anda kehabisan alamat IP di subnet yang awalnya ditentukan selama pembuatan cluster. Harap verifikasi bahwa subnet baru yang akan diberikan kepada Anda:

Harap pertimbangkan untuk mengaitkan blok CIDR tambahan jika alamat IP di blok VPC CIDR yang ada habis. AWS memungkinkan asosiasi blok CIDR tambahan dengan VPC cluster Anda yang ada, 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 VPC CIDR 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=<cluster name>
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"
        }
    ]
}

Bermigrasi ke EKS Add-ons

Amazon EKS secara otomatis menginstal add-on seperti plugin Amazon VPC CNI untuk Kubernetes,kube-proxy, dan CoreDNS untuk setiap cluster. Add-ons dapat dikelola sendiri, atau diinstal sebagai Amazon EKS Add-ons. Amazon EKS Add-ons adalah cara alternatif untuk mengelola add-on menggunakan EKS API.

Anda dapat menggunakan Amazon EKS Add-ons 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 EKS Add-ons dengan:

aws eks list-addons --cluster-name <cluster name>

Pelajari lebih lanjut tentang komponen apa yang tersedia sebagai EKS Add-ons, dan cara memulainya.

Pelajari cara memasok konfigurasi khusus ke EKS Add-on.

Mengidentifikasi dan memperbaiki penggunaan API yang dihapus sebelum memutakhirkan bidang kontrol

Anda harus mengidentifikasi penggunaan API dari API yang dihapus 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 cluster langsung, alat ini dapat mengembalikan positif palsu.

API Kubernetes yang tidak digunakan lagi tidak berarti API telah dihapus. Anda harus memeriksa Kebijakan Penghenti an Kubernetes untuk memahami bagaimana penghapusan API memengaruhi beban kerja Anda.

Wawasan Cluster

Cluster Insights adalah fitur yang memberikan temuan tentang masalah yang dapat memengaruhi kemampuan untuk meningkatkan cluster 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 <region-code> --cluster-name <my-cluster>

{
    "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 output yang lebih deskriptif tentang wawasan yang diterima, Anda dapat menjalankan perintah:

aws eks describe-insight --region <region-code> --id <insight-id> --cluster-name <my-cluster>

Anda juga memiliki opsi untuk melihat wawasan di Amazon EKS Console. Setelah memilih cluster Anda dari daftar cluster, temuan wawasan terletak di bawah Upgrade Insights tab.

Jika Anda menemukan wawasan cluster dengan"status": ERROR, Anda harus mengatasi masalah tersebut sebelum melakukan peningkatan cluster. Jalan aws eks describe-insight kan perintah yang akan membagikan saran remediasi berikut:

Sumber daya yang terpengaruh:

"resources": [
      {
        "insightStatus": {
          "status": "ERROR"
        },
        "kubernetesResourceUri": "/apis/policy/v1beta1/podsecuritypolicies/null"
      }
]

API tidak digunakan lagi:

"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 cluster EKS yang berhasil. Pelajari lebih lanjut dengan sumber daya berikut: * Dokumen EKS Resmi * Blog peluncuran Cluster Insights.

Kube-no-trouble

Kube-no-troubleadalah utilitas baris perintah open source dengan perintahkubent. Ketika Anda menjalankan kubent tanpa argumen apa pun, itu akan menggunakan KubeConfig konteks Anda saat ini dan memindai cluster dan mencetak laporan dengan API apa yang akan usang 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   <undefined>   eks.privileged   policy/v1beta1   <removed> (1.21.0)

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 diterapkan. Pemindaian manifes juga lebih akurat daripada memindai cluster langsung.

Kube-no-trouble menyediakan contoh Akun Layanan dan Peran dengan izin yang sesuai untuk memindai cluster.

Pluto

Pilihan lain adalah Pluto yang mirip dengan kubent karena mendukung pemindaian cluster langsung, file manifes, bagan helm dan memiliki T GitHub indakan 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 cluster Anda tidak menggunakan API yang tidak digunakan lagi sebelum upgrade, Anda harus memantau:

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

CLUSTER="<cluster_name>"
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 API usang 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 secara otomatis mengonversi file manifes Anda. Misalnya, untuk mengonversi Deployment yang lebih lama menjadiapps/v1. Untuk informasi selengkapnya, lihat Meng instal plugin kubectl convert di situs web Kubernetes.

kubectl-convert -f <file> --output-version <group>/<version>

Konfigur PodDisruptionBudgets asikan dan topologi SpreadConstraints untuk memastikan ketersediaan beban kerja Anda saat bidang data ditingkatkan

Pastikan beban kerja Anda memiliki topologi yang tepat PodDisruptionBudgets SpreadConstraints untuk memastikan ketersediaan beban kerja Anda saat bidang data ditingkatkan. Tidak setiap beban kerja memerlukan 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 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 perangkat lunak, infrastruktur, atau gangguan operasional.

Gunakan Grup Node Terkelola atau Karpenter untuk menyederhanakan peningkatan bidang 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 mengakhiri 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 AMI yang diperbarui atau cluster ditingkatkan, Karpenter akan secara otomatis mulai menggunakan gambar-gambar ini. Karpenter juga mengimplementasikan Node Expiration untuk memperbarui node.

Karpenter dapat dikonfigurasi untuk menggunakan AMI khusus. Jika Anda menggunakan AMI khusus dengan Karpenter, Anda bertanggung jawab atas versi kubelet.

Konfirmasikan kompatibilitas versi dengan node yang ada dan bidang kontrol

Sebelum melanjutkan dengan peningkatan 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 bervariasi berdasarkan skenario yang berbeda. Taktik:

Aktifkan kedaluwarsa node untuk node yang dikelola Karpenter

Salah satu cara Karpenter mengimplementasikan upgrade node adalah menggunakan konsep node berakhir. Ini mengurangi perencanaan yang diperlukan untuk peningkatan node. Ketika Anda menetapkan nilai untuk ttl SecondsUntilExpired di penyedia Anda, ini mengaktifkan kadaluwarsa node. Setelah node mencapai usia yang ditentukan dalam hitungan detik, node akan terkuras dan dihapus dengan aman. Ini benar bahkan jika mereka sedang digunakan, memungkinkan Anda mengganti node dengan instans upgrade yang baru disediakan. Saat node diganti, Karpenter menggunakan AMI terbaru EKS-optimized . Untuk informasi lebih lanjut, lihat Gang guan di situs web Karpenter.

Karpenter tidak secara otomatis menambahkan jitter ke nilai ini. Untuk mencegah gangguan beban kerja yang berlebihan, tentukan anggaran gangguan pod, seperti yang ditunjukkan dalam dokumentasi Kubernetes.

Jika Anda mengkonfigurasi ttl SecondsUntilExpired pada penyedia, ini berlaku untuk node yang ada yang terkait dengan penyedianya.

Gunakan fitur Drift untuk node yang dikelola Karpenter

Fitur Drift Karpenter dapat secara otomatis meningkatkan Karpenter-provisioned node agar tetap sinkron dengan bidang kontrol EKS. Karpenter Drift saat ini perlu diaktifkan menggunakan gerbang fitur. Konfigurasi default Karpenter menggunakan EKS-Optimized AMI terbaru untuk versi mayor dan minor yang sama dengan bidang kontrol cluster EKS.

Setelah peningkatan Cluster EKS selesai, fitur Drift Karpenter akan mendeteksi bahwa Karpenter-provisioned node menggunakan EKS-Optimized AMI untuk versi cluster sebelumnya, dan secara otomatis menutup, menguras, dan mengganti node tersebut. Untuk mendukung pemindahan pod ke node baru, ikuti praktik terbaik Kubernetes dengan menetapkan kuota sumber daya pod yang sesuai, dan menggunakan anggaran gangguan pod (PDB). Deprovisioning Karpenter akan melakukan pre-spin up node pengganti berdasarkan permintaan sumber daya pod, dan akan menghormati PDB saat mendeprovisioning node.

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 meningkatkan grup node yang dikelola sendiri, Anda harus merujuk ke dokumentasi alat Anda.

Misalnya, eksctl mendukung penghapusan dan pengeringan node yang dikelola sendiri.

Beberapa alat umum meliputi:

Cadangkan cluster sebelum memutakhirkan

Versi baru Kubernetes memperkenalkan perubahan signifikan pada cluster Amazon EKS Anda. Anda dapat mengembalikan peningkatan dalam waktu 7 hari, tetapi kami sarankan Anda membuat cadangan cluster Anda sebelum memutakhirkan.

Anda dapat membuat cadangan cluster Anda dengan AWS Backup, layanan yang dikelola sepenuhnya. Anda juga dapat menggunakan Velero, alat sumber terbuka yang didukung komunitas.

Perhatikan bahwa Anda hanya dapat membuat cluster baru untuk versi Kubernetes yang saat ini didukung oleh EKS. Jika versi yang sedang dijalankan cluster Anda masih didukung dan peningkatan gagal, Anda dapat membuat cluster baru dengan versi asli dan memulihkan bidang data. Perhatikan bahwa sumber daya AWS, termasuk IAM, tidak disertakan dalam cadangan. Anda perlu membuat ulang sumber daya ini.

Mulai ulang penerapan Fargate setelah memutakhirkan pesawat kontrol

Untuk memutakhirkan node bidang data Fargate, Anda perlu menyebarkan ulang beban kerja. Anda dapat mengidentifikasi beban kerja mana yang berjalan di node fargate dengan mencantumkan semua pod dengan opsi tersebut-o wide. Setiap nama node yang dimulai dengan fargate- perlu dikerahkan ulang di cluster.

Mengevaluasi Blue/Green Cluster sebagai alternatif untuk peningkatan cluster di tempat

Beberapa pelanggan lebih suka melakukan strategi blue/green peningkatan. Ini dapat memiliki manfaat, tetapi juga termasuk kerugian yang harus dipertimbangkan.

Manfaatnya meliputi:

Beberapa kelemahan meliputi:

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:

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) dihapus di Kubernetes. 1.24 Perubahan semacam ini membutuhkan lebih banyak waktu untuk dipersiapkan.

Tinjau semua perubahan terdokumentasi untuk versi yang Anda tingkatkan, dan catat langkah-langkah peningkatan yang diperlukan. Juga, perhatikan persyaratan atau prosedur apa pun yang khusus untuk cluster yang dikelola Amazon EKS.

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 instance di mana Anda memiliki ketergantungan pada soket Docker sebelum memutakhirkan ke 1.25. Sebaiknya gunakan Detector for Docker Socket (DDS), sebuah plugin kubectl. .

Penghapusan PodSecurityPolicy di 1.25 - Bermigrasi ke Standar Keamanan Pod atau solusi kebijakan sebagai kode

PodSecurityPolicytidak digunakan lagi di Kubernetes 1.21, dan telah dihapus di Kubernetes 1.25. Jika Anda menggunakan PodSecurityPolicy di cluster Anda, maka Anda harus bermigrasi ke Standar Keamanan Pod Kubernetes bawaan (PSS) atau ke solusi kebijakan sebagai kode sebelum memutakhirkan cluster Anda ke versi 1.25 untuk menghindari gangguan pada beban kerja Anda.

AWS menerbitkan FAQ terperinci dalam dokumentasi EKS.

Tinjau praktik terbaik Standar Keamanan Pod (PSS) dan Penerimaan Keamanan Pod (PSA).

Tinjau posting blog PodSecurityPolicy Deprecation di situs web Kubernetes.

Penghentian Driver Penyimpanan In-Tree di 1.23 - Bermigrasi ke Driver Antarmuka Penyimpanan Kontainer (CSI)

Container Storage Interface (CSI) dirancang untuk membantu Kubernetes mengganti mekanisme driver penyimpanan in-tree yang ada. Fitur migrasi antarmuka penyimpanan wadah Amazon EBS (CSI) diaktifkan secara default di Amazon EKS 1.23 dan cluster yang lebih baru. Jika Anda memiliki pod yang berjalan pada cluster versi 1.22 atau sebelumnya, maka Anda harus menginstal driver Amazon EBS CSI sebelum memperbarui cluster Anda ke versi 1.23 untuk menghindari gangguan layanan.

Tinjau pertanyaan umum tentang migrasi Amazon EBS CSI.

Sumber Daya Tambahan

ClowdHaus Panduan Peningkatan EKS

ClowdHaus EKS Upgrade Guidance adalah CLI untuk membantu meningkatkan cluster Amazon EKS. Ini dapat menganalisis cluster untuk masalah potensial untuk diperbaiki sebelum meningkatkan.

GoNoGo

GoNoGoadalah alat tahap alfa untuk menentukan kepercayaan peningkatan add-on cluster Anda.