/добрая особенность

/ сиг кли

То же самое здесь. Звучит невероятно, чтобы использовать сложный синтаксис для перечисления только неработающих контейнеров...

В идеале я мог бы сказать что-то вроде:

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 предназначен для версии 1.9, которая скоро выйдет.

@dixudx спасибо за пиар для селектора полей. Но я думаю, что это не то, что я имел в виду. Я хотел иметь возможность определить модули, у которых есть один или несколько контейнеров, которые не проходят проверку готовности.

Учитывая, что у меня есть не готовый модуль (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 try 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:

Здесь я пытаюсь получить все модули с заданным родительским идентификатором...

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

Также вы можете использовать поддержку JSONPath для kubectl.

Спасибо @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-жизненный цикл устарел

Я использую kubectl get po --all-namespaces | grep -vE '1/1|2/2|3/3' для вывода списка всех не полностью готовых модулей.

ИМХО, это не просто функция, а необходимость. Тот факт, что у вас может быть модуль, находящийся в CrashBackoffLoop, который не указан в списке --field-selector=status.phase!=Running , делает всю эту 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.phase? Я отключил узел, и все модули отображаются как Unknown или 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

Я бы не ожидал, что эти неработающие модули будут перечислены с этим запросом...

Должен ли этот селектор полей работать и для других типов объектов? Для ПВХ не подходит.

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

Должен быть способ просто составить список запущенных модулей, которые прошли (или не прошли) проверку на готовность.

Кроме того, где задокументировано, что означают значения в столбце «Готово»? (0/1, 1/1)

@ye Это не работает, потому что Выселено не значение status.phase: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

Выселено по причине статуса: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#podstatus -v1-core

Что, к сожалению, на данный момент недоступно для запроса с помощью селектора полей.

Не следует ли включать CrashLoopBackOff , потому что это статус.фаза в соответствии с документами жизненного цикла 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"}

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как свежую с помощью /remove-lifecycle stale .
Устаревшие проблемы гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если эту проблему можно безопасно закрыть сейчас, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes/test-infra и/или fejta .
/жизненный цикл устарел

/remove-жизненный цикл устарел

еще и выпуск, спустя 2 года

Я не могу поверить, что это было так долго без решения.

я использую kubectl get pods --all-namespaces | grep -Ev '([0-9]+)/\1'

Это уже можно сделать в kubectl , используя вывод jsonpath:

Например: это напечатает namespace и name каждого модуля в состоянии Running .

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!=Running, довольно странный. Почему бы нам просто не сделать что-то простое, например, 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-жизненный цикл устарел

kubectl get po --all-namespaces|grep -v Running Это может помочь отфильтровать не работающие модули

Я хотел иметь возможность фильтровать модули по состоянию готовности (полностью готов) и разместил здесь вопрос StackOverflow с некоторыми возможными ответами (у меня работает)

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как свежую с помощью /remove-lifecycle stale .
Устаревшие проблемы гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если эту проблему можно безопасно закрыть сейчас, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes/test-infra и/или fejta .
/жизненный цикл устарел

/remove-жизненный цикл устарел

Добавлю к этому свой голос — согласитесь, было бы здорово иметь возможность делать kubectl get pods --ready или что-то подобное. Я хотел добавить шаг к конвейеру, который будет ждать, пока все модули не будут готовы (и в противном случае произойдет сбой после тайм-аута), и мне пришлось полагаться на grep ... что будет хрупким, если вывод kubectl постоянно меняется. Скорее бы запросить статус стручков более напрямую.

Как заявил @luvkrai , я должен использовать grep для поиска контейнеров в статусе CrashLoopBackOff. Вот как я фильтрую прямо сейчас. Я сортирую по имени узла, чтобы показать, есть ли у меня узел, который вызывает больше проблем, чем другие. Как-то это похоже на сверхсложную проблему. Забавно, что мы можем последовательно получать все эти выходные данные в столбце «СТАТУС», но не можем фильтровать этот столбец без дополнительных инструментов.

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

Если бы у меня было больше знаний о Golang, я думаю, как это делается для создания столбца «СТАТУС», здесь было бы ясно, и это могло бы привести к лучшему решению.
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-жизненный цикл устарел

см. здесь