kubernetes 🚀 - クラスタリソースの使用状況を確認するには、単純なkubectlコマンドが必要です

UXの人々は私よりもよく知っているでしょうが、（2）の線に沿った何かは合理的なようです。

（3）は漠然と＃15743に関連しているように見えますが、それらを組み合わせるのに十分近いかどうかはわかりません。

davidopp 2015年11月20日

上記の場合に加えて、どのようなリソース使用率が得られているかを確認すると便利です。

kubectl utilization requestsが表示される場合があります（おそらくkubectl utilまたはkubectl usage方が良い/短いです）：

cores: 4.455/5 cores (89%)
memory: 20.1/30 GiB (67%)
...

この例では、集約コンテナー要求は4.455コアと20.1 GiBであり、クラスターには5コアと合計30GiBがあります。

chrishiestand 2016年09月16日

👍172 🎉21 😄2 ❤1

がある：

$ kubectl top nodes
NAME                    CPU(cores)   CPU%      MEMORY(bytes)   MEMORY%   
cluster1-k8s-master-1   312m         15%       1362Mi          68%       
cluster1-k8s-node-1     124m         12%       233Mi           11%

xmik 2016年12月19日

👍268 👎56 ❤3 😄3 🚀2 👀1 🎉1

以下のコマンドを使用して、リソースの使用状況をすばやく確認します。それは私が見つけた最も簡単な方法です。

kubectl describe nodes

ozbillwang 2017年01月11日

👍155 ❤5 😄4 🚀3 👀2 🎉2

kubectl describe nodesの出力を「フォーマット」する方法があれば、すべてのノードのリソース要求/制限を要約する方法をスクリプトで記述してもかまいません。

tonglil 2017年01月20日

これが私のハックですkubectl describe nodes | grep -A 2 -e "^\\s*CPU Requests"

from-nibly 2017年02月02日

👍106 ❤4 😄2

@ from-どうもありがとう、私が探していたものだけ

jredl-va 2017年05月25日

うん、これは私のものです：

$ cat bin/node-resources.sh 
#!/bin/bash
set -euo pipefail

echo -e "Iterating...\n"

nodes=$(kubectl get node --no-headers -o custom-columns=NAME:.metadata.name)

for node in $nodes; do
  echo "Node: $node"
  kubectl describe node "$node" | sed '1,/Non-terminated Pods/d'
  echo
done

tonglil 2017年05月25日

👍40

@goltermannこの問題に関するsigラベルはありません。次の方法でsigラベルを追加してください。
（1）sigに言及する： @kubernetes/sig-<team-name>-misc
（2）ラベルを手動で指定する： /sig <label>

_注：方法（1）は、チームへの通知をトリガーします。ここでチームリストを見つけることができます。_

k8s-github-robot 2017年06月01日

@ kubernetes / sig-cli-misc

kargakis 2017年06月10日

以下のコマンドを使用して、ノードのCPU使用率を確認できます。

alias util='kubectl get nodes | grep node | awk '\''{print $1}'\'' | xargs -I {} sh -c '\''echo   {} ; kubectl describe node {} | grep Allocated -A 5 | grep -ve Event -ve Allocated -ve percent -ve -- ; echo '\'''

Note: 4000m cores is the total cores in one node
alias cpualloc="util | grep % | awk '{print \$1}' | awk '{ sum += \$1 } END { if (NR > 0) { result=(sum**4000); printf result/NR \"%\n\" } }'"

$ cpualloc
3.89358%

Note: 1600MB is the total cores in one node
alias memalloc='util | grep % | awk '\''{print $3}'\'' | awk '\''{ sum += $1 } END { if (NR > 0) { result=(sum*100)/(NR*1600); printf result/NR "%\n" } }'\'''

$ memalloc
24.6832%

alok87 2017年07月05日

👍12 👎1

@tomfotherby alias util='kubectl get nodes | grep node | awk '\''{print $1}'\'' | xargs -I {} sh -c '\''echo {} ; kubectl describe node {} | grep Allocated -A 5 | grep -ve Event -ve Allocated -ve percent -ve -- ; echo '\'''

alok87 2017年07月21日

👍12

@ alok87-エイリアスをありがとう。私の場合、 bashとm3.largeインスタンスタイプ（2 cpu、7.5Gメモリ）を使用していることを考えると、これがうまくいきました。

alias util='kubectl get nodes --no-headers | awk '\''{print $1}'\'' | xargs -I {} sh -c '\''echo {} ; kubectl describe node {} | grep Allocated -A 5 | grep -ve Event -ve Allocated -ve percent -ve -- ; echo '\'''

# Get CPU request total (we x20 because because each m3.large has 2 vcpus (2000m) )
alias cpualloc='util | grep % | awk '\''{print $1}'\'' | awk '\''{ sum += $1 } END { if (NR > 0) { print sum/(NR*20), "%\n" } }'\'''

# Get mem request total (we x75 because because each m3.large has 7.5G ram )
alias memalloc='util | grep % | awk '\''{print $5}'\'' | awk '\''{ sum += $1 } END { if (NR > 0) { print sum/(NR*75), "%\n" } }'\'''

$util
ip-10-56-0-178.ec2.internal
  CPU Requests  CPU Limits  Memory Requests Memory Limits
  960m (48%)    2700m (135%)    630Mi (8%)  2034Mi (27%)

ip-10-56-0-22.ec2.internal
  CPU Requests  CPU Limits  Memory Requests Memory Limits
  920m (46%)    1400m (70%) 560Mi (7%)  550Mi (7%)

ip-10-56-0-56.ec2.internal
  CPU Requests  CPU Limits  Memory Requests Memory Limits
  1160m (57%)   2800m (140%)    972Mi (13%) 3976Mi (53%)

ip-10-56-0-99.ec2.internal
  CPU Requests  CPU Limits  Memory Requests Memory Limits
  804m (40%)    794m (39%)  824Mi (11%) 1300Mi (17%)

cpualloc 
48.05 %

$ memalloc 
9.95333 %

tomfotherby 2017年07月25日

👍79 🚀3 ❤2

https://github.com/kubernetes/kubernetes/issues/17512#issuecomment -267992922 kubectl topは、割り当てではなく使用状況を示していinsufficient CPU問題の原因です。この問題には、違いについて多くの混乱があります。

AFAICT、リクエストは仕様のコンテナごとであるため、ポッドごとのノードCPU割り当てのレポートを取得する簡単な方法はありません。それでも、 .spec.containers[*].requestsはlimits / requestsフィールドがある場合とない場合があるため、困難です（私の経験では）

nfirvine 2017年08月30日

👍42

/ cc @mysterikkit

misterikkit 2018年01月02日

このシェルスクリプトパーティーに参加します。スケールダウンを無効にしてCAを実行している古いクラスターがあります。このスクリプトを作成して、AWSルート制限にぶつかり始めたときにクラスターをスケールダウンできるおおよその量を決定しました。

#!/bin/bash

set -e

KUBECTL="kubectl"
NODES=$($KUBECTL get nodes --no-headers -o custom-columns=NAME:.metadata.name)

function usage() {
    local node_count=0
    local total_percent_cpu=0
    local total_percent_mem=0
    local readonly nodes=$@

    for n in $nodes; do
        local requests=$($KUBECTL describe node $n | grep -A2 -E "^\\s*CPU Requests" | tail -n1)
        local percent_cpu=$(echo $requests | awk -F "[()%]" '{print $2}')
        local percent_mem=$(echo $requests | awk -F "[()%]" '{print $8}')
        echo "$n: ${percent_cpu}% CPU, ${percent_mem}% memory"

        node_count=$((node_count + 1))
        total_percent_cpu=$((total_percent_cpu + percent_cpu))
        total_percent_mem=$((total_percent_mem + percent_mem))
    done

    local readonly avg_percent_cpu=$((total_percent_cpu / node_count))
    local readonly avg_percent_mem=$((total_percent_mem / node_count))

    echo "Average usage: ${avg_percent_cpu}% CPU, ${avg_percent_mem}% memory."
}

usage $NODES

次のような出力を生成します。

ip-REDACTED.us-west-2.compute.internal: 38% CPU, 9% memory
...many redacted lines...
ip-REDACTED.us-west-2.compute.internal: 41% CPU, 8% memory
ip-REDACTED.us-west-2.compute.internal: 61% CPU, 7% memory
Average usage: 45% CPU, 15% memory.

negz 2018年02月21日

👍20

topコマンドにはポッドオプションもあります。

kubectl top pod

ylogx 2018年02月21日

👎60 👍23

@ylogx https://github.com/kubernetes/kubernetes/issues/17512#issuecomment -326089708

nfirvine 2018年02月21日

クラスタ全体で割り当てを取得する私の方法：

$ kubectl get po --all-namespaces -o=jsonpath="{range .items[*]}{.metadata.namespace}:{.metadata.name}{'\n'}{range .spec.containers[*]}  {.name}:{.resources.requests.cpu}{'\n'}{end}{'\n'}{end}"

次のようなものが生成されます。

kube-system:heapster-v1.5.0-dc8df7cc9-7fqx6
  heapster:88m
  heapster-nanny:50m
kube-system:kube-dns-6cdf767cb8-cjjdr
  kubedns:100m
  dnsmasq:150m
  sidecar:10m
  prometheus-to-sd:
kube-system:kube-dns-6cdf767cb8-pnx2g
  kubedns:100m
  dnsmasq:150m
  sidecar:10m
  prometheus-to-sd:
kube-system:kube-dns-autoscaler-69c5cbdcdd-wwjtg
  autoscaler:20m
kube-system:kube-proxy-gke-cluster1-default-pool-cd7058d6-3tt9
  kube-proxy:100m
kube-system:kube-proxy-gke-cluster1-preempt-pool-57d7ff41-jplf
  kube-proxy:100m
kube-system:kubernetes-dashboard-7b9c4bf75c-f7zrl
  kubernetes-dashboard:50m
kube-system:l7-default-backend-57856c5f55-68s5g
  default-http-backend:10m
kube-system:metrics-server-v0.2.0-86585d9749-kkrzl
  metrics-server:48m
  metrics-server-nanny:5m
kube-system:tiller-deploy-7794bfb756-8kxh5
  tiller:10m

shtouff 2018年03月04日

👍53 🎉11

これは変です。割り当て容量に達したとき、または割り当て容量に近づいたときを知りたい。これは、クラスターのかなり基本的な機能のようです。高い％またはテキストエラーを示す統計であるかどうか...他の人はこれをどのように知っていますか？クラウドプラットフォームで常に自動スケーリングを使用しますか？

kierenj 2018年03月13日

👍27

https://github.com/dpetzold/kube-resource-explorer/をアドレス＃3に作成しました。次に出力例を示します。

$ ./resource-explorer -namespace kube-system -reverse -sort MemReq
Namespace    Name                                               CpuReq  CpuReq%  CpuLimit  CpuLimit%  MemReq    MemReq%  MemLimit  MemLimit%
---------    ----                                               ------  -------  --------  ---------  ------    -------  --------  ---------
kube-system  event-exporter-v0.1.7-5c4d9556cf-kf4tf             0       0%       0         0%         0         0%       0         0%
kube-system  kube-proxy-gke-project-default-pool-175a4a05-mshh  100m    10%      0         0%         0         0%       0         0%
kube-system  kube-proxy-gke-project-default-pool-175a4a05-bv59  100m    10%      0         0%         0         0%       0         0%
kube-system  kube-proxy-gke-project-default-pool-175a4a05-ntfw  100m    10%      0         0%         0         0%       0         0%
kube-system  kube-dns-autoscaler-244676396-xzgs4                20m     2%       0         0%         10Mi      0%       0         0%
kube-system  l7-default-backend-1044750973-kqh98                10m     1%       10m       1%         20Mi      0%       20Mi      0%
kube-system  kubernetes-dashboard-768854d6dc-jh292              100m    10%      100m      10%        100Mi     3%       300Mi     11%
kube-system  kube-dns-323615064-8nxfl                           260m    27%      0         0%         110Mi     4%       170Mi     6%
kube-system  fluentd-gcp-v2.0.9-4qkwk                           100m    10%      0         0%         200Mi     7%       300Mi     11%
kube-system  fluentd-gcp-v2.0.9-jmtpw                           100m    10%      0         0%         200Mi     7%       300Mi     11%
kube-system  fluentd-gcp-v2.0.9-tw9vk                           100m    10%      0         0%         200Mi     7%       300Mi     11%
kube-system  heapster-v1.4.3-74b5bd94bb-fz8hd                   138m    14%      138m      14%        301856Ki  11%      301856Ki  11%

dpetzold 2018年05月02日

👍31

@shtouff

root<strong i="7">@debian9</strong>:~# kubectl get po -n chenkunning-84 -o=jsonpath="{range .items[*]}{.metadata.namespace}:{.metadata.name}{'\n'}{range .spec.containers[*]}  {.name}:{.resources.requests.cpu}{'\n'}{end}{'\n'}{end}"
error: error parsing jsonpath {range .items[*]}{.metadata.namespace}:{.metadata.name}{'\n'}{range .spec.containers[*]}  {.name}:{.resources.requests.cpu}{'\n'}{end}{'\n'}{end}, unrecognized character in action: U+0027 '''
root<strong i="8">@debian9</strong>:~# kubectl version
Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.7-beta.0+$Format:%h$", GitCommit:"bb053ff0cb25a043e828d62394ed626fda2719a1", GitTreeState:"dirty", BuildDate:"2017-08-26T09:34:19Z", GoVersion:"go1.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.7-beta.0+$Format:84c3ae0384658cd40c1d1e637f5faa98cf6a965c$", GitCommit:"3af2004eebf3cbd8d7f24b0ecd23fe4afb889163", GitTreeState:"clean", BuildDate:"2018-04-04T08:40:48Z", GoVersion:"go1.8.1", Compiler:"gc", Platform:"linux/amd64"}

harryge00 2018年05月22日

👍1

@ harryge00 ：U + 0027はアンドペーストの問題です

nfirvine 2018年05月22日

@nfirvineありがとう！私は以下を使用して問題を解決しました：

kubectl get pods -n my-ns -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].resources.limits.cpu} {"\n"}{end}' |awk '{sum+=$2 ; print $0} END{print "sum=",sum}'

これは、ポッドにそれぞれ1つのコンテナしか含まれていない名前空間で機能します。

harryge00 2018年05月25日

👎2

@xmikねえ、私はk8 1.7を使用していて、hepasterを実行しています。 $ kubectl top node --heapster-namespace = kube-systemを実行すると、「エラー：メトリックはまだ利用できません」と表示されます。エラーに取り組むための手がかりはありますか？

abushoeb 2018年06月05日

😕2

@abushoeb ：

~~kubectl topがフラグ--heapster-namespaceサポートしているとは思いません。~~ 編集：このフラグはサポートされています、あなたは正しかった： https ：//github.com/kubernetes/kubernetes/issues/44540#issuecomment-362882035。
「エラー：メトリックはまだ利用できません」が表示された場合は、ヒープスターのデプロイメントを確認する必要があります。そのログは何と言っていますか？ヒープスターサービスは大丈夫ですか、エンドポイントは<none>ませんか？次のようなコマンドで後者を確認してください： kubectl -n kube-system describe svc/heapster

xmik 2018年06月05日

❤1

@xmikそうです、ヒープスターが正しく構成されていませんでした。どうもありがとう。現在動作しています。リアルタイムのGPU使用情報を取得する方法があるかどうか知っていますか？このトップコマンドは、CPUとメモリの使用量のみを示します。

abushoeb 2018年06月05日

わかりません。 :(

xmik 2018年06月05日

@abushoeb同じエラー「エラー：メトリックはまだ利用できません」が表示されます。どのように修正しましたか？

avgKol 2018年06月21日

@avgKolは、最初にヒープスターのデプロイを確認します。私の場合、正しく展開されていませんでした。これを確認する1つの方法は、 curl -L http://heapster-pod-ip:heapster-service-port/api/v1/model/metrics/などのCURLコマンドを介してメトリックにアクセスすることです。メトリックが表示されない場合は、ヒープスターポッドとログを確認してください。ヘプスターメトリックには、このようにWebブラウザからもアクセスできます。

abushoeb 2018年06月22日

興味のある方は、Kubernetesリソースの使用量（およびコスト）の静的HTMLを生成するツールを作成しました： https ：

hjacobs 2018年07月18日

👍9

@hjacobs私はそのツールを使いたいのですが、Pythonパッケージのインストール/使用のファンではありません。 Dockerイメージとしてパッケージ化してもよろしいですか？

tonglil 2018年07月18日

@tonglilプロジェクトはかなり早い段階ですが、私の計画では、すぐに使用できるDockerイメージ（含む）を用意する予定です。 kubectl apply -f ..で実行できるWebサーバー。

hjacobs 2018年07月18日

これが私のために働いたものです：

kubectl get nodes -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.allocatable.memory}{'\t'}{.status.allocatable.cpu}{'\n'}{end}"

出力は次のように表示されます。

ip-192-168-101-177.us-west-2.compute.internal   251643680Ki 32
ip-192-168-196-254.us-west-2.compute.internal   251643680Ki 32

arun-gupta 2018年09月12日

👍1

@tonglil Dockerイメージが利用可能になりました： https ：

hjacobs 2018年09月13日

👍2

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

fejta-bot 2018年12月17日

/ remove-lifecycle stale

毎月かそこらで、私のグーグルは私をこの問題に戻します。長いjq文字列を使用するか、一連の計算を含むGrafanaダッシュボードを使用して、必要な統計を取得する方法があります...しかし、次のようなコマンドがあれば、それは_so_素晴らしいでしょう。

# kubectl utilization cluster
cores: 19.255/24 cores (80%)
memory: 16.4/24 GiB (68%)

# kubectl utilization [node name]
cores: 3.125/4 cores (78%)
memory: 2.1/4 GiB (52%)

（ @chrishiestandがスレッドの前半で述べたものと同様です）。

私は週に数十のテストクラスターを構築して破棄することがよくあります。自動化を構築したり、シェルエイリアスを追加したりする必要はなく、「これだけ多くのサーバーを配置して、これらのアプリを投げれば」を確認できます。それらについて、私の全体的な使用率/圧力は何ですか？」

特に小規模で難解なクラスターの場合、月への自動スケールを設定したくありませんが（通常はお金の理由で）、マイナーなポッドの自動スケーリングイベントを処理するのに十分なオーバーヘッドがあるかどうかを知る必要があります。

geerlingguy 2018年12月30日

👍39 ❤10

もう1つのリクエスト-名前空間ごとのリソース使用量の合計を確認できるようにしたいので（少なくとも、デプロイメント/ラベルごとも役立ちます）、どの名前空間が価値があるかを把握することで、リソーストリミングの作業に集中できます。に集中します。

evankanderson 2019年01月01日

👍2

@geerlingguyが説明した機能を提供する小さなプラグインkubectl-view-utilizationを作成しました。 krewプラグインマネージャーを介したインストールが可能です。これはBASHで実装されており、awkとbcが必要です。
kubectlプラグインフレームワークを使用すると、これをコアツールから完全に抽象化できます。

etopeter 2019年01月13日

👍13 😄6 ❤4

他の人もこの課題に直面してくれてうれしいです。 Kube Eagle（プロメテウスエクスポーター）を作成しました。これにより、クラスターリソースの概要を把握し、最終的には利用可能なハードウェアリソースをより有効に活用できるようになりました。

https://github.com/google-cloud-tools/kube-eagle

Kubernetes Resource monitoring dashboard

weeco 2019年03月03日

❤7 👍1

これは、実際のノード使用率をテーブル形式で取得するためのPythonスクリプトです。
https://github.com/amelbakry/kube-node-utilization

Kubernetesノードの使用率.........。
+ ------------------------------------------------ + -------- + -------- +
| NodeName | CPU | メモリ|
+ ------------------------------------------------ + -------- + -------- +
| ip-176-35-32-139.eu-central-1.compute.internal | 13.49％| 60.87％|
| ip-176-35-26-21.eu-central-1.compute.internal | 5.89％| 15.10％|
| ip-176-35-9-122.eu-central-1.compute.internal | 8.08％| 65.51％|
| ip-176-35-22-243.eu-central-1.compute.internal | 6.29％| 19.28％|
+ ------------------------------------------------ + -------- + -------- +

amelbakry 2019年04月24日

少なくとも@amelbakryにとって重要なのは、クラスターレベルの使用率です。「マシンを追加する必要がありますか？」 /「いくつかのマシンを削除する必要がありますか？」 /「クラスターがすぐにスケールアップすることを期待する必要がありますか？」 ..

kierenj 2019年04月25日

エフェメラルストレージの使用についてはどうですか？すべてのポッドからそれを取得する方法はありますか？

そして、役に立つために、私のヒント：

kubectl get pods -o json -n kube-system | jq -r '.items[] | .metadata.name + " \n Req. RAM: " + .spec.containers[].resources.requests.memory + " \n Lim. RAM: " + .spec.containers[].resources.limits.memory + " \n Req. CPU: " + .spec.containers[].resources.requests.cpu + " \n Lim. CPU: " + .spec.containers[].resources.limits.cpu + " \n Req. Eph. DISK: " + .spec.containers[].resources.requests["ephemeral-storage"] + " \n Lim. Eph. DISK: " + .spec.containers[].resources.limits["ephemeral-storage"] + "\n"'
...
kube-proxy-xlmjt
 Req. RAM: 32Mi
 Lim. RAM: 256Mi
 Req. CPU: 100m
 Lim. CPU:
 Req. Eph. DISK: 100Mi
 Lim. Eph. DISK: 512Mi
...

echo "\nRAM Requests TOTAL:" && kubectl describe namespace kube-system | grep 'requests.memory' && echo "\nRAM Requests:\n" && kubectl get pods -o json -n kube-system | jq -r '.items[] | .spec.containers[].resources.requests.memory + " | " + .metadata.name'

echo "\nRAM Limits TOTAL:" && kubectl describe namespace kube-system | grep 'limits.memory' &&  echo "\nRAM Limits:\n" && kubectl get pods -o json -n kube-system | jq -r '.items[] | .spec.containers[].resources.limits.memory + " | " + .metadata.name'

echo "\nCPU Requests TOTAL:" && kubectl describe namespace kube-system | grep 'requests.cpu' &&  echo "\nCPU Requests:\n" && kubectl get pods -o json -n kube-system | jq -r '.items[] | .spec.containers[].resources.requests.cpu + " | " + .metadata.name'

echo "\nCPU Limits TOTAL:" && kubectl describe namespace kube-system | grep 'limits.cpu' &&  echo "\nCPU Limits:\n" && kubectl get pods -o json -n kube-system | jq -r '.items[] | .spec.containers[].resources.limits.cpu + " | " + .metadata.name'

echo "\nEph. DISK Requests TOTAL:" && kubectl describe namespace kube-system | grep 'requests.ephemeral-storage' && echo "\nEph. DISK Requests:\n" && kubectl get pods -o json -n kube-system | jq -r '.items[] | .spec.containers[].resources.requests["ephemeral-storage"] + " | " + .metadata.name'

echo "\nEph. DISK Limits TOTAL:" && kubectl describe namespace kube-system | grep 'limits.ephemeral-storage' && echo "\nEph. DISK Limits:\n" && kubectl get pods -o json -n kube-system | jq -r '.items[] | .spec.containers[].resources.limits["ephemeral-storage"] + " | " + .metadata.name'

RAM Requests TOTAL:
 requests.memory               3504Mi   16Gi

RAM Requests:

64Mi | aws-alb-ingress-controller-6b569b448c-jzj6f
...

kivagant-ba 2019年04月25日

👍4

@ kivagant-baこのスニプトを試して、ノードごとのポッドメトリックを取得できます。たとえば、次のようなすべてのノードを取得できます。
https://github.com/amelbakry/kube-node-utilization

def get_pod_metrics_per_node（node）：
pod_metrics = "/ api / v1 / pods？fieldSelector = spec.nodeName％3D" +ノード
応答= api_client.call_api（pod_metrics、
'GET'、auth_settings = ['BearerToken']、
response_type = 'json'、_ preload_content = False）

response = json.loads（response [0] .data.decode（ 'utf-8'））

応答を返す

amelbakry 2019年04月25日

👀1

@kierenjどのクラウドkubernetesが実行されているかに基づくcluster-autoscalerコンポーネントが容量を処理する必要があると思います。これがあなたの質問かどうかわからない。

amelbakry 2019年04月25日

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

fejta-bot 2019年07月30日

/ remove-lifecycle stale

他の多くの人と同じように、CLI（AWS ASGなど）を介してクラスターを管理するために必要なハックを取得するために、ここに何年も戻ってきます

eduncan911 2019年08月28日

❤6

@etopeterこのようなクールなCLIプラグインをありがとうございます。そのシンプルさが大好きです。数字とその正確な意味をよりよく理解する方法について何かアドバイスはありますか？

demisx 2019年08月28日

誰かがそれの使用を見つけることができるなら、ここにポッドの現在の制限をダンプするスクリプトがあります。

kubectl get pods --all-namespaces -o=jsonpath="{range .items[*]}{.metadata.namespace}:{.metadata.name}{'\n'}\ {'.spec.nodeName -'} {.spec.nodeName}{'\n'}\ {range .spec.containers[*]}\ {'requests.cpu -'} {.resources.requests.cpu}{'\n'}\ {'limits.cpu -'} {.resources.limits.cpu}{'\n'}\ {'requests.memory -'} {.resources.requests.memory}{'\n'}\ {'limits.memory -'} {.resources.limits.memory}{'\n'}\ {'\n'}{end}\ {'\n'}{end}"

出力例
..。
kube- system：addon-http-application-routing-nginx-ingress-controller-6bq49l7
.spec.nodeName --aks-agentpool-84550961-0
requests.cpu-
Limits.cpu-
requests.memory-
Limits.memory-

kube-システム：coredns-696c4d987c-pjht8
.spec.nodeName --aks-agentpool-84550961-0
requests.cpu-100m
Limits.cpu-
requests.memory-70Mi
Limits.memory-170Mi

kube-システム：coredns-696c4d987c-rtkl6
.spec.nodeName --aks-agentpool-84550961-2
requests.cpu-100m
Limits.cpu-
requests.memory-70Mi
Limits.memory-170Mi

kube-システム：coredns-696c4d987c-zgcbp
.spec.nodeName --aks-agentpool-84550961-1
requests.cpu-100m
Limits.cpu-
requests.memory-70Mi
Limits.memory-170Mi

kube- system：coredns-autoscaler-657d77ffbf-7t72x
.spec.nodeName --aks-agentpool-84550961-2
requests.cpu-20m
Limits.cpu-
requests.memory-10Mi
Limits.memory-

kube-システム：coredns-autoscaler-657d77ffbf-zrp6m
.spec.nodeName --aks-agentpool-84550961-0
requests.cpu-20m
Limits.cpu-
requests.memory-10Mi
Limits.memory-

kube-システム： kube
.spec.nodeName --aks-agentpool-84550961-1
requests.cpu-100m
Limits.cpu-
requests.memory-
Limits.memory-
..。

Spaceman1861 2019年09月02日

👍3

@ Spaceman1861例を挙げていただけますか？

eduncan911 2019年09月02日

@ eduncan911完了

Spaceman1861 2019年09月02日

👍2

次のように、テーブル形式で出力を読む方が簡単だと思います（これは制限ではなくリクエストを表示します）：

kubectl get pods -o custom-columns=NAME:.metadata.name,"CPU(cores)":.spec.containers[*].resources.requests.cpu,"MEMORY(bytes)":.spec.containers[*].resources.requests.memory --all-namespaces

サンプル出力：

NAME                                CPU(cores)      MEMORY(bytes)
pod1                                100m            128Mi
pod2                                100m            128Mi,128Mi

lentzi90 2019年09月02日

👍7

@ lentzi90参考までに： Kubernetes Webビュー（「kubectlfor the web」）、デモで同様のカスタム列を表示できます： https ：//kube-web-view.demo.j-serv.de/clusters/local/namespaces/ ] .resources.requests.cpu）％3BMemory + Requests = join（％27、％20％ 27、％20spec.containers [ ] .resources.requests.memory）

カスタム列のドキュメント： https ：//kube-web-view.readthedocs.io/en/latest/features.html#listing -resources

hjacobs 2019年09月02日

Oooo光沢のある

Spaceman1861 2019年09月02日

これは、使用状況と構成された制限に基づいて、展開中のポッドの使用率を取得するためのスクリプト（deployment-health.sh）です。
https://github.com/amelbakry/kubernetes-scripts

Screenshot from 2019-09-02 15-11-42

amelbakry 2019年09月02日

@ lentzi90と@ylogxの回答に触発されて、実際のリソース使用量（ kubectl top pods ）とリソース要求と制限を示す独自の大きなスクリプトを作成しました。

join -a1 -a2 -o 0,1.2,1.3,2.2,2.3,2.4,2.5, -e '<none>' <(kubectl top pods) <(kubectl get pods -o custom-columns=NAME:.metadata.name,"CPU_REQ(cores)":.spec.containers[*].resources.requests.cpu,"MEMORY_REQ(bytes)":.spec.containers[*].resources.requests.memory,"CPU_LIM(cores)":.spec.containers[*].resources.limits.cpu,"MEMORY_LIM(bytes)":.spec.containers[*].resources.limits.memory) | column -t -s' '

出力例：

NAME                                                             CPU(cores)  MEMORY(bytes)  CPU_REQ(cores)  MEMORY_REQ(bytes)  CPU_LIM(cores)  MEMORY_LIM(bytes)
xxxxx-847dbbc4c-c6twt                                            20m         110Mi          50m             150Mi              150m            250Mi
xxx-service-7b6b9558fc-9cq5b                                     19m         1304Mi         1               <none>             1               <none>
xxxxxxxxxxxxxxx-hook-5d585b449b-zfxmh                            0m          46Mi           200m            155M               200m            155M

ターミナルでkstatsを使用するためのエイリアスは次のとおりです。

alias kstats='join -a1 -a2 -o 0,1.2,1.3,2.2,2.3,2.4,2.5, -e '"'"'<none>'"'"' <(kubectl top pods) <(kubectl get pods -o custom-columns=NAME:.metadata.name,"CPU_REQ(cores)":.spec.containers[*].resources.requests.cpu,"MEMORY_REQ(bytes)":.spec.containers[*].resources.requests.memory,"CPU_LIM(cores)":.spec.containers[*].resources.limits.cpu,"MEMORY_LIM(bytes)":.spec.containers[*].resources.limits.memory) | column -t -s'"'"' '"'"

PS私は自分のMacでのみスクリプトをテストしました。LinuxとWindowsの場合、いくつかの変更が必要になる場合があります

alikhil 2019年09月25日

👍4

これは、使用状況と構成された制限に基づいて、展開中のポッドの使用率を取得するためのスクリプト（deployment-health.sh）です。
https://github.com/amelbakry/kubernetes-scripts

@amelbakry Macで実行しようとすると、次のエラーが発生します。

Failed to execute process './deployment-health.sh'. Reason:
exec: Exec format error
The file './deployment-health.sh' is marked as an executable but could not be run by the operating system.

demisx 2019年09月25日

おっと、
「＃！」一番最初の行である必要があります。代わりに「bash」を試してください
./deployment-health.sh "を使用して、問題を回避します。

/ charles
PS。問題を修正するためにPRが開始されました

10:19ドミトリ・ムーアの水、2019年9月25日には[email protected]
書きました：

これは、ポッドの使用率を取得するためのスクリプト（deployment-health.sh）です。
使用状況と構成された制限に基づいた展開
https://github.com/amelbakry/kubernetes-scripts
@amelbakryhttps ：//github.com/amelbakry次の情報を取得しています
Macで実行しようとしたときにエラーが発生しました：
プロセス './deployment-health.sh'の実行に失敗しました。理由：
exec：実行フォーマットエラー
ファイル './deployment-health.sh'は実行可能ファイルとしてマークされていますが、オペレーティングシステムで実行できませんでした。
—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/17512?email_source=notifications&email_token=AACA3TODQEUPWK3V3UY3SF3QLOMSFA5CNFSM4BUXCUG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AACA3TOPOBIWXFX2DAOT6JDQLOMSFANCNFSM4BUXCUGQ
。

cgthayer 2019年09月25日

@cgthayerそのPR修正をグローバルに適用したい場合があります。また、MacOs Mojaveでスクリプトを実行すると、使用していないEU固有のゾーン名など、多数のエラーが表示されました。これらのスクリプトは特定のプロジェクト用に作成されているようです。

demisx 2019年10月02日

これがjoinexの修正バージョンです。これは、列の合計も行います。

oc_ns_pod_usage () {
    # show pod usage for cpu/mem
    ns="$1"
    usage_chk3 "$ns" || return 1
    printf "$ns\n"
    separator=$(printf '=%.0s' {1..50})
    printf "$separator\n"
    output=$(join -a1 -a2 -o 0,1.2,1.3,2.2,2.3,2.4,2.5, -e '<none>' \
        <(kubectl top pods -n $ns) \
        <(kubectl get -n $ns pods -o custom-columns=NAME:.metadata.name,"CPU_REQ(cores)":.spec.containers[*].resources.requests.cpu,"MEMORY_REQ(bytes)":.spec.containers[*].resources.requests.memory,"CPU_LIM(cores)":.spec.containers[*].resources.limits.cpu,"MEMORY_LIM(bytes)":.spec.containers[*].resources.limits.memory))
    totals=$(printf "%s" "$output" | awk '{s+=$2; t+=$3; u+=$4; v+=$5; w+=$6; x+=$7} END {print s" "t" "u" "v" "w" "x}')
    printf "%s\n%s\nTotals: %s\n" "$output" "$separator" "$totals" | column -t -s' '
    printf "$separator\n"
}

例

$ oc_ns_pod_usage ls-indexer
ls-indexer
==================================================
NAME                                                CPU(cores)  MEMORY(bytes)  CPU_REQ(cores)  MEMORY_REQ(bytes)  CPU_LIM(cores)  MEMORY_LIM(bytes)
ls-indexer-f5-7cd5859997-qsfrp                      15m         741Mi          1               1000Mi             2               2000Mi
ls-indexer-f5-7cd5859997-sclvg                      15m         735Mi          1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-4b7j2                 92m         1103Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-5xj5l                 88m         1124Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-6vvl2                 92m         1132Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-85f66                 85m         1151Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-924jz                 96m         1124Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-g6gx8                 119m        1119Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-hkhnt                 52m         819Mi          1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-hrsrs                 51m         1122Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-j4qxm                 53m         885Mi          1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-lxlrb                 83m         1215Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-mw6rt                 86m         1131Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-pbdf8                 95m         1115Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-qk9bm                 91m         1141Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-sdv9r                 54m         1194Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-t67v6                 75m         1234Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-tkxs2                 88m         1364Mi         1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-v6jl2                 53m         747Mi          1               1000Mi             2               2000Mi
ls-indexer-filebeat-7858f56c9-wkqr7                 53m         838Mi          1               1000Mi             2               2000Mi
ls-indexer-metricbeat-74d89d7d85-jp8qc              190m        1191Mi         1               1000Mi             2               2000Mi
ls-indexer-metricbeat-74d89d7d85-jv4bv              192m        1162Mi         1               1000Mi             2               2000Mi
ls-indexer-metricbeat-74d89d7d85-k4dcd              194m        1144Mi         1               1000Mi             2               2000Mi
ls-indexer-metricbeat-74d89d7d85-n46tz              192m        1155Mi         1               1000Mi             2               2000Mi
ls-indexer-packetbeat-db98f6fdf-8x446               35m         1198Mi         1               1000Mi             2               2000Mi
ls-indexer-packetbeat-db98f6fdf-gmxxd               22m         1203Mi         1               1000Mi             2               2000Mi
ls-indexer-syslog-5466bc4d4f-gzxw8                  27m         1125Mi         1               1000Mi             2               2000Mi
ls-indexer-syslog-5466bc4d4f-zh7st                  29m         1153Mi         1               1000Mi             2               2000Mi
==================================================
Totals:                                             2317        30365          28              28000              56              56000
==================================================

slmingol 2019年10月21日

そして、usage_chk3とは何ですか？

cristifalcas 2019年10月25日

私のツールも共有したいと思います;-) kubectl-view-allocations：割り当てを一覧表示するkubectlプラグイン（cpu、memory、gpu、... X要求、制限、割り当て可能、...）。、リクエストは大歓迎です。

私は（内部の）ユーザーに「誰が何を割り当てるか」を確認する方法を提供したいので、それを作りました。デフォルトではすべてのリソースが表示されますが、次のサンプルでは、名前に「gpu」が含まれるリソースのみを要求します。

> kubectl-view-allocations -r gpu

 Resource                                   Requested  %Requested  Limit  %Limit  Allocatable  Free
  nvidia.com/gpu                                    7         58%      7     58%           12     5
  ├─ node-gpu1                                      1         50%      1     50%            2     1
  │  └─ xxxx-784dd998f4-zt9dh                       1                  1
  ├─ node-gpu2                                      0          0%      0      0%            2     2
  ├─ node-gpu3                                      0          0%      0      0%            2     2
  ├─ node-gpu4                                      1         50%      1     50%            2     1
  │  └─ aaaa-1571819245-5ql82                       1                  1
  ├─ node-gpu5                                      2        100%      2    100%            2     0
  │  ├─ bbbb-1571738839-dfkhn                       1                  1
  │  └─ bbbb-1571738888-52c4w                       1                  1
  └─ node-gpu6                                      2        100%      2    100%            2     0
     ├─ bbbb-1571738688-vlxng                       1                  1
     └─ cccc-1571745684-7k6bn                       1                  1

今後のバージョン：

（ノード、ポッド）レベルを非表示にしたり、グループ化する方法を選択したりできます（たとえば、リソースのみで概要を提供するため）
curl、krew、brew、...を介したインストール（現在、バイナリはgithubのリリースセクションで利用可能です）

インスピレーションを与えてくれたkubectl-view-utilizationに感謝し

davidB 2019年10月25日

👍6 🎉2

これが私のハックですkubectl describe nodes | grep -A 2 -e "^\\s*CPU Requests"

これはもう機能しません:(

libudas 2019年11月28日

👍3

kubectl describe node | grep -A5 "Allocated"を試してみてください

MostafaGazar 2019年11月28日

❤9 🎉4 👍2

これは現在、親指を立てて4番目にリクエストの多い問題ですが、それでもpriority/backlogです。

誰かが私を正しい方向に向けることができれば、または私たちが提案を完成させることができれば、私はこれを突き刺して喜んでいます。 @davidBのツールのUXはkubectl属しています。

alexkreidler 2019年12月01日

👍16

次のコマンドを使用します： kubectl top nodes ＆ kubectl describe node一貫した結果が得られません

たとえば、最初のCPU（コア）は1064mですが、この結果は2番目のCPU（1480m）ではフェッチできません。

kubectl top nodes
NAME                                                CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
abcd-p174e23ea5qa4g279446c803f82-abc-node-0         1064m        53%    6783Mi          88%

kubectl describe node abcd-p174e23ea5qa4g279446c803f82-abc-node-0
...
  Resource  Requests          Limits
  --------  --------          ------
  cpu       1480m (74%)       1300m (65%)
  memory    2981486848 (37%)  1588314624 (19%)

kubectl top nodesを使用せずにCPU（コア）を取得することについて何かアイデア

smpar 2019年12月18日

私のツールも共有したいと思います;-) kubectl-view-allocations：割り当てを一覧表示するkubectlプラグイン（cpu、memory、gpu、... X要求、制限、割り当て可能、...）。、リクエストは大歓迎です。
私は（内部の）ユーザーに「誰が何を割り当てるか」を確認する方法を提供したいので、それを作りました。デフォルトではすべてのリソースが表示されますが、次のサンプルでは、名前に「gpu」が含まれるリソースのみを要求します。
> kubectl-view-allocations -r gpu

 Resource                                   Requested  %Requested  Limit  %Limit  Allocatable  Free
  nvidia.com/gpu                                    7         58%      7     58%           12     5
  ├─ node-gpu1                                      1         50%      1     50%            2     1
  │  └─ xxxx-784dd998f4-zt9dh                       1                  1
  ├─ node-gpu2                                      0          0%      0      0%            2     2
  ├─ node-gpu3                                      0          0%      0      0%            2     2
  ├─ node-gpu4                                      1         50%      1     50%            2     1
  │  └─ aaaa-1571819245-5ql82                       1                  1
  ├─ node-gpu5                                      2        100%      2    100%            2     0
  │  ├─ bbbb-1571738839-dfkhn                       1                  1
  │  └─ bbbb-1571738888-52c4w                       1                  1
  └─ node-gpu6                                      2        100%      2    100%            2     0
     ├─ bbbb-1571738688-vlxng                       1                  1
     └─ cccc-1571745684-7k6bn                       1                  1
今後のバージョン：
* will allow to hide (node, pod) level or to choose how to group, (eg to provide an overview with only resources)

* installation via curl, krew, brew, ... (currently binary are available under the releases section of github)
インスピレーションを与えてくれたkubectl-view-utilizationに感謝し

こんにちはデビッドあなたが新しいディストリビューションのためにもっとコンパイルされたバイナリを提供するならそれは素晴らしいでしょう。 Ubuntu 16.04では、

kubectl-view-allocations：/lib/x86_64-linux-gnu/libc.so.6：バージョン `GLIBC_2.25 'が見つかりません（kubectl-view-allocationsで必要）

dpkg -l |grep glib

ii libglib2.0-0：amd64 2.48.2-0ubuntu4.4

omerfsen 2020年01月12日

👎3

@omerfsenは、新しいバージョンkubectl-view-allocationsを試して、チケットバージョン `GLIBC_2.25 'が見つかりません＃14にコメントできますか？

davidB 2020年01月15日

クラスタ全体で割り当てを取得する私の方法：

$ kubectl get po --all-namespaces -o=jsonpath="{range .items[*]}{.metadata.namespace}:{.metadata.name}{'\n'}{range .spec.containers[*]}  {.name}:{.resources.requests.cpu}{'\n'}{end}{'\n'}{end}"

次のようなものが生成されます。

kube-system:heapster-v1.5.0-dc8df7cc9-7fqx6
  heapster:88m
  heapster-nanny:50m
kube-system:kube-dns-6cdf767cb8-cjjdr
  kubedns:100m
  dnsmasq:150m
  sidecar:10m
  prometheus-to-sd:
kube-system:kube-dns-6cdf767cb8-pnx2g
  kubedns:100m
  dnsmasq:150m
  sidecar:10m
  prometheus-to-sd:
kube-system:kube-dns-autoscaler-69c5cbdcdd-wwjtg
  autoscaler:20m
kube-system:kube-proxy-gke-cluster1-default-pool-cd7058d6-3tt9
  kube-proxy:100m
kube-system:kube-proxy-gke-cluster1-preempt-pool-57d7ff41-jplf
  kube-proxy:100m
kube-system:kubernetes-dashboard-7b9c4bf75c-f7zrl
  kubernetes-dashboard:50m
kube-system:l7-default-backend-57856c5f55-68s5g
  default-http-backend:10m
kube-system:metrics-server-v0.2.0-86585d9749-kkrzl
  metrics-server:48m
  metrics-server-nanny:5m
kube-system:tiller-deploy-7794bfb756-8kxh5
  tiller:10m

ここで断然ベストアンサー。

abelal83 2020年01月31日

上記のスクリプトに触発されて、使用法、リクエスト、制限を表示するために次のスクリプトを作成しました。

join -1 2 -2 2 -a 1 -a 2 -o "2.1 0 1.3 2.3 2.5 1.4 2.4 2.6" -e '<wait>' \
  <( kubectl top pods --all-namespaces | sort --key 2 -b ) \
  <( kubectl get pods --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,"CPU_REQ(cores)":.spec.containers[*].resources.requests.cpu,"MEMORY_REQ(bytes)":.spec.containers[*].resources.requests.memory,"CPU_LIM(cores)":.spec.containers[*].resources.limits.cpu,"MEMORY_LIM(bytes)":.spec.containers[*].resources.limits.memory | sort --key 2 -b ) \
  | column -t -s' '

joinシェルスクリプトは並べ替えられたリストを想定しているため、上記のスクリプトは失敗しました。

結果として、現在の使用状況を上から、デプロイメントから、要求と（ここで）すべての名前空間の制限を確認できます。

NAMESPACE                 NAME                                                        CPU(cores)  CPU_REQ(cores)  CPU_LIM(cores)  MEMORY(bytes)  MEMORY_REQ(bytes)   MEMORY_LIM(bytes)
kube-system               aws-node-2jzxr                                              18m         10m             <none>          41Mi           <none>              <none>
kube-system               aws-node-5zn6w                                              <wait>      10m             <none>          <wait>         <none>              <none>
kube-system               aws-node-h8cc5                                              20m         10m             <none>          42Mi           <none>              <none>
kube-system               aws-node-h9n4f                                              0m          10m             <none>          0Mi            <none>              <none>
kube-system               aws-node-lz5fn                                              17m         10m             <none>          41Mi           <none>              <none>
kube-system               aws-node-tpmxr                                              20m         10m             <none>          39Mi           <none>              <none>
kube-system               aws-node-zbkkh                                              23m         10m             <none>          47Mi           <none>              <none>
cluster-autoscaler        cluster-autoscaler-aws-cluster-autoscaler-5db55fbcf8-mdzkd  1m          100m            500m            9Mi            300Mi               500Mi
cluster-autoscaler        cluster-autoscaler-aws-cluster-autoscaler-5db55fbcf8-q9xs8  39m         100m            500m            75Mi           300Mi               500Mi
kube-system               coredns-56b56b56cd-bb26t                                    6m          100m            <none>          11Mi           70Mi                170Mi
kube-system               coredns-56b56b56cd-nhp58                                    6m          100m            <none>          11Mi           70Mi                170Mi
kube-system               coredns-56b56b56cd-wrmxv                                    7m          100m            <none>          12Mi           70Mi                170Mi
gitlab-runner-l           gitlab-runner-l-gitlab-runner-6b8b85f87f-9knnx              3m          100m            200m            10Mi           128Mi               256Mi
gitlab-runner-m           gitlab-runner-m-gitlab-runner-6bfd5d6c84-t5nrd              7m          100m            200m            13Mi           128Mi               256Mi
gitlab-runner-mda         gitlab-runner-mda-gitlab-runner-59bb66c8dd-bd9xw            4m          100m            200m            17Mi           128Mi               256Mi
gitlab-runner-ops         gitlab-runner-ops-gitlab-runner-7c5b85dc97-zkb4c            3m          100m            200m            12Mi           128Mi               256Mi
gitlab-runner-pst         gitlab-runner-pst-gitlab-runner-6b8f9bf56b-sszlr            6m          100m            200m            20Mi           128Mi               256Mi
gitlab-runner-s           gitlab-runner-s-gitlab-runner-6bbccb9b7b-dmwgl              50m         100m            200m            27Mi           128Mi               512Mi
gitlab-runner-shared      gitlab-runner-shared-gitlab-runner-688d57477f-qgs2z         3m          <none>          <none>          15Mi           <none>              <none>
kube-system               kube-proxy-5b65t                                            15m         100m            <none>          19Mi           <none>              <none>
kube-system               kube-proxy-7qsgh                                            12m         100m            <none>          24Mi           <none>              <none>
kube-system               kube-proxy-gn2qg                                            13m         100m            <none>          23Mi           <none>              <none>
kube-system               kube-proxy-pz7fp                                            15m         100m            <none>          18Mi           <none>              <none>
kube-system               kube-proxy-vdjqt                                            15m         100m            <none>          23Mi           <none>              <none>
kube-system               kube-proxy-x4xtp                                            19m         100m            <none>          15Mi           <none>              <none>
kube-system               kube-proxy-xlpn7                                            0m          100m            <none>          0Mi            <none>              <none>
metrics-server            metrics-server-5875c7d795-bj7cq                             5m          200m            500m            29Mi           200Mi               500Mi
metrics-server            metrics-server-5875c7d795-jpjjn                             7m          200m            500m            29Mi           200Mi               500Mi
gitlab-runner-s           runner-heq8ujaj-project-10386-concurrent-06t94f             <wait>      200m,100m       200m,200m       <wait>         200Mi,128Mi         500Mi,500Mi
gitlab-runner-s           runner-heq8ujaj-project-10386-concurrent-10lpn9j            1m          200m,100m       200m,200m       12Mi           200Mi,128Mi         500Mi,500Mi
gitlab-runner-s           runner-heq8ujaj-project-10386-concurrent-11jrxfh            <wait>      200m,100m       200m,200m       <wait>         200Mi,128Mi         500Mi,500Mi
gitlab-runner-s           runner-heq8ujaj-project-10386-concurrent-129hpvl            1m          200m,100m       200m,200m       12Mi           200Mi,128Mi         500Mi,500Mi
gitlab-runner-s           runner-heq8ujaj-project-10386-concurrent-13kswg8            1m          200m,100m       200m,200m       12Mi           200Mi,128Mi         500Mi,500Mi
gitlab-runner-s           runner-heq8ujaj-project-10386-concurrent-15qhp5w            <wait>      200m,100m       200m,200m       <wait>         200Mi,128Mi         500Mi,500Mi

注目すべき点：CPU消費量は次のように並べ替えることができます。

| awk 'NR<2{print $0;next}{print $0| "sort --key 3 --numeric -b --reverse"}

これはMacで動作します-Linuxでも動作するかどうかはわかりません（結合、並べ替えなどのため）。

うまくいけば、kubectlがそのための良いビューを取得するまで、誰かがこれを使用できます。

stefanjacobs 2020年02月11日

👍7

私はkube-capacityで良い経験をしています。

例：

kube-capacity --util

NODE              CPU REQUESTS    CPU LIMITS    CPU UTIL    MEMORY REQUESTS    MEMORY LIMITS   MEMORY UTIL
*                 560m (28%)      130m (7%)     40m (2%)    572Mi (9%)         770Mi (13%)     470Mi (8%)
example-node-1    220m (22%)      10m (1%)      10m (1%)    192Mi (6%)         360Mi (12%)     210Mi (7%)
example-node-2    340m (34%)      120m (12%)    30m (3%)    380Mi (13%)        410Mi (14%)     260Mi (9%)

eyalev 2020年02月18日

👍23 🎉6 🚀2 ❤2

このツールが本当に役立つためには、クラスターにデプロイされているすべてのkubernetesデバイスプラグインを検出し、それらすべての使用状況を表示する必要があります。 CPU / Memは明らかに十分ではありません。 GPU、TPU（機械学習用）、Intel QATなど、おそらく私が知らないものもあります。また、ストレージはどうですか？何が要求され、何が使用されているかを簡単に確認できるはずです（理想的にはIOPSの観点からも）。

boniek83 2020年04月09日

@ boniek83 、GPUをリストする必要があるため、 kubectl-view-allocationsを作成したのは

davidB 2020年04月09日

❤2

@ boniek83 、GPUをリストする必要があるため、 kubectl-view-allocationsを作成したのは

私はあなたのツールを知っています、そして私の目的のために、それは現在利用可能な最高のものです。作ってくれてありがとう！
イースターの後にTPUをテストしてもらいます。このデータがきれいなグラフを備えたWebアプリ形式で利用できると便利なので、データサイエンティストにkubernetesへのアクセスを許可する必要はありません。彼らは誰が資源を食い尽くしているのかを知りたいだけで、それ以上は何も知りたくない:)

boniek83 2020年04月09日

上記のツールとスクリプトはどれも私のニーズに合わないので（そしてこの問題はまだ開いています:(）、私は自分の亜種をハッキングしました：
https://github.com/eht16/kube-cargo-load

クラスタ内のPODの概要を簡単に説明し、構成されたメモリ要求と制限、および実際のメモリ使用量を示します。アイデアは、構成されたメモリ制限と実際の使用量の比率を把握することです。

eht16 2020年04月13日

ポッドのメモリダンプログを取得するにはどうすればよいですか？
ポッドは頻繁にハングアップしていますが、

RahulRatan07 2020年04月26日

👎3 👍1

kubectl describe nodesまたはkubectl top nodes 、どちらを考慮してクラスターリソースの使用率を計算する必要がありますか？
また、なぜこれら2つの結果に違いがあるのか。
これについて論理的な説明はまだありますか？

hmsvigle 2020年04月27日

👎4

/種類の機能

brianpursley 2020年04月29日

ノードを使ったすべてのコメントとハックは私にとってうまくいきました。また、ノードプールごとのリソースの合計のように、より高いビューを追跡するための何かが必要です。

prathameshd9 2020年04月30日

やあ、
ある期間にわたって5分ごとに、ポッドのCPUとメモリの使用量をログに記録したいと思います。次に、このデータを使用してExcelでグラフを作成します。何か案は？ありがとう

rajjar123456 2020年07月18日

やあ、
グーグルが私たち全員にこの問題を指摘してくれてうれしいです：-）（ほぼ5年経ってもまだ開いていることに少しがっかりしました。）すべてのシェルスニップと他のツールに感謝します。

yceoshda 2020年07月28日

シンプルで迅速なハック：

$ kubectl describe nodes | grep 'Name:\|  cpu\|  memory'

Name:               XXX-2-wke2
  cpu                                               1552m (77%)   2402m (120%)
  memory                                            2185Mi (70%)  3854Mi (123%)
Name:               XXX-2-wkep
  cpu                                               1102m (55%)   1452m (72%)
  memory                                            1601Mi (51%)  2148Mi (69%)
Name:               XXX-2-wkwz
  cpu                                               852m (42%)    1352m (67%)
  memory                                            1125Mi (36%)  3624Mi (116%)

SerheyDolgushev 2020年08月05日

シンプルで迅速なハック：

$ kubectl describe nodes | grep 'Name:\|  cpu\|  memory'

Name:               XXX-2-wke2
  cpu                                               1552m (77%)   2402m (120%)
  memory                                            2185Mi (70%)  3854Mi (123%)
Name:               XXX-2-wkep
  cpu                                               1102m (55%)   1452m (72%)
  memory                                            1601Mi (51%)  2148Mi (69%)
Name:               XXX-2-wkwz
  cpu                                               852m (42%)    1352m (67%)
  memory                                            1125Mi (36%)  3624Mi (116%)

デバイスプラグインはありません。彼らはする必要があります。このようなデバイスもリソースです。

boniek83 2020年08月05日

こんにちは！

このスクリプトを作成して共有しました。

https://github.com/Sensedia/open-tools/blob/master/scripts/listK8sHardwareResources.sh

このスクリプトには、ここで共有したアイデアのいくつかをまとめたものが含まれています。スクリプトはインクリメントでき、他の人がより簡単にメトリックを取得するのに役立ちます。

ヒントとコマンドを共有していただきありがとうございます。

aeciopires 2020年08月07日

私のユースケースでは、テーブル内のノードのCPU / RAM制限/予約を一覧表示する単純なkubectlプラグインを作成することになりました。また、現在のポッドのCPU / RAM消費量（ kubectl top pods ）もチェックしますが、CPUによる出力を降順で並べ替えます。

それは他の何よりも便利なことですが、おそらく他の誰かがそれを役立つと思うでしょう。

https://github.com/laurybueno/kubectl-hoggers

laurybueno 2020年08月09日

👍2

おっと、クラスター全体の現在の全体的なCPU使用率を適切に計算するための、kubernetesチームからの巨大なスレッドであり、まだ適切なソリューションはありませんか？

denissabramovs 2020年09月20日

👍1

minikubeでこれを実行したい場合は、最初にメトリックサーバーアドオンを有効にしてください
minikube addons enable metrics-server
次にコマンドを実行します
kubectl top nodes

raul1991 2020年10月16日

Krewを使用している場合：

kubectl krew install resource-capacity
kubectl resource-capacity

NODE                                          CPU REQUESTS   CPU LIMITS     MEMORY REQUESTS   MEMORY LIMITS
*                                             16960m (35%)   18600m (39%)   26366Mi (14%)     3100Mi (1%)
ip-10-0-138-176.eu-north-1.compute.internal   2460m (31%)    4200m (53%)    567Mi (1%)        784Mi (2%)
ip-10-0-155-49.eu-north-1.compute.internal    2160m (27%)    2200m (27%)    4303Mi (14%)      414Mi (1%)
ip-10-0-162-84.eu-north-1.compute.internal    3860m (48%)    3900m (49%)    8399Mi (27%)      414Mi (1%)
ip-10-0-200-101.eu-north-1.compute.internal   2160m (27%)    2200m (27%)    4303Mi (14%)      414Mi (1%)
ip-10-0-231-146.eu-north-1.compute.internal   2160m (27%)    2200m (27%)    4303Mi (14%)      414Mi (1%)
ip-10-0-251-167.eu-north-1.compute.internal   4160m (52%)    3900m (49%)    4491Mi (14%)      660Mi (2%)

benjick 2020年11月14日

👍3

Kubernetes: クラスタリソースの使用状況を確認するには、単純なkubectlコマンドが必要です

最も参考になるコメント

全てのコメント88件

関連する問題