Kubernetes: 클러스터 리소스 사용량을 보려면 간단한 kubectl 명령이 필요합니다.

UX 사람들이 나보다 더 잘 알겠지만 (2)의 라인을 따라 뭔가가 합리적으로 보입니다.

(3) #15743과 모호하게 관련되어 있는 것 같지만 결합하기에 충분히 가까운지 확신할 수 없습니다.

위의 경우 외에도 리소스 활용도를 확인하는 것이 좋습니다.

kubectl utilization requests 가 표시될 수 있음( kubectl util 또는 kubectl usage 이 더 좋거나 더 짧을 수 있음):

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

이 예에서 집계 컨테이너 요청은 4.455개 코어 및 20.1GiB이고 클러스터에 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"

@from-nily 감사합니다, 내가 찾던 바로 그 것

예, 이것은 내 것입니다.

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

아래 명령을 사용하여 노드의 CPU 사용률을 찾을 수 있습니다.

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

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

$ cpualloc
3.89358%

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

$ memalloc
24.6832%

@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 cpu , 7.5G 메모리)을 사용한다는 점을 감안할 때 이것이 저에게 효과적이었습니다.

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

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

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

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

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

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

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

cpualloc 
48.05 %

$ memalloc 
9.95333 %

https://github.com/kubernetes/kubernetes/issues/17512#issuecomment -267992922 kubectl top 는 할당이 아닌 사용량을 보여줍니다. 할당은 insufficient CPU 문제의 원인입니다. 차이점에 대한 이 문제에는 많은 혼란이 있습니다.

AFAICT, 요청이 사양의 컨테이너별로 있기 때문에 포드별 노드 CPU 할당 보고서를 얻는 쉬운 방법은 없습니다. 그리고 .spec.containers[*].requests 에 limits / requests 필드가 있을 수도 있고 없을 수도 있기 때문에 어렵습니다(내 경험상)

/cc @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.

top 명령에는 pod 옵션도 있습니다.

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

이상하다. 할당 용량에 도달했거나 거의 도달한 시점을 알고 싶습니다. 클러스터의 꽤 기본적인 기능인 것 같습니다. 높은 %를 나타내는 통계인지 텍스트 오류인지... 다른 사람들이 이것을 어떻게 압니까? 클라우드 플랫폼에서 항상 자동 확장을 사용하시겠습니까?

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%

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

각각 1개의 컨테이너만 포함하는 팟(Pod)의 네임스페이스에서 작동합니다.

@xmik 안녕하세요, 저는 k8 1.7을 사용하고 있고 hepaster를 실행하고 있습니다. $ kubectl top nodes --heapster-namespace=kube-system을 실행하면 "오류: 메트릭을 아직 사용할 수 없음"이 표시됩니다. 오류를 해결하기 위한 단서가 있습니까?

@abusheb :

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/ 와 같은 CURL 명령을 통해 메트릭에 액세스하는 것입니다. 메트릭이 표시되지 않으면 힙스터 포드 및 로그를 확인하십시오. hepster 메트릭은 이와 같이 웹 브라우저를 통해 액세스할 수 있습니다.

관심 있는 사람이 있으면 Kubernetes 리소스 사용량(및 비용)에 대한 정적 HTML을 생성하는 도구를 만들었습니다. 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 .

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

/remove-lifecycle 부실

매달 정도, 내 인터넷 검색은 나를 이 문제로 다시 안내합니다. 긴 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%)

( @chrishiesand 가 스레드의 앞부분에서 언급한 것과 유사).

나는 종종 일주일에 수십 개의 테스트 클러스터를 구축하고 파괴하며, 자동화를 구축하거나 일부 셸 별칭을 추가하지 않고도 "이렇게 많은 서버를 배치하고 이 앱을 버린다면 그들에 대한 나의 전반적인 활용도/압력은 얼마입니까?"

특히 더 작거나 더 난해한 클러스터의 경우 달에 자동 크기 조정을 설정하고 싶지 않지만(일반적으로 금전적 이유), 사소한 포드 자동 크기 조정 이벤트를 처리하기에 충분한 오버헤드가 있는지 알아야 합니다.

한 가지 추가 요청 -- 네임스페이스별로 합산된 리소스 사용량을 확인할 수 있기를 원합니다(최소한 배포/레이블별도 유용할 것입니다). 에 집중하고 있습니다.

@geerlingguy가 설명한 기능을 제공하는 작은 플러그인 kubectl-view-utilization을 만들었습니다 . krew 플러그인 관리자를 통한 설치가 가능합니다. 이것은 BASH에서 구현되며 awk와 bc가 필요합니다.
kubectl 플러그인 프레임워크를 사용하면 핵심 도구에서 완전히 추상화할 수 있습니다.

다른 사람들도 이 도전에 직면해 있어서 기쁩니다. 클러스터 리소스에 대한 더 나은 개요를 얻고 궁극적으로 사용 가능한 하드웨어 리소스를 더 잘 활용할 수 있도록 도와주는 Kube Eagle(prometheus 내보내기)을 만들었습니다.

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

이것은 테이블 형식으로 실제 노드 사용률을 가져오는 python 스크립트입니다.
https://github.com/amelbakry/kube-node-utilization

쿠버네티스 노드 활용...........
+------------------------------------------------+ ------+--------+
| 노드 이름 | CPU | 메모리 |
+------------------------------------------------+ ------+--------+
| ip-176-35-32-139.eu-central-1.compute.internal | 13.49% | 60.87% |
| ip-176-35-26-21.eu-central-1.compute.internal | 5.89% | 15.10% |
| ip-176-35-9-122.eu-central-1.compute.internal | 8.08% | 65.51% |
| ip-176-35-22-243.eu-central-1.compute.internal | 6.29% | 19.28% |
+------------------------------------------------+ ------+--------+

적어도 @amelbakry 에게 중요한 것은 클러스터 수준 활용입니다. "머신을 더 추가해야 하나요?" / "일부 기계를 제거해야 하나요?" / "클러스터가 곧 확장될 것으로 예상해야 합니까?" ..

임시 스토리지 사용량은 어떻습니까? 모든 포드에서 가져오는 방법에 대한 아이디어가 있습니까?

그리고 유용하기 위해 내 힌트는 다음과 같습니다.

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 내 생각에는 어떤 클라우드 쿠버네티스가 실행되고 있는지 기반으로 하는 클러스터 자동 크기 조정 구성 요소가 용량을 처리해야 한다고 생각합니다. 이것이 귀하의 질문인지 확실하지 않습니다.

90일 동안 사용하지 않으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

이 문제를 지금 종료하는 것이 안전하다면 /close .

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

/remove-lifecycle 부실

나는 다른 많은 사람들과 마찬가지로 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 -system:addon-http-application-routing-nginx-ingress-controller-6bq49l7
.spec.nodeName - aks-agentpool-84550961-0
요청.cpu -
limits.cpu -
요청.메모리 -
limits.memory -

kube- 시스템: coredns-696c4d987c-pjht8
.spec.nodeName - aks-agentpool-84550961-0
요청.cpu - 100m
limits.cpu -
요청.메모리 - 70Mi
limits.memory - 170Mi

kube 시스템: coredns-696c4d987c-rtkl6
.spec.nodeName - aks-agentpool-84550961-2
요청.cpu - 100m
limits.cpu -
요청.메모리 - 70Mi
limits.memory - 170Mi

kube 시스템: coredns-696c4d987c-zgcbp
.spec.nodeName - aks-agentpool-84550961-1
요청.cpu - 100m
limits.cpu -
요청.메모리 - 70Mi
limits.memory - 170Mi

kube 시스템: coredns-autoscaler-657d77ffbf-7t72x
.spec.nodeName - aks-agentpool-84550961-2
요청.cpu - 20m
limits.cpu -
요청.메모리 - 10Mi
limits.memory -

kube- 시스템: coredns-autoscaler-657d77ffbf-zrp6m
.spec.nodeName - aks-agentpool-84550961-0
요청.cpu - 20m
limits.cpu -
요청.메모리 - 10Mi
limits.memory -

kube 시스템:kube-proxy-57nw5
.spec.nodeName - aks-agentpool-84550961-1
요청.cpu - 100m
limits.cpu -
요청.메모리 -
limits.memory -
...

@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 for web"), 데모: https://kube-web-view.demo.j-serv.de/clusters/local/namespaces/ 에서 유사한 사용자 지정 열을 표시할 수 있습니다. ].resources.requests.cpu)%3BMemory+Requests=join(%27,%20% 27,%20spec.containers[ ].resources.requests.memory)

사용자 정의 열 문서: https://kube-web-view.readthedocs.io/en/latest/features.html#listing -resources

오오 반짝반짝

사용량 및 구성된 제한을 기반으로 배포에서 포드의 사용률을 가져오는 스크립트(deployment-health.sh)입니다.
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'"'"' '"'" 

추신: 저는 Mac에서만 스크립트를 테스트했습니다. Linux 및 Windows의 경우 약간의 변경이 필요할 수 있습니다.

사용량 및 구성된 제한을 기반으로 배포에서 포드의 사용률을 가져오는 스크립트(deployment-health.sh)입니다.
https://github.com/amelbakry/kubernetes-scripts

@amelbakry Mac에서 실행하려고 하면 다음 오류가 발생합니다.

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

이런,
"#!" 맨 처음 줄에 있어야 합니다. 대신 "bash
./deployment-health.sh"를 참조하여 문제를 해결하세요.

/찰스
추신. 문제를 해결하기 위해 PR이 열렸습니다.

2019년 9월 25일 수요일 오전 10:19 Dmitri Moore [email protected]
썼다:

포드 활용도를 얻기 위한 스크립트(deployment-health.sh)입니다.
사용량 및 구성된 제한을 기반으로 배포
https://github.com/amelbakry/kubernetes-scripts

@amelbakry https://github.com/amelbakry 나는 다음을 얻고 있습니다
Mac에서 실행하는 동안 오류:

'./deployment-health.sh' 프로세스를 실행하지 못했습니다. 이유:
exec: 실행 형식 오류
'./deployment-health.sh' 파일은 실행 파일로 표시되지만 운영 체제에서 실행할 수 없습니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/17512?email_source=notifications&email_token=AACA3TODQEUPWK3V3UY3SF3QLOMSFA5CNFSM4BUXCUG2YY3PNVWWK3TUL52HS4DFVEXG43VMV
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AACA3TOPOBIWXFX2DAOT6JDQLOMSFANCNFSM4BUXCUGQ
.

@cgthayer 해당 PR 수정 사항을 전역적으로 적용할 수 있습니다. 또한 MacOs Mojave에서 스크립트를 실행했을 때 내가 사용하지 않는 EU 특정 영역 이름을 포함하여 많은 오류가 나타났습니다. 이 스크립트는 특정 프로젝트를 위해 작성된 것 같습니다.

다음은 조인 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-allocations: 할당(cpu, memory, gpu,... X 요청, 제한, 할당 가능,...)을 나열하는 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

향후 버전:

• (노드, 파드) 레벨을 숨기거나 그룹화 방법을 선택할 수 있습니다(예: 리소스만 있는 개요 제공)
• curl, krew, brew, ...를 통한 설치 (현재 바이너리는 github의 릴리스 섹션에서 사용 가능)

영감을 준 kubectl-view-utilization 덕분에 다른 리소스에 대한 지원을 추가하는 것은 많은 복사/붙여넣기를 하거나 bash(일반적인 방법의 경우)에서 수행하기 어려웠습니다.

여기 내 해킹이 있습니다 kubectl describe nodes | grep -A 2 -e "^\\s*CPU Requests"

이것은 더 이상 작동하지 않습니다 :(

kubectl describe node | grep -A5 "Allocated" 사용해 보기

이것은 현재 최고로 많은 요청을 받은 4번째 문제이지만 여전히 priority/backlog 입니다.

누군가가 나를 올바른 방향으로 안내해 주거나 제안을 마무리할 수 있다면 기꺼이 이 일을 하고 싶습니다. @davidB 도구 의 UX는 kubectl 속합니다.

kubectl top nodes & kubectl describe node 명령을 사용하면 일관된 결과를 얻지 못합니다.

예를 들어 첫 번째 CPU(코어)는 1064m이지만 이 결과는 두 번째 CPU(1480m)로 가져올 수 없습니다.

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

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

kubectl top nodes 를 사용하지 않고 CPU(코어)를 얻는 것에 대한 아이디어가 있습니까?

내 도구도 공유하고 싶습니다 ;-) kubectl-view-allocations: 할당(cpu, memory, gpu,... X 요청, 제한, 할당 가능,...)을 나열하는 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)

영감을 준 kubectl-view-utilization 덕분에 다른 리소스에 대한 지원을 추가하는 것은 많은 복사/붙여넣기를 하거나 bash(일반적인 방법의 경우)에서 수행하기 어려웠습니다.

안녕하세요 David 새 배포판에 대해 더 많은 컴파일된 바이너리를 제공하면 좋을 것입니다. 우분투 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' not found #14에 댓글을 달

클러스터 전체에서 할당을 얻는 방법은 다음과 같습니다.

$ 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

주목할만한 사항: 다음과 같이 CPU 소비량을 정렬할 수 있습니다.

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

이것은 Mac에서 작동합니다. Linux에서도 작동하는지 확실하지 않습니다(조인, 정렬 등으로 인해...).

kubectl이 이에 대해 좋은 견해를 가질 때까지 누군가가 이것을 사용할 수 있기를 바랍니다.

kube-capacity에 대한 좋은 경험이

예시:

kube-capacity --util

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

이 도구가 진정으로 유용하려면 클러스터에 배포된 모든 kubernetes 장치 플러그인을 감지하고 모든 플러그인의 사용량을 표시해야 합니다. CPU/Mem은 확실히 충분하지 않습니다. GPU, TPU(머신 러닝용), Intel QAT 등이 있고 아마도 제가 모르는 더 많은 것들이 있을 것입니다. 또한 스토리지는 어떻습니까? 요청된 내용과 사용된 내용을 쉽게 볼 수 있어야 합니다(이상적으로는 iops 측면에서도).

@boniek83 , 내가 kubectl-view-allocations 를 만든 이유는 GPU를 나열해야 하기 때문입니다. github 프로젝트에 대한 모든 피드백을 환영합니다. TPU를 감지하는지 알고 싶습니다(노드의 리소스로 나열되는 경우 감지해야 함)

@boniek83 , 내가 kubectl-view-allocations 를 만든 이유는 GPU를 나열해야 하기 때문입니다. github 프로젝트에 대한 모든 피드백을 환영합니다. TPU를 감지하는지 알고 싶습니다(노드의 리소스로 나열되는 경우 감지해야 함)

나는 당신의 도구를 알고 있으며, 내 목적을 위해 현재 사용 가능한 도구 중 최고입니다. 만들어 주셔서 감사합니다!
나는 부활절 이후에 TPU를 테스트하려고 노력할 것입니다. 이 데이터가 예쁜 그래프와 함께 웹 앱 형식으로 제공되어 데이터 과학자에게 kubernetes에 대한 액세스 권한을 부여하지 않아도 된다면 도움이 될 것입니다. 그들은 누가 자원을 먹고 있는지 알고 싶을 뿐입니다. :)

위의 도구와 스크립트 중 어느 것도 내 필요에 맞지 않기 때문에(이 문제는 여전히 열려 있습니다.( ), 저는 제 변형을 해킹했습니다.
https://github.com/eht16/kube-cargo-load

클러스터의 POD에 대한 빠른 개요를 제공하고 구성된 메모리 요청 및 제한과 실제 메모리 사용량을 보여줍니다. 아이디어는 구성된 메모리 제한과 실제 사용량 간의 비율을 파악하는 것입니다.

포드의 메모리 덤프 로그를 어떻게 얻을 수 있습니까?
포드가 자주 걸려요.

• kubectl describe nodes OR kubectl top nodes , 클러스터 리소스 사용률을 계산하려면 어느 것을 고려해야 합니까?
• 또한 이 2개의 결과 사이에 차이가 있는 이유.
  이것에 대한 논리적 설명이 아직 있습니까?

/종류 기능

노드에 대한 모든 댓글과 해킹은 저에게 효과적이었습니다. 또한 노드 풀당 리소스 합계를 추적하기 위해 더 높은 보기를 위한 무언가가 필요합니다!

안녕하세요,
일정 기간 동안 5분마다 포드의 CPU 및 메모리 사용량을 기록하고 싶습니다. 그런 다음 이 데이터를 사용하여 Excel에서 그래프를 만듭니다. 어떤 아이디어? 감사 해요

안녕하세요,
Google이 우리 모두에게 이 문제를 지적했다는 사실을 알게 되어 기쁩니다 :-) (거의 5년이 지난 후에도 여전히 열려 있다는 점에 약간 실망합니다.) 모든 셸 조각 및 기타 도구에 감사드립니다.

간단하고 빠른 해킹:

$ 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

이 스크립트에는 여기에서 공유한 아이디어 중 일부가 포함되어 있습니다. 스크립트는 증가할 수 있으며 다른 사람들이 메트릭을 더 간단하게 얻을 수 있도록 도울 수 있습니다.

팁과 명령을 공유해 주셔서 감사합니다!

내 사용 사례의 경우 테이블의 노드에 대한 CPU/RAM 제한/예약을 나열하는 간단한 kubectl 플러그인을 작성했습니다. 또한 현재 포드 CPU/RAM 소비(예 kubectl top pods )를 확인하지만 CPU별로 출력을 내림차순으로 정렬합니다.

그 무엇보다 편리한 것이지만 다른 누군가에게도 유용할 것입니다.

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

와우, 전체 클러스터의 현재 전체 CPU 사용량을 적절하게 계산하기 위한 kubernetes 팀의 적절한 솔루션이 아직 없는 거대한 스레드입니까?

minikube에서 이것을 실행하려는 경우 먼저 metric 서버 애드온을 활성화하십시오.
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%)