Kubernetes: क्लस्टर संसाधन उपयोग देखने के लिए सरल कुबेक्टल कमांड की आवश्यकता है

(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 GiB हैं और क्लस्टर में कुल 5 कोर और 30GiB हैं।

वहाँ है:

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

@ से-बिल्कुल धन्यवाद, बस वही जो मैं ढूंढ रहा था

हाँ, यह मेरा है:

$ 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) टीम को एक सूचना ट्रिगर करेगी। आप टीम की सूची यहां देख सकते हैं ._

@ कुबेरनेट्स / sig-cli-misc

आप अपने नोड्स के प्रतिशत सीपीयू उपयोग का पता लगाने के लिए नीचे दिए गए कमांड का उपयोग कर सकते हैं

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

@ आलोक87 - आपके उपनामों के लिए धन्यवाद। मेरे मामले में, यह मेरे लिए काम करता है कि हम 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, पॉड द्वारा नोड CPU आवंटन की रिपोर्ट प्राप्त करने का कोई आसान तरीका नहीं है, क्योंकि अनुरोध कल्पना में प्रति कंटेनर हैं। और फिर भी, यह मुश्किल है क्योंकि .spec.containers[*].requests में limits / requests फ़ील्ड हो सकते हैं या नहीं भी हो सकते हैं (मेरे अनुभव में)

/सीसी @mysterikkit

इस शेल स्क्रिप्टिंग पार्टी में शामिल होना। मेरे पास एक पुराना क्लस्टर है जो 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.

शीर्ष आदेश में पॉड विकल्प भी है:

kubectl top pod

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

आवंटन प्राप्त करने का मेरा तरीका, क्लस्टर-व्यापी:

$ 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

यह अजीब है। मैं जानना चाहता हूं कि मैं आवंटन क्षमता पर कब हूं या उसके करीब हूं। यह एक क्लस्टर का एक बहुत ही बुनियादी कार्य लगता है। क्या यह एक ऐसा आँकड़ा है जो एक उच्च% या पाठ्य त्रुटि दिखाता है ... अन्य लोग इसे कैसे जानते हैं? क्लाउड प्लेटफॉर्म पर हमेशा ऑटोस्केलिंग का उपयोग करें?

मैंने #3 पते पर https://github.com/dpetzold/kube-resource-explorer/ लिखा है। यहाँ कुछ नमूना आउटपुट है:

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

@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 : यू

@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 कंटेनर होता है।

@xmik अरे, मैं k8 1.7 का उपयोग कर रहा हूं और हेपस्टर चला रहा हूं। जब मैं $ kubectl शीर्ष नोड्स --heapster-namespace=kube-system चलाता हूं, तो यह मुझे "त्रुटि: मेट्रिक्स अभी तक उपलब्ध नहीं" दिखाता है। त्रुटि से निपटने के लिए कोई सुराग?

@abushoeb :

1. मुझे नहीं लगता कि kubectl top ध्वज का समर्थन करता है: --heapster-namespace । संपादित करें: यह ध्वज समर्थित है, आप सही थे: https://github.com/kubernetes/kubernetes/issues/44540#issuecomment -362882035।
2. यदि आप "त्रुटि: मेट्रिक्स अभी तक उपलब्ध नहीं" देखते हैं, तो आपको हीपस्टर परिनियोजन की जांच करनी चाहिए। इसके लॉग क्या कहते हैं? क्या हीपस्टर सेवा ठीक है, समापन बिंदु <none> ? बाद वाले को कमांड के साथ जांचें: kubectl -n kube-system describe svc/heapster

@xmik आप सही हैं, हीपस्टर ठीक से कॉन्फ़िगर नहीं किया गया था। बहुत - बहुत धन्यवाद। अब यह काम कर रहा है। क्या आप जानते हैं कि रीयल-टाइम GPU उपयोग की जानकारी प्राप्त करने का कोई तरीका है या नहीं? यह शीर्ष आदेश केवल CPU और मेमोरी उपयोग देता है।

मुझे यह नहीं पता। :(

@abushoeb मुझे वही त्रुटि मिल रही है "त्रुटि: मेट्रिक्स अभी तक उपलब्ध नहीं है"। आपने यह कैसे फिक्स किया?

@avgKol पहले आप हीपस्टर परिनियोजन की जाँच करें। मेरे मामले में, इसे ठीक से तैनात नहीं किया गया था। इसे जांचने का एक तरीका curl -L http://heapster-pod-ip:heapster-service-port/api/v1/model/metrics/ जैसे कर्ल कमांड के माध्यम से मेट्रिक्स तक पहुंचना है। यदि यह मेट्रिक्स नहीं दिखाता है तो हीपस्टर पॉड और लॉग की जाँच करें। हेपस्टर मेट्रिक्स को इस तरह भी एक वेब ब्राउज़र के माध्यम से एक्सेस किया जा सकता है।

यदि कोई दिलचस्पी रखता है, तो मैंने कुबेरनेट्स संसाधन उपयोग (और लागत) के लिए स्थिर HTML उत्पन्न करने के लिए एक उपकरण बनाया है: https://github.com/hjacobs/kube-resource-report

@hjacobs मैं उस उपकरण का उपयोग करना चाहूंगा, लेकिन अजगर पैकेजों को स्थापित/उपयोग करने का प्रशंसक नहीं हूं। एक डॉकटर छवि के रूप में इसे पैक करने का मन?

@tonglil परियोजना बहुत जल्दी है, लेकिन मेरी योजना एक आउट-ऑफ-द-बॉक्स तैयार डॉकर छवि सहित है। वेबसर्वर जिसके साथ आप बस 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 एक डॉकर छवि अब उपलब्ध है: https://github.com/hjacobs/kube-resource-report

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया इसे /close ।

सिग-टेस्टिंग, कुबेरनेट्स/टेस्ट-इन्फ्रा और/या फेजटा को फीडबैक भेजें ।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

हर महीने या तो, मेरी गुगलिंग मुझे इस मुद्दे पर वापस ले जाती है। लंबे jq स्ट्रिंग्स के साथ, या गणनाओं के एक समूह के साथ ग्राफाना डैशबोर्ड के साथ मुझे आवश्यक आँकड़े प्राप्त करने के तरीके हैं ...

# 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 ने पहले सूत्र में बताया था)।

मैं अक्सर प्रति सप्ताह कुछ दर्जन परीक्षण समूहों का निर्माण और नष्ट कर रहा हूं, और मुझे स्वचालन बनाने या कुछ शेल उपनामों में जोड़ने की ज़रूरत नहीं है, ताकि मैं यह देख सकूं कि "अगर मैं वहां कई सर्वर डालता हूं, और इन ऐप्स को टॉस करता हूं उन पर, मेरा समग्र उपयोग/दबाव क्या है"।

विशेष रूप से छोटे / अधिक गूढ़ समूहों के लिए, मैं ऑटोस्केल-टू-द-मून (आमतौर पर पैसे के कारणों के लिए) स्थापित नहीं करना चाहता, लेकिन यह जानने की जरूरत है कि क्या मेरे पास मामूली पॉड ऑटोस्केलिंग घटनाओं को संभालने के लिए पर्याप्त ओवरहेड है।

एक अतिरिक्त अनुरोध - मैं नामस्थान द्वारा सारांशित संसाधन उपयोग को देखने में सक्षम होना चाहता हूं (कम से कम; परिनियोजन/लेबल द्वारा भी उपयोगी होगा), इसलिए मैं अपने संसाधन-ट्रिमिंग प्रयासों पर ध्यान केंद्रित कर सकता हूं कि कौन से नामस्थान लायक हैं पर ध्यान केंद्रित कर रहा है।

मैंने एक छोटा प्लगइन kubectl-view-utilization बनाया है , जो वर्णित कार्यक्षमता @geerlingguy प्रदान करता है। क्रू प्लगइन प्रबंधक के माध्यम से स्थापना उपलब्ध है। इसे बाश में लागू किया गया है और इसे अजीब और बीसी की जरूरत है।
Kubectl प्लगइन फ्रेमवर्क के साथ इसे कोर टूल्स से पूरी तरह से दूर किया जा सकता है।

मुझे खुशी है कि अन्य लोग भी इस चुनौती का सामना कर रहे थे। मैंने क्यूब ईगल (एक प्रोमेथियस निर्यातक) बनाया जिसने मुझे क्लस्टर संसाधनों का बेहतर अवलोकन प्राप्त करने में मदद की और अंततः मुझे उपलब्ध हार्डवेयर संसाधनों का बेहतर उपयोग करने दिया:

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

तालिका प्रारूप में वास्तविक नोड उपयोग प्राप्त करने के लिए यह एक पायथन लिपि है
https://github.com/amelbakry/kube-node-utilization

कुबेरनेट्स नोड उपयोग ............
+--------------------------------------------------------+ --------+----------+
| नोडनाम | सीपीयू | मेमोरी |
+--------------------------------------------------------+ --------+----------+
| आईपी-176-35-32-139.eu-central-1.compute.internal | 13.49% | 60.87% |
| आईपी-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% |
| आईपी-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 आप पॉड मेट्रिक्स प्रति नोड प्राप्त करने के लिए इस स्निपेट को आजमा सकते हैं, आप सभी नोड्स प्राप्त कर सकते हैं
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=false)

प्रतिक्रिया = json.loads (प्रतिक्रिया [0] .data.decode ('utf-8'))

वापसी प्रतिक्रिया

@kierenj मुझे लगता है कि क्लस्टर-

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया इसे /close ।

सिग-टेस्टिंग, कुबेरनेट्स/टेस्ट-इन्फ्रा और/या फेजटा को फीडबैक भेजें ।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

मैं, कई अन्य लोगों की तरह, यहां वापस आता रहता हूं - वर्षों तक - हैक प्राप्त करने के लिए हमें सीएलआई (जैसे एडब्ल्यूएस एएसजी) के माध्यम से क्लस्टर प्रबंधित करने की आवश्यकता होती है।

@etopeter इतनी अच्छी सीएलआई प्लगइन के लिए धन्यवाद। इसकी सादगी पसंद है। संख्याओं और उनके सटीक अर्थ को बेहतर ढंग से समझने के बारे में कोई सलाह?

अगर किसी को इसका उपयोग मिल सकता है तो यहां एक स्क्रिप्ट है जो फली की वर्तमान सीमा को डंप कर देगी।

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

उदाहरण आउटपुट
...
क्यूब- सिस्टम: एडऑन-http-
.spec.nodeName - अक्स-एजेंटपूल-84550961-0
request.cpu -
सीमाएं.सीपीयू -
अनुरोध.स्मृति -
सीमा.स्मृति -

क्यूब- सिस्टम: coredns-696c4d987c-pjht8
.spec.nodeName - अक्स-एजेंटपूल-84550961-0
request.cpu - 100m
सीमाएं.सीपीयू -
request.memory - 70Mi
सीमाएं.मेमोरी - 170Mi

क्यूब- सिस्टम: coredns-696c4d987c-rtkl6
.spec.nodeName - अक्स-एजेंटपूल-84550961-2
request.cpu - 100m
सीमाएं.सीपीयू -
request.memory - 70Mi
सीमाएं.मेमोरी - 170Mi

क्यूब- सिस्टम: coredns-696c4d987c-zgcbp
.spec.nodeName - अक्स-एजेंटपूल-84550961-1
request.cpu - 100m
सीमाएं.सीपीयू -
request.memory - 70Mi
सीमाएं.मेमोरी - 170Mi

क्यूब- सिस्टम: कोर्डन्स-ऑटोस्केलर-657d77ffbf-7t72x
.spec.nodeName - अक्स-एजेंटपूल-84550961-2
request.cpu - 20m
सीमाएं.सीपीयू -
request.memory - 10Mi
सीमा.स्मृति -

क्यूब- सिस्टम: coredns-autoscaler-657d77ffbf-zrp6m
.spec.nodeName - अक्स-एजेंटपूल-84550961-0
request.cpu - 20m
सीमाएं.सीपीयू -
request.memory - 10Mi
सीमा.स्मृति -

क्यूब- सिस्टम: क्यूब-प्रॉक्सी-57nw5
.spec.nodeName - अक्स-एजेंटपूल-84550961-1
request.cpu - 100m
सीमाएं.सीपीयू -
अनुरोध.स्मृति -
सीमा.स्मृति -
...

@ 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 बस FYI करें: आप में समान कस्टम कॉलम दिखा सकते हैं Kubernetes वेब दृश्य ( "वेब के लिए kubectl"), डेमो: https://kube-web-view.demo.j-serv.de/clusters/local/namespaces/ ? डिफ़ॉल्ट / फली में शामिल होने = मैट्रिक्स; customcols = सीपीयू + अनुरोध = में शामिल होने के (% 27% 20% 27% 20spec.containers [] .resources.requests.cpu)% 3BMemory + अनुरोध = में शामिल होने के (% 27% 20% 27% 20spec.containers [] .resources.requests.memory)

कस्टम स्तंभ पर डॉक्स: https://kube-web-view.readthedocs.io/en/latest/features.html#listing -resources

ऊओ चमकदार

उपयोग और कॉन्फ़िगर की गई सीमाओं के आधार पर तैनाती में पॉड्स का उपयोग प्राप्त करने के लिए यह एक स्क्रिप्ट (तैनाती-स्वास्थ्य.श) है
https://github.com/amelbakry/kubernetes-scripts

@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'"'"' '"'" 

पीएस मैंने केवल अपने मैक पर स्क्रिप्ट का परीक्षण किया है, लिनक्स और विंडोज़ के लिए इसमें कुछ बदलावों की आवश्यकता हो सकती है

उपयोग और कॉन्फ़िगर की गई सीमाओं के आधार पर तैनाती में पॉड्स का उपयोग प्राप्त करने के लिए यह एक स्क्रिप्ट (तैनाती-स्वास्थ्य.श) है
https://github.com/amelbakry/kubernetes-scripts

@amelbakry मुझे मैक पर इसे निष्पादित करने का प्रयास करने में निम्न त्रुटि मिल रही है:

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.

वूप्स,
"#!" पहली पंक्ति होने की जरूरत है। इसके बजाय "बाशो" का प्रयास करें
./deployment-health.sh" समस्या को हल करने के लिए।

/चार्ल्स
पुनश्च. पीआर ने इस मुद्दे को ठीक करने के लिए खोला

बुधवार, 25 सितंबर, 2019 को सुबह 10:19 बजे दिमित्री मूर सूचनाएं @github.com
लिखा था:

पॉड्स का उपयोग करने के लिए यह एक स्क्रिप्ट (तैनाती-स्वास्थ्य.श) है
उपयोग और कॉन्फ़िगर की गई सीमाओं के आधार पर परिनियोजन में
https://github.com/amelbakry/kubernetes-scripts

@amelbakry https://github.com/amelbakry मुझे निम्नलिखित मिल रहे हैं
मैक पर इसे निष्पादित करने का प्रयास करने में त्रुटि:

प्रक्रिया './deployment-health.sh' निष्पादित करने में विफल। कारण:
निष्पादन: निष्पादन प्रारूप त्रुटि
फ़ाइल './deployment-health.sh' को एक निष्पादन योग्य के रूप में चिह्नित किया गया है लेकिन ऑपरेटिंग सिस्टम द्वारा नहीं चलाया जा सकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/17512?email_source=notifications&email_token=AACA3TODQEUPWK3V3UY3SF3QLOMSFA5CNFSM4BUXCUG2YY3PNVWWK3WTUL52HS4DFVREXG43VMVHJHRKGODNMV
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AACA3TOPOBIWXFX2DAOT6JDQLOMSFANCNFSM4BUXCUGQ
.

@cgthayer आप विश्व स्तर पर उस पीआर फिक्स को लागू करना चाहेंगे। इसके अलावा, जब मैंने MacOs Mojave पर स्क्रिप्ट चलाई, तो त्रुटियों का एक समूह दिखाई दिया, जिसमें यूरोपीय संघ के विशिष्ट क्षेत्र के नाम शामिल हैं जिनका मैं उपयोग नहीं करता। ऐसा लगता है कि ये स्क्रिप्ट किसी खास प्रोजेक्ट के लिए लिखी गई हैं।

यहां शामिल हों पूर्व का एक संशोधित संस्करण है। जो कुल कॉलम भी करता है।

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

और use_chk3 क्या है?

मैं अपने टूल्स ;-) kubectl-view-allocations: kubectl प्लगइन को सूची आवंटन (सीपीयू, मेमोरी, जीपीयू, ... एक्स अनुरोधित, सीमा, आवंटन योग्य, ...) साझा करना चाहता हूं। , अनुरोध का स्वागत है।

मैंने इसे इसलिए बनाया क्योंकि मैं अपने (आंतरिक) उपयोगकर्ताओं को यह देखने का एक तरीका प्रदान करना चाहता हूं कि "कौन क्या आवंटित करता है"। डिफ़ॉल्ट रूप से प्रत्येक संसाधन प्रदर्शित होते हैं, लेकिन निम्नलिखित नमूने में मैं केवल "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

आने वाले संस्करण:

• छिपाने की अनुमति देगा (नोड, पॉड) स्तर या समूह कैसे चुनें, (उदाहरण के लिए केवल संसाधनों के साथ एक सिंहावलोकन प्रदान करने के लिए)
• कर्ल, क्रू, ब्रू, ... के माध्यम से इंस्टॉलेशन (वर्तमान में बाइनरी जीथब के रिलीज सेक्शन के तहत उपलब्ध हैं)

प्रेरणा के लिए कुबेक्टल-व्यू-यूटिलाइजेशन के लिए धन्यवाद, लेकिन अन्य संसाधनों के लिए समर्थन जोड़ना मेरे लिए बैश (सामान्य तरीके से) में कई कॉपी/पेस्ट या करना मुश्किल था।

यहाँ मेरा हैक है kubectl describe nodes | grep -A 2 -e "^\\s*CPU Requests"

यह अब और काम नहीं करता है :(

kubectl describe node | grep -A5 "Allocated" आज़माएं

यह वर्तमान में थम्स अप द्वारा अनुरोधित चौथा सबसे बड़ा मुद्दा है, लेकिन फिर भी priority/backlog ।

अगर कोई मुझे सही दिशा में इंगित कर सकता है या अगर हम एक प्रस्ताव को अंतिम रूप दे सकते हैं तो मुझे इस पर एक कदम उठाने में खुशी होगी। मुझे लगता है कि @davidB के टूल का UX कमाल का है, लेकिन यह वास्तव में मूल kubectl ।

निम्नलिखित कमांड का उपयोग करना: kubectl top nodes और kubectl describe node हमें लगातार परिणाम नहीं मिलते हैं

उदाहरण के लिए पहले वाले के साथ CPU (कोर) 1064m है लेकिन यह परिणाम दूसरे (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 (कोर) प्राप्त करने के बारे में कोई विचार?

मैं अपने टूल्स ;-) kubectl-view-allocations: kubectl प्लगइन को सूची आवंटन (सीपीयू, मेमोरी, जीपीयू, ... एक्स अनुरोधित, सीमा, आवंटन योग्य, ...) साझा करना चाहता हूं। , अनुरोध का स्वागत है।

मैंने इसे इसलिए बनाया क्योंकि मैं अपने (आंतरिक) उपयोगकर्ताओं को यह देखने का एक तरीका प्रदान करना चाहता हूं कि "कौन क्या आवंटित करता है"। डिफ़ॉल्ट रूप से प्रत्येक संसाधन प्रदर्शित होते हैं, लेकिन निम्नलिखित नमूने में मैं केवल "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)

प्रेरणा के लिए कुबेक्टल-व्यू-यूटिलाइजेशन के लिए धन्यवाद, लेकिन अन्य संसाधनों के लिए समर्थन जोड़ना मेरे लिए बैश (सामान्य तरीके से) में कई कॉपी/पेस्ट या करना मुश्किल था।

हैलो डेविड यह अच्छा होगा यदि आप नए वितरण के लिए अधिक संकलित बाइनरी प्रदान करते हैं। उबंटू 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 क्या आप नए संस्करण kubectl-view-allocations संस्करण 'GLIBC_2.25' पर टिप्पणी कर सकते हैं जो

आवंटन प्राप्त करने का मेरा तरीका, क्लस्टर-व्यापी:

$ 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 शेल स्क्रिप्ट एक क्रमबद्ध सूची की अपेक्षा करती है, ऊपर दी गई स्क्रिप्ट मेरे लिए विफल रही।

परिणामस्वरूप आप शीर्ष से वर्तमान उपयोग और परिनियोजन से अनुरोध और (यहां) सभी नामस्थानों की सीमाएं देखते हैं:

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

यह मैक पर काम करता है - मुझे यकीन नहीं है, अगर यह लिनक्स पर भी काम करता है (शामिल होने, सॉर्ट करने आदि के कारण ...)

उम्मीद है, कोई इसका उपयोग तब तक कर सकता है जब तक कि कुबेक्टल को इसके लिए एक अच्छा दृश्य न मिल जाए।

मुझे क्यूब-क्षमता के साथ अच्छा अनुभव

उदाहरण:

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

इस उपकरण के वास्तव में उपयोगी होने के लिए इसे क्लस्टर पर तैनात सभी कुबेरनेट डिवाइस प्लगइन्स का पता लगाना चाहिए और उन सभी के लिए उपयोग दिखाना चाहिए। सीपीयू/मेम निश्चित रूप से पर्याप्त नहीं है। जीपीयू, टीपीयू (मशीन लर्निंग के लिए), इंटेल क्यूएटी और शायद अधिक के बारे में मुझे पता नहीं है। भंडारण के बारे में भी क्या? मुझे आसानी से यह देखने में सक्षम होना चाहिए कि क्या अनुरोध किया गया था और क्या उपयोग किया जाता है (आदर्श रूप से आईओएस के मामले में भी)।

@ boniek83 , यही कारण है कि मैंने kubectl-view-allocations बनाया , क्योंकि मुझे GPU सूचीबद्ध करने की आवश्यकता है, ... किसी भी प्रतिक्रिया (गीथब प्रोजेक्ट पर) का स्वागत है। मुझे यह जानने की उत्सुकता है कि क्या यह टीपीयू का पता लगाता है (इसे नोड के संसाधनों के रूप में सूचीबद्ध किया जाना चाहिए)

@ boniek83 , यही कारण है कि मैंने kubectl-view-allocations बनाया , क्योंकि मुझे GPU सूचीबद्ध करने की आवश्यकता है, ... किसी भी प्रतिक्रिया (गीथब प्रोजेक्ट पर) का स्वागत है। मुझे यह जानने की उत्सुकता है कि क्या यह टीपीयू का पता लगाता है (इसे नोड के संसाधनों के रूप में सूचीबद्ध किया जाना चाहिए)

मुझे आपके टूल के बारे में पता है और, मेरे उद्देश्य के लिए, यह वर्तमान में उपलब्ध सर्वोत्तम है। इसे बनाने के लिए धन्यवाद!
मैं ईस्टर के बाद टीपीयू का परीक्षण कराने की कोशिश करूंगा। यह उपयोगी होगा यदि यह डेटा वेब ऐप प्रारूप में सुंदर ग्राफ के साथ उपलब्ध होगा, इसलिए मुझे डेटा वैज्ञानिकों को कुबेरनेट्स तक कोई पहुंच नहीं देनी पड़ेगी। वे केवल यह जानना चाहते हैं कि संसाधनों को कौन खा रहा है और कुछ नहीं :)

चूंकि उपरोक्त में से कोई भी उपकरण और स्क्रिप्ट मेरी आवश्यकताओं के अनुरूप नहीं है (और यह समस्या अभी भी खुली है :( ), मैंने अपना स्वयं का संस्करण हैक कर लिया है:
https://github.com/eht16/kube-cargo-load

यह क्लस्टर में POD का त्वरित अवलोकन प्रदान करता है और उनके कॉन्फ़िगर किए गए मेमोरी अनुरोधों और सीमाओं और वास्तविक मेमोरी उपयोग को दिखाता है। विचार कॉन्फ़िगर की गई स्मृति सीमा और वास्तविक उपयोग के बीच अनुपात की एक तस्वीर प्राप्त करना है।

हम पॉड्स के मेमोरी डंप लॉग कैसे प्राप्त कर सकते हैं?
फली अक्सर लटकती रहती है,

• kubectl describe nodes या kubectl top nodes , क्लस्टर संसाधन उपयोग की गणना के लिए किस पर विचार किया जाना चाहिए?
• साथ ही इन 2 परिणामों में अंतर क्यों है।
  क्या इसकी अभी तक कोई तार्किक व्याख्या है?

/ तरह की सुविधा

नोड्स के साथ सभी टिप्पणियों और हैक्स ने मेरे लिए अच्छा काम किया। मुझे उच्च दृश्य के लिए भी कुछ चाहिए .. प्रति नोड पूल संसाधनों की तरह का ट्रैक रखने के लिए!

नमस्ते,
मैं एक पॉड के लिए सीपीयू और मेमोरी उपयोग को हर 5 मिनट में लॉग करना चाहता हूं। मैं एक्सेल में ग्राफ बनाने के लिए इस डेटा का उपयोग करूंगा। कोई विचार? धन्यवाद

नमस्ते,
मुझे यह देखकर खुशी हुई कि Google ने हम सभी को इस मुद्दे की ओर इशारा किया :-) (थोड़ा निराश है कि यह लगभग 5y के बाद भी खुला है।) सभी शेल स्निप्स और अन्य टूल के लिए धन्यवाद।

सरल और त्वरित हैक:

$ 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 ) की भी जांच करता है, लेकिन CPU द्वारा आउटपुट को अवरोही क्रम में ऑर्डर करता है।

यह किसी भी चीज़ की तुलना में अधिक सुविधाजनक है, लेकिन हो सकता है कि किसी और को भी यह उपयोगी लगे।

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

वाह, एक पूरे क्लस्टर के वर्तमान समग्र सीपीयू उपयोग की ठीक से गणना करने के लिए कुबेरनेट्स टीम से कितना बड़ा धागा और अभी भी कोई उचित समाधान नहीं है?

जो लोग इसे मिनीक्यूब पर चलाना चाहते हैं, उनके लिए पहले मीट्रिक सर्वर ऐड-ऑन सक्षम करें
minikube addons enable metrics-server
और फिर कमांड चलाएँ
kubectl top nodes

यदि आप क्रू का उपयोग कर रहे हैं:

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