Kubernetesにおけるリソース管理: スケーリング vs リソース制限のアプローチ

# Kubernetesにおけるリソース管理: スケーリング vs リソース制限のアプローチ

## 目次

- [はじめに](#はじめに)
- [Kubernetesの基本的なリソース制御機構](#kubernetesの基本的なリソース制御機構)
- [Nodeのスケーリングを活用するアプローチ](#nodeのスケーリングを活用するアプローチ)
- [リソース制限を活用するアプローチ](#リソース制限を活用するアプローチ)
- [2つのアプローチの選択基準](#2つのアプローチの選択基準)
- [まとめ](#まとめ)

---

## はじめに

Kubernetes（K8s）は、コンテナ化されたアプリケーションのデプロイメント、スケーリング、運用を自動化するためのプラットフォームです。この記事では、Kubernetesにおけるリソース管理の2つの主なアプローチについて詳しく説明します。

---

## Kubernetesの基本的なリソース制御機構

### `requests` と `limits` とは？

# Kubernetesにおけるリソース管理: スケーリング vs リソース制限のアプローチ

## 目次

- [はじめに](#はじめに)
- [Kubernetesの基本的なリソース制御機構](#kubernetesの基本的なリソース制御機構)
- [Nodeのスケーリングを活用するアプローチ](#nodeのスケーリングを活用するアプローチ)
- [リソース制限を活用するアプローチ](#リソース制限を活用するアプローチ)
- [2つのアプローチの選択基準](#2つのアプローチの選択基準)
- [まとめ](#まとめ)

---

## はじめに

Kubernetes（K8s）は、コンテナ化されたアプリケーションのデプロイメント、スケーリング、運用を自動化するためのプラットフォームです。この記事では、Kubernetesにおけるリソース管理の2つの主なアプローチについて詳しく説明します。

---

## Kubernetesの基本的なリソース制御機構

### `requests` と `limits` とは？

Kubernetesでは、`requests`と`limits`を用いて、Podやコンテナのリソース使用量を制御します。`requests`はリソースの保証される最小量を、`limits`は許容される最大量を指定します。

例：

```yaml
resources:
  requests:
    memory: "1Gi"
    cpu: "500m"
  limits:
    memory: "2Gi"
    cpu: "1"
```

### Quality of Service (QoS) クラスの概要

Kubernetesは、Node上のリソースが不足する場面で、どのPodを先に追い出す（Evict）かを決定する際の基準として、QoSクラスを使用します。

### QoSクラスの優先順位

1. **BestEffort**:
    - 最低の優先順位を持ちます。
    - Pod内の全てのコンテナがCPUもメモリも`requests`や`limits`を持たない場合にこのクラスになります。
    - リソース不足時には最初に追い出される傾向があります。

2. **Burstable**:
    - 中間の優先順位を持ちます。
    - Pod内の少なくとも1つのコンテナがCPUまたはメモリの`requests`を持ち、かつ、`requests`と`limits`が異なる、または`limits`が指定されていない場合にこのクラスになります。
    - BestEffortよりは追い出しにくいが、Guaranteedよりは追い出しやすい。

3. **Guaranteed**:
    - 最高の優先順位を持ちます。
    - Pod内の全てのコンテナが等しい`requests`と`limits`を持つ場合にこのクラスになります。
    - リソース不足時でも最後まで残される傾向があります。

### Podの追い出しフロー

Node上でのリソースが圧迫されると、Kubernetesは以下の手順でPodの追い出しを試みます：

1. 不足しているリソースのタイプ（例：メモリ、CPU）を特定します。
2. 該当Node上のPodをQoSクラスの優先順位と、同一QoSクラス内でのPodのエイジ（稼働時間）に基づきソートします。
3. ソート順に基づき、最も低い優先順位のPodから順に追い出しを試みます。

このフローにより、Kubernetesはシステムの全体的な安定性を維持しつつ、リソースの不足を効果的に管理します。

もちろん、KubernetesにおけるPodの追い出しの優先順位の詳細について説明します。

### Podの追い出しの優先順位

Kubernetesは、Node上でリソースが圧迫されている場合に、どのPodを先に追い出すかを決定するための明確な優先順位が定められています。この優先順位は主に2つの基準に基づいています：**QoSクラス**と**Podのエイジ（稼働時間）**。

1. **QoSクラスの優先順位**:
    - 先述の通り、`BestEffort` < `Burstable` < `Guaranteed` の順番で優先度が低から高になっています。
    - つまり、リソースが圧迫された際には、まず`BestEffort`クラスのPodが追い出される可能性が高く、最後に`Guaranteed`クラスのPodが対象となります。

2. **同一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の数を自動的にスケーリングします。

```bash
# Cluster Autoscalerの導入例
kubectl apply -f <autoscaler-config>
```

---

## リソース制限を活用するアプローチ

固定されたNode数で運用する際に、各Podにリソースの上限と下限を明確に設定します。

### 主な特徴

- `requests`と`limits`の明確な設定
- Nodeの数は固定

### 適用シナリオと利点

- リソ

ース使用量が予測可能なワークロード
- 高いリソースの保証

---

## 2つのアプローチの選択基準

どちらのアプローチを選択するかは、運用環境、ワークロードの特性、SLA要件に基づきます。

---

## まとめ

Kubernetesのリソース管理は、運用の効率と安定性を確保するための鍵となります。適切なアプローチの選択と適切な設定は、成功のための基盤を築くために不可欠です。