EKSリソース調整メモ

前提

• Amazon EKSをセルフマネージド型ノードで運用している
• スポット・オンデマンドインスタンス、Fargateを併用している
  • ステートレスなコンテナ（Webアプリケーション）はスポットインスタンス
  • ステートフルなコンテナ（ジョブ管理サーバーなど）はオンデマンドインスタンス
  • バッチ処理はFargate

基本的な考え方

Kubernetesにおけるリソース調整の軸はおおよそ以下で、それぞれの増減によってトレードオフが生じる

• コンテナ軸の調整
  • replicasの台数
    • 減らすと負荷⬆️、応答性⬇️、コスト⬇️
    • 増やすと負荷⬇️、応答性⬆️、コスト⬆️
  • CPUのrequestsの調整
    • 減らすと集積性⬆️、ノード起因スロットルリスク⬆️、コスト⬇️
    • 増やすと集積性⬇️、ノード起因スロットルリスク⬇️、コスト⬆️
  • CPUのlimitsの調整
    • 減らすとコンテナ起因スロットルリスク⬆️、コスト⬇️
    • 増やすとコンテナ起因スロットルリスク⬇️、コスト⬆️
  • メモリの requests&limitsの調整
    • 減らすと集積性⬆️、OOMリスク⬆️、コスト⬇️
    • 増やすと集積性⬇️、OOMリスク⬇️、コスト⬆️
• ノード軸の調整
  • インスタンスの台数
    • 減らすと負荷⬆️、コスト⬇️
    • 減らすと負荷⬇️、コスト⬆️
  • インスタンススペック（vCPU・メモリ）
    • 増やすと集積性⬆️、停止時リスク⬆️、コスト⬇️
    • 減らすと集積性⬇️、停止時リスク⬇️、コスト⬆️

上記の関係があったときに、リソース最適化とは

• 元々のシステム品質を損なわない範囲で、
  • CPUスロットルが生じるとコンテナのLivenessProbe / ReadinessProbeの失敗率が上昇し、restartが生じる
  • OOMが生じるとプロセスが強制終了させられ、restartが生じる
  • 集積性を高めすぎると、スポットインスタンスの中断やEC2障害発生時の安定性が損なわれる
• コンテナのリソースを調整し
  • requestsを減らして、ノード当たりのコンテナの集積性をあげる
  • limitsを設定、ないし減らして、オーバーコミットによる他コンテナへの影響を最小化する
• ノードのリソースを調整する
  • インスタンスタイプをコンテナの メモリ量 / vCPU数 に近い比率のものに変える
  • オートスケーリンググループによる自動調整や手動変更により、インスタンス台数を最小化する

流れ

以下の順序でやっていく

• 構成把握
• 監視
• コンテナレベルの最適化
• 監視
• ノードレベルの最適化
• 監視

構成把握

環境に適用するすべてのリソースについて、以下を把握する

• コンテナ毎のrequests および limits
  • kube-systemの中にあったりhelmで入れているライブラリの設定状態も見たほうがいい
    • ものによってrequests / limits設定が緩く、高集積性にしすぎた時に影響を受けやすい印象

監視

以下を観測可能にする
メトリクスはDatadogの場合なので、他の監視基盤ならそれに倣う

• コンテナ
  • 死活
    • restartsの数 kubernetes.containers.restarts
    • evictionの数 kubernetes.kubelet.evictions
  • CPU / メモリ比率
    • 割当量ベース kubernetes.memory.requests / kubernetes.cpu.requests
    • 使用量ベース kubernetes.memory.usage / kubernetes.cpu.usage.total
  • CPU
    • requests / limitsの値
    • 使用量 kubernetes.cpu.usage.total
    • CPUスロットルの発生状況
      • 不足CPU時間量 kubernetes.cpu.cfs.throttled.seconds
      • 発生割合 (kubernetes.cpu.cfs.throttled.periods / kubernetes.cpu.cfs.periods) * 100
  • メモリ
    • requests / limitsの値
    • 使用量 kubernetes.memory.usage / 使用率 kubernetes.memory.usage_pct
    • OOMの発生状況
      • kubernetes.containers.last_state.terminated を reason:oomkilled に絞って
      • Datadog eventsから -status: info 以外でイベントを見ておくとよい
  • ディスク
    • ephemeral-storageのlimitsの値
    • ディスク使用量 kubernetes.ephemeral_storage.usage
    • ディスク読み込みバイト数 kubernetes.io.read_bytes
    • ディスク書き込みバイト数 kubernetes.io.write_bytes
  • ネットワークI/O
    • 送信
      • バイト数 kubernetes.network.tx_dropped
      • パケットドロップ数 kubernetes.network.tx_dropped
      • エラー数 kubernetes.network.tx_errors
    • 受信
      • バイト数 kubernetes.network.rx_dropped
      • パケットドロップ数 kubernetes.network.rx_dropped
      • エラー数 kubernetes.network.rx_errors
• ワーカーノード ( instance-type host などの単位で集約する)
  • 死活
    • 台数とステータス kubernetes_state.node.status
  • CPU
    • EC2の使用率 100 - system.cpu.idle
  • メモリ
    • EC2の使用率 1 - system.mem.pct_usable
• コスト
  • CostExplorerで EC2 インスタンス (Elastic Compute Cloud - Compute) を 使用タイプ 別で
    • オートスケーリンググループ使ってるならタグでフィルタできるはず
  • CostUsageReportでEKS単位のコストが見れる ので、個別に深堀したい場合はそちらも活用できる
• アプリケーション（普段やってる監視も併せて見るくらいの意味で）
  • リクエスト量
  • エラー率
  • レイテンシ

リソース制限

自分は特にハマらなかったが、集積性の向上に伴いインスタンス台数あたりの制限に

https://atlaxblogs.nri.co.jp/entry/20240315

https://tech-blog.optim.co.jp/entry/2021/11/10/100000