/종류 기능

/시그널 클립

여기도 마찬가지입니다. 실행되지 않는 컨테이너만 나열하기 위해 복잡한 구문을 사용하는 것은 놀라운 일입니다...

이상적으로는 다음과 같이 말할 수 있습니다.

kubectl get pods --namespace foo -l status=pending

작동하려면 .status == "False" 을 약간 수정해야 했습니다.

kubectl get pods -a --all-namespaces -o json  | jq -r '.items[] | select(.status.phase != "Running" or ([ .status.conditions[] | select(.type == "Ready" and .status == "False") ] | length ) == 1 ) | .metadata.namespace + "/" + .metadata.name'

50140은 지금 이러한 포드를 필터링하기 위해 새 플래그 --field-selector 를 제공합니다.

$ kubectl get pods --field-selector=status.phase!=Running

/닫기

@dixudx

kubectl version
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"9befc2b8928a9426501d3bf62f72849d5cbcd5a3", GitTreeState:"clean", BuildDate:"2017-11-20T19:11:02Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"0b9efaeb34a2fc51ff8e4d34ad9bc6375459c4a4", GitTreeState:"clean", BuildDate:"2017-11-29T22:43:34Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"}

kubectl get po --field-selector=status.phase==Running -l app=k8s-watcher
Error: unknown flag: --field-selector

@asarkar --field-selector 는 곧 나올 v1.9를 대상으로 합니다.

@dixudx 필드 선택기에 대한 PR에 감사드립니다. 그러나 이것은 내가 염두에 두었던 것이 아니라고 생각합니다. 준비 상태 확인을 통과하지 못한 하나 이상의 컨테이너가 있는 포드를 파악할 수 있기를 원했습니다.

준비되지 않은 포드(kubectl v1.9.1)가 있다고 가정하면 READY 0/1 :

$ kubectl get pods                                       
NAME          READY     STATUS    RESTARTS   AGE
pod-unready   0/1       Running   0          50s

이 포드는 아직 단계적으로 실행 중이므로 제안된 필터를 사용하여 가져올 수 없습니다.

$ kubectl get pods --field-selector=status.phase!=Running
No resources found.

/다시 열다

같은 문제가 발생했습니다.
다음과 같은 것이 있으면 기쁠 것입니다.
kubectl 포드 가져오기 --field-selector=status.ready!=True

흠, 중첩된 배열 항목을 가져오는 데 사용할 수 있습니까? 하고 싶은 대로

kubectl get pods --field-selector=status.containerStatuses.restartCount!=0

하지만 status.containerStatuses..restartCount 시도한 오류를 반환하지만 작동하지 않고 동일한 오류를 반환합니다 Error from server (BadRequest): Unable to find "pods" that match label selector "", field selector "status.containerStatuses..restartCount==0": field label not supported: status.containerStatuses..restartCount

@artemyarulin 시도 status.containerStatuses[*].restartCount==0

감사합니다. 방금 kubectl v1.9.3/cluster v1.9.2로 시도했는데 Error from server (BadRequest): Unable to find "pods" that match label selector "", field selector "status.containerStatuses[*].restartCount!=0": field label not supported: status.containerStatuses[*].restartCount 같은 오류를 반환합니다. 내가 뭔가 잘못하고 있습니까? 그것은 당신을 위해 작동합니까?

슬프게도 v1.9.4에서도 동일한 일이 발생합니다.

내가 여기서하려는 것은 주어진 부모 uid를 가진 모든 포드를 얻는 것입니다 ...

$ kubectl get pod --field-selector='metadata.ownerReferences[*].uid=d83a23e1-37ba-11e8-bccf-0a5d7950f698'
Error from server (BadRequest): Unable to find "pods" that match label selector "", field selector "ownerReferences[*].uid=d83a23e1-37ba-11e8-bccf-0a5d7950f698": field label not supported: ownerReferences[*].uid

이 기능을 애타게 기다리고 있습니다 •ᴗ•

--field-selector='metadata.ownerReferences[ ].uid=d83a23e1-37ba-11e8-bccf-0a5d7950f698'필드 레이블이 지원되지 않음: ownerReferences[ ].uid

이 필터 문자열은 지원되지 않습니다.

포드의 경우 "metadata.name", "metadata.namespace", "spec.nodeName", "spec.restartPolicy", "spec.schedulerName", status.phase", "status.podIP", "status.nominatedNodeName"만 , "sepc.nodeName"이 지원됩니다.

@migueleliasweb 귀하의 경우에 포드를 정리하려면 jq 를 사용할 수 있습니다.

$ kubectl get pod -o json | jq '.items | map(select(.metadata.ownerReferences[] | .uid=="d83a23e1-37ba-11e8-bccf-0a5d7950f698"))'

또한 kubectl의 JSONPath 지원 을 사용할 수 있습니다.

@dixudx 감사합니다. 하지만 조금 더 잘 이해하겠습니다. 수천 개의 포드가 있는 클러스터에서 이 쿼리를 실행하는 경우:

• APIServer는 ETCD에서 모두 가져오고 메모리 내 필터링을 적용합니까?
• 아니면 내 kubectl이 모든 포드를 수신하고 필터를 로컬로 적용합니까?
• 아니면 ETCD 내부에서 필터링이 발생합니까? 따라서 필터링된 결과만 반환됩니까?

APIServer는 ETCD에서 모두 가져오고 메모리 내 필터링을 적용합니까?
아니면 내 kubectl이 모든 포드를 수신하고 필터를 로컬에 적용합니까?
아니면 ETCD 내부에서 필터링이 발생합니까? 따라서 필터링된 결과만 반환됩니까?

@migueleliasweb kubectl 을 사용할 때 --field-selector 가 발행되면 필터링은 apiserver의 캐시에 있습니다. APIServer는 필터링 없이 모든 객체(주어진 유형의)를 감시하면서 etcd에 대해 단일 감시를 엽니다. etcd에서 전달된 변경 사항은 apiserver의 캐시에 저장됩니다.

--sort-by 의 경우 필터링은 kubectl 클라이언트 측에서 이루어집니다.

이것은 kubectl get 와 함께 잘 작동하지만 delete 및 describe 에도 적용할 수 있다면 좋을 것입니다.

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

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

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

/remove-lifecycle 부실

kubectl get po --all-namespaces | grep -vE '1/1|2/2|3/3' 를 사용하여 준비되지 않은 모든 포드를 나열하고 있습니다.

IMHO 이것은 단순한 기능 이상이며 거의 필수입니다. --field-selector=status.phase!=Running 에 나열되지 않은 CrashBackoffLoop에 있는 포드를 가질 수 있다는 사실은 전체 field-selector 를 매우 쓸모 없게 만듭니다. json 구문 분석에 의존하지 않고 문제가 있는 포드 목록을 쉽게 얻을 수 있는 방법이 있어야 합니다.

PowerShell을 사용하면 다음과 같이 할 수 있습니다.

모든 상태를 반환하려면

Get-PodStatus | ft -autosize

필터링하려면

Get-PodStatus | where { ($_.status -eq "Running") -and ($_.state -eq "ready") } | ft -AutoSize

참고로:

kubectl get pods --field-selector=status.phase!=Succeeded

버전 217부터 기본적으로 포함된 것으로 보이는 완료된 작업을 필터링하는 데 사용할 수 있습니다.

아니다:

kubectl get pods --field-selector=status.phase!=Completed STATUS가 'Completed'로 표시된다는 점을 고려할 때 더 합리적입니다.

이것이 status.phase에서 작동해야 합니까? 노드를 종료했고 모든 포드가 알 수 없음 또는 NodeLost로 표시되지만 필드 선택기에 의해 필터링되지 않습니다.

$ kubectl get pods --field-selector=status.phase=Running --all-namespaces
NAMESPACE     NAME                                          READY   STATUS     RESTARTS   AGE
kube-system   coredns-78fcdf6894-9gc7n                      1/1     Running    0          1h
kube-system   coredns-78fcdf6894-lt58z                      1/1     Running    0          1h
kube-system   etcd-i-0564e0652e0560ac4                      1/1     Unknown    0          1h
kube-system   etcd-i-0af8bbf22a66edc1d                      1/1     Running    0          1h
kube-system   etcd-i-0e780f1e91f5a7116                      1/1     Running    0          1h
kube-system   kube-apiserver-i-0564e0652e0560ac4            1/1     Unknown    0          1h
kube-system   kube-apiserver-i-0af8bbf22a66edc1d            1/1     Running    1          1h
kube-system   kube-apiserver-i-0e780f1e91f5a7116            1/1     Running    1          1h
kube-system   kube-controller-manager-i-0564e0652e0560ac4   1/1     Unknown    1          1h
kube-system   kube-controller-manager-i-0af8bbf22a66edc1d   1/1     Running    0          1h
kube-system   kube-controller-manager-i-0e780f1e91f5a7116   1/1     Running    0          1h
kube-system   kube-router-9kkxh                             1/1     NodeLost   0          1h
kube-system   kube-router-dj9sp                             1/1     Running    0          1h
kube-system   kube-router-n4zzw                             1/1     Running    0          1h
kube-system   kube-scheduler-i-0564e0652e0560ac4            1/1     Unknown    0          1h
kube-system   kube-scheduler-i-0af8bbf22a66edc1d            1/1     Running    0          1h
kube-system   kube-scheduler-i-0e780f1e91f5a7116            1/1     Running    0          1h
kube-system   tiller-deploy-7678f78996-6t84j                1/1     Running    0          1h

실행 중이 아닌 포드가 이 쿼리와 함께 나열될 것으로 기대하지 않습니다...

이 필드 선택기가 다른 개체 유형에서도 작동해야 합니까? pvc에서는 안되는 것 같습니다.

$ kubectl get pvc --field-selector=status.phase!=Bound
Error from server (BadRequest): Unable to find {"" "v1" "persistentvolumeclaims"} that match label selector "", field selector "status.phase!=Bound": "status.phase" is not a known field selector: only "metadata.name", "metadata.namespace"

이 필드 선택기 구문은 여전히 ​​혼란스럽습니다. 어떤 이유로 "제거됨" 상태를 긍정적으로 필터링할 수 없습니다(실행 중이 아닌 경우에만 표시될 수 있음). 내가 여기서 뭘 잘못했어?

https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/ 를 읽었지만 여전히 작동하지 않습니다.

$ kubectl get po --field-selector status.phase!=Running
NAME                        READY     STATUS      RESTARTS   AGE
admin-55d76dc598-sr78x      0/2       Evicted     0          22d
admin-57f6fcc898-df82r      0/2       Evicted     0          17d
admin-57f6fcc898-dt5kb      0/2       Evicted     0          18d
admin-57f6fcc898-jqp9j      0/2       Evicted     0          17d
admin-57f6fcc898-plxhr      0/2       Evicted     0          17d
admin-57f6fcc898-x5kdz      0/2       Evicted     0          17d
admin-57f6fcc898-zgsr7      0/2       Evicted     0          18d
admin-6489584498-t5fzf      0/2       Evicted     0          28d
admin-6b7f5dbb5d-8h9kt      0/2       Evicted     0          9d
admin-6b7f5dbb5d-k57sk      0/2       Evicted     0          9d
admin-6b7f5dbb5d-q7h7q      0/2       Evicted     0          7d
admin-6b7f5dbb5d-sr8j6      0/2       Evicted     0          9d
admin-7454f9b9f7-wrgdk      0/2       Evicted     0          38d
admin-76749dd59d-tj48m      0/2       Evicted     0          22d
admin-78648ccb66-qxgjp      0/2       Evicted     0          17d
admin-795c79f58f-dtcnb      0/2       Evicted     0          25d
admin-7d58ff6cfd-5pt9p      0/2       Evicted     0          4d
admin-7d58ff6cfd-99pzq      0/2       Evicted     0          3d
admin-7d58ff6cfd-9cbjd      0/2       Evicted     0          3d
admin-b5d6d84d6-5q67l       0/2       Evicted     0          12d
admin-b5d6d84d6-fh2ck       0/2       Evicted     0          13d
admin-b5d6d84d6-r4d8b       0/2       Evicted     0          14d
admin-c56558f95-bxxq5       0/2       Evicted     0          7d
api-5445fd6b8b-4jts8        0/2       Evicted     0          3d
api-5445fd6b8b-5b2jp        0/2       Evicted     0          2d
api-5445fd6b8b-7km72        0/2       Evicted     0          4d
api-5445fd6b8b-8tsgf        0/2       Evicted     0          4d
api-5445fd6b8b-ppnxp        0/2       Evicted     0          2d
api-5445fd6b8b-qqnxr        0/2       Evicted     0          2d
api-5445fd6b8b-z77wp        0/2       Evicted     0          2d
api-5445fd6b8b-zjcmg        0/2       Evicted     0          2d
api-5b6647d48b-frbhj        0/2       Evicted     0          9d
api-9459cb775-5cz7f         0/2       Evicted     0          1d

$ kubectl get po --field-selector status.phase=Evicted
No resources found.
$ kubectl get po --field-selector status.phase==Evicted
No resources found.
$ kubectl get po --field-selector status.phase=="Evicted"
No resources found.
$ kubectl get po --field-selector status.phase="Evicted"
No resources found.

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.7", GitCommit:"0c38c362511b20a098d7cd855f1314dad92c2780", GitTreeState:"clean", BuildDate:"2018-08-20T10:09:03Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.6-gke.11", GitCommit:"42df8ec7aef509caba40b6178616dcffca9d7355", GitTreeState:"clean", BuildDate:"2018-11-08T20:06:00Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}

준비 상태 확인을 통과한(또는 통과하지 못한) Running Pod를 나열하는 방법이 있어야 합니다.

또한 Ready 열의 값이 의미하는 바는 어디에 문서화되어 있습니까? (0/1, 1/1)

@ye Evicted가 status.phase 값이 아니기 때문에 작동하지 않습니다. https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

퇴거는 상태에 속함' 이유: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#podstatus -v1-core

불행히도 현재 필드 선택기로 쿼리할 수 없습니다.

pod-lifecycle 문서에 따른 status.phase이므로 CrashLoopBackOff 가 포함되어서는 안 됩니까?

17:18:13 $ kubectl get pods --field-selector=status.phase!=Running
No resources found.
17:19:32 $ kubectl get pods|grep CrashLoopBackOff
kubernetes-dashboard-head-57b9585588-lvr5t               0/1     CrashLoopBackOff   2292       8d
17:22:45 $ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-01T20:08:12Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.2", GitCommit:"cff46ab41ff0bb44d8584413b598ad8360ec1def", GitTreeState:"clean", BuildDate:"2019-01-10T23:28:14Z", GoVersion:"go1.11.4", Compiler:"gc", Platform:"linux/amd64"}

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

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

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

/remove-lifecycle 부실

스틸과 이슈, 2년 후

나는 이것이 해결책 없이 오랫동안 주변에 있었다는 것을 믿을 수 없습니다.

나는 kubectl get pods --all-namespaces | grep -Ev '([0-9]+)/\1' 를 사용하고 있다

이것은 jsonpath 출력을 사용하여 kubectl 에서 이미 수행할 수 있습니다.

예: Running 상태의 각 포드의 namespace 및 name 를 인쇄합니다.

kubectl get pods --all-namespaces -o jsonpath="{range .items[?(@.status.phase == 'Running')]}{.metadata.namespace}{' '}{.metadata.name}{'\n'}{end}"

@albertvaka CrashLoopBackOff 가 있는 포드가 있으면 표시되지 않습니다.

$ kubectl get pods --all-namespaces -o jsonpath="{range .items[?(@.status.phase != 'Running')]}{.metadata.namespace}{' '}{.metadata.name}{'\n'}{end}"
default pod-with-sidecar
my-system glusterfs-brick-0
my-system sticky-scheduler-6f8d74-6mh4q

$ kubectl get pods --all-namespaces | grep -Ev '([0-9]+)/\1'
NAMESPACE       NAME                                        READY     STATUS             RESTARTS   AGE
default         pod-with-sidecar                            1/2       ImagePullBackOff   0          3m
default         pod-with-sidecar2                           1/2       CrashLoopBackOff   4          3m
my-system       glusterfs-brick-0                           0/2       Pending            0          4m
my-system       sticky-scheduler-6f8d74-6mh4q               0/1       ImagePullBackOff   0          9m

또한 kubectl get pods 와 유사한 출력 형식이 필요합니다.

이렇게해도 도움이되지 않았습니다

$ kubectl get pods --field-selector=status.phase!=Running,status.phase!=Succeeded --all-namespaces
NAMESPACE       NAME                                READY     STATUS              RESTARTS   AGE
default         pod-with-sidecar                    0/2       ContainerCreating   0          37s
my-system       glusterfs-brick-0                   0/2       Pending             0          3m
my-system       sticky-scheduler-6f8d74-6mh4q       0/1       ImagePullBackOff    0          7m

@albertvaka CrashLoopBackOff 가 있는 포드가 있으면 표시되지 않습니다.

그게 요점입니다.

또한 kubectl get pods 와 유사한 출력 형식이 필요합니다.

jsonpath를 사용하여 표시하려는 열을 사용자 정의할 수 있습니다.

@albertvaka 여기에서 요점은 필터에서 제외되는 둔한 json 경로 구문(CrashLoopBackOff로 인해 어쨌든 작동하지 않을 것이라고 생각함)을 작성하지 않고 준비되지 않은 모든 포드를 얻을 수 있는 간단한 방법이 있어야 한다는 것입니다. . CrashLoopBackOff 상태의 포드가 kubectl get pods --field-selector=status.phase!=실행과 같은 쿼리에서 제외된다는 사실은 꽤 기이합니다. 왜 우리는 kubectl get pods --not-ready 또는 간단한 것과 같은 간단한 것을 가질 수 없습니다.

여전히 문제입니다. "실행 중인" 포드를 보기 위해 이 작업을 수행하는 데 동의합니다.
kubectl get -n kube-system pods -lname=tiller --field-selector=status.phase=Running NAME READY STATUS RESTARTS AGE tiller-deploy-55c564dc54-2lfpt 0/1 Running 0 71m
또한 준비되지 않은 컨테이너를 반환하기 위해 다음과 같은 작업을 수행할 수 있어야 합니다.
kubectl get -n kube-system pods -lname=tiller --field-selector=status.containerStatuses[*].ready!=true

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

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

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

/remove-lifecycle 부실

kubectl get po --all-namespaces|grep -v Running 이것은 실행되지 않는 포드를 필터링하는 데 도움이 될 수 있습니다.

준비 상태(완전히 준비됨)로 포드를 필터링할 수 있기를 원했으며 가능한 답변과 함께 여기에 StackOverflow 질문 을 게시했습니다(저에게 효과적임).

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

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

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

/remove-lifecycle 부실

여기에 내 목소리를 추가하면 kubectl get pods --ready 또는 이와 유사한 작업을 수행할 수 있다는 점에 동의합니다. 모든 포드가 준비될 때까지 대기하고(그렇지 않으면 시간 초과 후 실패) grep ...에 의존해야 하는 파이프라인에 단계를 추가하고 싶었습니다 kubectl 는 항상 변경됩니다. 포드의 상태를 더 직접적으로 쿼리하는 것이 훨씬 낫습니다.

@luvkrai 가 말했듯이 CrashLoopBackOff 상태의 컨테이너를 찾으려면 grep을 사용해야 합니다. 지금 필터링하는 방법은 다음과 같습니다. 다른 노드보다 더 많은 문제를 일으키는 노드가 있는지 표시하기 위해 nodeName별로 정렬합니다. 어떻게 보면 굉장히 어려운 문제인 것 같습니다. 흥미롭게도 "STATUS" 열에서 이러한 모든 출력을 일관되게 얻을 수 있지만 추가 도구 없이는 해당 열을 필터링할 수 없습니다.

oc get pods --all-namespaces -o wide --sort-by=.spec.nodeName | grep -Ev "(Running|Completed)"

Golang에 대한 지식이 더 많았다면 "STATUS" 열을 구축하기 위해 이것이 어떻게 달성되었는지 여기에서 명확하고 더 나은 솔루션으로 이어질 수 있다고 생각합니다.
https://github.com/kubernetes/kubectl/blob/7daf5bcdb45a24640236b361b86c056282ddcf80/pkg/describe/describe.go#L679

@alexburlton-sonocent grep의 깨지기 쉬운 측면을 피하기 위해 --no-headers --output custom-columns= 옵션을 사용하여 원하는 열을 지정할 수 있지만 STATUS 열에 입력한 전체 정보와 동일한 문제가 발생할 수 있습니다. 포드 정의에서 안정적으로 찾을 수 없습니다.

다음은 완전히 실행되지 않는 모든 포드를 찾는 데 사용하는 것입니다(예: 일부 컨테이너가 실패함)

kubectl get po --all-namespaces | gawk 'match($3, /([0-9])+\/([0-9])+/, a) {if (a[1] < a[2] && $4 != "Completed") print $0}'

NAMESPACE        NAME                               READY   STATUS      RESTARTS   AGE
blah             blah-6d46d95b96-7wsh6              2/4     Running     0          33h

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

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

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

/remove-lifecycle 부실

여기를 참조하십시오