Karpenter 1.0 升級指南：Kubernetes 成本大幅優化秘籍

利用 Karpenter 1.0 提升成本效益：升級指南

Karpenter 是一款 Kubernetes 集群管理工具，提供動態節點供應和成本優化功能。最初，它被設計為 Kubernetes 集群自動擴展器的高性能、靈活替代方案。經過幾年的發展，Karpenter 已演變成一個更全面的節點生命週期管理器，與 Kubernetes 原生集成。隨著 Karpenter 1.0 的發布，組織現在可以利用穩定的 API 和增強功能，自動化基礎設施擴展，實現更高的精確度。

本文探討 Karpenter 的起源、推動其採用的關鍵功能、升級到 Karpenter 1.x 的基礎知識以及生產環境中最大化價值的最佳實踐。

穩步成熟的自動擴展器
——————————

Karpenter 最初由 Fairwinds 團隊為特定客戶部署，後來逐漸推廣到其他客戶。AWS Karpenter 於 2021 年 11 月首次發布，是一款開源、高性能的 Kubernetes 集群自動擴展器，現已發展成熟。它被捐贈給雲原生計算基金會（CNCF），通過 Kubernetes 自動擴展特別興趣小組（SIG），現在是 Amazon EKS 和 Azure AKS 的開源工具，未來計劃支持其他雲提供商。

早期採用者面臨一些挑戰，包括 alpha/beta 階段的快速 API 變更，需要頻繁調整。此外，Spotinst Ocean 和 CAST.AI 等付費替代方案提供了類似的節省，但缺乏與 Kubernetes 的原生集成。隨著 v1.0 版本的發布，Karpenter 的 API 現在更加穩定，使其成為 Fairwinds 所有客戶的寶貴標準附加組件，能夠通過智能整合和 Spot 实例利用降低 30-50% 的 Amazon Elastic Compute Cloud（AWS EC2）成本。

對於熟悉集群自動擴展器的人來說，兩者都提供自動擴展 Kubernetes 集群的功能，但在架構、靈活性和運營效率方面存在顯著差異。集群自動擴展器是一款成熟、廣泛採用的工具，在節點組級別運行，根據待處理的 pod 和用戶指定的擴展策略調整預定義節點組的大小。這提供了精確的控制和對多雲提供商和自託管環境的廣泛支持，使其成為需要多雲支持和詳細放置策略的組織的理想選擇。然而，集群自動擴展器可能更復雜，擴展速度更慢，因為它依賴雲提供商的抽象，如自動擴展組，需要手動配置實例類型和組大小。

相比之下，Karpenter 直接與雲提供商的 API 交互，根據實際工作負載需求動態供應最佳節點類型。這實現了更快速、更具成本效益的擴展、先進的工作負載整合以及對 Spot 实例的一流支持，減少了運營開銷和基礎設施成本。Karpenter 特別適用於 AWS 環境，在需要快速擴展和資源優化的場景中表現出色，儘管在多雲支持方面不如集群自動擴展器成熟。

推動 Karpenter 採用的功能
———————————–

### 1. 增強的中斷控制

粒度中斷預算允許針對特定場景（利用不足、漂移、空），在成本節省和應用程序穩定性之間取得平衡。

### 2. 節點生命週期控制

consolidateAfter 參數延遲了利用不足節點的整合，以便服務能夠處理流量突增，而 terminationGracePeriod 確保集群始終具有新鮮的節點，從而減少了具有過時配置或未文檔手動長期運行的節點的機會。

### 3. 漂移管理

當基礎設施偏離所需狀態（例如，過時的 Amazon Machine Images（AMIs））時，自動節點替換現在是一項穩定功能。這簡化了集群節點的維護，無需在節點上進行手動更改的風險。

### 4. 多雲靈活性

雖然針對 AWS 進行了優化，但 Karpenter 1.0 支持混合/多雲環境，在 AWS、Alibaba Cloud 和 Azure 等提供商之間實現一致擴展。

升級路線圖：v0.37.x 至 v1.1.x
———————————-

在開始之前，請注意 Karpenter v1.0 是一個重大版本，包含破壞性變更。請在升級前查看完整的變更日誌。

* 確保您使用的是兼容的 Kubernetes 版本以及支持向後兼容的 0.37.x Karpenter 版本（以防升級失敗，需要回滾）。
* 一旦驗證完成，請升級到 0.37.x 至 1.0.9，支持 v1 和 v1beta1 API。確保 webhook 已啟用 Custom Resource Definitions（CRDs），並指向部署 Karpenter 的正確命名空間。
* 將 EC2Nodeclasses 和 Nodepools 遷移到 Karpenter v1 API。上述變更日誌突出了大部分變更，包括：
* Kubelet 字段已從 NodePool 移至 EC2NodeClass
* NodePool 的 ConsolidationPolicy WhenUnderutilized 更名為 WhenEmptyOrUnderutilized
* ExpireAfter 已從 Spec.Disruption 區塊移至 Spec.Template.Spec 區塊，現在可漂移
* Ubuntu AMIFamily 已刪除
* 變更日誌中記錄了更多變更
* 一旦所有自定義資源遷移完成，請在節點角色中添加任何其他策略
* 最後，將 Karpenter 從 1.0.9 升級到 1.1.x，後者刪除了對 v1beta1 API 的支持。

### 驗證升級成功

部署測試工作負載以驗證節點供應：

apiVersion: apps/v1
kind: Deployment
metadata:
name: karpenter-test
spec:
replicas: 5
template:
spec:
nodeSelector:
karpenter.sh/capacity-type: spot
tolerations:
– key: “karpenter”
value: “true”
effect: NoSchedule
containers:
– name: stress-test
image: public.ecr.aws/nginx/nginx:latest
resources:
requests:
cpu: “2”
memory: 4Gi

通過以下 CLI 命令監控節點啟動：

kubectl get nodeclaims -owide

### 確保最大價值的最佳實踐

1. **環境特定調優**
* 對集群使用 consolidationPolicy: WhenEmptyOrUnderutilized
* 為批處理工作負載設置 terminationGracePeriod: 1h
2. **安全強化**

* 啟用 IMDSv2 並限制 pod 级別的元數據訪問
* 實施 OpenID Connect（OIDC）集成以進行身份和訪問管理（IAM）角色
* 在生產集群中通過固定到特定版本來鎖定 AMIs

4. **成本監控**

* 使用 karpenter.sh/node-pool 標記節點以實現粒度成本分配
* 與 Fairwinds Insights、OpenCost 或 Datadog 結合使用，以實現跨集群可視性

6. **穩定性**

* 確保 Karpenter 在不受 Karpenter 管理的節點上運行，以防止調度問題
* 在使用 Spot 節點時啟用中斷處理，以實現工作負載的正常關閉

Karpenter 使用者的現實世界影響
————————————-

Karpenter 1.x 為 Kubernetes 生產環境帶來了顯著的好處，包括動態、實時節點供應、通過智能工作負載整合和 Spot 实例使用實現成本優化，以及增強的中斷控制以維護高可用性和可靠性。

這些功能允許團隊高效擴展基礎設施、減少運營開銷，並確保工作負載始終與最合適的資源匹配。然而，充分發揮 Karpenter（以及 Kubernetes）的價值需要持續關注最佳實踐，例如仔細管理 AMI 版本、設置準確的資源請求以及監控基礎設施和工作負載的效率和安全性。

對於許多組織來說，Kubernetes 運營的複雜性，包括頻繁升級、附加組件管理和 24/7 監控，可能會迅速超過內部資源，特別是在集群擴展或組織採用多雲策略時。

如果您需要幫助，Fairwinds Managed Kubernetes-as-a-Service 處理所有 Kubernetes 升級、附加組件更新和安全補丁。它還包括專家 SRE 支持、主動監控和基礎設施問題的快速響應，解放您的內部團隊擺脫日常維護的負擔，讓他們專注於創新和業務差異化。

作為編輯，我想補充一些見解：Karpenter 1.0 的發布標誌著 Kubernetes 集群管理的一個重要里程碑。它的增強功能和穩定 API 使其成為尋求優化 Kubernetes 集群成本效益和效率的組織的有吸引力的選擇。然而，實施 Karpenter 需要仔細考慮升級路徑、環境特定調優和安全強化，以確保順利過渡和最大化價值。

此外，Karpenter 與其他 Kubernetes 工具（如 Fairwinds Insights 和 OpenCost）的集成提供了對集群性能和成本的全面可視性，使組織能夠做出明智的決策並優化資源利用。

總之，Karpenter 1.0 為 Kubernetes 集群管理提供了強大的解決方案，組織應考慮其優勢和最佳實踐，以充分發揮其潛力。