スキップしてコンテンツを表示

Amazon EKS ワーカーノードに対するディスク負荷を解決する方法を教えてください。

所要時間1分
0

Amazon Elastic Kubernetes サービス (Amazon EKS) ワーカーノードにおいて、ディスク負荷が過剰となっているため、解決したいです。

簡単な説明

使用可能なディスク容量が減少すると、Kubernetes ワーカーノードにディスク負荷がかかります。ディスク負荷を軽減するには、EBS ボリュームサイズを増やすか、新しいワーカーノードをノードグループに追加してディスク容量を増やします。さらに、Kubelet イメージのガベージコレクションのしきい値を調整したり、コンテナランタイムのログローテーションを設定したり、未使用のイメージを手動でクリーンアップしたりすることでも、ディスク使用率を効果的に管理できます。

ディスク負荷の問題を防ぎ、Kubernetes クラスターの正常な動作を保証するには、エフェメラルストレージの監視と管理が重要です。

ディスクに過負荷がかかっている場合、エラーメッセージが表示される場合があります。

ノードに対しては、次の例に類似したエラーメッセージが表示される場合があります。

"Warning DiskPressure ... kubelet, worker-node DiskPressure on node"

Kubelet に対しては、次の例に類似したエラーメッセージが表示される場合があります。

"Disk usage on image filesystem is over the high threshold, trying to free bytes down to the low threshold"

問題を確認するには、df-h コマンドを実行してワーカーノードのディスク使用率を確認します。

出力例:

/dev/nvme0n1p1   20G   18G  2.2G  90% /       
........

注: 上記の例では、ルートファイルシステム /dev/nvme0n1p1 の使用率は 90% です。使用率が高くなると、ディスク負荷が原因でイメージガベージコレクションに障害が発生します。

解決策

EBS ボリュームサイズを増やす

使用可能なディスク容量を増やすには、ワーカーノードにアタッチされた EBS ボリュームのサイズを増やします。詳細については、「EBS ボリュームのサイズを拡大または縮小する方法を教えてください」を参照してください。

注: エフェメラルボリュームのサイズを変更するのではなく、新しいインスタンスを目的のディスクサイズでプロビジョニングすることをおすすめします。古いインスタンスを新しいインスタンスで置き換えると、新しいインスタンスには適切なディスクサイズが割り当てられ、不変なインフラストラクチャの考え方に沿ったものになります。

ノードグループに新しいワーカーノードを追加する

新しいノードをノードグループまたはプールに追加し、クラスターにディスクボリュームを追加すると、ワークロードを複数のノードに分散できます。この方法では、単一ノードに対するディスク負荷が軽減されます。

Kubelet ガベージコレクターにカスタムしきい値を設定する

Kubelet で設定を行い、複数のディスク使用率のしきい値でイメージガベージコレクションを開始するようにします。--image-gc-high-threshold 引数および --image-gc-low-threshold 引数を指定し、バッファ許容量を増やします。たとえば、上限しきい値を 70% に、下限しきい値を 60% に設定すると、空きディスク容量のバッファを増やすことができます。この構成を行うと、Kubelet はディスク容量の深刻な枯渇が発生する前にイメージのガベージコレクションを実行できます。

ワーカーノードでこれらの引数を指定する方法の詳細については、「Amazon EKS ワーカーノードで設定を行い、ディスク使用量が指定した割合に達した際に、イメージキャッシュをクリーンアップする方法を教えてください」を参照してください。

コンテナランタイムのログローテーションを確認、調整する

コンテナ化されたアプリケーションはログを stdoutstderr に書き込みます。ログファイルは、コンテナランタイムによって管理されます。ワーカーノード上のコンテナランタイムでログローテーション設定を調整することをおすすめします。

ログローテーションを構成するには、containerd において、構成ファイル /etc/cotainerd/config/toml で containerd.runc.log オプションを指定します。log_file_max オプションと log_file_max_size オプションを指定すると、ローテーションするログファイルの最大数および、各ログファイルの最大サイズを制御できます。

未使用のコンテナイメージをクリーンアップする

Kubelet がイメージのガベージコレクションを自動実行できない場合は、ワーカーノード上の未使用のコンテナイメージを手動でクリーンアップします。crictl rmi --prune コマンドを実行すると、ダングリング状態のイメージや未使用のイメージを削除し、有意なディスク容量を確保できます。

エフェメラルストレージを管理する

アプリケーションの長期的な安定性と円滑な運用を実現するために、エフェメラルストレージを適切に管理することをおすすめします。エフェメラルストレージに制限を設定しない場合、ポッドを実行するノードのディスク容量が枯渇する可能性があります。

このリスクを軽減するには、エフェメラルストレージに対する適切なリクエスト量を設定し、ポッドに制限を適用します。適用する制限を判断するには、次の手順を実行します。

  • アプリケーションのストレージニーズ、一時データ、およびエフェメラルストレージに保存されているその他のファイルを分析し、ポッドストレージの要件を特定します。各ポッドのストレージ要件をこの方法で推定します。
  • ポッドが正しく機能するために必要なエフェメラルストレージの最小量を定義し、エフェメラルストレージに対するリクエスト量と制限を設定します。この方法により、Kubernetes スケジューラーは、ポッドに十分なストレージリソースを持つノードを割り当てられます。
    例:
    apiVersion: v1
    kind: Pod
    metadata:
      name: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:latest
        resources:
            requests:
                ephemeral-storage: "1Mi"
            limits:
                ephemeral-storage: "2Mi"
AWS公式更新しました 4ヶ月前
コメントはありません

関連するコンテンツ