本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
叢集升級的最佳實務
本指南示範叢集管理員如何規劃和執行其 Amazon EKS 升級策略。它還描述了如何升級自我管理節點、受管節點群組、Karpenter 節點和 Fargate 節點。它不包括 EKS Anywhere、自我管理 Kubernetes、AWSOutpost 或 AWS Local Zones 的指引。
概觀
Kubernetes 版本包含控制平面和資料平面。為確保操作順暢，控制平面和資料平面都應執行相同的 Kubernetes 次要版本，例如 1.24。
-
控制平面 — 控制平面的版本由 Kubernetes API 伺服器決定。在 Amazon EKS叢集中， AWS 會負責管理此元件。控制平面升級可以透過 AWS 啟動API。
-
資料平面 — 資料平面版本與在個別節點上執行的 Kubelet 版本相關聯。同一叢集中的節點可能會執行不同的版本。您可以執行 來檢查所有節點的版本
kubectl get nodes。
升級之前
如果您打算在 Amazon 中升級 Kubernetes 版本EKS，您應該在開始升級之前，先備妥幾個重要的政策和工具和程序。
-
了解棄用政策 — 深入了解 Kubernetes 棄用政策
的運作方式。請注意可能影響現有應用程式的任何近期變更。較新的 Kubernetes 版本通常會淘汰某些 APIs和 功能，這可能會導致執行應用程式的問題。 -
檢閱 Kubernetes 變更日誌 — 徹底檢閱 Kubernetes 變更日誌
與 Amazon EKS Kubernetes 版本，以了解對叢集的任何可能影響，例如突破可能會影響工作負載的變更。 -
評估叢集附加元件相容性：當新版本發行時或將叢集更新至新的 Kubernetes 次要版本後，Amazon EKS不會自動更新附加元件。檢閱更新附加元件，以了解任何現有叢集附加元件與您要升級之叢集版本的相容性。
-
啟用控制平面記錄 — 啟用控制平面記錄，以擷取升級程序期間可能發生的日誌、錯誤或問題。請考慮檢閱這些日誌是否有任何異常。在非生產環境中測試叢集升級，或將自動化測試整合到您的持續整合工作流程中，以評估與應用程式、控制器和自訂整合的版本相容性。
-
探索叢集管理的 eksctl — 考慮使用 eksctl
管理您的EKS叢集。它可讓您更新控制平面、管理附加元件，以及處理工作者節點更新 out-of-the-box。 -
選擇 Managed Node Groups 或在 Fargate EKS 上：使用EKS受管節點群組或在 Fargate 上簡化和自動化工作者節點升級。 EKS 這些選項可簡化程序並減少手動介入。
-
使用 kubectl 轉換外掛程式 — 利用 kubectl 轉換外掛程式
，以促進不同API版本之間 Kubernetes 資訊清單檔案的轉換 。這有助於確保您的組態與新的 Kubernetes 版本相容。
保留叢集 up-to-date
掌握最新的 Kubernetes 更新對於安全且有效率EKS的環境至關重要，這反映了 Amazon 中的共同責任模型EKS。透過將這些策略整合到您的操作工作流程中，您將自行定位以維護 up-to-date，並保護充分利用最新功能和改進的叢集。策略：
-
支援的版本政策 — Amazon EKS通常提供三個作用中的 Kubernetes 版本，並與 Kubernetes 社群保持一致。Kubernetes 次要版本在發行後的EKS前 14 個月，在 Amazon 中受到標準支援。版本超過標準支援日期後，會在接下來的 12 個月內輸入延伸支援。取代通知會在版本達到其標準支援結束日期之前至少 60 天發出。如需詳細資訊，請參閱 EKS 生命週期文件版本 。
-
Auto-Upgrade 政策 — 我們強烈建議您與您的EKS叢集中的 Kubernetes 更新保持同步。在 Kubernetes 版本上執行的叢集，如果已完成其 26 個月的生命週期 （14 個月的標準支援加上 12 個月的延伸支援），則會自動升級至下一個版本。請注意，您可以停用延伸支援 。無法在版本觸發 end-of-life自動升級之前主動升級，這可能會中斷您的工作負載和系統。如需詳細資訊，請參閱EKS版本 FAQs。
-
建立升級 Runbook — 建立記錄良好的程序來管理升級。作為主動方法的一部分，開發針對升級程序量身打造的 Runbook 和專用工具。這不僅可以增強您的準備，還可以簡化複雜的轉換。讓它成為標準做法，每年至少升級叢集一次。此做法可讓您與持續的技術進步保持一致，從而提高環境的效率和安全性。
檢閱EKS發行行事曆
檢閱 EKS Kubernetes 版本行事曆，了解新版本何時推出，以及特定版本何時支援結束。一般而言， 每年EKS發行三個次要版本的 Kubernetes，每個次要版本支援約 14 個月。
此外，請檢閱上游 Kubernetes 版本資訊
了解共同責任模型如何套用至叢集升級
您負責啟動叢集控制平面和資料平面的升級。了解如何啟動升級。當您啟動叢集升級時， 會AWS管理叢集控制平面的升級。您有責任升級資料平面，包括 Fargate Pod 和附加元件 。您必須驗證和規劃叢集上執行的工作負載升級，以確保叢集升級後其可用性和操作不會受到影響
就地升級叢集
EKS 支援就地叢集升級策略。這可維護叢集資源，並保持叢集組態的一致性 （例如API端點、OIDC、ENIs、負載平衡器）。這對叢集使用者來說干擾性較低，而且會使用叢集中現有的工作負載和資源，而不需要重新部署工作負載或遷移外部資源 （例如 DNS、 儲存體）。
執行就地叢集升級時，請務必注意一次只能執行一個次要版本升級 （例如，從 1.24 到 1.25）。
這表示如果您需要更新多個版本，則需要一系列的循序升級。規劃循序升級更為複雜，而且停機時間的風險更高。在這種情況下，請參閱 評估藍/綠叢集作為就地叢集升級的替代方案。
依序升級控制平面和資料平面
若要升級叢集，您需要採取下列動作：
-
如果使用受管節點群組，請確保與控制平面位於相同的 Kubernetes 版本上。EKS EKS Fargate Profiles 建立的受管節點群組和節點支援 Kubernetes 1.27 版及以下版本的控制平面與資料平面之間的 2 個次要版本偏移。從 1.28 及更高版本開始，EKSFargate Profiles 建立的EKS受管節點群組和節點支援 3 個次要版本偏斜的控制平面和資料平面。例如，如果您的EKS控制平面版本是 1.28，則可以安全地使用舊有的 kubelet 版本，舊為 1.25。如果您的EKS版本為 1.27，您可以使用的最舊 kubelet 版本為 1.25。
-
檢閱附加元件相容性。視需要升級 Kubernetes 附加元件和自訂控制器。
-
升級叢集資料平面。將節點升級至與升級叢集相同的 Kubernetes 次要版本。
使用 EKS 文件建立升級檢查清單
Kubernetes EKS 版本文件包含每個版本的詳細變更清單。為每次升級建立檢查清單。
如需特定EKS版本升級指南，請檢閱文件，了解每個版本的顯著變更和考量事項。
使用 Kubernetes 升級附加元件和元件 API
升級叢集之前，您應該了解正在使用的 Kubernetes 元件版本。清查叢集元件，並識別API直接使用 Kubernetes 的元件。這包括關鍵叢集元件，例如監控和記錄代理程式、叢集自動擴展器、容器儲存驅動程式EBS CSI（例如 EFS CSI、）、輸入控制器，以及API直接依賴 Kubernetes 的任何其他工作負載或附加元件。
提示
關鍵叢集元件通常安裝在*-system命名空間中
kubectl get ns | grep '-system'
識別依賴 Kubernetes 的元件後API，請檢查其文件是否有版本相容性和升級需求。例如，請參閱 AWS Load Balancer 控制器
叢集通常包含許多使用 Kubernetes 的工作負載，API且工作負載功能需要這些工作負載，例如輸入控制器、連續交付系統和監控工具。升級EKS叢集時，您還必須升級附加元件和第三方工具，以確保它們相容。
請參閱下列常見附加元件及其相關升級文件的範例：
-
Amazon VPC CNI：有關每個叢集版本的 Amazon VPC CNI 附加元件建議版本，請參閱更新 Kubernetes 自我管理附加元件的 Amazon VPCCNI外掛程式。當安裝為 Amazon 附加EKS元件時，一次只能升級一個次要版本。
-
kube-proxy：請參閱更新 Kubernetes kube-proxy 自我管理附加元件。
-
核心 DNS：請參閱更新核心DNS自我管理附加元件 。
-
AWS Load Balancer 控制器：AWSLoad Balancer 控制器需要與您部署的EKS版本相容。如需詳細資訊，請參閱 安裝指南。
-
Amazon Elastic Block Store （AmazonEBS） Container Storage Interface （CSI） 驅動程式：如需安裝和升級資訊，請參閱將 Amazon EBSCSI驅動程式作為 Amazon EKS附加元件管理。
-
Amazon Elastic File System （AmazonEFS） Container Storage Interface （CSI） 驅動程式：如需安裝和升級資訊，請參閱 Amazon EFSCSI驅動程式 。
-
Kubernetes Metrics Server：如需詳細資訊，請參閱 上的 metrics-server
GitHub。 -
Kubernetes Cluster Autoscaler：若要升級 Kubernetes Cluster Autoscaler 的版本，請在部署中變更映像的版本。Cluster Autoscaler 與 Kubernetes 排程器緊密結合。當您升級叢集時，一律需要將其升級。檢閱GitHub 版本
，尋找與您的 Kubernetes 次要版本對應的最新版本地址。 -
Karpenter：如需安裝和升級資訊，請參閱 Karpenter 文件。
升級前請確認基本EKS需求
AWS 需要帳戶中的特定資源才能完成升級程序。如果沒有這些資源，則無法升級叢集。控制平面升級需要下列資源：
-
可用的 IP 地址：Amazon EKS需要您在建立叢集時指定的子網路中最多五個可用的 IP 地址，才能更新叢集。如果沒有，請在執行版本更新之前更新您的叢集組態，以包含新的叢集子網路。
-
EKS IAM 角色：具有必要許可的 帳戶中仍然存在控制平面IAM角色。
-
如果您的叢集已啟用秘密加密，請確定叢集IAM角色具有使用AWS金鑰管理服務 （AWS KMS） 金鑰的許可。
驗證可用的 IP 地址
若要更新叢集，Amazon 最多EKS需要五個可用 IP 地址，這些 IP 地址來自您在建立叢集時指定的子網路。
若要確認您的子網路有足夠的 IP 地址可以升級叢集，您可以執行下列命令：
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
-
屬於叢集建立期間AZs選取的同一組 。
-
屬於叢集建立期間VPC提供的相同
如果現有CIDR區塊中的 IP 地址用完，請考慮關聯其他VPCCIDR區塊。AWS 可讓其他CIDR區塊與現有叢集建立關聯VPC，有效地擴展您的 IP 地址集區。此擴展可以透過引入其他私有 IP 範圍 （RFC 1918 年） 或在必要時引入公有 IP 範圍 （非RFC 1918 年） 來完成。您必須新增VPCCIDR區塊並允許VPC重新整理以完成，Amazon EKS才能使用新的 CIDR。之後，您可以根據新設定的CIDR區塊將子網路更新至 VPC。
驗證EKSIAM角色
若要驗證IAM角色是否可用，並在您的帳戶中有正確的擔任角色政策，您可以執行下列命令：
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" } ] }
遷移至EKS附加元件
Amazon EKS會自動為每個叢集安裝 Amazon VPC CNI 外掛程式，例如 Kubernetes、 kube-proxy和 CoreDNS。附加元件可以自我管理，也可以安裝為 Amazon EKS 附加元件。Amazon EKS 附加元件是使用 EKS 管理附加元件的替代方法API。
您可以使用 Amazon EKS 附加元件，透過單一命令更新版本。例如：
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
檢查您是否具有下列EKS任何附加元件：
aws eks list-addons --cluster-name <cluster name>
警告
EKS 在控制平面升級期間，附加元件不會自動升級。您必須啟動EKS附加元件更新，然後選取所需的版本。
-
您有責任從所有可用版本中選取相容的版本。檢閱附加元件版本相容性的指引。
-
Amazon EKS 附加元件一次只能升級一個次要版本。
進一步了解哪些元件可作為EKS附加元件使用，以及如何開始使用。
在升級控制平面之前，識別並修復移除的API用量
升級EKS控制平面APIs之前，您應該先識別已移除的 API用量。若要執行這項操作，我們建議您使用可檢查執行中叢集或靜態轉譯的 Kubernetes 資訊清單檔案的工具。
針對靜態資訊清單檔案執行檢查通常更準確。如果針對即時叢集執行，這些工具可能會傳回誤報。
取代的 Kubernetes API 並不表示 API 已被移除。您應該檢查 Kubernetes 取代政策
Cluster Insights
Cluster Insights 是一種功能，可提供可能影響將EKS叢集升級至較新版本 Kubernetes 之能力的問題調查結果。這些調查結果由 Amazon 策劃和管理EKS，並針對如何修復問題提供建議。透過利用 Cluster Insights，您可以將升級至較新 Kubernetes 版本所花費的精力降到最低。
若要檢視EKS叢集的洞見，您可以執行 命令：
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." } ] }
如需有關所收到洞見的更描述性輸出，您可以執行 命令：
aws eks describe-insight --region <region-code> --id <insight-id> --cluster-name <my-cluster>
您也可以選擇在 Amazon EKS主控台 Upgrade Insights 索引標籤下。
如果您找到具有 的叢集洞察"status": ERROR，您必須先解決問題，才能執行叢集升級。執行 aws eks describe-insight命令，該命令將共用下列修復建議：
受影響的資源：
"resources": [ { "insightStatus": { "status": "ERROR" }, "kubernetesResourceUri": "/apis/policy/v1beta1/podsecuritypolicies/null" } ]
APIs 已棄用：
"deprecationDetails": [ { "usage": "/apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas", "replacedWith": "/apis/flowcontrol.apiserver.k8s.io/v1beta3/flowschemas", "stopServingVersion": "1.29", "clientStats": [], "startServingReplacementVersion": "1.26" } ]
建議採取的動作：
"recommendation": "Update manifests and API clients to use newer Kubernetes APIs if applicable before upgrading to Kubernetes v1.26."
透過EKS主控台利用叢集洞察，或CLI協助加快成功升級EKS叢集版本的程序。使用下列資源進一步了解：* Official EKS Docs * Cluster Insights 啟動部落格
Kube-no-trouble
Kube-no-troublekubent。當您在沒有任何引數kubent的情況下執行 時，它將使用您目前的 KubeConfig內容，掃描叢集，並使用APIs將被取代和移除的內容列印報告。
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)
它也可以用來掃描靜態資訊清單檔案和 helm 套件。建議kubent作為連續整合 （CI） 程序的一部分執行，以在部署資訊清單之前識別問題。掃描資訊清單也比掃描即時叢集更準確。
Kube-no-trouble 提供範例服務帳戶和角色
Pluto
另一個選項是類似 的 plutokubent因為它支援掃描即時叢集、資訊清單檔案、 Helm Chart，並具有您可以在 CI 程序中包含 GitHub 的動作。
pluto detect-all-in-cluster NAME KIND VERSION REPLACEMENT REMOVED DEPRECATED REPL AVAIL eks.privileged PodSecurityPolicy policy/v1beta1 false true true
資源
若要確認您的叢集在升級APIs之前未使用已棄用，您應該監控：
-
Kubernetes 1.19 版
apiserver_requested_deprecated_apis以來的指標：
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
-
稽核日誌中的事件，
k8s.io/deprecated設定為true：
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
如果已棄用APIs，哪些 會輸出線路：
{ "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\"}}" }, [...]
更新 Kubernetes 工作負載。使用 kubectl-convert 更新資訊清單
確定需要更新哪些工作負載和資訊清單後，您可能需要變更資訊清單檔案中的資源類型 （例如PodSecurityPolicies ，變更為 PodSecurityStandards）。這將需要更新資源規格和其他研究，具體取決於要取代的資源。
如果資源類型保持不變，但需要更新API版本，您可以使用 kubectl-convert命令自動轉換資訊清單檔案。例如，將較舊的部署轉換為 apps/v1。如需詳細資訊，請參閱 Kubernetes 網站上的安裝 kubectl 轉換外掛程式
kubectl-convert -f <file> --output-version <group>/<version>
設定 PodDisruptionBudgets 和 topologySpreadConstraints 以確保升級資料平面時工作負載的可用性
確保您的工作負載具有適當的 PodDisruptionBudgets
確保工作負載分散在多個可用區域中，並在具有拓撲分散的多個主機上，將可提高工作負載自動遷移到新資料平面的可信度。
以下是工作負載範例，這些工作負載一律會有 80% 的可用複本，並將複本分散到區域和主機
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
使用 Managed Node Groups 或 Karpenter 簡化資料平面升級
Managed Node Groups 和 Karpenter 都簡化了節點升級，但它們採用不同的方法。
受管節點群組可自動化節點的佈建和生命週期管理。這表示您可以使用單一操作建立、自動更新或終止節點。
在預設組態中，Karpenter 會使用最新的相容EKS最佳化 自動建立新的節點AMI。隨著EKS版本更新 EKS Optimized AMIs或叢集升級，Karpenter 將自動開始使用這些映像。Karpenter 也實作 Node Expiry 來更新節點。
Karpenter 可設定為使用自訂 AMIs。
確認與現有節點和控制平面的版本相容性
在 Amazon 中繼續進行 Kubernetes 升級之前EKS，請務必確保受管節點群組、自我管理節點和控制平面之間的相容性。相容性取決於您使用的 Kubernetes 版本，而且會因不同案例而異。策略：
-
Kubernetes v1.28+ — ** 從 Kubernetes 1.28 版及更新版本開始，針對核心元件有更寬鬆的版本政策。具體而言，Kubernetes API 伺服器與 kubelet 之間的支援偏移已從 n-2 擴展至 n-3。例如，如果您的EKS控制平面版本是 1.28，則可以安全地使用舊有的 kubelet 版本，舊為 1.25。AWS Fargate 、受管節點群組 和自我管理節點 支援此版本偏移。基於安全考量，強烈建議保留您的 Amazon Machine Image （AMI） 版本 up-to-date。較舊的 kubelet 版本可能會因為潛在的常見漏洞和暴險 （CVEs） 而帶來安全風險，這可能會超過使用較舊 kubelet 版本的好處。
-
Kubernetes < v1.28 — 如果您使用的版本早於 v1.28，API伺服器與 kubelet 之間的支援偏移為 n-2。例如，如果您的EKS版本是 1.27，您可以使用的最舊 kubelet 版本是 1.25。此版本偏移適用於 AWS Fargate 、受管節點群組 和自我受管節點 。
啟用 Karpenter 受管節點的節點過期
Karpenter 實作節點升級的一種方式是使用節點過期的概念。這可減少節點升級所需的規劃。當您在佈建器中設定ttlSecondsUntil過期的值時，這會啟用節點過期。節點達到定義的使用年限秒後，就會安全地耗盡並刪除。即使節點在使用中，也一樣如此，可讓您將節點取代為新佈建的升級執行個體。取代節點時，Karpenter EKS會使用最新的 最佳化 AMIs。如需詳細資訊，請參閱 Karpenter 網站上的取消佈建
Karpenter 不會自動將抖動新增至此值。為了防止過度的工作負載中斷，請定義 Pod 中斷預算
如果您在佈建器上設定ttlSecondsUntil過期，這適用於與佈建器相關聯的現有節點。
針對 Karpenter 受管節點使用漂移功能
Karpenter 的漂移功能
EKS 叢集升級完成後，Karpenter 的漂移功能會偵測 Karpenter 佈建的節點是否使用 EKS-AMIs針對先前的叢集版本最佳化，並自動封鎖、排放和取代這些節點。若要支援移至新節點的 Pod，請遵循 Kubernetes 最佳實務，方法是設定適當的 Pod 資源配額
使用 eksctl 自動化自我管理節點群組的升級
自我管理節點群組是在您的帳戶中部署，並在EKS服務外部連接至叢集的EC2執行個體。這些通常由某種形式的自動化工具部署和管理。若要升級自我管理節點群組，您應該參閱工具文件。
例如，eksctl 支援刪除和耗盡自我管理節點。
一些常見的工具包括：
升級前備份叢集
新版本的 Kubernetes 會為您的 Amazon EKS叢集帶來重大變更。升級叢集之後，就無法降級叢集。
Velero
請注意，您只能為 目前支援的 Kubernetes 版本建立新的叢集EKS。如果您的叢集目前執行的版本仍受支援且升級失敗，您可以使用原始版本建立新的叢集並還原資料平面。請注意，包括 在內的AWS資源IAM不會包含在 Velero 的備份中。需要重新建立這些資源。
升級控制平面後重新啟動 Fargate 部署
若要升級 Fargate 資料平面節點，您需要重新部署工作負載。您可以透過列出所有 Pod 和 -o wide選項來識別在 Fargate 節點上執行的工作負載。任何以 開頭的節點名稱fargate-都需要在叢集中重新部署。
評估藍/綠叢集作為就地叢集升級的替代方案
有些客戶偏好執行藍/綠升級策略。這可以帶來好處，但也包括應考慮的下行。
優點包括：
-
可以一次變更多個EKS版本 （例如 1.23 到 1.25）
-
能夠切換回舊叢集
-
建立新的叢集，可以使用較新的系統進行管理 （例如 terraform）
-
工作負載可以個別遷移
部分缺點包括：
-
API 需要更新消費者的端點和OIDC變更 （例如 kubectl 和 CI/CD）
-
在遷移期間需要 2 個叢集並行執行，這可能很昂貴，並限制區域容量
-
如果工作負載彼此依賴，以便一起遷移，則需要更多協調
-
負載平衡器和外部DNS無法輕鬆跨多個叢集
雖然可以執行此策略，但它比就地升級更昂貴，並且需要更多的時間來進行協調和工作負載遷移。在某些情況下可能需要，且應仔細規劃。
使用像 這樣的高度自動化和宣告式系統 GitOps，這可能更容易做到這一點。您將需要針對具狀態工作負載採取額外的預防措施，以便將資料備份並遷移至新的叢集。
如需詳細資訊，請參閱這些部落格文章：
追蹤 Kubernetes 專案中計劃的主要變更：預先思考
不要只看下一個版本。在新版本的 Kubernetes 發佈時檢閱這些版本，並識別重大變更。例如，某些直接使用 Docker 的應用程式API，以及對 Docker （也稱為 DockershimCRI） 的 Container Runtime Interface （） 的支援已在 Kubernetes 中移除1.24。這種變更需要更多時間來準備。
檢閱您要升級到的版本的所有記錄變更，並記下任何必要的升級步驟。此外，請注意 Amazon EKS受管叢集特有的任何要求或程序。
功能移除的特定指南
移除 1.25 中的 Dockershim - 使用 Docker Socket 的偵測器 （DDS）
EKS Optimized AMI for 1.25 不再包含對 Dockershim 的支援。如果您有 Dockershim 的相依性，例如您要掛載 Docker 通訊端，您需要先移除這些相依性，才能將工作節點升級至 1.25。
在升級至 1.25 之前，尋找您依賴 Docker 通訊端的執行個體。建議使用 Detector for Docker Socket （DDS），這是 kubectl 外掛程式。
在 1.25 PodSecurityPolicy 中移除 - 遷移至 Pod 安全標準或 policy-as-code解決方案
PodSecurityPolicy 在 Kubernetes 1.21 中已棄用
AWS 已發佈EKS文件中的詳細 FAQ 。
檢閱 Pod 安全標準 （PSS） 和 Pod 安全許可 （PSA）
檢閱 PodSecurityPolicyKubernetes 網站上的棄用部落格文章
1.23 中樹體內儲存驅動程式的棄用 - 遷移至容器儲存介面 （CSI） 驅動程式
Container Storage Interface （CSI） 旨在協助 Kubernetes 取代其現有的樹狀儲存驅動程式機制。Amazon EKS1.23及更新版本的叢集預設會啟用 Amazon EBS容器儲存介面 （CSI） 遷移功能。如果您的 Pod 在 版本1.22或更早的叢集上執行，則必須先安裝 Amazon EBSCSI驅動程式，才能將叢集更新至 版本1.23，以避免服務中斷。
檢閱 Amazon EBSCSI遷移常見問答集 。
其他資源
ClowdHaus EKS 升級指南
ClowdHaus EKS 升級指南
GoNoGo
GoNoGo
