web-dev-qa-db-ja.com

Kubernetesノードでのポッドリソースの使用状況のモニタリング

使用例/問題

私は、40ノード（2つのゾーンに分割）のkubernetesクラスターの維持を担当しています。約100のマイクロサービスとKafkaブローカーのようなクラスターがこのクラスターで実行されています。すべてのマイクロサービスはリソース要求と制限を定義しています。ただし、それらのほとんどはバースト可能であり、RAMは保証されていません。クラスターの定義済みの制限にサービスをデプロイします。リクエスト（下記の例を参照）よりもはるかに大きくなり、最終的にさまざまなノードで多くの強制排除されたポッドが発生します。ただし、バースト可能なリソースを使用してコストを節約できるため、サービスでバースト可能なリソースを使用したいと考えています。 。したがって、これらの情報を含む、各ノードで実行されているすべてのポッドの監視機能を改善する必要があります。

  • ノード名とCPU/RAM容量
  • すべてのポッド名と
    • ポッドのリソースリクエストと制限
    • ポッドの現在のCPUとRAMの使用状況

このようにして、問題のある2種類のサービスを簡単に特定できました。

ケースA：開発者が物事をテストしているだけであるか、サービスをベンチ/モニターするのが面倒なので、巨大なリソース制限を設定するだけのマイクロサービス

resources:
  requests:
    cpu: 100m
    ram: 500Mi
  limits:
    cpu: 6
    ram: 20Gi

ケースB：正確なリソース制限を設定していない同じノード上のサービスが多すぎる（例：500Mi、ただしサービスは常に1.5Gi RAMを使用）。 Java開発者がJavaガベージコレクターは、利用可能な75％のときにのみクリーンアップを開始しますRAMが使用されました。

私の質問：

このような立ち退きの問題を防ぐために、これを適切に監視し、誤って構成されたマイクロサービスを特定するにはどうすればよいですか？小規模では、単にkubectl describe nodesおよびkubectl top pods手動で計算しますが、このスケールでは機能しません。

注：この問題の既存の解決策は見つかりませんでした（kubeメトリックと同様のプロメテウス+グラファナボードを含む）。それは可能だと思っていましたが、Grafanaでこれを視覚化するのは本当に難しいです。

kubernetesmonitoring
6
kentor

可能であれば、 LimitRange および ResourceQuota リソースを使用することをお勧めします。次に例を示します。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: happy-developer-quota
spec:
  hard:
    requests.cpu: 400m
    requests.memory: 200Mi
    limits.cpu: 600m
    limits.memory: 500Mi

LimitRangeの場合：

 apiVersion: v1
 kind: LimitRange
 metadata:
   name: happy-developer-limit
 spec:
   limits:
   - default:
       cpu: 600m
       memory: 100Mib
     defaultRequest
       cpu: 100m
       memory: 200Mib
     max:
       cpu: 1000m
       memory: 500Mib
     type: Container

これにより、デフォルトの名前空間内に非常に小さなコンテナや非常に大きなコンテナを作成できなくなります。

1
Nicola Ben