Question: <ins> --- title: 가비지(Garbage) 수집 content_type: concept weight: 50 --- <!-- overview --> {{<glossary_definition term_id="garbage-collection" length="short">}} 다음과 같은 리소스를 정리한다: * [실패한 파드](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) * [종료된 잡](/ko/docs/concepts/workloads/controllers/ttlafterfinished/) * [소유자 참조가 없는 오브젝트](#owners-dependents) * [사용되지 않는 컨테이너와 컨테이너 이미지](#containers-images) * [반환 정책이 삭제인 스토리지클래스에 의해 동적으로 생성된 퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/#delete) * [Stale 또는 만료된 CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) <!-- en 글에서부터 링크가 깨져있어 /docs를 따로 추가--> * {{<glossary_tooltip text="노드" term_id="node">}} 는 다음과 같은 상황에서 삭제된다: * 클러스터가 [클라우드 컨트롤러 매니저](/ko/docs/concepts/architecture/cloud-controller/)를 사용하는 클라우드 * 클러스터가 클라우드 컨트롤러 매니저와 유사한 애드온을 사용하는 온프레미스 * [노드 리스(Lease) 오브젝트](/ko/docs/concepts/architecture/nodes/#heartbeats) ## 소유자(Owners)와 종속(dependents) {#owners-dependents} 쿠버네티스의 많은 오브젝트는 [*owner references*](/docs/concepts/overview/working-with-objects/owners-dependents/)를 통해 서로 연결되어 있다. 소유자 참조(Owner references)는 컨트롤 플레인에게 어떤 오브젝트가 서로 종속적인지를 알려준다. 쿠버네티스는 소유자 참조를 사용하여 컨트롤 플레인과 다른 API 클라이언트에게 오브젝트를 삭제하기 전 관련 리소스를 정리하는 기회를 제공한다. 대부분의 경우, 쿠버네티스는 소유자 참조를 자동으로 관리한다. 소유권(Ownership)은 일부 리소스가 사용하는 [레이블과 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/) 메커니즘과는 다르다. 예를 들어, `EndpointSlice` 오브젝트를 생성하는 {{<glossary_tooltip text="서비스" term_id="service">}}를 생각해보자. 서비스는 *레이블*을 사용해 컨트롤 플레인이 어떤 `EndpointSlice` 오브젝트가 해당 서비스에 의해 사용되는지 판단하는 데 도움을 준다. 레이블과 더불어, 서비스를 대신해 관리되는 각 `EndpointSlice` 오브젝트는 소유자 참조를 가진다. 소유자 참조는 쿠버네티스의 다른 부분이 제어하지 않는 오브젝트를 방해하는 것을 방지하는 데 도움을 준다. {{< note >}} 교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다. 네임스페이스 종속 오브젝트는 클러스터 범위 또는 네임스페이스 소유자를 지정할 수 있다. 네임스페이스 소유자는 **반드시** 종속 오브젝트와 동일한 네임스페이스에 존재해야 한다. 그렇지 않다면, 소유자 참조는 없는 것으로 간주되어, 종속 오브젝트는 모든 소유자가 없는 것으로 확인되면 삭제될 수 있다. 클러스터 범위의 종속 오브젝트는 클러스터 범위의 소유자만 지정할 수 있다. v1.20 이상에서, 클러스터 범위의 종속 오브젝트가 네임스페이스 종류를 소유자로 지정하면, 확인할 수 없는 소유자 참조가 있는 것으로 간주되어 가비지 수집이 될 수 없다. v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `ownerReference` 또는 네임스페이스 종류를 참조하는 `ownerReference`가 있는 클러스터 범위의 종속 항목을 감지하면, `OwnerRefInvalidNamespace`가 원인인 경고 이벤트와 유효하지 않은 종속 항목의 `involvedObject`가 보고된다. `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace` 를 실행하여 이러한 종류의 이벤트를 확인할 수 있다. {{< /note >}} ## 캐스케이딩(Cascading) 삭제 {#cascading-deletion} 쿠버네티스는 오브젝트를 삭제할 때 더 이상 소유자 참조가 없는지, 예를 들어 레플리카셋을 삭제할 때, 남겨진 파드가 없는지 확인하고 삭제한다. 오브젝트를 삭제할 때 쿠버네티스가 오브젝트의 종속 오브젝트들을 자동으로 삭제할 지 여부를 제어할 수 있다. 이 과정을 `캐스케이딩 삭제`라고 한다. 캐스케이딩 삭제에는 다음과 같은 두 가지 종류가 있다. * 포그라운드 캐스케이딩 삭제(Foreground cascading deletion) * 백그라운드 캐스케이딩 삭제(Background cascading deletion) 또한 쿠버네티스의 {{<glossary_tooltip text="finalizers" term_id="finalizer">}}를 사용하여 가비지 수집이 소유자 참조가 있는 자원을 언제 어떻게 삭제할 것인지 제어할 수 있다. ### 포그라운드 캐스케이딩 삭제 {#foreground-deletion} 포그라운드 캐스케이딩 삭제에서는 삭제하려는 소유자 오브젝트가 먼저 *삭제 중* 상태가 된다. 이 상태에서는 소유자 오브젝트에게 다음과 같은 일이 일어난다: * 쿠버네티스 API 서버가 오브젝트의 `metadata.deletionTimestamp` 필드를 오브젝트가 삭제 표시된 시간으로 설정한다. * 쿠버네티스 API 서버가 `metadata.finalizers` 필드를 `foregroundDeletion`로 설정한다. * 오브젝트는 삭제 과정이 완료되기 전까지 쿠버네티스 API를 통해 조회할 수 있다. 소유자 오브젝트가 삭제 중 상태가 된 이후, 컨트롤러는 종속 오브젝트들을 삭제한다. 모든 종속 오브젝트들이 삭제되고나면, 컨트롤러가 소유자 오브젝트를 삭제한다. 이 시점에서 오브젝트는 더 이상 쿠버네티스 API를 통해 조회할 수 없다. 포그라운드 캐스케이딩 삭제 중에 소유자 오브젝트의 삭제를 막는 종속 오브젝트는`ownerReference.blockOwnerDeletion=true`필드를 가진 오브젝트다. 더 자세한 내용은 [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)를 참고한다. ### 백그라운드 캐스케이딩 삭제 {#background-deletion} 백그라운드 캐스케이딩 삭제에서는 쿠버네티스 API 서버가 소유자 오브젝트를 즉시 삭제하고 백그라운드에서 컨트롤러가 종속 오브젝트들을 삭제한다. 쿠버네티스는 수동으로 포그라운드 삭제를 사용하거나 종속 오브젝트를 분리하지 않는다면, 기본적으로 백그라운드 캐스케이딩 삭제를 사용한다. 더 자세한 내용은 [Use background cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)를 참고한다. ### 분리된 종속 (Orphaned dependents) 쿠버네티스가 소유자 오브젝트를 삭제할 때, 남은 종속 오브젝트는 *분리된* 오브젝트라고 부른다. 기본적으로 쿠버네티스는 종속 오브젝트를 삭제한다. 이 행동을 오버라이드하는 방법을 보려면, 다음 [Delete owner objects and orphan dependents](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)를 참고한다. ## 사용되지 않는 컨테이너와 이미지 가비지 수집 {#containers-images} {{<glossary_tooltip text="kubelet" term_id="kubelet">}}은 사용되지 않는 이미지에 대한 가비지 수집을 5분마다, 컨테이너에 대한 가비지 수집을 1분마다 수행한다. 외부 가비지 수집 도구는 Kubelet 의 행동을 중단시키고 존재해야만 하는 컨테이너를 삭제할 수 있으므로 사용을 피해야 한다. 사용되지 않는 컨테이너와 이미지에 대한 가비지 수집 옵션을 구성하려면, [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/) 사용하여 Kubelet 을 수정하거나 [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 리소스 타입의 가비지 수집과 관련된 파라미터를 수정한다. ### 컨테이너 이미지 라이프사이클 쿠버네티스는 Kubelet의 일부인 *이미지 관리자*가 {{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}와 협동하여 모든 이미지의 라이프사이클을 관리한다. Kubelet은 가비지 수집 결정을 내릴 때, 다음 디스크 사용량 제한을 고려한다. * `HighThresholdPercent` * `LowThresholdPercent` `HighThresholdPercent` 값을 초과한 디스크 사용량은 마지막으로 사용된 시간을 기준으로 오래된 이미지순서대로 이미지를 삭제하는 가비지 수집을 트리거한다. Kubelet은 디스크 사용량이 `LowThresholdPercent` 값에 도달할 때까지 이미지를 삭제한다. ### 컨테이너 이미지 가비지 수집 {#container-image-garbage-collection} Kubelet은 사용자가 정의할 수 있는 다음 변수들을 기반으로 사용되지 않는 컨테이너들을 삭제한다: * `MinAge`: Kubelet이 가비지 수집할 수 있는 최소 나이. `0`으로 세팅하여 비활성화할 수 있다. * `MaxPerPodContainer`: 각 파드 쌍이 가질 수 있는 죽은 컨테이너의 최대 개수. `0`으로 세팅하여 비활성화할 수 있다. * `MaxContainers`: 클러스터가 가질 수 있는 죽은 컨테이너의 최대 개수 `0`으로 세팅하여 비활성화할 수 있다. 위 변수와 더불어, Kubelet은 식별할 수 없고 삭제된 컨테이너들을 오래된 순서대로 가비지 수집한다. `MaxPerPodContainer`와 `MaxContainer`는 파드의 최대 컨테이너 개수(`MaxPerPodContainer`)를 유지하는 것이 전체 죽은 컨테이너의 개수 제한(`MaxContainers`)을 초과하게 될 때, 서로 충돌이 발생할 수 있다. 이 상황에서 Kubelet은 충돌을 해결하기 위해 `MaxPodPerContainer`를 조절한다. 최악의 시나리오에서는 `MaxPerPodContainer`를 `1`로 다운그레이드하고 가장 오래된 컨테이너들을 축출한다. 또한, 삭제된 파드가 소유한 컨테이너들은 `MinAge`보다 오래되었을 때 삭제된다. {{<note>}} Kubelet은 자신이 관리하는 컨테이너에 대한 가비지 수집만을 수행한다. {{</note>}} ## 가비지 수집 구성하기 {#configuring-gc} 자원을 관리하는 컨트롤러의 옵션을 구성하여 가비지 컬렉션을 수정할 수 있다. 다음 페이지에서 어떻게 가비지 수집을 구성할 수 있는지 확인할 수 있다: * [쿠버네티스 오브젝트의 캐스케이딩 삭제 구성하기](/docs/tasks/administer-cluster/use-cascading-deletion/) * [완료된 잡 자동 정리하기](/docs/concepts/workloads/controllers/ttlafterfinished/) <!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) --> ## {{% heading "whatsnext" %}} * [쿠버네티스 오브젝트의 소유권](/docs/concepts/overview/working-with-objects/owners-dependents/)에 대해 알아보자. * 쿠버네티스 [finalizers](/docs/concepts/overview/working-with-objects/finalizers/)에 대해 알아보자. * 완료된 잡을 정리하는 [TTL 컨트롤러](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) 에 대해 알아보자. </ins>

This is a Feature Request Translate in Korean What would you like to be Translate in Korean Why is this needed This file is not translated yet. Comments Page to translate : /language ko /assign Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/triage accepted
Resolved by page: /close
Closing this issue. <detailsIn response to : Resolved by Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: * start and configure additional etcd instance * configure the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} to use it for storing events <del> See [Operating etcd clusters for Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) and [Set up a High Availability etcd cluster with kubeadm](docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) </del> <ins> See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) and [Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) </ins> for details on configuring and managing etcd for a large cluster. ## Addon resources

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The href of contains unwanted . A slash () is missing in the href of . Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en /assign
/triage accepted


Question: To configure options for unused container and image garbage collection, tune the kubelet using a [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/) and change the parameters related to garbage collection using the <del> [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) </del> <ins> [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) </ins> resource type. ### Container image lifecycle

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Url selector #kubelet-config-k8s-io-v1beta1-KubeletConfiguration doesn't make a difference between: and Proposed Solution: Removing the selector from the URLs Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language en
/assign
/retitle Problems with (generated) reference for kubelet configuration


Question: <del> --- title: Kerangka Kerja Penjadwalan (Scheduling Framework) content_type: concept weight: 60 --- <!-- overview --> {{< feature-state for_k8s_version="1.15" state="alpha" >}} Kerangka kerja penjadwalan (_Scheduling Framework_) adalah arsitektur yang dapat dipasang (_pluggable_) pada penjadwal Kubernetes untuk membuat kustomisasi penjadwal lebih mudah. Hal itu dilakukan dengan menambahkan satu kumpulan "plugin" API ke penjadwal yang telah ada. _Plugin_ dikompilasi ke dalam penjadwal. Beberapa API memungkinkan sebagian besar fitur penjadwalan diimplementasikan sebagai _plugin_, sambil tetap mempertahankan penjadwalan "inti" sederhana dan terpelihara. Silahkan merujuk pada [proposal desain dari kerangka penjadwalan] [kep] untuk informasi teknis lebih lanjut tentang desain kerangka kerja tersebut. [kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md <!-- body --> # Alur kerja kerangka kerja Kerangka kerja penjadwalan mendefinisikan beberapa titik ekstensi. _Plugin_ penjadwal mendaftar untuk dipanggil di satu atau lebih titik ekstensi. Beberapa _plugin_ ini dapat mengubah keputusan penjadwalan dan beberapa hanya bersifat informasi. Setiap upaya untuk menjadwalkan satu Pod dibagi menjadi dua fase, **Siklus Penjadwalan (_Scheduling Cycle_)** dan **Siklus Pengikatan (_Binding Cycle_)**. ## Siklus Penjadwalan dan Siklus Pengikatan Siklus penjadwalan memilih sebuah Node untuk Pod, dan siklus pengikatan menerapkan keputusan tersebut ke klaster. Secara bersama-sama, siklus penjadwalan dan siklus pengikatan diartikan sebagai sebuah "konteks penjadwalan (_scheduling context_)". Siklus penjadwalan dijalankan secara serial, sementara siklus pengikatan dapat berjalan secara bersamaan. Siklus penjadwalan atau pengikatan dapat dibatalkan jika Pod telah ditentukan untuk tidak terjadwalkan atau jika terdapat kesalahan internal. Pod akan dikembalikan ke antrian dan dicoba lagi. ## Titik-titik ekstensi Gambar berikut menunjukkan konteks penjadwalan Pod dan titik-titik ekstensi yang diperlihatkan oleh kerangka penjadwalan. Dalam gambar ini "Filter" setara dengan "Predicate" dan "Scoring" setara dengan "Priority Function". Satu _plugin_ dapat mendaftar di beberapa titik ekstensi untuk melakukan pekerjaan yang lebih kompleks atau _stateful_. {{< figure src="/images/docs/scheduling-framework-extensions.png" title="Titik-titik ekstensi dari kerangka kerja Penjadwalan" >}} ### QueueSort {#queue-sort} _Plugin_ ini digunakan untuk mengurutkan Pod-Pod dalam antrian penjadwalan. _Plugin_ QueueSort pada dasarnya menyediakan fungsi `Less (Pod1, Pod2)`. Hanya satu jenis _plugin_ QueueSort yang dapat diaktifkan dalam waktu yang bersamaan. ### PreFilter {#pre-filter} _Plugin_ ini digunakan untuk melakukan pra-proses informasi tentang Pod, atau untuk memeriksa tertentu kondisi yang harus dipenuhi oleh klaster atau Pod. Jika _plugin_ PreFilter menghasilkan hasil yang salah, siklus penjadwalan dibatalkan. ### Filter _Plugin_ ini digunakan untuk menyaring Node yang tidak dapat menjalankan Pod. Untuk setiap Node, penjadwal akan memanggil _plugin_ Filter sesuai dengan urutan mereka dikonfigurasi. Jika ada _plugin_ Filter menandai Node menjadi _infeasible_, maka _plugin_ yang lainnya tidak akan dipanggil untuk Node itu. Node-Node dapat dievaluasi secara bersamaan. ### PostFilter {#post-filter} Plugin ini disebut setelah fase Filter, tetapi hanya ketika tidak ada node yang layak ditemukan untuk pod. Plugin dipanggil dalam urutan yang dikonfigurasi. Jika plugin postFilter menandai node sebagai 'Schedulable', plugin yang tersisa tidak akan dipanggil. Implementasi PostFilter yang khas adalah preemption, yang mencoba membuat pod dapat di menjadwalkan dengan mendahului Pod lain. ### PreScore {#pre-score} _Plugin_ ini digunakan untuk melakukan pekerjaan "pra-penilaian", yang menghasilkan keadaan yang dapat dibagi untuk digunakan oleh _plugin-plugin_ Score. Jika _plugin_ PreScore mengeluarkan hasil salah, maka siklus penjadwalan dibatalkan. ### Score {#score} _Plugin_ ini digunakan untuk menentukan peringkat Node yang telah melewati fase penyaringan. Penjadwal akan memanggil setiap _plugin_ Score untuk setiap Node. Akan ada kisaran bilangan bulat yang telah ditetapkan untuk mewakili skor minimum dan maksimum. Setelah fase [NormalizeScore](#normalize-scoring), penjadwal akan menggabungkan skor Node dari semua _plugin_ sesuai dengan bobot _plugin_ yang telah dikonfigurasi. ### NormalizeScore {#normalize-score} _Plugin_ ini digunakan untuk memodifikasi skor sebelum penjadwal menghitung peringkat akhir Node-Node. _Plugin_ yang mendaftar untuk titik ekstensi ini akan dipanggil dengan hasil [Score](#score) dari _plugin_ yang sama. Hal ini dilakukan sekali untuk setiap _plugin_ dan setiap siklus penjadwalan. Sebagai contoh, anggaplah sebuah _plugin_ `BlinkingLightScorer` memberi peringkat pada Node-Node berdasarkan berapa banyak kedipan lampu yang mereka miliki. ```go func ScoreNode(_ *v1.pod, n *v1.Node) (int, error) { return getBlinkingLightCount(n) } ``` Namun, jumlah maksimum kedipan lampu mungkin kecil jika dibandingkan dengan `NodeScoreMax`. Untuk memperbaikinya, `BlinkingLightScorer` juga harus mendaftar untuk titik ekstensi ini. ```go func NormalizeScores(scores map[string]int) { highest := 0 for _, score := range scores { highest = max(highest, score) } for node, score := range scores { scores[node] = score*NodeScoreMax/highest } } ``` Jika ada _plugin_ NormalizeScore yang menghasilkan hasil yang salah, maka siklus penjadwalan dibatalkan. {{< note >}} _Plugin_ yang ingin melakukan pekerjaan "pra-pemesanan" harus menggunakan titik ekstensi NormalizeScore. {{< /note >}} ### Reserve Ini adalah titik ekstensi yang bersifat informasi. _Plugin_ yang mempertahankan keadaan _runtime_ (alias "_stateful plugins_") harus menggunakan titik ekstensi ini untuk diberitahukan oleh penjadwal ketika sumber daya pada suatu Node dicadangkan untuk Pod yang telah disiapkan. Proses ini terjadi sebelum penjadwal benar-benar mengikat Pod ke Node, dan itu ada untuk mencegah kondisi balapan (_race conditions_) ketika penjadwal menunggu agar pengikatan berhasil. Ini adalah langkah terakhir dalam siklus penjadwalan. Setelah Pod berada dalam status dicadangkan, maka itu akan memicu _plugin_ [Unreserve](#unreserve) (apabila gagal) atau _plugin_ [PostBind](#post-bind) (apabila sukses) di akhir siklus pengikatan. ### Permit _Plugin_ Permit dipanggil pada akhir siklus penjadwalan untuk setiap Pod untuk mencegah atau menunda pengikatan ke Node kandidat. _Plugin_ Permit dapat melakukan salah satu dari ketiga hal ini: 1. **approve**  Setelah semua _plugin_ Permit menyetujui sebuah Pod, Pod tersebut akan dikirimkan untuk diikat. 2. **deny**  Jika ada _plugin_ Permit yang menolak sebuah Pod, Pod tersebut akan dikembalikan ke antrian penjadwalan. Hal ini akan memicu _plugin_ [Unreserve](#unreserve). 3. **wait** (dengan batas waktu)  Jika _plugin_ Permit menghasilkan "wait", maka Pod disimpan dalam daftar Pod "yang menunggu" internal, dan siklus pengikatan Pod ini dimulai tetapi akan langsung diblokir sampai mendapatkan [_approved_](#frameworkhandle). Jika waktu tunggu habis, ** wait ** menjadi ** deny ** dan Pod dikembalikan ke antrian penjadwalan, yang memicu _plugin_ [Unreserve](#unreserve). {{< note >}} Ketika setiap _plugin_ dapat mengakses daftar Pod-Pod "yang menunggu" dan menyetujuinya (silahkan lihat [`FrameworkHandle`](#frameworkhandle)), kami hanya mengharapkan _plugin_ Permit untuk menyetujui pengikatan Pod dalam kondisi "menunggu" yang telah dipesan. Setelah Pod disetujui, akan dikirim ke fase [PreBind](#pre-bind). {{< /note >}} ### PreBind {#pre-bind} _Plugin_ ini digunakan untuk melakukan pekerjaan apa pun yang diperlukan sebelum Pod terikat. Sebagai contoh, _plugin_ PreBind dapat menyediakan _network volume_ dan melakukan _mounting_ pada Node target sebelum mengizinkan Pod berjalan di sana. Jika ada _plugin_ PreBind yang menghasilkan kesalahan, maka Pod [ditolak](#unreserve) dan kembali ke antrian penjadwalan. ### Bind _Plugin_ ini digunakan untuk mengikat Pod ke Node. _Plugin-plugin_ Bind tidak akan dipanggil sampai semua _plugin_ PreBind selesai. Setiap _plugin_ Bind dipanggil sesuai urutan saat dikonfigurasi. _Plugin_ Bind dapat memilih untuk menangani atau tidak Pod yang diberikan. Jika _plugin_ Bind memilih untuk menangani Pod, ** _plugin_ Bind yang tersisa dilewati **. ### PostBind {#post-bind} Ini adalah titik ekstensi bersifat informasi. _Plugin-plugin_ PostBind dipanggil setelah sebuah Pod berhasil diikat. Ini adalah akhir dari siklus pengikatan, dan dapat digunakan untuk membersihkan sumber daya terkait. ### Unreserve Ini adalah titik ekstensi bersifat informasi. Jika sebuah Pod telah dipesan dan kemudian ditolak di tahap selanjutnya, maka _plugin-plugin_ Unreserve akan diberitahu. _Plugin_ Unreserve harus membersihkan status yang terkait dengan Pod yang dipesan. _Plugin_ yang menggunakan titik ekstensi ini sebaiknya juga harus digunakan [Reserve](#unreserve). ## _Plugin_ API Ada dua langkah untuk _plugin_ API. Pertama, _plugin_ harus mendaftar dan mendapatkan konfigurasi, kemudian mereka menggunakan antarmuka titik ekstensi. Antarmuka (_interface_) titik ekstensi memiliki bentuk sebagai berikut. ```go type Plugin interface { Name() string } type QueueSortPlugin interface { Plugin Less(*v1.pod, *v1.pod) bool } type PreFilterPlugin interface { Plugin PreFilter(context.Context, *framework.CycleState, *v1.pod) error } // ... ``` ## Konfigurasi _plugin_ Kamu dapat mengaktifkan atau menonaktifkan _plugin_ dalam konfigurasi penjadwal. Jika kamu menggunakan Kubernetes v1.18 atau yang lebih baru, kebanyakan [plugin-plugin penjadwalan](/docs/reference/scheduling/profiles/#scheduling-plugins) sudah digunakan dan diaktifkan secara bawaan. Selain _plugin-plugin_ bawaan, kamu juga dapat mengimplementasikan _plugin-plugin_ penjadwalan kamu sendiri dan mengonfigurasinya bersama-sama dengan _plugin-plugin_ bawaan. Kamu bisa mengunjungi [plugin-plugin penjadwalan](https://github.com/kubernetes-sigs/scheduler-plugins) untuk informasi lebih lanjut. Jika kamu menggunakan Kubernetes v1.18 atau yang lebih baru, kamu dapat mengonfigurasi sekumpulan _plugin_ sebagai profil penjadwal dan kemudian menetapkan beberapa profil agar sesuai dengan berbagai jenis beban kerja. Pelajari lebih lanjut di [multi profil](/docs/reference/scheduling/profiles/#multiple-profiles). </del>

This is tracking issue of our progress from Q1 2021 onwards. In the beginning of this milestone, as per our , we have translated 220 pages from 84 contributors (the script from main repo shows 260+ pages), with around 8,000 views per month. In this milestone, we still continuing on updating the obsolete pages. We are not officially listing down target pages to translate, but feel free if you have spare time to translate some. Please check this documentation about which gives step-by-step on how to start to contribute and translate using official guidelines. There is a list of outdated pages (40 out of 162 pages for this milestone) and please feel free if you want to take part on this work.

[X] removed [X] removed content/en//docs/tasks/tools/install- [X] removed [X] removed content/en//docs/tasks/example-task- [X] removed content/en//docs/tasks/administer-cluster/cluster- [X] removed content/en//docs/setup/learning- [X] removed content/en//docs/concepts/configuration/assign-pod- [X] removed content/en//docs/concepts/configuration/pod- [ ] removed content/en//docs/concepts/configuration/manage-compute-resources- [X] moved content/en//docs/concepts/configuration/resource-bin- [X] moved content/en//docs/concepts/configuration/taint-and- [X] renamed content/en//docs/concepts/scheduling/scheduling- [X] renamed content/en//docs/concepts/scheduling/scheduler-perf- [X] renamed content/en//docs/concepts/scheduling/kube- [X] renamed [ ] removed content/en//docs/concepts/workloads/pods/pod-[ ] removed [ ] removed content/en//docs/concepts/workloads/controllers/jobs-run-to- [ ] removed content/en//docs/concepts/extend-kubernetes/poseidon-firmament-alternate- [ ] removed [ ] removed content/en//docs/concepts/cluster-administration/cluster-administration- [ ] removed content/en//docs/concepts/cluster- [ ] removed content/en//docs/concepts/cluster-administration/cloud- [ ] removed content/en//docs/concepts/cluster-administration/controller-[X] removed content/en//docs/concepts/cluster- [X] removed [X] removed [X] removed [X] modified content/en/includes/task-tutorial- [X] modified content/en/docs/home/supported-doc- [ ] modified [ ] modified content/en/docs/tasks/debug-application-cluster/resource-usage-[ ] modified content/en/docs/tasks/run-application/horizontal-pod-autoscale- [ ] modified content/en/docs/tasks/run-application/horizontal-pod- [ ] modified content/en/docs/tasks/run-application/run-stateless-application- [ ] modified content/en/docs/tasks/run-application/force-delete-stateful-set- [ ] modified content/en/docs/tasks/tools/install- [ ] modified [ ] modified content/en/docs/tasks/configure-pod-container/configure-service- [ ] modified content/en/docs/tasks/configure-pod-container/configure-persistent-volume- /language id /cc
/triage accepted
I'm taking the 4th part, as I've done the in
Thanks .

it is updated.
is moved to as mentioned here
is removed and redirect to official minikube webpage , as mentioned here
The whole pages are move into including as mentioned here
The whole are removed in , I'm going to remove the directory as well as it's unused now.
is moved to via
is removed via
Just sharing a useful trick for finding related PR which delete/modified a file: e.g. The output will be similar with this: Please note the commit hash in the output (, in the case of the example above). You can use the same command to find which commit modified a file by changing the filter from to (refer to for more filters). In case of modified file, you might get multiple commit hashes, pick the latest one (contains the recent changes), or just pick ones that suit your needs. Go to, e.g., (replace with your commit hash in step 1). Find the related PR with the commit, e.g. via web UI: ! In bottom left hand corner near the branch name, in this case , you can see the PR id . Click on the link and you will be redirected to the respective PR page, then you can analyse what changes has been made and what actions needed to incorporate it to our localization.
is removed here together with others.
is removed here
Hi ... it seems this issue is automatically closed. Do you have any idea how to re-opened it?
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Thanks :)
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi .... I think we need to close this issue, because it has already behind the schedule. Do we need to complete all within 1-2 weeks? or we need to carry forward to next quarter?
Hi All, I have opened Q2 2021 tracking issue


Question: [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] ``` <del> containerdの設定に関する詳細なドキュメントは下記を参照してください。 https://github.com/containerd/containerd/blob/main/docs/cri/config.md </del> <ins> 詳細はcontainerdの[設定に関するドキュメント](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)を参照してください。 </ins> #### {{< glossary_tooltip term_id="cri-o" >}}

This is a Feature Request What would you like to be We need to update content/ja/docs/concepts/containers/runtime- according to the English text, because it is outdated. Why is this needed content/ja/docs/concepts/containers/runtime- is outdated. Comments /language ja /assign
/triage accepted


Question: Information on the different Windows Server servicing channels including their support models can be found at <del> [Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). </del> <ins> [Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison). </ins>

broken link in page:
/kind bug /sig windows /language en /triage accepted /priority backlog Thanks for the report
Would like to work on this issue /assign


Question: 每个 Kubernetes 对象也有一个 [**UID**](#uids) 来标识在整个集群中的唯一性。 比如，在同一个[名字空间](/zh-cn/docs/concepts/overview/working-with-objects/namespaces/) <del> 中有一个名为 `myapp-1234` 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`。 </del> <ins> 中只能有一个名为 `myapp-1234` 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`。 </ins> <!-- For non-unique user-provided attributes, Kubernetes provides [labels](/docs/concepts/overview/working-with-objects/labels/) and [annotations](/docs/concepts/overview/working-with-objects/annotations/).

Hello, I found some ambiguity in the Chinese translation of the documentation. In this document() the third line in chinese version is: " myapp-1234 Pod Pod Deployment myapp-1234" And in english version is: "For example, you can only have one Pod named myapp-1234 within the same namespace, but you can have one Pod and one Deployment that are each named myapp-1234." The word "only" is missing in the Chinese version, which will cause ambiguity. Thanks
/language zh /sig documentation
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /language zh /sig documentation Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig docs
/triage accepted
It seems that there is indeed an ambiguity, we can modify it. /assign


Question: - DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster bootstrap. <del> Daemon pods do respect [taints and tolerations](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature), but they are created with `NoExecute` tolerations for the `node.alpha.kubernetes.io/notReady` and `node.alpha.kubernetes.io/unreachable` taints with no `tolerationSeconds`. This ensures that when the `TaintBasedEvictions` alpha feature is enabled, </del> <ins> Daemon pods do respect [taints and tolerations](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature), but they are created with `NoExecute` tolerations for the following taints with no `tolerationSeconds`: - `node.alpha.kubernetes.io/notReady` - `node.alpha.kubernetes.io/unreachable` - `node.alpha.kubernetes.io/memoryPressure` - `node.alpha.kubernetes.io/diskPressure` When the support to critical pods is enabled and the pods in a DaemonSet are labelled as critical, the Daemon pods are created with an additional `NoExecute` toleration for the `node.alpha.kubernetes.io/outOfDisk` taint with no `tolerationSeconds`. This ensures that when the `TaintBasedEvictions` alpha feature is enabled, </ins> they will not be evicted when there are node problems such as a network partition. (When the `TaintBasedEvictions` feature is not enabled, they are also not evicted in these scenarios, but due to hard-coded behavior of the NodeController rather than due to tolerations).

This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: A DaemonSet by default tolerates not only node ready and node reachability taints. By design, it can tolerate memory pressure and disk pressure taints. For critical pods, it can tolerate outOfDisk taint as well. Proposed Solution: The above mentioned features should be documented. Page to Update:
/assign
Let the doc team know if you require any assistance from SMEs. Since you have assigned the defect to yourself, we assume that you have all the necessary information to fix this issue.
Thanks for the heads up. The source code (and comment) is already telling us what were missing.


Question: <ins> --- title: Watch id: watch date: 2024-07-02 full_link: /docs/reference/using-api/api-concepts/#api-verbs short_description: > A verb that is used to track changes to an object in Kubernetes as a stream. aka: tags: - API verb - fundamental --- A verb that is used to track changes to an object in Kubernetes as a stream. It is used for the efficient detection of changes. <!--more--> A verb that is used to track changes to an object in Kubernetes as a stream. Watches allow efficient detection of changes; for example, a {{< glossary_tooltip term_id="controller" text="controller">}} that needs to know whenever a ConfigMap has changed can use a watch rather than polling. See [Efficient Detection of Changes in API Concepts](/docs/reference/using-api/api-concepts/#efficient-detection-of-changes) for more information. </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update the to include an explanation of “watch”. Why is this needed The watch verb (and actually watchcollection as well) is K8s-specific jargon. We should help readers understand it. Comments Extra credit for also using the new term in existing pages, using a . /kind feature /wg api-expression
/assign
/priority backlog /triage accepted
Hi PR: for this issue. PTAL
I'm happy for any reviewer (for English) to take a look there.


Question: ### Linux ```shell <del> export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 </del> <ins> export KUBECONFIG="${KUBECONFIG}:config-demo:config-demo-2" </ins> ``` ### Windows PowerShell

Setting KUBECONFIG variable doesn't work very well on macOS (Monterey 12.2.1). In the line: The first colon (:) will make the following character (c) dissappear: What I get is the mangled text: What works for me better is explicitly using full paths:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Thanks for reporting, I can open a PR to fix this! /remove-lifecycle stale /assign


Question: The UserName in Windows to run the entrypoint of the container process. Defaults to the user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.  ### Not allowed - **ports** ([]ContainerPort) *Patch strategy: merge on key `containerPort`* *Map: unique values on keys `containerPort, protocol` will be kept during a merge* Ports are not allowed for ephemeral containers.  *ContainerPort represents a network port in a single container.* - **ports.containerPort** (int32), required Number of port to expose on the pod's IP address. This must be a valid port number, 0 < x < 65536. - **ports.hostIP** (string) What host IP to bind the external port to. - **ports.hostPort** (int32) Number of port to expose on the host. If specified, this must be a valid port number, 0 < x < 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this. - **ports.name** (string) If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services. - **ports.protocol** (string) Protocol for port. Must be UDP, TCP, or SCTP. Defaults to "TCP". Possible enum values: - `"SCTP"` is the SCTP protocol. - `"TCP"` is the TCP protocol. - `"UDP"` is the UDP protocol. - **resources** (ResourceRequirements) Resources are not allowed for ephemeral containers. Ephemeral containers use spare resources already allocated to the pod.  *ResourceRequirements describes the compute resource requirements.* - **resources.limits** (map[string]<a href="{{< ref "../common-definitions/quantity#Quantity" >}}">Quantity) Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - **resources.requests** (map[string]<a href="{{< ref "../common-definitions/quantity#Quantity" >}}">Quantity) Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - **lifecycle** (Lifecycle) Lifecycle is not allowed for ephemeral containers.  *Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.* - **lifecycle.postStart** (<a href="{{< ref "../workload-resources/pod-v1#LifecycleHandler" >}}">LifecycleHandler) PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - **lifecycle.preStop** (<a href="{{< ref "../workload-resources/pod-v1#LifecycleHandler" >}}">LifecycleHandler) PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The Pod's termination grace period countdown begins before the PreStop hook is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period (unless delayed by finalizers). Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - **livenessProbe** (<a href="{{< ref "../workload-resources/pod-v1#Probe" >}}">Probe) Probes are not allowed for ephemeral containers. - **readinessProbe** (<a href="{{< ref "../workload-resources/pod-v1#Probe" >}}">Probe) Probes are not allowed for ephemeral containers.  - **startupProbe** (<a href="{{< ref "../workload-resources/pod-v1#Probe" >}}">Probe) Probes are not allowed for ephemeral containers.

This is a Bug Report <!--Required Information--Problem: Setting for ephemeral containers is allowed as of Kubernetes 1.22, but it's still showing up as a "not allowed" field here: Proposed Solution: This page looks to be autogenerated based on the API definition, but I'm not sure how it's detecting not allowed fields. If it's automatic we'll correct the metadata or if it's curated then just reclassify the field in docs. Page to Update:
/assign
The fix is likely to happen within
is autogenerated. I don't think received field updates for v1.22
Track the update of the documentation as an issue in this repository. /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Looks like this is still happening, and also is showing up under the alpha heading even though its description says (correctly) that it's beta. This dropped off my radar, but I'll take a look at it in the next few days. /remove-lifecycle stale
/priority critical-urgent
/remove-priority critical-urgent /priority important-soon /sig security you're welcome to make a case for raising it back to critical. What would be the motivation there?
Hi I don't wish to make that case. I was just trying to assign a priority according to guidance and . The documentation is wrong for a core feature, which seems like a "fix it now" rather than "fix it in the next release" priority. The priority isn't important to me, though. Happy for it to be whatever you think is best.
This repo uses continuous deployment (we don't wait for a release for fixes). Anyway, yes, it looks important.


Question: the nodes, managing the pods and containers running on a machine. The kubelet translates each pod into its constituent containers and fetches individual container usage statistics from the container runtime through the container <del> runtime interface. The kubelet fetches this information from the integrated cAdvisor for the legacy Docker integration.  It then exposes the aggregated pod </del> <ins> runtime interface. If you use a container runtime that uses Linux cgroups and namespaces to implement containers, and the container runtime does not publish usage statistics, then the kubelet can look up those statistics directly (using code from [cAdvisor](https://github.com/google/cadvisor)). No matter how those statistics arrive, the kubelet then exposes the aggregated pod </ins> resource usage statistics through the metrics-server Resource Metrics API. This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated and read-only ports.

Umbrella issue Fixes issue File: /tasks/debug-application-cluster/resource-usage- URL: Line 44 mentions how the kubelet pulls info for Docker integration for metrics-server. Action: Review to see if it works as intended in a world without dockershim. File: /tasks/debug-application-cluster/debug-application- URL: Line 106 and other output examples use docker as the runtime. Action: Reproduce the output samples on a cluster not running Docker and update the samples. kubernetes/website/content/en/docs/tasks/debug-application- File: /tasks/debug-application- URL: Line 103 mentions specifying the Docker version when filing a Github issue. Action: Say instead to mention the runtime and version being used. File: /tasks/debug-application-cluster/debug- URL: Line 679 has . Action: Reproduce using a different runtime and update. /sig docs /language en
I'm tempted to move to a new page in the reference section, that we insta-deprecate (removal in, say, v1.27). How does that sound?
Agreed /assign
Are you covering everything listed in this issue? If so, I'd like to move this from backlog to in-flight in the dockershim project board, so nobody else tries to work on this.
yes, thank you!
/triage accepted
Is everything listed in the first entry done? What's left, if anything?
cc
Yes it is, I'm waiting for my PR in kubernetes/cri-tools to get merged before I close that one :)
URL: I don't think this needs to change tbh, since it's a very generic example.
/milestone 1.24
Dockershim removal work is ongoing, clearing the 1.24 milestone. This can be to subsequent milestones if needed. /milestone clear


Question: * [Knitter](https://github.com/ZTE/Knitter/)は、1つのKubernetes Podで複数のネットワークインターフェイスをサポートするためのプラグインです。 * [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)は、すべてのCNIプラグイン(たとえば、Calico、Cilium、Contiv、Flannel)に加えて、SRIOV、DPDK、OVS-DPDK、VPPをベースとするKubernetes上のワークロードをサポートする、複数のネットワークサポートのためのマルチプラグインです。 * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)は、Open vSwitch(OVS)プロジェクトから生まれた仮想ネットワーク実装である[OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)をベースとする、Kubernetesのためのネットワークプロバイダーです。OVN-Kubernetesは、OVSベースのロードバランサーおよびネットワークポリシーの実装を含む、Kubernetes向けのオーバーレイベースのネットワーク実装を提供します。 <del> * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)は、クラウドネイティブベースのService function chaining(SFC)、Multiple OVNオーバーレイネットワーク、動的なサブネットの作成、動的な仮想ネットワークの作成、VLANプロバイダーネットワーク、Directプロバイダーネットワークを提供し、他のMulti-networkプラグインと付け替え可能なOVNベースのCNIコントローラープラグインです。 </del> <ins> * [Nodus](https://github.com/akraino-edge-stack/icn-nodus)は、OVNベースのCNIコントローラープラグインで、クラウドネイティブベースのService function chaining(SFC)を提供します。 </ins> * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in(NCP)は、VMware NSX-TとKubernetesなどのコンテナオーケストレーター間のインテグレーションを提供します。また、NSX-Tと、Pivotal Container Service(PKS)とOpenShiftなどのコンテナベースのCaaS/PaaSプラットフォームとのインテグレーションも提供します。 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)は、Kubernetes Podと非Kubernetes環境間で可視化とセキュリティモニタリングを使用してポリシーベースのネットワークを提供するSDNプラットフォームです。 * [Romana](https://github.com/romana)は、[NetworkPolicy](/ja/docs/concepts/services-networking/network-policies/) APIもサポートするPodネットワーク向けのL3のネットワークソリューションです。 * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。 <del> ## サービスディスカバリ </del> <ins> ## サービスディスカバリー {#service-discovery} </ins> * [CoreDNS](https://coredns.io)は、フレキシブルで拡張可能なDNSサーバーです。Pod向けのクラスター内DNSとして[インストール](https://github.com/coredns/deployment/tree/master/kubernetes)できます。 <del> ## 可視化と制御 </del> <ins> ## 可視化と制御 {#visualization-amp-control} </ins> * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard)はKubernetes向けのダッシュボードを提供するウェブインターフェイスです。 * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s)は、コンテナ、Pod、Serviceなどをグラフィカルに可視化するツールです。[Weave Cloud account](https://cloud.weave.works/)と組み合わせて使うか、UIを自分でホストして使います。 <del> ## インフラストラクチャ </del> <ins> ## インフラストラクチャ {#infrastructure} </ins> * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスタで実行します。 * [node problem detector](https://github.com/kubernetes/node-problem-detector)はLinuxノード上で動作し、システムの問題を[Event](/docs/reference/kubernetes-api/cluster-resources/event-v1/)または[ノードのCondition](/ja/docs/concepts/architecture/nodes/#condition)として報告します。 <del> ## レガシーなアドオン </del> <ins> ## レガシーなアドオン {#legacy-add-ons} </ins> いくつかのアドオンは、廃止された[cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)ディレクトリに掲載されています。

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The file might be outdated. Currently in , there is no "Romana" section. It was removed by the PR . there is no section relevant to "AOS from Apstra". there is no section relevant to "Big Cloud Fabric from Big Switch Networks". there is no section relevant to "Google Compute Engine (GCE)". there is no section relevant to "Nuage Networks VCS (Virtualized Cloud Services)".Also see: Proposed Solution: Update . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ja
/triage accepted
/assign
/assign I'll also check if there are any other differences.


Question: <ins> apiVersion: v1 kind: Pod metadata: name: configmap-demo-pod spec: containers: - name: demo image: alpine command: ["sleep", "3600"] env: # Define the environment variable - name: PLAYER_INITIAL_LIVES # Notice that the case is different here # from the key name in the ConfigMap. valueFrom: configMapKeyRef: name: game-demo           # The ConfigMap this value comes from. key: player_initial_lives # The key to fetch. - name: UI_PROPERTIES_FILE_NAME valueFrom: configMapKeyRef: name: game-demo key: ui_properties_file_name volumeMounts: - name: config mountPath: "/config" readOnly: true volumes: # You set volumes at the Pod level, then mount them into containers inside that Pod - name: config configMap: # Provide the name of the ConfigMap you want to mount. name: game-demo # An array of keys from the ConfigMap to create as files items: - key: "game.properties" path: "game.properties" - key: "user-interface.properties" path: "user-interface.properties" </ins>  No newline at end of file

We can, and should, update the example that appears after We can make this use the shortcode - see Whenever we give examples that the reader could try out by running them, we should prefer using shortcodes.
/language en /triage accepted I recommend switching it to a shortcode per
I'm not sure that there's anything actually wrong with the of that Pod, though. /kind cleanup
Pasting that snippet into my own code gave me errors and it took me some time to figure out that it was due to the copied code being incorrect.
would you be willing to provide a diff for that manifest that shows the fix? It'd help.
Here is what it is currently: and here's how it should be. It's actually and everything within that block that should be shift-tab'd. There's another example on that page which is correct and you can find it by searching for "name: foo"
/assign


Question: An example is an existing application that assumes a particular well-known environment variable holds a unique identifier. One possibility is to wrap the <del> application, but that is tedious and error prone, and it violates the goal of low </del> <ins> application, but that is tedious and error-prone, and it violates the goal of low </ins> coupling. A better option would be to use the Pod's name as an identifier, and inject the Pod's name into the well-known environment variable.

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The downward API page writes “error prone”, where “error-prone” would send a much more clear context signal to localization teams. Proposed Solution: Add the missing character. The page was recently updated so no other changes are needed; however, it would super useful to include the other fix from The other change is to remove the parens around: (from the same page!) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /kind cleanup /language en /good-first-issue /priority backlog /triage accepted
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The downward API page writes “error prone”, where “error-prone” would send a much more clear context signal to localization teams. Add the missing character. The page was recently updated so no other changes are needed; however, it would super useful to include the other fix from The other change is to remove the parens around: based on the calculation <!--Kubernetes Version:--/kind cleanup /language en /good-first-issue /priority backlog /triage accepted </details
/assign


Question: - proxy to target may use HTTP or HTTPS as chosen by proxy using available information - can be used to reach a Node, Pod, or Service - does load balancing when used to reach a Service 1. The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): - runs on each node - proxies UDP and TCP - does not understand HTTP - provides load balancing - is just used to reach services 1. A Proxy/Load-balancer in front of apiserver(s): - existence and implementation varies from cluster to cluster (e.g. nginx) - sits between all clients and one or more apiservers - acts as load balancer if there are several apiservers. 1. Cloud Load Balancers on external services: - are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer) - are created automatically when the Kubernetes service has type `LoadBalancer` - use UDP/TCP only

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: The bullet points nested under numbered list aren't rendered as bulleted list: <img width="869" alt="screen shot 2017-06-10 at 2 15 49 pm" src="https://user-"Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
The sub-link isn't correct either. For example, kubectl proxy links to but should instead link to I guess it's because is split from () /assign


Question: ```shell docker build -t gcr.io/PROJECT_ID/hello-node:v2 . <del> docker push gcr.io/PROJECT_ID/hello-node:v2 </del> <ins> gcloud docker push gcr.io/PROJECT_ID/hello-node:v2 </ins> ``` Building and pushing this updated image should be much quicker as we take full advantage of the Docker cache.

In issuing the push to in the "Rolling Updates" section: docker push read: gcloud docker push
PR submitted:
cc
Thanks, Al; confirmed that is the command by talking to the GCR team today.


Question: /docs/admin/     /docs/concepts/cluster-administration/cluster-administration-overview/ 301 /docs/admin/add-ons/     /docs/concepts/cluster-administration/addons/ 301 <ins> /docs/admin/addons/     /docs/concepts/cluster-administration/addons/ 301 </ins> /docs/admin/apparmor/     /docs/tutorials/clusters/apparmor/ 301 /docs/admin/audit/     /docs/tasks/debug-application-cluster/audit/ 301 /docs/admin/authorization/rbac.md     /docs/admin/authorization/rbac/ 301

<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: The above wiki and mentions an invalid URL Browsing to results in URL 404 Error Proposed Solution: Update url on the wiki and in output Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
thanks Looks like we need a redirect for that gets to the right end destintation (which I think is has moved to )


Question: <ins> --- title: セットアップツールのリファレンス weight: 50 --- </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign


Question: {{< note >}} Um eine spezifische Version herunterzuladen, ersetze `$(curl -L -s https://dl.k8s.io/release/stable.txt)` mit der spezifischen Version. <del> Um zum Beispiel Version {{< param "fullversion" >}} auf Linux herunterzuladen: </del> <ins> Um zum Beispiel Version {{< skew currentPatchVersion >}} auf Linux herunterzuladen: </ins> ```bash <del> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/linux/amd64/kubectl </ins> ``` {{< /note >}}

[de] Replace deprecated shortcode Problem: Based on , I have created this issue/task to help update the [de] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website" /home/rdlugyhe/kubernetes/k8s-website/content/de/docs/tasks/tools/install-kubectl- 42: Um zum Beispiel Version {{< param "fullversion" }} auf Linux herunterzuladen: 45: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl /home/rdlugyhe/kubernetes/k8s-website/content/de/docs/tasks/tools/install-kubectl- 47: Um zum Beispiel Version {{< param "fullversion" }} auf Intel macOS herunterzuladen: 50: curl -LO "{{< param "fullversion" }}/bin/darwin/amd64/kubectl" 56: curl -LO "{{< param "fullversion" }}/bin/darwin/arm64/kubectl" /home/rdlugyhe/kubernetes/k8s-website/content/de/docs/tasks/tools/install- 200: Um beispielsweise die Version {{< param "fullversion" }} auf macOS herunterzuladen, verwenden Sie 203: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 228: Um beispielsweise die Version {{< param "fullversion" }} auf Linux herunterzuladen, verwenden Sie 231: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 247: Laden Sie das aktuellste Release {{< param "fullversion" }} von diesem linkg


Question: {{< /note >}} {{< note >}} <del> If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line: ```powershell wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" ``` in the flannel-host-gw.yml or flannel-overlay.yml file and specify your interface accordingly. </del> <ins> If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line: ```powershell wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" ``` in the `flannel-host-gw.yml` or `flannel-overlay.yml` file and specify your interface accordingly. ```bash # Example curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f - ``` </ins> {{< /note >}} <del> ```bash # Example curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f - ``` </del> ### Joining a Windows worker node

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Powershell markdown code block in block doesn't render correctly Proposed Solution: Move markdown code block out of block or change code block to inline code snippet Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:-- Attached Screenshot of issue !
Duplicate of

UI issues with page !
would you like sending a PR to fix the formatting of the page? /kind bug /sig windows cluster-lifecycle cc
Done but I never did it before so not sure if I did it correctly
If you send a PR in it will have a netlify preview that you can verify with. We should have checked that on the last one.


Question: priority: 1.0 --- <ins> {{< site-searchbar >}} </ins> {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} [Kubernetes]({{< relref "/docs/concepts/overview/" >}}), also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Add a facility to search the website to the main page, Why is this needed Let's say someone arrives at and wants to find the download page. Well, the top 3 results on look pretty relevant. The trouble is there's no form on to do that search, and it's not obvious that navigating round the site will reveal that search. Comments Consider both desktop and mobile browser use cases. The main page is some readers' first impression of Kubernetes, so it's important to make a good one. Most people known how to use Google (other search products exist) so fixing this need not be a priority.
I think this dovetails with as well. From an implementation perspective (from what I can tell) the site uses a custom google search engine. First step would be identifying who the admin(s) of that are. Second step would be identifying what directories are scanned Third step would be including the pages we now want to include. Fourth step is fairly easy – add to the layout template you want to see a search box on. The third step requires some thought, however. If we put a search box on the homepage, is the expectation that it searches the entire_ site or just the docs+blog? From a UX perspective, if I see a search box on the homepage I kind of expect it to search everything.
The site search already covers the whole site, so this is really about adding a form to the front page.
For an example of where to put a site search on the main page, see (I'm not proposing to move the search UI there across for the whole site; that would be a separate issue).
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Also relevant: issue
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/remove-lifecycle rotten /lifecycle frozen
/triage accepted
/area web-development (ish)
/priority backlog
I'm more than happy to work on it and get this moving forward. /assign
/assign


Question: ## {{% heading "whatsnext" %}} <del> * Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node. * Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). * Read the [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) section of the architecture design document. * Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). </del> <ins> Learn more about the following: * [Components](/docs/concepts/overview/components/#node-components) that make up a node. * [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). * [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) section of the architecture design document. * [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). * [Node Resource Managers](/docs/concepts/policy/node-resource-managers/). * [Resource Management for Windows nodes](/docs/concepts/configuration/windows-resource-management/). </ins>

This is a Feature Request What would you like to be Below are terms that can use the addition of a glossary tooltip to show the meaning of the said term.Below points can be to section of Nodes page which will help users for quick follow-ups. Why is this needed These references can help user understanding the concept while staying on same page or finding more about the concept with right link. it will enhance user experience and bring more clarity and less confusion. Comments :
/sig docs / language en /assign
If triage is accepted, i would be happy to contribute on it. PTAL.
/language en Fixed here .
/triage accepted


Question: title: kube-apiserver id: kube-apiserver date: 2018-04-12 <del> full_link: /docs/reference/generated/kube-apiserver/ </del> <ins> full_link: /zh/docs/reference/command-line-tools-reference/kube-apiserver/ </ins> short_description: > <del> Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane. </del> <ins> Control plane component that serves the Kubernetes API. </ins> aka: tags:

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: when I finished the translation of docs/reference/using-api/health-, I found a broken link when clicked the "API ":  Proposed Solution: fix it in
/language zh /assign /kind bug
/triage accepted


Question: cluster. Provided you enabled the feature gate, Kubernetes implements _validation racheting_ <del> for CustomResourceDefinitions. The API server is willing accept updates to resources that </del> <ins> for CustomResourceDefinitions. The API server is willing to accept updates to resources that </ins> are not valid after the update, provided that each part of the resource that failed to validate was not changed by the update operation. In other words, any invalid part of the resource that remains invalid must have already been wrong.

simple typo: "The API server is willing accept updates to resources that are not valid after the update" It probably should be "The API server is willing to accept updates to resources that are not valid after the update"
Page related to the issue: /language en
/assign
Hi Thank you for raising the issue please let me know if you want to work on this issue; I will unassign it. Also, make sure to follow the community guidelines by not creating multiple issues on a single page.
Issue could have also been here, instead of a separate issue /remove-kind bug /kind feature /sig docs
The issue is resolved here .


Question: resources used. ```sh <del> kubectl delete -f frontend-tcp-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml </del> <ins> kubectl delete -f web-tcp-service.yaml,redis-leader-service.yaml,redis-replica-service.yaml,web-deployment.yaml,redis-leader-deployment.yaml,redis-replica-deployment.yaml </ins> ``` <!-- discussion -->

This demonstration for converting docker compose to a kubernetes demo is referencing some old docker image / manifest types that are no longer supported and I think they fail to build, this breaks the demo workflow. Following the guide as described isn't working... To test, running a confirms this sample yaml file is using an obsolete tag, and more so the container images aren't compliant. Running the kompose conversion & apply works, but the application never shows up when attempting to curl (using for the , or even just changing to for local dev). trying to get the minikube service (with minikube tunnel running), it fails with the following: Checking the pod confirms the image pull fails with an : Same when trying to curl I believe the maintainers need to kindly update the Docker Compose yaml sample file provided to reflect newer docker images! Thanks in advance for this helpful demonstration
This refers specifically to the information contained here: which was last updated funny enough on my birthday, February 5th, 2023. Probably just needs to be updated given newer Dockerfile support versions / manifests
It was also I think necessary to add the Ingress add-on for minikube
/language en
maybe the updated version of this demo is here: as it looks like that docker sample does in fact build with docker. Running kompose convert though doesn't work on that.

Probably just some divergence
/kind bug
/retitle Stale page "Translate a Docker Compose File to Kubernetes Resources"
/triage accepted
/assign
Issues with image pull: Warning Failed 17m (x4 over 19m) kubelet Failed to pull image "": Error response from daemon: manifest for not found: manifest unknown: Failed to fetch "v4" from request "/v2/google-samples/gb-frontend/manifests/v4" Changes to commands/files: #Upgrade to v1.33 curl -L -o kompose #Update to docker- based on kompose site examples At services: redis-leader: containername: redis-leader image: redis ports: "6379" redis-replica: containername: redis-replica image: redis ports: "6379" command: redis-server --replicaof redis-leader 6379 --dir /tmp web: containername: web image: ports: "8080:8080" environment: GETHOSTS_FROM=dns labels: LoadBalancer #Apply new yaml files kubectl apply -f redis-leader-, redis-replica-, web-, redis-leader-,redis-replica-,web-tcp- Changes to Output: INFO Kubernetes file "redis-leader-" created INFO Kubernetes file "redis-replica-" created INFO Kubernetes file "web-tcp-" created INFO Kubernetes file "redis-leader-" created INFO Kubernetes file "redis-replica-" created INFO Kubernetes file "web-" created created created created service/redis-leader created service/redis-replica created service/web-tcp created Changes to Testing Services: minikube service web-tcp Starting tunnel for service web-tcp. Opening service default/web-tcp in default browser... Because you are using a Docker driver on linux, the terminal needs to be open to run it.

kubectl describe service web-tcp Name: web-tcp Namespace: default Labels: io.kompose.service=web-tcp Annotations: kompose convert LoadBalancer kompose.version: 1.33.0 () Selector: io.kompose.service=web Type: LoadBalancer IP Family Policy: SingleStack IP Families: IPv4 IP: 10.102.30.3 IPs: 10.102.30.3 Port: 8080 8080/TCP TargetPort: 8080/TCP NodePort: 8080 /TCP Endpoints: 10.244.0.5:8080 Session Affinity: None External Traffic Policy: Cluster Events: <none


Question: Example: `app.kubernetes.io/component: "database"` <del> Used on: All Objects </del> <ins> Used on: All Objects (typically used on [workload resources](/docs/reference/kubernetes-api/workload-resources/)). </ins> The component within the architecture.

Page: The labels' fields by could be clearer - they typically apply to as pointed out by in - I'll address this in a PR shortly, opening this issue to link.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue.

<detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: <ins> --- reviewers: - hasheddan - pjbgf - saschagrunert title: Restrict a Container's Syscalls with seccomp content_type: tutorial weight: 20 min-kubernetes-server-version: v1.22 --- <!-- overview --> {{< feature-state for_k8s_version="v1.19" state="stable" >}} Seccomp stands for secure computing mode and has been a feature of the Linux kernel since version 2.6.12. It can be used to sandbox the privileges of a process, restricting the calls it is able to make from userspace into the kernel. Kubernetes lets you automatically apply seccomp profiles loaded onto a {{< glossary_tooltip text="node" term_id="node" >}} to your Pods and containers. Identifying the privileges required for your workloads can be difficult. In this tutorial, you will go through how to load seccomp profiles into a local Kubernetes cluster, how to apply them to a Pod, and how you can begin to craft profiles that give only the necessary privileges to your container processes. ## {{% heading "objectives" %}} * Learn how to load seccomp profiles on a node * Learn how to apply a seccomp profile to a container * Observe auditing of syscalls made by a container process * Observe behavior when a missing profile is specified * Observe a violation of a seccomp profile * Learn how to create fine-grained seccomp profiles * Learn how to apply a container runtime default seccomp profile ## {{% heading "prerequisites" %}} In order to complete all steps in this tutorial, you must install [kind](/docs/tasks/tools/#kind) and [kubectl](/docs/tasks/tools/#kubectl). This tutorial shows some examples that are still alpha (since v1.22) and others that use only generally available seccomp functionality. You should make sure that your cluster is [configured correctly](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version) for the version you are using. The tutorial also uses the `curl` tool for downloading examples to your computer. You can adapt the steps to use a different tool if you prefer. {{< note >}} It is not possible to apply a seccomp profile to a container running with `privileged: true` set in the container's `securityContext`. Privileged containers always run as `Unconfined`. {{< /note >}} <!-- steps --> ## Download example seccomp profiles {#download-profiles} The contents of these profiles will be explored later on, but for now go ahead and download them into a directory named `profiles/` so that they can be loaded into the cluster. {{< tabs name="tab_with_code" >}} {{{< tab name="audit.json" >}} {{< codenew file="pods/security/seccomp/profiles/audit.json" >}} {{< /tab >}} {{< tab name="violation.json" >}} {{< codenew file="pods/security/seccomp/profiles/violation.json" >}} {{< /tab >}}} {{< tab name="fine-grained.json" >}} {{< codenew file="pods/security/seccomp/profiles/fine-grained.json" >}} {{< /tab >}}} {{< /tabs >}} Run these commands: ```shell mkdir ./profiles curl -L -o profiles/audit.json https://k8s.io/examples/pods/security/seccomp/profiles/audit.json curl -L -o profiles/violation.json https://k8s.io/examples/pods/security/seccomp/profiles/violation.json curl -L -o profiles/fine-grained.json https://k8s.io/examples/pods/security/seccomp/profiles/fine-grained.json ls profiles ``` You should see three profiles listed at the end of the final step: ``` audit.json  fine-grained.json  violation.json ``` ## Create a local Kubernetes cluster with kind For simplicity, [kind](https://kind.sigs.k8s.io/) can be used to create a single node cluster with the seccomp profiles loaded. Kind runs Kubernetes in Docker, so each node of the cluster is a container. This allows for files to be mounted in the filesystem of each container similar to loading files onto a node. {{< codenew file="pods/security/seccomp/kind.yaml" >}} Download that example kind configuration, and save it to a file named `kind.yaml`: ```shell curl -L -O https://k8s.io/examples/pods/security/seccomp/kind.yaml ``` You can set a specific Kubernetes version by setting the node's container image. See [Nodes](https://kind.sigs.k8s.io/docs/user/configuration/#nodes) within the kind documentation about configuration for more details on this. This tutorial assumes you are using Kubernetes {{< param "version" >}}. As an alpha feature, you can configure Kubernetes to use the profile that the {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} prefers by default, rather than falling back to `Unconfined`. If you want to try that, see [enable the use of `RuntimeDefault` as the default seccomp profile for all workloads](#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads) before you continue. Once you have a kind configuration in place, create the kind cluster with that configuration: ```shell kind create cluster --config=kind.yaml ``` After the new Kubernetes cluster is ready, identify the Docker container running as the single node cluster: ```shell docker ps ``` You should see output indicating that a container is running with name `kind-control-plane`. The output is similar to: ``` CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS                       NAMES 6a96207fed4b        kindest/node:v1.18.2   "/usr/local/bin/entr…"   27 seconds ago      Up 24 seconds       127.0.0.1:42223->6443/tcp   kind-control-plane ``` If observing the filesystem of that container, you should see that the `profiles/` directory has been successfully loaded into the default seccomp path of the kubelet. Use `docker exec` to run a command in the Pod: ```shell # Change 6a96207fed4b to the container ID you saw from "docker ps" docker exec -it 6a96207fed4b ls /var/lib/kubelet/seccomp/profiles ``` ``` audit.json  fine-grained.json  violation.json ``` You have verified that these seccomp profiles are available to the kubelet running within kind. ## Enable the use of `RuntimeDefault` as the default seccomp profile for all workloads {{< feature-state state="alpha" for_k8s_version="v1.22" >}} `SeccompDefault` is an optional kubelet [feature gate](/docs/reference/command-line-tools-reference/feature-gates) as well as corresponding `--seccomp-default` [command line flag](/docs/reference/command-line-tools-reference/kubelet). Both have to be enabled simultaneously to use the feature. If enabled, the kubelet will use the `RuntimeDefault` seccomp profile by default, which is defined by the container runtime, instead of using the `Unconfined` (seccomp disabled) mode. The default profiles aim to provide a strong set of security defaults while preserving the functionality of the workload. It is possible that the default profiles differ between container runtimes and their release versions, for example when comparing those from CRI-O and containerd. Some workloads may require a lower amount of syscall restrictions than others. This means that they can fail during runtime even with the `RuntimeDefault` profile. To mitigate such a failure, you can: - Run the workload explicitly as `Unconfined`. - Disable the `SeccompDefault` feature for the nodes. Also making sure that workloads get scheduled on nodes where the feature is disabled. - Create a custom seccomp profile for the workload. If you were introducing this feature into production-like cluster, the Kubernetes project recommends that you enable this feature gate on a subset of your nodes and then test workload execution before rolling the change out cluster-wide. More detailed information about a possible upgrade and downgrade strategy can be found in the [related Kubernetes Enhancement Proposal (KEP)](https://github.com/kubernetes/enhancements/tree/a70cc18/keps/sig-node/2413-seccomp-by-default#upgrade--downgrade-strategy). Since the feature is in alpha state it is disabled per default. To enable it, pass the flags `--feature-gates=SeccompDefault=true --seccomp-default` to the `kubelet` CLI or enable it via the [kubelet configuration file](/docs/tasks/administer-cluster/kubelet-config-file/). To enable the feature gate in [kind](https://kind.sigs.k8s.io), ensure that `kind` provides the minimum required Kubernetes version and enables the `SeccompDefault` feature [in the kind configuration](https://kind.sigs.k8s.io/docs/user/quick-start/#enable-feature-gates-in-your-cluster): ```yaml kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 featureGates: SeccompDefault: true ``` ## Create a Pod with a seccomp profile for syscall auditing To start off, apply the `audit.json` profile, which will log all syscalls of the process, to a new Pod. Here's a manifest for that Pod: {{< codenew file="pods/security/seccomp/ga/audit-pod.yaml" >}} {{< note >}} The functional support for the already deprecated seccomp annotations `seccomp.security.alpha.kubernetes.io/pod` (for the whole pod) and `container.seccomp.security.alpha.kubernetes.io/[name]` (for a single container) is going to be removed with the release of Kubernetes v1.25. Please always use the native API fields in favor of the annotations. {{< /note >}} Create the Pod in the cluster: ```shell kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/audit-pod.yaml ``` This profile does not restrict any syscalls, so the Pod should start successfully. ```shell kubectl get pod/audit-pod ``` ``` NAME        READY   STATUS    RESTARTS   AGE audit-pod   1/1     Running   0          30s ``` In order to be able to interact with this endpoint exposed by this container, create a NodePort {{< glossary_tooltip text="Services" term_id="service" >}} that allows access to the endpoint from inside the kind control plane container. ```shell kubectl expose pod audit-pod --type NodePort --port 5678 ``` Check what port the Service has been assigned on the node. ```shell kubectl get service audit-pod ``` The output is similar to: ``` NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE audit-pod   NodePort   10.111.36.142   <none>        5678:32373/TCP   72s ``` Now you can use `curl` to access that endpoint from inside the kind control plane container, at the port exposed by this Service. Use `docker exec` to run the `curl` command within the container belonging to that control plane container: ```shell # Change 6a96207fed4b to the control plane container ID you saw from "docker ps" docker exec -it 6a96207fed4b curl localhost:32373 ``` ``` just made some syscalls! ``` You can see that the process is running, but what syscalls did it actually make? Because this Pod is running in a local cluster, you should be able to see those in `/var/log/syslog`. Open up a new terminal window and `tail` the output for calls from `http-echo`: ```shell tail -f /var/log/syslog | grep 'http-echo' ``` You should already see some logs of syscalls made by `http-echo`, and if you `curl` the endpoint in the control plane container you will see more written. For example: ``` Jul  6 15:37:40 my-machine kernel: [369128.669452] audit: type=1326 audit(1594067860.484:14536): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=51 compat=0 ip=0x46fe1f code=0x7ffc0000 Jul  6 15:37:40 my-machine kernel: [369128.669453] audit: type=1326 audit(1594067860.484:14537): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=54 compat=0 ip=0x46fdba code=0x7ffc0000 Jul  6 15:37:40 my-machine kernel: [369128.669455] audit: type=1326 audit(1594067860.484:14538): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000 Jul  6 15:37:40 my-machine kernel: [369128.669456] audit: type=1326 audit(1594067860.484:14539): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=288 compat=0 ip=0x46fdba code=0x7ffc0000 Jul  6 15:37:40 my-machine kernel: [369128.669517] audit: type=1326 audit(1594067860.484:14540): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=0 compat=0 ip=0x46fd44 code=0x7ffc0000 Jul  6 15:37:40 my-machine kernel: [369128.669519] audit: type=1326 audit(1594067860.484:14541): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000 Jul  6 15:38:40 my-machine kernel: [369188.671648] audit: type=1326 audit(1594067920.488:14559): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000 Jul  6 15:38:40 my-machine kernel: [369188.671726] audit: type=1326 audit(1594067920.488:14560): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000 ``` You can begin to understand the syscalls required by the `http-echo` process by looking at the `syscall=` entry on each line. While these are unlikely to encompass all syscalls it uses, it can serve as a basis for a seccomp profile for this container. Clean up that Pod and Service before moving to the next section: ```shell kubectl delete service audit-pod --wait kubectl delete pod audit-pod --wait --now ``` ## Create Pod with seccomp profile that causes violation For demonstration, apply a profile to the Pod that does not allow for any syscalls. The manifest for this demonstration is: {{< codenew file="pods/security/seccomp/ga/violation-pod.yaml" >}} Attempt to create the Pod in the cluster: ```shell kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/violation-pod.yaml ``` The Pod creates, but there is an issue. If you check the status of the Pod, you should see that it failed to start. ```shell kubectl get pod/violation-pod ``` ``` NAME            READY   STATUS             RESTARTS   AGE violation-pod   0/1     CrashLoopBackOff   1          6s ``` As seen in the previous example, the `http-echo` process requires quite a few syscalls. Here seccomp has been instructed to error on any syscall by setting `"defaultAction": "SCMP_ACT_ERRNO"`. This is extremely secure, but removes the ability to do anything meaningful. What you really want is to give workloads only the privileges they need. Clean up that Pod before moving to the next section: ```shell kubectl delete pod violation-pod --wait --now ``` ## Create Pod with seccomp profile that only allows necessary syscalls If you take a look at the `fine-grained.json` profile, you will notice some of the syscalls seen in syslog of the first example where the profile set `"defaultAction": "SCMP_ACT_LOG"`. Now the profile is setting `"defaultAction": "SCMP_ACT_ERRNO"`, but explicitly allowing a set of syscalls in the `"action": "SCMP_ACT_ALLOW"` block. Ideally, the container will run successfully and you will see no messages sent to `syslog`. The manifest for this example is: {{< codenew file="pods/security/seccomp/ga/fine-pod.yaml" >}} Create the Pod in your cluster: ```shell kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/fine-pod.yaml ``` ```shell kubectl get pod fine-pod ``` The Pod should be showing as having started successfully: ``` NAME        READY   STATUS    RESTARTS   AGE fine-pod   1/1     Running   0          30s ``` Open up a new terminal window and use `tail` to monitor for log entries that mention calls from `http-echo`: ```shell # The log path on your computer might be different from "/var/log/syslog" tail -f /var/log/syslog | grep 'http-echo' ``` Next, expose the Pod with a NodePort Service: ```shell kubectl expose pod fine-pod --type NodePort --port 5678 ``` Check what port the Service has been assigned on the node: ```shell kubectl get service fine-pod ``` The output is similar to: ``` NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE fine-pod    NodePort   10.111.36.142   <none>        5678:32373/TCP   72s ``` Use `curl` to access that endpoint from inside the kind control plane container: ```shell # Change 6a96207fed4b to the control plane container ID you saw from "docker ps" docker exec -it 6a96207fed4b curl localhost:32373 ``` ``` just made some syscalls! ``` You should see no output in the `syslog`. This is because the profile allowed all necessary syscalls and specified that an error should occur if one outside of the list is invoked. This is an ideal situation from a security perspective, but required some effort in analyzing the program. It would be nice if there was a simple way to get closer to this security without requiring as much effort. Clean up that Pod and Service before moving to the next section: ```shell kubectl delete service fine-pod --wait kubectl delete pod fine-pod --wait --now ``` ## Create Pod that uses the container runtime default seccomp profile Most container runtimes provide a sane set of default syscalls that are allowed or not. You can adopt these defaults for your workload by setting the seccomp type in the security context of a pod or container to `RuntimeDefault`. {{< note >}} If you have the `SeccompDefault` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled, then Pods use the `RuntimeDefault` seccomp profile whenever no other seccomp profile is specified. Otherwise, the default is `Unconfined`. {{< /note >}} Here's a manifest for a Pod that requests the `RuntimeDefault` seccomp profile for all its containers: {{< codenew file="pods/security/seccomp/ga/default-pod.yaml" >}} Create that Pod: ```shell kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/default-pod.yaml ``` ```shell kubectl get pod default-pod ``` The Pod should be showing as having started successfully: ``` NAME        READY   STATUS    RESTARTS   AGE default-pod 1/1     Running   0          20s ``` Finally, now that you saw that work OK, clean up: ```shell kubectl delete pod default-pod --wait --now ``` ## {{% heading "whatsnext" %}} You can learn more about Linux seccomp: * [A seccomp Overview](https://lwn.net/Articles/656307/) * [Seccomp Security Profiles for Docker](https://docs.docker.com/engine/security/seccomp/) </ins>

This is a Feature Request What would you like to be Post-merge of , move the tutorials under into Merge clusters section into security section here: Why is this needed Issue description is a slight modification from original request in the comment Comments /hold for /cc /sig docs security
this might be a good first issue for new contributors in sig-security-docs /triage accepted
Hi, I would like to work on this issue. /assign
/kind cleanup
Hi , I a query: moving the tutorials from the cluster sub-directory into the security sub-directory, the cluster sub-directory will only have its file so do I need to do something regarding it ( file)? Thanks
Whenever you are free can you please help me with the above mentioned query. Thanks


Question: 和 [`terminationGracePeriodSeconds`](/zh/docs/concepts/workloads/pods/pod-lifecycle#pod-termination) 配置。 <ins> 使用 API 创建 Eviction 对象，就像对 Pod 执行策略控制的 [`DELETE` 操作](/zh/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod) <!-- ## Calling the Eviction API You can use a [Kubernetes language client](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) to access the Kubernetes API and create an `Eviction` object. To do this, you POST the attempted operation, similar to the following example: --> ## 调用 Eviction API 你可以使用 [Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) 来访问 Kubernetes API 并创建 `Eviction` 对象。 要执行此操作，你应该用 POST 发出要尝试的请求，类似于下面的示例： {{< tabs name="Eviction_example" >}} {{% tab name="policy/v1" %}} {{< note >}} <!-- `policy/v1` Eviction is available in v1.22+. Use `policy/v1beta1` with prior releases. --> `policy/v1`  版本的 Eviction 在 v1.22 以及更高的版本中可用，之前的发行版本使用 `policy/v1beta1` 版本。 {{< /note >}} ```json { "apiVersion": "policy/v1", "kind": "Eviction", "metadata": { "name": "quux", "namespace": "default" } } ``` {{% /tab %}} {{% tab name="policy/v1beta1" %}} {{< note >}} <!-- Deprecated in v1.22 in favor of `policy/v1` --> 在 v1.22 版本废弃以支持 `policy/v1` {{< /note >}} ```json { "apiVersion": "policy/v1beta1", "kind": "Eviction", "metadata": { "name": "quux", "namespace": "default" } } ``` {{% /tab %}} {{< /tabs >}} <!-- Alternatively, you can attempt an eviction operation by accessing the API using `curl` or `wget`, similar to the following example: --> 或者，你可以通过使用 `curl` 或者 `wget` 来访问 API 以尝试驱逐操作，类似于以下示例： ```bash curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json ``` <!-- ## How API-initiated eviction works When you request an eviction using the API, the API server performs admission checks and responds in one of the following ways: --> ## API 发起驱逐的工作原理 当你使用 API 来请求驱逐时，API 服务器将执行准入检查，并通过以下方式之一做出响应： <!-- * `200 OK`: the eviction is allowed, the `Eviction` subresource is created, and the Pod is deleted, similar to sending a `DELETE` request to the Pod URL. * `429 Too Many Requests`: the eviction is not currently allowed because of the configured {{<glossary_tooltip term_id="pod-disruption-budget" text="PodDisruptionBudget">}}. You may be able to attempt the eviction again later. You might also see this response because of API rate limiting. * `500 Internal Server Error`: the eviction is not allowed because there is a misconfiguration, like if multiple PodDisruptionBudgets reference the same Pod. --> * `200 OK`：允许驱逐，子资源 `Eviction` 被创建，并且 Pod 被删除， 类似于发送一个 `DELETE` 请求到 Pod 地址。 * `429 Too Many Requests`：当前不允许驱逐，因为配置了 {{<glossary_tooltip term_id="pod-disruption-budget" text="PodDisruptionBudget">}}。 你可以稍后再尝试驱逐。你也可能因为 API 速率限制而看到这种响应。 * `500 Internal Server Error`：不允许驱逐，因为存在配置错误， 例如存在多个 PodDisruptionBudgets 引用同一个 Pod。 <!-- If the Pod you want to evict isn't part of a workload that has a PodDisruptionBudget, the API server always returns `200 OK` and allows the eviction. If the API server allows the eviction, the Pod is deleted as follows: --> 如果你想驱逐的 Pod 不属于有 PodDisruptionBudget 的工作负载， API 服务器总是返回 `200 OK` 并且允许驱逐。 如果 API 服务器允许驱逐，Pod 按照如下方式删除： <!-- 1. The `Pod` resource in the API server is updated with a deletion timestamp, after which the API server considers the `Pod` resource to be terminated. The `Pod` resource is also marked with the configured grace period. 1. The {{<glossary_tooltip term_id="kubelet" text="kubelet">}} on the node where the local Pod is running notices that the `Pod` resource is marked for termination and starts to gracefully shut down the local Pod. 1. While the kubelet is shutting the Pod down, the control plane removes the Pod from {{<glossary_tooltip term_id="endpoint" text="Endpoint">}} and {{<glossary_tooltip term_id="endpoint-slice" text="EndpointSlice">}} objects. As a result, controllers no longer consider the Pod as a valid object. 1. After the grace period for the Pod expires, the kubelet forcefully terminates the local Pod. 1. The kubelet tells the API server to remove the `Pod` resource. 1. The API server deletes the `Pod` resource. --> 1. API 服务器中的 `Pod` 资源会更新上删除时间戳，之后 API 服务器会认为此 `Pod` 资源将被终止。 此 `Pod` 资源还会标记上配置的宽限期。 1. 本地运行状态的 Pod 所处的节点上的 {{<glossary_tooltip term_id="kubelet" text="kubelet">}} 注意到 `Pod` 资源被标记为终止，并开始优雅停止本地 Pod。 1. 当 kubelet 停止 Pod 时，控制面从 {{<glossary_tooltip term_id="endpoint" text="Endpoint">}} 和 {{<glossary_tooltip term_id="endpoint-slice" text="EndpointSlice">}} 对象中移除该 Pod。因此，控制器不再将此 Pod 视为有用对象。 1. Pod 的宽限期到期后，kubelet 强制终止本地 Pod。 1. kubelet 告诉 API 服务器删除 `Pod` 资源。 1. API 服务器删除 `Pod` 资源。 <!-- ## Troubleshooting stuck evictions In some cases, your applications may enter a broken state, where the Eviction API will only return `429` or `500` responses until you intervene. This can happen if, for example, a ReplicaSet creates pods for your application but new pods do not enter a `Ready` state. You may also notice this behavior in cases where the last evicted Pod had a long termination grace period. --> ## 解决驱逐被卡住的问题 在某些情况下，你的应用可能进入中断状态， 在你干预之前，驱逐 API 总是返回 `429` 或 `500`。 例如，如果 ReplicaSet 为你的应用程序创建了 Pod， 但新的 Pod 没有进入 `Ready` 状态，就会发生这种情况。 在最后一个被驱逐的 Pod 有很长的终止宽限期的情况下，你可能也会注意到这种行为。 <!-- If you notice stuck evictions, try one of the following solutions: * Abort or pause the automated operation causing the issue. Investigate the stuck application before you restart the operation. * Wait a while, then directly delete the Pod from your cluster control plane instead of using the Eviction API. --> 如果你注意到驱逐被卡住，请尝试以下解决方案之一： * 终止或暂停导致问题的自动化操作，重新启动操作之前，请检查被卡住的应用程序。 * 等待一段时间后，直接从集群控制平面删除 Pod，而不是使用 Eviction API。 </ins> ## {{% heading "whatsnext" %}} <!-- <del> * Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) * Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) </del> <ins> * Learn how to protect your applications with a [Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/). * Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/). * Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/). </ins> --> <del> * 了解[节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) * 了解 [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) </del> <ins> * 了解如何使用 [Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/) 保护你的应用。 * 了解[节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 * 了解 [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 </ins>

There is a bug: "Eviction API"'s hyperlink status is 404, it should be changed to "".
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind bug /language zh
/assign