/tipo recurso

/sig cli

O mesmo aqui, parece incrível usar uma sintaxe complexa para listar apenas o contêiner não em execução ...

O ideal seria dizer algo como:

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

Eu tive que fazer uma pequena modificação em .status == "False" para que funcionasse

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 fornece um novo sinalizador --field-selector para filtrar esses pods agora.

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

/Fechar

@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 é direcionado para a v1.9, que será lançada em breve.

@dixudx obrigado pelo PR pelo seletor de campo. Mas acho que não era isso que eu tinha em mente. Eu queria poder descobrir pods que tivessem um ou mais contêineres que não estivessem passando nas verificações de prontidão.

Dado que eu não tenho pod pronto (kubectl v1.9.1) READY 0/1 :

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

Este pod ainda está na fase em execução, então não consigo obtê-lo usando o filtro proposto:

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

/reabrir

Obteve o mesmo problema.
Eu ficaria feliz em ter algo como:
kubectl get pods --field-selector=status.ready!=True

Hm, posso usá-lo para obter itens de matriz aninhados? Como eu quero fazer

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

Mas ele retorna erro, tentei status.containerStatuses..restartCount , mas também não funciona e retorna o mesmo erro 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 tente status.containerStatuses[*].restartCount==0

Obrigado, apenas tentei com kubectl v1.9.3/cluster v1.9.2 e ele retorna o mesmo erro - 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 . Estou fazendo algo errado? Funciona para você?

Infelizmente, a mesma coisa acontece para v1.9.4:

O que estou tentando fazer aqui é obter todos os pods com um determinado uid pai ...

$ 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

Aguardando ansiosamente por este recurso •ᴗ•

--field-selector='metadata.ownerReferences[ ].uid=d83a23e1-37ba-11e8-bccf-0a5d7950f698'rótulo de campo não suportado: ownerReferences[ ].uid

Esta string de filtro não é suportada.

Para pods, apenas "metadata.name", "metadata.namespace", "spec.nodeName", "spec.restartPolicy", "spec.schedulerName", status.phase", "status.podIP", "status.nomeNodeName" , "sepc.nodeName" são suportados.

@migueleliasweb Se você deseja arquivar o pod no seu caso, pode usar jq .

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

Além disso, você pode usar o suporte JSONPath do kubectl.

Obrigado @dixudx . Mas deixe-me entender um pouco melhor. Se eu estiver executando esta consulta em um cluster com alguns milhares de pods:

• O APIServer busca todos eles do ETCD e eles aplicam filtragem na memória?
• Ou meu kubectl recebe todos os pods e aplica localmente o filtro?
• Ou a filtragem ocorre dentro do ETCD? Então, apenas os resultados filtrados são retornados?

O APIServer buscará todos eles do ETCD e aplicará filtragem na memória?
Ou meu kubectl receberá todos os pods e aplicará localmente o filtro?
Ou a filtragem ocorre dentro do ETCD? Então, apenas os resultados filtrados são retornados?

@migueleliasweb Se --field-selector for emitido ao usar kubectl, a filtragem está em um cache de apiserver. O APIServer terá uma única observação aberta ao etcd, observando todos os objetos (de um determinado tipo) sem nenhuma filtragem. As alterações entregues pelo etcd serão armazenadas em um cache do apiserver.

Para --sort-by , a filtragem está no lado do cliente kubectl.

Isso funciona muito bem para mim com kubectl get , mas também seria bom se pudesse se aplicar a delete e describe

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como recente com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se este problema for seguro para fechar agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes/test-infra e/ou fejta .
/ciclo de vida obsoleto

/remove-lifecycle obsoleto

Estou usando kubectl get po --all-namespaces | grep -vE '1/1|2/2|3/3' para listar todos os pods não totalmente prontos.

IMHO isso é mais do que apenas um recurso, é praticamente uma obrigação. O fato de que você pode ter um pod que está em um CrashBackoffLoop que não está listado pelo --field-selector=status.phase!=Running torna a coisa toda field-selector bastante inútil. Deve haver uma maneira fácil de obter uma lista de pods que apresentam problemas sem recorrer à análise de json.

Com o PowerShell, assim , você pode fazer algo como

Para retornar todos os status

Get-PodStatus | ft -autosize

Para filtrá-los

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

PARA SUA INFORMAÇÃO:

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

Pode ser usado para filtrar trabalhos concluídos, que parecem estar incluídos por padrão a partir da versão 217.

Não:

kubectl get pods --field-selector=status.phase!=Completed que, para mim, seria mais racional, visto que o STATUS é exibido como 'Completed'.

Isso deveria funcionar no status.phase? Eu encerrei um nó e todos os pods são exibidos como Unknown ou NodeLost, mas eles não são filtrados pelo seletor de campo:

$ 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

Eu não esperaria que os pods que não estivessem em execução fossem listados com esta consulta ...

Esse seletor de campo também deve funcionar para outros tipos de objeto? Não parece funcionar para 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"

Essa sintaxe do seletor de campo ainda é confusa para mim, por algum motivo não consigo filtrar o status "Evicted" positivamente (eles só podem ser mostrados por não estarem em execução). O que eu fiz de errado aqui?

Eu li https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/ ainda não consigo fazê-lo funcionar.

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

Deve haver uma maneira de listar os pods em execução que passaram (ou não) na verificação de prontidão.

Além disso, onde está documentado o que significam os valores na coluna Pronto? (0/1, 1/1)

@ye Não está funcionando porque Evicted não é um valor de status.phase: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

Despejados pertencem a um motivo de status: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#podstatus -v1-core

O que infelizmente não pode ser consultado com o seletor de campo no momento.

CrashLoopBackOff não deveria ser incluído, porque é um status.phase de acordo com os documentos do ciclo de vida do pod?

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

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como recente com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se este problema for seguro para fechar agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes/test-infra e/ou fejta .
/ciclo de vida obsoleto

/remove-lifecycle obsoleto

ainda e emissão, 2 anos depois

Eu não posso acreditar que isso existe há tanto tempo sem uma solução.

estou usando kubectl get pods --all-namespaces | grep -Ev '([0-9]+)/\1'

Isso já pode ser feito em kubectl usando a saída do jsonpath:

Por exemplo: isso imprimirá o namespace e name de cada pod no estado Running .

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

@albertvaka que não será exibido se você tiver um pod com 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

Também preciso de formato de saída semelhante a kubectl get pods

mesmo fazendo isso não ajudou

$ 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 que não será exibido se você tiver um pod com CrashLoopBackOff

Essa é a questão.

Também preciso de formato de saída semelhante a kubectl get pods

Você pode personalizar as colunas que deseja exibir com jsonpath.

@albertvaka Acredito que o ponto aqui é que deve haver uma maneira simples de obter todos os pods que não estão prontos, sem escrever a sintaxe de caminho json obtusa (que acho que não funcionará de qualquer maneira devido ao CrashLoopBackOff) ser excluído do filtro . O fato de que pods em um estado CrashLoopBackOff são excluídos de uma consulta como kubectl get pods --field-selector=status.phase!=Running é bem bizarro. Por que não podemos simplesmente ter algo simples como kubectl get pods --not-ready, ou algo direto.

Ainda um problema. Eu concordo que se eu fizer isso para ver um pod "em execução":
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
Também devo poder fazer algo assim para retornar contêineres que não estão prontos:
kubectl get -n kube-system pods -lname=tiller --field-selector=status.containerStatuses[*].ready!=true

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como recente com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se este problema for seguro para fechar agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes/test-infra e/ou fejta .
/ciclo de vida obsoleto

/remove-lifecycle obsoleto

kubectl get po --all-namespaces|grep -v Running Isso pode ajudar a filtrar o pod que não está em execução

Eu queria poder filtrar pods por um estado pronto (totalmente pronto) e postei uma pergunta do StackOverflow aqui , com algumas respostas possíveis (funciona para mim)

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como recente com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se este problema for seguro para fechar agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes/test-infra e/ou fejta .
/ciclo de vida obsoleto

/remove-lifecycle obsoleto

Adicionando minha voz a isso - concordo que seria incrível poder fazer kubectl get pods --ready ou similar. Eu estava querendo adicionar uma etapa a um pipeline que esperasse até que todos os pods estivessem prontos (e falharia após um tempo limite) e tive que confiar em grep ... que é frágil se a saída de kubectl sempre muda. Preferiria consultar o status dos pods mais diretamente.

Como @luvkrai afirmou, eu tenho que usar grep para encontrar contêineres no status CrashLoopBackOff. Veja como estou filtrando agora. Classifico por nodeName para mostrar se tenho um nó que está causando mais problemas do que outros. Parece um problema super difícil de alguma forma. Engraçado, podemos obter todas essas saídas na coluna "STATUS" de forma consistente, mas não podemos filtrar nessa coluna sem ferramentas adicionais.

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

Se eu tivesse mais conhecimento de Golang, acho que como isso é feito para construir a coluna "STATUS" ficaria claro aqui e poderia levar a uma solução melhor.
https://github.com/kubernetes/kubectl/blob/7daf5bcdb45a24640236b361b86c056282ddcf80/pkg/describe/describe.go#L679

@alexburlton-sonocent Para evitar alguns dos aspectos frágeis do grep, você pode usar a opção --no-headers --output custom-columns= para especificar quais colunas você deseja, mas você pode encontrar o mesmo problema que a informação completa colocada na coluna STATUS é não é encontrado de forma confiável na definição do pod.

Aqui está algo que eu uso para encontrar todos os pods que não estão totalmente em execução (por exemplo, alguns contêineres estão falhando)

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

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como recente com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se este problema for seguro para fechar agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes/test-infra e/ou fejta .
/ciclo de vida obsoleto

/remove-lifecycle obsoleto

veja aqui