Kubernetesにおけるリソース管理: スケーリング vs リソース制限のアプローチ
目次
はじめに
Kubernetes（K8s）は、コンテナ化されたアプリケーションのデプロイメント、スケーリング、運用を自動化するためのプラットフォームです。この記事では、Kubernetesにおけるリソース管理の2つの主なアプローチについて詳しく説明します。
Kubernetesの基本的なリソース制御機構
requests と limits とは？
Kubernetesにおけるリソース管理: スケーリング vs リソース制限のアプローチ
目次
はじめに
Kubernetes（K8s）は、コンテナ化されたアプリケーションのデプロイメント、スケーリング、運用を自動化するためのプラットフォームです。この記事では、Kubernetesにおけるリソース管理の2つの主なアプローチについて詳しく説明します。
Kubernetesの基本的なリソース制御機構
requests と limits とは？
Kubernetesでは、requestsとlimitsを用いて、Podやコンテナのリソース使用量を制御します。requestsはリソースの保証される最小量を、limitsは許容される最大量を指定します。
例：
resources:
requests:
memory: "1Gi"
cpu: "500m"
limits:
memory: "2Gi"
cpu: "1"
Quality of Service (QoS) クラスの概要
Kubernetesは、Node上のリソースが不足する場面で、どのPodを先に追い出す（Evict）かを決定する際の基準として、QoSクラスを使用します。
QoSクラスの優先順位
-
BestEffort:
- 最低の優先順位を持ちます。
- Pod内の全てのコンテナがCPUもメモリも
requestsやlimitsを持たない場合にこのクラスになります。 - リソース不足時には最初に追い出される傾向があります。
-
Burstable:
- 中間の優先順位を持ちます。
- Pod内の少なくとも1つのコンテナがCPUまたはメモリの
requestsを持ち、かつ、requestsとlimitsが異なる、またはlimitsが指定されていない場合にこのクラスになります。 - BestEffortよりは追い出しにくいが、Guaranteedよりは追い出しやすい。
-
Guaranteed:
- 最高の優先順位を持ちます。
- Pod内の全てのコンテナが等しい
requestsとlimitsを持つ場合にこのクラスになります。 - リソース不足時でも最後まで残される傾向があります。
Podの追い出しフロー
Node上でのリソースが圧迫されると、Kubernetesは以下の手順でPodの追い出しを試みます：
- 不足しているリソースのタイプ（例：メモリ、CPU）を特定します。
- 該当Node上のPodをQoSクラスの優先順位と、同一QoSクラス内でのPodのエイジ（稼働時間）に基づきソートします。
- ソート順に基づき、最も低い優先順位のPodから順に追い出しを試みます。
このフローにより、Kubernetesはシステムの全体的な安定性を維持しつつ、リソースの不足を効果的に管理します。
もちろん、KubernetesにおけるPodの追い出しの優先順位の詳細について説明します。
Podの追い出しの優先順位
Kubernetesは、Node上でリソースが圧迫されている場合に、どのPodを先に追い出すかを決定するための明確な優先順位が定められています。この優先順位は主に2つの基準に基づいています：QoSクラスとPodのエイジ（稼働時間）。
-
QoSクラスの優先順位:
- 先述の通り、
BestEffort<Burstable<Guaranteedの順番で優先度が低から高になっています。 - つまり、リソースが圧迫された際には、まず
BestEffortクラスのPodが追い出される可能性が高く、最後にGuaranteedクラスのPodが対象となります。
- 先述の通り、
-
同一QoSクラス内でのPodのエイジ（稼働時間）:
- 同一のQoSクラス内では、Podのエイジ（稼働時間）が短いものから優先的に追い出されます。
- Kubernetesは新しくスタートしたばかりのPodを追い出すことで、長時間稼働しているPodやより安定したPodの稼働を保護します。
具体的には、もしBurstableクラスのPodが複数Node上に存在し、そのNodeでメモリなどのリソースが不足している場合、最も新しく起動されたBurstableクラスのPodが最初に追い出されることになります。このロジックにより、長く稼働しているPodは短期間しか稼働していないPodよりも重要なジョブを実行している可能性が高いと判断され、追い出しの対象から保護されることになります。
このような優先順位付けは、システムの全体的な安定性と効率を保つために設計されています。
Nodeのスケーリングを活用するアプローチ
このアプローチでは、Podのリソース制限を設けず、必要に応じてNodeの数を動的に増減させます。
主な特徴
- リソースの自由な使用
- Cluster Autoscalerの利用
適用シナリオと利点
- クラウド環境や変動するトラフィック
- 効率的なリソース利用とコスト最適化
Cluster Autoscalerの役割
Cluster Autoscalerは、リソースの要求に応じてNodeの数を自動的にスケーリングします。
# Cluster Autoscalerの導入例
kubectl apply -f <autoscaler-config>
リソース制限を活用するアプローチ
固定されたNode数で運用する際に、各Podにリソースの上限と下限を明確に設定します。
主な特徴
-
requestsとlimitsの明確な設定 - Nodeの数は固定
適用シナリオと利点
- リソ
ース使用量が予測可能なワークロード
- 高いリソースの保証
2つのアプローチの選択基準
どちらのアプローチを選択するかは、運用環境、ワークロードの特性、SLA要件に基づきます。
まとめ
Kubernetesのリソース管理は、運用の効率と安定性を確保するための鍵となります。適切なアプローチの選択と適切な設定は、成功のための基盤を築くために不可欠です。