Kubernetes Cluster Autoscalerとは?
Kubernetes Cluster Autoscalerは、現在のワークロードの需要に応じてKubernetesクラスタのサイズを自動的に調整するオープンソースコンポーネントです。リソース不足によりスケジュールできないPodを監視し、必要に応じてノードを追加してクラスタをスケールアップします。逆に、使用率の低いノードを検出し、不要なノードを削除してクラスタをスケールダウンすることで、最適なリソース利用とコスト効率を実現します。
この動的なスケーリングにより、手動での介入なしに高可用性とパフォーマンスを維持できます。Cluster AutoscalerはAWS、Azure、Google Cloudをはじめとする複数のクラウドプロバイダーに対応しており、各社のマネージドKubernetesサービスとシームレスに統合されます。プロバイダー固有のAPIを利用して必要に応じてノードのプロビジョニングと廃止を行うため、変化するトラフィックパターンにリアルタイムで対応できます。
本記事は、Kubernetesオートスケーリングに関する連載記事の一部です。
この記事の内容:
Helmチャートとは?
Helmチャートは、Kubernetesアプリケーション向けの標準化されたパッケージで、複雑なワークロードの定義・設定・デプロイに必要なすべてのYAMLマニフェストとテンプレートを含んでいます。アプリケーションのリソース、依存関係、設定値を再利用可能な単一の成果物としてまとめることで、デプロイプロセスを簡素化します。Helmチャートでは次のことが可能です:
- バージョン管理
- 共有
- リポジトリでの保管
Helmチャートを使うことで、チームはアプリケーションのインストール、アップグレード、ロールバックを自動化でき、ヒューマンエラーのリスクを減らし、環境間の一貫性を確保できます。Helmのテンプレートエンジンによりデプロイをカスタマイズでき、valuesファイルやコマンドライン引数を通じてデフォルト値を上書きすることが可能です。
クイックスタート:Helm ChartでCluster Autoscalerを実行する
Cluster Autoscaler Helm Chartの前提条件
Cluster Autoscalerチャートをインストールする前に、Helm 3以降とKubernetes 1.35.x以降を使用していることを確認してください。Azure AKSでは、RBACが有効なKubernetes 1.10以降が必要です。
Cluster Autoscalerは内部でKubernetesスケジューラーの動作をシミュレートします。コンテナイメージを上書きすれば他のKubernetesバージョンでも動作する可能性はありますが、バージョンの不一致は気づきにくいスケジューリング上の問題を引き起こすことがあります。現在のチャートはHelmチャートAPIバージョンv2を使用しているため、Helm 3より前のバージョンはサポートされていません。
cluster-autoscaler-chartの1.X系から移行する場合は、cluster-autoscalerバージョン9.0.0以降をインストールする前に、既存のリリースをアンインストールしてください。旧1.X系のチャートリリースは非推奨です。
ステップ1:Cluster AutoscalerのHelmリポジトリを追加する
Cluster Autoscalerチャートは、autoscaler/cluster-autoscalerのチャートパスからインストールします。インストールの前に、このチャートを含むリポジトリがHelm環境に設定されていることを確認してください。
このチャートは、デフォルト値のままでは動作可能なオートスケーリングのデプロイメントを作成しません。インストール時に、ノードグループの自動検出または静的ノードグループのいずれかを設定する必要があります。両方のアプローチを併用することは推奨されません。
自動検出を使用する場合は、autoDiscovery.clusterNameと必要なプロバイダー固有の値を設定します。静的に設定する場合は、autoscalingGroupsまたはautoscalingGroupsnamePrefixで1つ以上のグループを定義します。
ステップ2:HelmでCluster Autoscalerをインストールする方法
helm installでチャートをインストールし、利用するクラウドプロバイダーに必要な設定を指定します。設定をvaluesファイルに保存している場合は、次のように実行します:
helm install my-release autoscaler/cluster-autoscaler \-f myvalues.yaml
valuesでは、オートスケーラーが管理できるノードグループを指定する必要があります。autoDiscovery.clusterNameで自動検出を設定するか、グループとその最小・最大サイズを明示的に定義できます。
インストール後は、オートスケーラーのログを確認し、メインループが実行されていることを確かめてください。実行されていない場合は、生成されたPodを調べ、cluster-autoscalerコマンドに渡された引数を確認します。
ステップ3:HelmでAWSにCluster Autoscalerをインストールする
AWSでは、Cluster AutoscalerがAuto Scalingグループ(ASG)を自動検出できます。管理対象の各ASGに、k8s.io/cluster-autoscaler/enabledおよびk8s.io/cluster-autoscaler/<CLUSTER NAME>というキーでタグを付けます。意味を持つのはタグのキーのみです。
次に、クラスタ名とAWSリージョンを指定してチャートをインストールします:
helm install my-release autoscaler/cluster-autoscaler \\
\--set autoDiscovery.clusterName=<CLUSTER NAME> \\
\--set awsRegion=<YOUR AWS REGION>
インストール時にawsAccessKeyIDとawsSecretAccessKeyを指定することもできます。Amazon EKSの場合は、オートスケーラーのサービスアカウントをIAMロールに関連付け、サービスアカウントのアノテーションを通じてそのARNを渡す方法もあります。
自動検出を使用しない場合は、ASGを手動で指定します:
helm install my-release autoscaler/cluster-autoscaler \\
\--set "autoscalingGroups\[0\].name=your-asg-name" \\
\--set "autoscalingGroups\[0\].maxSize=10" \\
\--set "autoscalingGroups\[0\].minSize=1"
オートスケーラーを実行するワーカーには、対象となるAWS Auto Scalingリソースを参照・変更するために必要なIAM権限が付与されている必要があります。
関連コンテンツ:Karpenter vs. Cluster Autoscalerの比較記事もご覧ください
ステップ4:Cluster Autoscaler Helm Chartをアップグレードする
古いインストールをアップグレードする際は、チャートバージョンの変更点に注意してください。バージョン9.0.0以降のリリースは、cluster-autoscalerというチャート名を使用します。非推奨の1.X系cluster-autoscaler-chartリリースから移行するには、まず既存の1.X系のインストールをアンインストールし、その後バージョン9.0.0以降をインストールします。
また、バージョン9.1.0ではenvFromConfigMapの意味が変更されています。envFromで参照するConfigMapの名前を指定する必要があります。従来のenvFromConfigMapの動作に依存している設定は、その設定名をextraEnvConfigMapsに変更してください。
参考として、リリースは次のコマンドで削除できます:
helm uninstall my-release
これにより、そのHelmリリースに関連付けられたKubernetesコンポーネントが削除されます。バージョンを変更する前に、インストール済みバージョンと移行先のチャートバージョンの間で変更された可能性のある設定値を確認してください。
Cluster Autoscaler Helm Chartのベストプラクティス
Cluster Autoscaler用のHelmチャートを扱う際に押さえておきたい重要なプラクティスを紹介します。
1. CPUとメモリのリクエストをライトサイジングする
Cluster Autoscalerを使用する際、ワークロードのCPUおよびメモリリクエストのライトサイジングは欠かせません。リクエストが高すぎると、スケジューラーがノードを過剰にプロビジョニングし、リソースの無駄とコストの増加につながります。逆にリクエストが低すぎると、リソースの競合やアプリケーションの不安定化を招くおそれがあります。
主なアクション:
- 過去のリソース使用状況を分析し、デフォルト値や推測ではなく実際のニーズに基づいてリクエストとリミットを設定する。
- ワークロードの変化に合わせて、これらの設定を定期的に見直し、調整する。
- Kubernetesの監視ツールを使ってリアルタイムのリソース消費を観察し、最適化の機会を見つける。
正確なリソースリクエストはオートスケーラーの効率を高め、本当に必要なときにのみ新しいノードが追加され、既存のリソースが有効に活用されるようにします。
2. ワークロードのライトサイジングとノードオートスケーリングを一つのシステムとして扱う
ワークロードのライトサイジングとノードのオートスケーリングは、切り離して管理すべきではありません。アプリケーションのリソースリクエストの変更は、オートスケーラーによるクラスタのスケーリングに直接影響します。ワークロードが恒常的に過剰プロビジョニングされていると、オートスケーラーは不必要にノードを追加します。一方、プロビジョニング不足はスケジュール不能なPodやパフォーマンスの低下につながります。これらのプロセスを連携させることで、リソースの可用性とコストのバランスを保つことができます。
主なアクション:
- ワークロードのリクエストとノードグループのサイズを連動して調整する自動化ツールやポリシーを導入する。
- 開発チームと運用チームが定期的にコミュニケーションを取り、スケーリングの判断が実際のアプリケーションのニーズを反映するようにする。
ライトサイジングとオートスケーリングを相互に関連するものとして扱うことで、リソース利用率、アプリケーションの安定性、コスト効率を向上させることができます。
関連コンテンツ:Kubernetes Vertical Pod Autoscalerのガイドもご覧ください
3. リソース使用状況を継続的に見直す
効率的なオートスケーリング構成を維持するには、リソース使用状況の継続的な監視が不可欠です。静的なリソース割り当ては、アプリケーションの需要の変化に伴ってすぐに古くなり、非効率やパフォーマンスの問題につながります。使用データを定期的に分析することで、ワークロードのリクエストやオートスケーラーの設定を的確に調整できます。
主なアクション:
- Kubernetesのダッシュボードや監視プラットフォームを使い、CPU、メモリ、ノードの使用率を継続的に追跡する。
- 毎月の監査や異常な使用パターンに対する自動アラートなど、定期的なレビューのプロセスを確立する。
- リソース消費の変化に迅速に対応し、過剰プロビジョニングを防ぎ、クラスタが適切にスケールするようにする。
継続的な見直しはプロアクティブなアプローチを支え、運用コストを削減し、応答性の高い環境を維持します。
4. 効率的なビンパッキングを見据えてノードグループを設計する
効率的なビンパッキングとは、リソース利用率を最大化し、無駄を最小限に抑える形でワークロードをノードに収めることを指します。ノードグループを設計する際は、ワークロードのプロファイルに合ったインスタンスタイプとサイズを選択することが重要です。
主なアクション:
- リソースの断片化や使用率の低下を招く、極端に大きいノードや小さいノードは避ける。
- 類似したワークロードをまとめて使用パターンを予測しやすくし、オートスケーラーの設定を簡素化する。
- アプリケーションの変化に合わせてノードグループの構成を調整する。
- ワークロードの分散状況を監視し、より良いパッキングのためにノードグループを統合・分割する機会を見つける。
効率的なビンパッキングにより、必要なノードの総数が減り、オートスケーラーのパフォーマンスが最適化され、利用可能なリソースを最大限に活用することでインフラコストを削減できます。
5. HPAとCluster Autoscalerを連携させる
Horizontal Pod Autoscaler(HPA)とCluster Autoscalerは、最適なスケーリングを実現するために連携して動作するよう設定する必要があります。HPAはワークロードのメトリクスに基づいてPod数を調整し、Cluster Autoscalerはその基盤となるノードを管理します。HPAが利用可能なノード容量を超えてPodをスケールさせる場合、Cluster Autoscalerはそれらを収容できるだけの速さでノードを追加できなければなりません。設定が噛み合っていないと、Podのスケジューリング失敗や不要なリソース割り当てが発生する可能性があります。
主なアクション:
- HPAとCluster Autoscalerの間でスケーリングポリシーとしきい値を調整する。
- メトリクスとログを使って両者の連携状況を監視し、スケーリング動作のボトルネックや遅延を特定する。
- HPAのターゲットとCluster Autoscalerのパラメータを調整し、バランスの取れた応答性の高いスケーリングを実現する。
両コンポーネントが連携して動作することで、ダウンタイムが減り、アプリケーションの可用性が向上し、効率的なリソース利用が可能になります。
PerfectScaleでCluster Autoscalerの効率を最大化
Cluster AutoscalerやKarpenterのようなノードオートスケーラーは、需要に応じてノードをスケールアップ・ダウンし、クラスタの可用性を高め、アイドルコストを削減します。しかし、その基盤で動くワークロードの設定が誤っていると、どれほど適切に設定されたオートスケーラーでも限界に突き当たります。過剰プロビジョニングされたコンテナは容量を無駄にし、オートスケーラーに必要以上のノードを追加させます。プロビジョニング不足のコンテナはPodの退避やノードへの負荷を引き起こし、非効率なビンパッキングはリソースを十分に活用できないまま不要なスケーリングイベントを発生させます。PerfectScaleはこれらの問題をワークロードとノードのレベルで解決し、オートスケーリング構成が期待どおりの効率を実際に発揮できるようにします。
Kubernetesオートスケーリングに関するPerfectScaleの主な機能:
- プロアクティブな設定エラー検出: ワークロードを継続的に分析し、CPU Request Not Set、Memory Request Not Set、Memory Limit Not Setといった設定エラーを特定・解消することで、予測不能な退避、ノードのオーバーコミット、非効率なオートスケーリングを防ぎます。
- 自律的なワークロードのライトサイジング: 実際の使用率に基づいてワークロードのリソースを即座に調整し、Podのビンパッキングを改善してオートスケーリングの効率を高めます。手動での操作は不要です。
- オートスケーリンググループとノードプールの可視化: オートスケーリンググループとノードプールのコストと使用率を可視化し、クラスタ全体の非効率な箇所を特定できます。
- 最適なノードタイプの選択: 使用率の向上、正確なリソース分配、コスト効率の最大化を実現するノードタイプの選択を支援します。
- 幅広いオートスケーラー対応: Karpenter、Cluster Autoscaler、Node Auto Provisioningと併用でき、ノードレベルの最適化とPodレベルのライトサイジングを組み合わせることで、より良いビンパッキングとより迅速なスケーリング判断を実現します。