Kubernetes: تحتاج إلى أمر kubectl بسيط لمعرفة استخدام موارد المجموعة

تم إنشاؤها على ١٩ نوفمبر ٢٠١٥  ·  88تعليقات  ·  مصدر: kubernetes/kubernetes

يتعثر المستخدمون بسبب عدم تمكنهم من الجدولة بسبب نقص الموارد. قد يكون من الصعب معرفة متى يكون البود معلقًا لأنه لم يبدأ بعد ، أو لأن الكتلة ليس لديها مجال لجدولتها. http://kubernetes.io/v1.1/docs/user-guide/compute-resources.html#monitoring -compute-Resource-Usage تساعد ، لكنها ليست قابلة للاكتشاف (أميل إلى تجربة "الحصول" على pod قيد الانتظار أولاً ، وفقط بعد الانتظار لفترة قصيرة ورؤيتها "عالقة" في الانتظار ، هل أستخدم "وصف" لإدراك أنها مشكلة في الجدولة).

هذا الأمر معقد أيضًا بسبب وجود أقراص النظام في مساحة اسم مخفية. ينسى المستخدمون أن هذه الكبسولات موجودة ، و "يحسبون ضد" موارد المجموعة.

هناك العديد من الإصلاحات الممكنة ، لا أعرف ما سيكون مثاليًا:

1) قم بتطوير حالة جراب جديدة غير المعلقة لتمثيل "حاولت جدولة وفشلت بسبب نقص الموارد".

2) اطلب من kubectl الحصول على po أو kubectl الحصول على po -o = عرض عمود على نطاق واسع لتفاصيل سبب تعليق شيء ما (ربما حالة الحاوية التي تنتظر في هذه الحالة ، أو أحدث رسالة event.message).

3) قم بإنشاء أمر kubectl جديد لوصف الموارد بسهولة أكبر. أتخيل "استخدام kubectl" الذي يعطي نظرة عامة عن إجمالي وحدة المعالجة المركزية (CPU) و Mem ، لكل وحدة CPU و Mem لكل عقدة واستخدام كل جراب / حاوية. سنقوم هنا بتضمين جميع الكبسولات ، بما في ذلك وحدات النظام. قد يكون هذا مفيدًا على المدى الطويل جنبًا إلى جنب مع برامج الجدولة الأكثر تعقيدًا ، أو عندما يكون لدى مجموعتك موارد كافية ولكن لا توجد عقدة واحدة (تشخيص مشكلة عدم وجود فجوات كبيرة بما يكفي).

kinfeature prioritbacklog sicli

التعليق الأكثر فائدة

هنالك:

$ 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% 

ال 88 كومينتر

يبدو شيء ما على غرار (2) معقولًا ، على الرغم من أن مستخدمي UX سيعرفون أفضل مني.

(3) يبدو مرتبطًا بشكل غامض بالرقم 15743 ولكني لست متأكدًا من أنهما قريبان بدرجة كافية للجمع بينهما.

بالإضافة إلى الحالة أعلاه ، سيكون من الجيد معرفة استخدام الموارد الذي نحصل عليه.

قد يظهر kubectl utilization requests (ربما يكون kubectl util أو kubectl usage أفضل / أقصر):

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

في هذا المثال ، يبلغ إجمالي طلبات الحاوية 4.455 نواة و 20.1 جيجا بايت وهناك 5 مراكز و 30 جيجا بايت إجمالاً في المجموعة.

هنالك:

$ 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% 

أستخدم الأمر أدناه للحصول على عرض سريع لاستخدام الموارد. إنها أبسط طريقة وجدتها.

kubectl describe nodes

إذا كانت هناك طريقة "لتنسيق" إخراج kubectl describe nodes ، فلن أمانع في كتابة طريقي لتلخيص جميع طلبات / حدود موارد العقدة.

هنا هو الاختراق الخاص بي kubectl describe nodes | grep -A 2 -e "^\\s*CPU Requests"

@ من - nible شكرا ، فقط ما كنت أبحث عنه

نعم ، هذا ملكي:

$ 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

goltermann لا توجد تسميات سيج على هذه المشكلة. الرجاء إضافة ملصق سيج من خلال:
(1) ذكر علامة التوقيع: @kubernetes/sig-<team-name>-misc
(2) تحديد التسمية يدويًا: /sig <label>

_ ملاحظة: ستؤدي الطريقة (1) إلى إرسال إشعار إلى الفريق. يمكنك العثور على قائمة الفريق هنا.

@ kubernetes / sig-cli-متفرقات

يمكنك استخدام الأمر أدناه للعثور على النسبة المئوية لاستخدام وحدة المعالجة المركزية لعقدك

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%

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 - شكرا على الأسماء المستعارة الخاصة بك. في حالتي ، هذا ما نجح بالنسبة لي نظرًا لأننا نستخدم أنواع المثيل bash و m3.large (2 وحدة معالجة مركزية ، ذاكرة 7.5 جيجا).

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 %

يعرض https://github.com/kubernetes/kubernetes/issues/17512#issuecomment -267992922 kubectl top الاستخدام وليس التخصيص. التخصيص هو سبب المشكلة insufficient CPU . هناك قدر كبير من الالتباس في هذه المسألة حول الاختلاف.

AFAICT ، لا توجد طريقة سهلة للحصول على تقرير بتخصيص وحدة المعالجة المركزية للعقدة بواسطة البود ، نظرًا لأن الطلبات لكل حاوية في المواصفات. وحتى ذلك الحين ، فمن الصعب نظرًا لأن .spec.containers[*].requests قد يحتوي أو لا يحتوي على حقول limits / requests (في تجربتي)

mysterikkit / cc

الدخول في حفلة البرمجة النصية هذه. لدي مجموعة أقدم تقوم بتشغيل 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.

يوجد أيضًا خيار pod في الأمر العلوي:

kubectl top pod

طريقتي للحصول على التخصيص ، على مستوى الكتلة:

$ 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

هذا غريب. أريد أن أعرف عندما أكون عند سعة التخصيص أو أقترب منها. يبدو أنها وظيفة أساسية للعنقود. سواء كانت إحصائية تُظهر نسبة مئوية عالية أو خطأ نصي ... كيف يعرف الآخرون ذلك؟ فقط استخدم دائمًا القياس التلقائي على منصة سحابية؟

قمت بتأليف 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%

تضمين التغريدة

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 : U + 0027 هو اقتباس مجعد ، وربما مشكلة نسخ ولصق

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}'

إنه يعمل مع مساحات الأسماء التي تحتوي كل منها على حاوية واحدة فقط.

xmik مرحبًا ، أنا أستخدم k8 1.7 وأقوم بتشغيل hepaster. عندما أقوم بتشغيل العقد العليا $ kubectl --heapster-namespace = kube-system ، يظهر لي "خطأ: المقاييس غير متوفرة بعد". أي دليل لمعالجة الخطأ؟

abushoeb :

  1. لا أعتقد أن kubectl top يدعم العلم: --heapster-namespace . تحرير: هذه العلامة مدعومة ، كنت على حق: https://github.com/kubernetes/kubernetes/issues/44540#issuecomment -362882035.
  2. إذا رأيت "خطأ: المقاييس غير متوفرة بعد" ، فعليك التحقق من نشر heapster. ماذا تقول سجلاتها؟ هل خدمة heapster جيدة ، ونقاط النهاية ليست <none> ؟ تحقق من الأخير بأمر مثل: kubectl -n kube-system describe svc/heapster

xmik أنت على حق ، لم يتم تكوين heapster بشكل صحيح. شكرا جزيلا. انه يعمل الان. هل تعرف ما إذا كانت هناك طريقة للحصول على معلومات استخدام GPU في الوقت الفعلي؟ هذا الأمر الأعلى يعطي فقط استخدام وحدة المعالجة المركزية والذاكرة.

لا اعرف ذلك. :(

abushoeb تظهر لي نفس الخطأ "الخطأ: المقاييس غير متوفرة بعد". كيف أصلحته؟

avgKol تحقق من نشر heapster أولاً. في حالتي ، لم يتم نشره بشكل صحيح. طريقة واحدة للتحقق من ذلك هي الوصول إلى المقاييس عبر أمر CURL مثل curl -L http://heapster-pod-ip:heapster-service-port/api/v1/model/metrics/ . إذا لم يظهر المقاييس ، فتحقق من السجلات والسجلات. يمكن الوصول إلى مقاييس hepster عبر متصفح ويب مثل هذا أيضًا.

إذا كان أي شخص مهتمًا ، فقد قمت بإنشاء أداة لإنشاء HTML ثابت لاستخدام موارد Kubernetes (والتكاليف): https://github.com/hjacobs/kube-resource-report

hjacobs أود استخدام هذه الأداة ولكني لست معجبًا بتثبيت / استخدام حزم بايثون. هل تمانع في تغليفها كصورة عامل ميناء؟

tonglil ، المشروع مبكر جدًا ، لكن خطتي هي الحصول على صورة Docker جاهزة للاستخدام بما في ذلك. خادم الويب الذي يمكنك القيام به kubectl apply -f .. باستخدامه.

هذا ما نجح معي:

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

tonglil صورة Docker متاحة الآن: https://github.com/hjacobs/kube-resource-report

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

/ إزالة دورة الحياة التي لا معنى لها

كل شهر أو نحو ذلك ، يقودني بحث Google الخاص بي إلى هذه المشكلة. هناك طرق للحصول على الإحصائيات التي أحتاجها باستخدام سلاسل طويلة من jq ، أو باستخدام لوحات معلومات Grafana مع مجموعة من العمليات الحسابية ... ولكن سيكون من الجيد أيضًا أن يكون هناك أمر مثل:

# 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 سابقًا في الموضوع).

غالبًا ما أقوم ببناء وتدمير بضع عشرات من مجموعات الاختبار كل أسبوع ، وأنا أفضل ألا أضطر إلى إنشاء أتمتة أو إضافة بعض الأسماء المستعارة لـ shell حتى أتمكن من رؤية "إذا وضعت هذه الخوادم العديدة هناك ، وألقيت هذه التطبيقات عليهم ، ما هو استخدامي / ضغوطي الإجمالية ".

خاصة بالنسبة للمجموعات الأصغر / الأكثر فئة مقصورة على فئة معينة ، لا أريد إعداد مقياس تلقائي للقمر (عادةً لأسباب مالية) ، لكنني بحاجة إلى معرفة ما إذا كان لديّ ما يكفي من النفقات العامة للتعامل مع أحداث القياس التلقائي للقرص الصغيرة.

طلب إضافي واحد - أود أن أتمكن من رؤية إجمالي استخدام الموارد حسب مساحة الاسم (على الأقل ؛ من خلال النشر / التسمية سيكون مفيدًا أيضًا) ، حتى أتمكن من تركيز جهود اقتطاع الموارد من خلال معرفة مساحات الأسماء التي تستحق التركيز على.

لقد صنعت مكونًا إضافيًا صغيرًا geerlingguy الموصوفة. التثبيت عن طريق مدير البرنامج المساعد krew متاح. يتم تنفيذ هذا في BASH ويحتاج إلى awk و bc.
باستخدام إطار عمل البرنامج المساعد kubectl ، يمكن استبعاد هذا تمامًا بعيدًا عن الأدوات الأساسية.

أنا سعيد لأن الآخرين واجهوا هذا التحدي أيضًا. لقد أنشأت Kube Eagle (مُصدِّر بروميثيوس) مما ساعدني في الحصول على نظرة عامة أفضل على موارد المجموعة ، وفي النهاية أتاح لي استخدام موارد الأجهزة المتاحة بشكل أفضل:

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

Kubernetes Resource monitoring dashboard

هذا برنامج نصي بيثون للحصول على استخدام العقدة الفعلي في تنسيق جدول
https://github.com/amelbakry/kube-node-utilization

استخدام عقدة Kubernetes ..........
+ ------------------------------------------------ + -------- + -------- +
| NodeName | وحدة المعالجة المركزية | الذاكرة |
+ ------------------------------------------------ + -------- + -------- +
| 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 ، يعد الاستخدام على مستوى المجموعة أمرًا مهمًا: "هل أحتاج إلى إضافة المزيد من الآلات؟" / "هل يجب إزالة بعض الأجهزة؟" / "هل أتوقع زيادة الكتلة قريبًا؟" ..

ماذا عن استخدام التخزين المؤقت؟ أي فكرة عن كيفية الحصول عليها من جميع القرون؟

ولكي تكون مفيدة ، تلميحاتي:

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 ، يمكنك تجربة هذا القصاصة للحصول على مقاييس pod لكل عقدة ، ويمكنك الحصول على جميع العقد مثل
https://github.com/amelbakry/kube-node-utilization

def get_pod_metrics_per_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 = خطأ)

response = json.loads (response [0] .data.decode ('utf-8'))

رد العودة

kierenj أعتقد أن مكوِّن مقياس الكتلة التلقائي الذي يعتمد على تشغيل kubernetes السحابية يجب أن يتعامل مع السعة. لست متأكدا إذا كان هذا هو سؤالك.

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

/ إزالة دورة الحياة التي لا معنى لها

أنا ، مثل كثيرين آخرين ، أواصل العودة إلى هنا - لسنوات - للحصول على الاختراق الذي نحتاجه لإدارة المجموعات عبر CLI (مثل AWS ASG)

etopeter نشكرك على هذا المكون الإضافي الرائع CLI. أحب بساطة ذلك. أي نصيحة حول كيفية فهم الأرقام بشكل أفضل ومعناها الدقيق؟

إذا كان بإمكان أي شخص أن يجد طريقة لاستخدامه هنا ، فهو برنامج نصي سيتخلص من الحدود الحالية للقرون.

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
.spec.nodeName - aks-agentpool-84550961-0
طلبات وحدة المعالجة المركزية -
limits.cpu -
طلبات الذاكرة -
حدود الذاكرة -

نظام kube
.spec.nodeName - aks-agentpool-84550961-0
الطلبات. وحدة المعالجة المركزية - 100 م
limits.cpu -
طلبات الذاكرة - 70 مي
حدود الذاكرة - 170 مي

نظام kube
.spec.nodeName - aks-agentpool-84550961-2
الطلبات. وحدة المعالجة المركزية - 100 م
limits.cpu -
طلبات الذاكرة - 70 مي
حدود الذاكرة - 170 مي

نظام kube
.spec.nodeName - aks-agentpool-84550961-1
الطلبات. وحدة المعالجة المركزية - 100 م
limits.cpu -
طلبات الذاكرة - 70 مي
حدود الذاكرة - 170 مي

نظام kube
.spec.nodeName - aks-agentpool-84550961-2
الطلبات. وحدة المعالجة المركزية - 20 م
limits.cpu -
طلبات الذاكرة - 10Mi
حدود الذاكرة -

نظام kube
.spec.nodeName - aks-agentpool-84550961-0
الطلبات. وحدة المعالجة المركزية - 20 م
limits.cpu -
طلبات الذاكرة - 10Mi
حدود الذاكرة -

نظام kube: kube-proxy-57nw5
.spec.nodeName - aks-agentpool-84550961-1
الطلبات. وحدة المعالجة المركزية - 100 م
limits.cpu -
طلبات الذاكرة -
حدود الذاكرة -
...

@ Spaceman1861 هل يمكنك عرض مثال للخروج؟

@ eduncan911 تم

أجد أنه من الأسهل قراءة المخرجات بتنسيق جدول ، مثل هذا (يعرض هذا الطلبات بدلاً من الحدود):

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 فقط لمعلوماتك: يمكنك إظهار أعمدة مخصصة مماثلة في Kubernetes Web View ("kubectl للويب") ، العرض التوضيحي: https://kube-web-view.demo.j-serv.de/clusters/local/namespaces/ الافتراضي / pods؟ Join = metrics؛ customcols = CPU + الطلبات = الانضمام (٪ 27،٪ 20٪ 27،٪ 20spec.containers [ ] .resources.requests.cpu)٪ 3B الذاكرة + الطلبات = الانضمام (٪ 27،٪ 20٪ 27 ،٪ 20spec.containers [ ] .resources.requests.memory)

محرر المستندات في الأعمدة المخصصة: https://kube-web-view.readthedocs.io/en/latest/features.html#listing -resources

أووو لامعة hjacobs أنا أحب ذلك.

هذا هو برنامج نصي (publish-health.sh) للحصول على الاستفادة من البودات في النشر على أساس الاستخدام والحدود التي تم تكوينها
https://github.com/amelbakry/kubernetes-scripts

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

مستوحاة من إجابات @ 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'"'"' '"'" 

ملاحظة: لقد اختبرت البرامج النصية فقط على جهاز Mac الخاص بي ، وقد تتطلب بعض التغييرات في نظام التشغيل Linux و windows

هذا هو برنامج نصي (publish-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.

ووبس ،
"#!" يجب أن يكون السطر الأول. بدلا من ذلك جرب "bash
./deployment-health.sh "للتغلب على هذه المشكلة.

/ تشارلز
ملاحظة. تم فتح العلاقات العامة لإصلاح المشكلة

يوم الأربعاء 25 سبتمبر 2019 الساعة 10:19 صباحًا Dmitri Moore [email protected]
كتب:

هذا برنامج نصي (publish-health.sh) للحصول على الاستفادة من pods
في النشر على أساس الاستخدام والحدود المكونة
https://github.com/amelbakry/kubernetes-scripts

amelbakry https://github.com/amelbakry أنا أتلقى ما يلي
خطأ أثناء محاولة تنفيذه على جهاز Mac:

فشل تنفيذ العملية "./deployment-health.sh". سبب:
exec: خطأ تنسيق Exec
تم وضع علامة على الملف "./deployment-health.sh" كملف قابل للتنفيذ ولكن لا يمكن تشغيله بواسطة نظام التشغيل.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/17512؟email_source=notifications&email_token=AACA3TODQEUPWK3V3UY3SF3QLOMSFA5CNFSM4BUXCUG2YY3PNVWWK3TUL52HS4DFVREXG43VM86
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AACA3TOPOBIWXFX2DAOT6JDQLOMSFANCNFSM4BUXCUGQ
.

cgthayer قد ترغب في تطبيق إصلاح العلاقات العامة هذا على مستوى العالم. أيضًا ، عندما قمت بتشغيل البرامج النصية على MacOs Mojave ، ظهرت مجموعة من الأخطاء ، بما في ذلك أسماء مناطق محددة في الاتحاد الأوروبي والتي لا أستخدمها. يبدو أن هذه النصوص قد تمت كتابتها لمشروع معين.

إليك نسخة معدلة من ex. والذي يقوم بعمل مجاميع الأعمدة أيضًا.

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
==================================================

وما هو Usage_chk3؟

أود أيضًا مشاركة أدواتي ؛-) kubectl-view-تخصيصات: kubectl plugin لإدراج التخصيصات (وحدة المعالجة المركزية ، الذاكرة ، 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-use للإلهام ، لكن إضافة الدعم إلى الموارد الأخرى كان للعديد من النسخ / اللصق أو كان من الصعب عليّ القيام به في bash (بطريقة عامة).

هنا هو الاختراق الخاص بي kubectl describe nodes | grep -A 2 -e "^\\s*CPU Requests"

هذا لا يعمل بعد الآن :(

جرّب kubectl describe node | grep -A5 "Allocated"

تعد هذه حاليًا رابع أكبر مشكلة مطلوبة من خلال الإعجاب ، ولكنها لا تزال priority/backlog .

سأكون سعيدًا لأخذ طعنة في هذا إذا كان بإمكان شخص ما توجيهي في الاتجاه الصحيح أو إذا تمكنا من وضع اللمسات الأخيرة على اقتراح. أعتقد أن تجربة المستخدم لأداةdavidB رائعة ، ولكن هذا حقًا ينتمي إلى جوهر kubectl .

باستخدام التعليمات التالية: kubectl top nodes & kubectl describe node لا نحصل على نتائج متسقة

على سبيل المثال ، في الحالة الأولى ، تبلغ وحدة المعالجة المركزية (النوى) 1064 م ولكن لا يمكن الحصول على هذه النتيجة مع الثانية (1480 م):

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 ؟

أود أيضًا مشاركة أدواتي ؛-) kubectl-view-تخصيصات: kubectl plugin لإدراج التخصيصات (وحدة المعالجة المركزية ، الذاكرة ، 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-use للإلهام ، لكن إضافة الدعم إلى الموارد الأخرى كان للعديد من النسخ / اللصق أو كان من الصعب عليّ القيام به في bash (بطريقة عامة).

مرحبًا ديفيد ، سيكون من الجيد أن تقوم بتوفير المزيد من الملفات الثنائية المجمعة للتوزيعات الجديدة. حصلنا على Ubuntu 16.04

تخصيصات kubectl-view: /lib/x86_64-linux-gnu/libc.so.6: الإصدار "GLIBC_2.25" غير موجود (مطلوب من قبل تخصيصات kubectl-view-view)

dpkg -l |grep glib

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

omerfsen هل يمكنك تجربة الإصدار الجديد من kubectl-view-تخصيصات والتعليق على إصدار التذكرة

طريقتي للحصول على التخصيص ، على مستوى الكتلة:

$ 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

إلى حد بعيد أفضل إجابة هنا.

مستوحاة من البرامج النصية أعلاه ، قمت بإنشاء البرنامج النصي التالي لعرض الاستخدام والطلبات والحدود:

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 shell يتوقع قائمة مرتبة ، فقد فشلت البرامج النصية الواردة أعلاه بالنسبة لي.

ترى كنتيجة للاستخدام الحالي من الأعلى ومن النشر طلبات وحدود جميع مساحات الأسماء (هنا):

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

جدير بالملاحظة: يمكنك الفرز على استهلاك وحدة المعالجة المركزية على سبيل المثال:

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

هذا يعمل على نظام Mac - لست متأكدًا ، إذا كان يعمل على Linux أيضًا (بسبب الانضمام والفرز وما إلى ذلك ...).

نأمل أن يتمكن شخص ما من استخدام هذا حتى يحصل kubectl على رؤية جيدة لذلك.

لدي خبرة جيدة مع قدرة kube .

مثال:

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%)

لكي تكون هذه الأداة مفيدة حقًا ، يجب أن تكتشف جميع المكونات الإضافية لجهاز kubernetes التي تم نشرها على المجموعة وإظهار الاستخدام لكل منها. CPU / Mem بالتأكيد ليست كافية. هناك أيضًا وحدات معالجة الرسومات (GPU) و TPU (للتعلم الآلي) و Intel QAT وربما أكثر من ذلك الذي لا أعرفه. أيضا ماذا عن التخزين؟ يجب أن أكون قادرًا بسهولة على رؤية ما تم طلبه وما يتم استخدامه (بشكل مثالي من حيث iops أيضًا).

@ boniek83 ، هذا هو سبب إنشاء تخصيصات kubectl-view-view ، لأنني بحاجة إلى سرد GPU ، ...

@ boniek83 ، هذا هو سبب إنشاء تخصيصات kubectl-view-view ، لأنني بحاجة إلى سرد GPU ، ...

أنا على دراية بأداتك ، ولأغراضي ، فهي أفضل ما هو متاح حاليًا. شكرا على صنعه!
سأحاول اختبار TPU بعد عيد الفصح. سيكون من المفيد أن تكون هذه البيانات متاحة في تنسيق تطبيقات الويب مع رسوم بيانية جميلة ، لذلك لن أضطر إلى منح أي وصول إلى kubernetes لعلماء البيانات. إنهم يريدون فقط معرفة من يأكل الموارد ولا شيء أكثر :)

نظرًا لعدم ملاءمة أي من الأدوات والنصوص المذكورة أعلاه لاحتياجاتي (وهذه المشكلة لا تزال مفتوحة :() ، فقد اخترقت البديل الخاص بي:
https://github.com/eht16/kube-cargo-load

يوفر نظرة عامة سريعة على PODs في مجموعة ويظهر طلبات وحدود الذاكرة التي تم تكوينها والاستخدام الفعلي للذاكرة. الفكرة هي الحصول على صورة للنسبة بين حدود الذاكرة المكونة والاستخدام الفعلي.

كيف يمكننا الحصول على سجلات مقالب الذاكرة للقرون؟
غالبًا ما يتم تعليق القرون ،

  • kubectl describe nodes OR kubectl top nodes ، أي واحد يجب مراعاته لحساب استخدام موارد الكتلة؟
  • أيضا لماذا هناك فرق بين هاتين النتيجتين.
    هل هناك أي تفسير منطقي لهذا حتى الآن؟

/ نوع الميزة

عملت جميع التعليقات والاختراقات مع العقد بشكل جيد بالنسبة لي. أحتاج أيضًا إلى شيء ما للحصول على عرض أعلى لتتبعه .. مثل مجموع الموارد لكل مجموعة عقدة!

أهلا،
أريد تسجيل استخدام وحدة المعالجة المركزية والذاكرة لحجرة كل 5 دقائق خلال فترة زمنية. سأستخدم بعد ذلك هذه البيانات لإنشاء رسم بياني في Excel. أيه أفكار؟ شكرا

أهلا،
يسعدني أن أرى أن Google وجهتنا جميعًا إلى هذه المشكلة :-) (أشعر بخيبة أمل بعض الشيء لأنه لا يزال مفتوحًا بعد حوالي 5 سنوات.) شكرًا لجميع قصاصات shell والأدوات الأخرى.

اختراق بسيط وسريع:

$ 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%)

اختراق بسيط وسريع:

$ 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%)

المكونات الإضافية للجهاز غير موجودة. يجب أن يكونوا. هذه الأجهزة هي موارد أيضًا.

أهلا!

لقد أنشأت هذا البرنامج النصي وشاركته معك.

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

يحتوي هذا النص على تجميع لبعض الأفكار التي شاركتها هنا. يمكن زيادة النص ويمكن أن يساعد الآخرين في الحصول على المقاييس بشكل أكثر بساطة.

شكرا لمشاركة النصائح والأوامر!

بالنسبة لحالة الاستخدام الخاصة بي ، انتهى بي الأمر بكتابة مكون إضافي بسيط kubectl يسرد حدود / حجوزات وحدة المعالجة المركزية / ذاكرة الوصول العشوائي للعقد في الجدول. كما يتحقق أيضًا من استهلاك وحدة المعالجة المركزية (CPU) / ذاكرة الوصول العشوائي (RAM) الحالية (مثل kubectl top pods ) ، ولكن يتم ترتيب الإخراج بواسطة وحدة المعالجة المركزية بترتيب تنازلي.

إنها أكثر راحة من أي شيء آخر ، ولكن ربما يجدها شخص آخر مفيدة أيضًا.

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

توقف ، يا له من خيط ضخم وما زال لا يوجد حل مناسب من فريق kubernetes لحساب الاستخدام الكلي الحالي لوحدة المعالجة المركزية لمجموعة كاملة بشكل صحيح؟

لأولئك الذين يتطلعون إلى تشغيل هذا على minikube ، قم أولاً بتمكين الوظيفة الإضافية للخادم المتري
minikube addons enable metrics-server
ثم قم بتشغيل الأمر
kubectl top nodes

إذا كنت تستخدم 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%)
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات