/jenis fitur

/sig kli

Sama di sini, Kedengarannya luar biasa menggunakan sintaks yang rumit untuk hanya mencantumkan wadah yang tidak berjalan ...

Idealnya saya akan dapat mengatakan sesuatu seperti:

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

Saya harus membuat sedikit modifikasi pada .status == "False" agar bisa berfungsi

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 menyediakan flag baru --field-selector untuk memfilter pod ini sekarang.

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

/menutup

@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 ditargetkan untuk v1.9, yang akan segera dirilis.

@dixudx terima kasih atas PR untuk pemilih lapangan. Tapi saya pikir ini bukan apa yang saya pikirkan. Saya ingin dapat mengetahui pod yang memiliki satu atau lebih container yang tidak lulus pemeriksaan kesiapan.

Mengingat saya memiliki pod yang tidak siap (kubectl v1.9.1) READY 0/1 :

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

Pod ini masih dalam fase berjalan, jadi saya tidak bisa mendapatkannya menggunakan filter yang Anda usulkan:

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

/buka kembali

Punya masalah yang sama.
Saya akan senang memiliki sesuatu seperti:
kubectl get pod --field-selector=status.ready!=True

Hm, bisakah saya menggunakannya untuk mendapatkan item array bersarang? Seperti yang ingin saya lakukan

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

Tapi itu mengembalikan kesalahan, mencoba status.containerStatuses..restartCount , tetapi juga tidak berhasil dan mengembalikan kesalahan yang sama 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 coba status.containerStatuses[*].restartCount==0

Terima kasih, baru saja mencoba dengan kubectl v1.9.3/cluster v1.9.2 dan mengembalikan kesalahan yang sama - 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 . Apakah saya melakukan sesuatu yang salah? Apakah itu bekerja untuk Anda?

Sayangnya, hal yang sama terjadi untuk v1.9.4:

Apa yang saya coba lakukan di sini adalah mendapatkan semua pod dengan uid induk yang diberikan ...

$ 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

Menunggu fitur ini dengan cemas •ᴗ•

--field-selector='metadata.ownerReferences[ ].uid=d83a23e1-37ba-11e8-bccf-0a5d7950f698'label bidang tidak didukung: ownerReferences[ ].uid

String filter ini tidak didukung.

Untuk Pod, hanya "metadata.name", "metadata.namespace", "spec.nodeName", "spec.restartPolicy", "spec.schedulerName", status.phase", "status.podIP", "status.nominatedNodeName" , "sepc.nodeName" didukung.

@migueleliasweb Jika Anda ingin mengeluarkan pod dalam kasus Anda, Anda dapat menggunakan jq .

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

Anda juga dapat menggunakan Dukungan JSONPath dari kubectl.

Terima kasih @dixudx . Tapi biarkan aku mengerti sedikit lebih baik. Jika saya menjalankan kueri ini dalam sebuah cluster dengan beberapa ribu pod:

• Apakah APIServer mengambil semuanya dari ETCD dan menerapkan pemfilteran dalam memori?
• Atau apakah kubectl saya menerima semua pod dan menerapkan filter secara lokal?
• Atau penyaringan terjadi di dalam ETCD? Jadi hanya hasil yang disaring yang dikembalikan?

Apakah APIServer akan mengambil semuanya dari ETCD dan menerapkan pemfilteran dalam memori?
Atau apakah kubectl saya akan menerima semua pod dan menerapkan filter secara lokal?
Atau penyaringan terjadi di dalam ETCD? Jadi hanya hasil yang disaring yang dikembalikan?

@migueleliasweb Jika --field-selector dikeluarkan saat menggunakan kubectl, filternya ada di cache apiserver. APIServer akan memiliki satu jam tangan yang terbuka untuk etcd, menonton semua objek (dari jenis tertentu) tanpa pemfilteran apa pun. Perubahan yang dikirimkan dari etcd kemudian akan disimpan dalam cache apiserver.

Untuk --sort-by , pemfilteran ada di sisi klien kubectl.

Ini bekerja sangat baik untuk saya dengan kubectl get , tetapi juga akan lebih baik jika itu bisa berlaku untuk delete dan describe

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

Saya menggunakan kubectl get po --all-namespaces | grep -vE '1/1|2/2|3/3' untuk mendaftar semua pod yang tidak-penuh-Siap.

IMHO ini lebih dari sekedar fitur, itu cukup banyak keharusan. Fakta bahwa Anda dapat memiliki pod yang ada di CrashBackoffLoop yang tidak terdaftar oleh --field-selector=status.phase!=Running membuat keseluruhan field-selector menjadi tidak berguna. Seharusnya ada cara mudah untuk mendapatkan daftar pod yang bermasalah tanpa menggunakan parsing json.

Dengan PowerShell, seperti ini , Anda dapat melakukan sesuatu seperti

Untuk mengembalikan semua status

Get-PodStatus | ft -autosize

Untuk menyaringnya

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

FYI:

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

Dapat digunakan untuk menyaring pekerjaan yang telah selesai, yang tampaknya disertakan secara default pada versi 217.

Bukan:

kubectl get pods --field-selector=status.phase!=Completed yang, bagi saya, akan lebih rasional, mengingat STATUS ditampilkan sebagai 'Selesai'.

Apakah ini seharusnya berfungsi pada status.phase? Saya menghentikan sebuah node dan semua pod ditampilkan sebagai Tidak Diketahui atau NodeLost tetapi mereka tidak difilter oleh pemilih bidang:

$ 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

Saya tidak berharap pod yang tidak Berjalan itu terdaftar dengan kueri ini ...

Haruskah pemilih bidang ini berfungsi untuk jenis objek lain juga? Tampaknya tidak bekerja untuk 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"

Sintaks pemilih bidang ini masih membingungkan saya, untuk beberapa alasan saya tidak dapat memfilter status "Diusir" secara positif (mereka hanya dapat ditampilkan karena tidak Berjalan). Apa yang saya lakukan salah di sini?

Saya memang membaca https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/ masih tidak bisa membuatnya berfungsi.

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

Seharusnya ada cara untuk hanya membuat daftar pod Berjalan yang telah (atau belum) lulus pemeriksaan kesiapannya.

Juga, di mana didokumentasikan apa arti nilai di kolom Siap? (0/1, 1/1)

@ye Tidak berfungsi karena Digusur bukan nilai status.fase: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

Digusur karena alasan Status: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#podstatus -v1-core

Yang sayangnya tidak dapat ditanyakan dengan pemilih bidang saat ini.

Bukankah CrashLoopBackOff seharusnya disertakan, karena ini adalah status.fase menurut dokumen siklus hidup 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"}

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

diam dan terbit, 2 tahun kemudian

Saya tidak percaya ini telah ada begitu lama tanpa solusi.

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

Ini sudah dapat dilakukan di kubectl menggunakan jsonpath output:

Contoh: ini akan mencetak namespace dan name dari setiap pod dalam keadaan Running .

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

@albertvaka yang tidak akan ditampilkan jika Anda memiliki pod dengan 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

Saya juga membutuhkan format output yang mirip dengan kubectl get pods

bahkan melakukan ini tidak membantu

$ 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 yang tidak akan ditampilkan jika Anda memiliki pod dengan CrashLoopBackOff

Itulah intinya.

Saya juga membutuhkan format output yang mirip dengan kubectl get pods

Anda dapat menyesuaikan kolom yang ingin Anda tampilkan dengan jsonpath.

@albertvaka Saya percaya intinya di sini adalah bahwa harus ada cara sederhana untuk mendapatkan semua pod yang belum siap, tanpa menulis sintaks jalur json yang tumpul (yang menurut saya tidak akan berfungsi karena CrashLoopBackOff) dikecualikan dari filter . Fakta bahwa pod dalam status CrashLoopBackOff dikecualikan dari kueri seperti kubectl get pods --field-selector=status.phase!=Running cukup aneh. Mengapa kita tidak memiliki sesuatu yang sederhana seperti kubectl get pods --not-ready, atau sesuatu yang sederhana.

Masih masalah. Saya setuju bahwa jika saya melakukan ini untuk melihat pod yang "berjalan":
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
Saya juga harus dapat melakukan sesuatu seperti ini untuk mengembalikan wadah yang belum siap:
kubectl get -n kube-system pods -lname=tiller --field-selector=status.containerStatuses[*].ready!=true

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

kubectl get po --all-namespaces|grep -v Running Ini dapat membantu memfilter pod yang tidak berjalan

Saya ingin dapat memfilter pod dengan status siap (siap sepenuhnya), dan memposting pertanyaan StackOverflow di sini , dengan beberapa kemungkinan jawaban (berfungsi untuk saya)

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

Menambahkan suara saya ke ini - setuju bahwa akan luar biasa untuk dapat melakukan kubectl get pods --ready atau serupa. Saya ingin menambahkan langkah ke pipa yang akan menunggu sampai semua pod siap (dan gagal setelah batas waktu sebaliknya) dan harus bergantung pada grep ... yang rapuh jika output kubectl pernah berubah. Lebih suka menanyakan status pod secara lebih langsung.

Seperti yang dinyatakan @luvkrai , saya harus menggunakan grep untuk menemukan wadah dalam status CrashLoopBackOff. Inilah cara saya memfilter sekarang. Saya mengurutkan berdasarkan nodeName untuk menunjukkan apakah saya memiliki node yang menyebabkan lebih banyak masalah daripada yang lain. Sepertinya masalah yang sangat sulit entah bagaimana. Lucunya kita bisa mendapatkan semua output ini di kolom "STATUS" secara konsisten, tetapi tidak bisa memfilter pada kolom itu tanpa alat tambahan.

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

Jika saya memiliki lebih banyak pengetahuan Golang, saya pikir bagaimana ini dicapai untuk membangun kolom "STATUS" akan jelas di sini dan mungkin mengarah pada solusi yang lebih baik.
https://github.com/kubernetes/kubectl/blob/7daf5bcdb45a24640236b361b86c056282ddcf80/pkg/describe/describe.go#L679

@alexburlton-sonocent Untuk menghindari beberapa aspek grep yang rapuh, Anda dapat menggunakan opsi --no-headers --output custom-columns= untuk menentukan kolom mana yang Anda inginkan, tetapi Anda mungkin mengalami masalah yang sama dengan info lengkap yang ditampilkan di kolom STATUS 't andal ditemukan dalam definisi pod.

Berikut adalah sesuatu yang saya gunakan untuk menemukan semua pod yang tidak sepenuhnya berjalan (misalnya beberapa container gagal)

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

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

lihat disini