MEGAZONEブログ
Karpenter:Amazon EKS best practices and cloud cost optimization
Karpenter:Amazon EKSのベストプラクティスとクラウドコストの最適化
Pulisher : Strategic Tech Center チャン・セジョン
Description:Amazon EKSの設定方法や Karpenterがどのように拡張されるかを理解し、Karpenterを通じたワークロードの最適化について実践してみるセッション
はじめに
現在EKS関連の仕事をしていて、EKSの長所であるトラフィックの増減によるPodとNodeのAutoscalingについて普段から関心を持っていましたが、ノードレベルのAutoscalerの一つであるKarpenterの実習をするセッションがあったので申し込みました。
セッションの概要紹介
Karpenterを使用してAmazon EKSを設定する方法を学び、アプリケーション要件に応じてKarpenterがどのように拡張されるかを理解し、Karpenterを通じたワークロードの最適化について実践してみる時間です。
Data Planeの適切なサイズは何で、ワークロードに応じて継続的に最適化するにはどうすればよいか?
アプリケーションの要件に応じてデータプレーンをどのように拡張するのか?
インフラストラクチャの管理をどのように簡素化するか?
このような質問に対する答えは、これからお話しするKarpenterです。
Amazon EC2には約700種類以上のインスタンスタイプがあります。
Memory特化インスタンス、Storage特化インスタンスなどの特定の性能によるインスタンスタイプがあります。
Intel、AMDなどのProcessor別インスタンスタイプなどがあります。
また、On-Demand、SPOTインスタンスのような購入オプションによるインスタンスタイプなど数多くのタイプのEC2タイプが存在します。
この複数のインスタンスタイプのうち、Karpenterによるコスト削減が可能なタイプであるSPOTインスタンスについて説明します。
SPOTインスタンスはOn-Demandインスタンスに比べて最大90%のコストを削減することができます。
ワークロードの種類がContainerあるいはBatchやCI/CDの場合、SPOTに適したワークロードです。
Karpenterは、適切なタイミングでワークロードに応じた適切なノードを使用することで、Kubernetesインフラストラクチャを合理化します。
Karpenterによって管理されるNodePoolには、複数のインスタンスタイプを組み合わせて使用することができます。
この時、SPOTインスタンスも混ぜて使うことで、EC2インスタンス使用に対するコスト削減効果も得ることができます。Karpenterの設定で使うインスタンスタイプをSPOTとOn-Demandを混ぜて入れれば、利用可能なSPOTインスタンスをNodePoolに混ぜて使うことができます。
アプリケーションPodがHPAによってPod増設が行われる時、それ以上のPodが起動される余裕Resourceがない場合、KarpenterはPending Podを検知して新しいノードを増設するAPIが呼び出されます。
もし、Cluster Autoscalerだったら、途中でASGにノード増設を要請するAPI呼び出し部分が真ん中に存在することになります。 KarpenterはCluster Autoscalerと違って真ん中にASGを通す部分がないので、ノード増設がより速くなります。
逆にKarpenterはワークロードが少なくなると、それに合わせてノードを減らします。
この時、ノードを減少させる条件に合致すれば、ノードが削除したり、統合されます。
Podが他のノードの空き容量で実行できる場合と、ノードが空いている場合、ノードを削除します。
Podがクラスター内の他のノードの空き容量の組み合わせで実行できる場合、またはより効率的な代替ノードがある場合、ノードを交換します。
AWSでKarpenterをインストールして、実習する基本的な設定をすでに済ませておいて、このワークショップの時間が終わったら、実習アカウントにもうアクセスすることができないことを注意事項として教えてくれます。
それでは、Karpenterについて分かったので、実習をしてみましょう。
セッションを終えて
残りの時間はWorkshopの実習時間としてAWSが提供してくれたWorkshopウェブページのガイドに沿って進めながらKarpenterを直接インストールしてトラフィックを増減させてノードが増設されたり減る部分まで直接実習することができました。
実行されるPodのResourceの大きさによって、それに合わせて適切なサイズのノードが増設されるのを見ながら
空きResourceを最小限にしてコスト削減効果まで直接体感することができた良いセッションでした。