Question: <ins> --- title: "Secretの管理" weight: 28 description: Secretを使用した機密設定データの管理 --- </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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Japanese Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign /triage accepted


Question: $($(CertUtil -hashfile .kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .kubectl.exe.sha256) ``` <del> 1. Append or prepend the kubectl binary folder to your `PATH` environment variable. </del> <ins> 1. Append or prepend the `kubectl` binary folder to your `PATH` environment variable. </ins> 1. Test to ensure the version of `kubectl` is the same as downloaded:

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: In , the step No. 3 is talking about the location of binary, but actually in this section ("Install plugin") we should care about the location of binary, not of binary. Proposed Solution: In : And optionally, wrap these words with backquotes in : : kubectl L47: kubectl L62: kubectl L159: kubectl-convert L165: kubectl-convert (L180: kubectl-convert) - Already suggested above. Page to Update: )-,Append%20or%20prepend%20the%20kubectl%20binary%20folder%20to%20your%20PATH%20environment%20variable.,-Verify%20plugin%20is <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en
/triage accepted
/assign


Question: 以下の理由によりPodは再起動し、Initコンテナの再実行も引き起こす可能性があります。 <del> * ユーザーが、そのPodのInitコンテナのイメージを変更するようにPodの仕様を更新する場合。アプリケーションコンテナのイメージの変更はそのアプリケーションコンテナの再起動のみ行われます。 </del> * そのPodのインフラストラクチャーコンテナが再起動された場合。これはあまり起きるものでなく、Nodeに対するルート権限を持ったユーザーにより行われることがあります。 <del> * `restartPolicy`が`Always`と設定されているPod内の全てのコンテナが停止され、再起動が行われた場合。およびガーベージコレクションによりInitコンテナの完了記録が失われた場合。 </del> <ins> * `restartPolicy`が`Always`と設定されているPod内の全てのコンテナが停止され、強制的に再起動が行われたことで、ガベージコレクションによりInitコンテナの完了記録が失われた場合。 Kubernetes v1.20以降では、initコンテナのイメージが変更されたり、ガベージコレクションによってinitコンテナの完了記録が失われたりした場合でも、Podは再起動されません。以前のバージョンを使用している場合は、対応バージョンのドキュメントを参照してください。 </ins> <del> ## {{% heading "whatsnext" %}} </del> <ins> ## {{% heading "whatsnext" %}} {#what-s-next} </ins> * [Initコンテナを含むPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)方法について学ぶ。 * [Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)を行う方法について学ぶ。

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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
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


Question: {{% tab name="Ubuntu" %}} <!-- <del> To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table: </del> <ins> To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table: </ins> | Operating system | `$OS`             | | ---------------- | ----------------- |

! w sudo systemctl enable crio --now
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
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: Typo in zh/docs/setup/production-environment/container-runtimes Proposed Solution: -Page to Update: zh: (en: ) <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/retitle [zh] Typo in docs/setup/production-environment/container-runtimes /kind bug /language zh
Page is a little bit lagging behind. Will fix. /assign


Question: <del> --- title: Bin Packing Sumber Daya untuk Sumber Daya Tambahan content_type: concept weight: 10 --- <!-- overview --> {{< feature-state for_k8s_version="1.16" state="alpha" >}} _Kube-scheduler_ dapat dikonfigurasikan untuk mengaktifkan pembungkusan rapat (_bin packing_) sumber daya bersama dengan sumber daya tambahan melalui fungsi prioritas `RequestedToCapacityRatioResourceAllocation`. Fungsi-fungsi prioritas dapat digunakan untuk menyempurnakan _kube-scheduler_ sesuai dengan kebutuhan. <!-- body --> ## Mengaktifkan _Bin Packing_ menggunakan RequestedToCapacityRatioResourceAllocation Sebelum Kubernetes 1.15, _kube-scheduler_ digunakan untuk memungkinkan mencetak skor berdasarkan rasio permintaan terhadap kapasitas sumber daya utama seperti CPU dan Memori. Kubernetes 1.16 menambahkan parameter baru ke fungsi prioritas yang memungkinkan pengguna untuk menentukan sumber daya beserta dengan bobot untuk setiap sumber daya untuk memberi nilai dari Node berdasarkan rasio permintaan terhadap kapasitas. Hal ini memungkinkan pengguna untuk _bin pack_ sumber daya tambahan dengan menggunakan parameter yang sesuai untuk meningkatkan pemanfaatan sumber daya yang langka dalam klaster yang besar. Perilaku `RequestedToCapacityRatioResourceAllocation` dari fungsi prioritas dapat dikontrol melalui pilihan konfigurasi yang disebut ` RequestToCapacityRatioArguments`. Argumen ini terdiri dari dua parameter yaitu `shape` dan `resources`. Shape memungkinkan pengguna untuk menyempurnakan fungsi menjadi yang paling tidak diminta atau paling banyak diminta berdasarkan nilai `utilization` dan `score`. Sumber daya terdiri dari `name` yang menentukan sumber daya mana yang dipertimbangkan selama penilaian dan `weight` yang menentukan bobot masing-masing sumber daya. Di bawah ini adalah contoh konfigurasi yang menetapkan `requestedToCapacityRatioArguments` pada perilaku _bin packing_ untuk sumber daya tambahan` intel.com/foo` dan `intel.com/bar` ```json { "kind" : "Policy", "apiVersion" : "v1", ... "priorities" : [ ... { "name": "RequestedToCapacityRatioPriority", "weight": 2, "argument": { "requestedToCapacityRatioArguments": { "shape": [ {"utilization": 0, "score": 0}, {"utilization": 100, "score": 10} ], "resources": [ {"name": "intel.com/foo", "weight": 3}, {"name": "intel.com/bar", "weight": 5} ] } } } ], } ``` **Fitur ini dinonaktifkan secara _default_** ### Tuning RequestedToCapacityRatioResourceAllocation Priority Function `shape` digunakan untuk menentukan perilaku dari fungsi `RequestedToCapacityRatioPriority`. ```yaml {"utilization": 0, "score": 0}, {"utilization": 100, "score": 10} ``` Argumen di atas memberikan Node nilai 0 jika utilisasi 0% dan 10 untuk utilisasi 100%, yang kemudian mengaktfikan perilaku _bin packing_. Untuk mengaktifkan dari paling yang tidak diminta, nilainya harus dibalik sebagai berikut. ```yaml {"utilization": 0, "score": 100}, {"utilization": 100, "score": 0} ``` `resources` adalah parameter opsional yang secara _default_ diatur ke: ``` yaml "resources": [ {"name": "CPU", "weight": 1}, {"name": "Memory", "weight": 1} ] ``` Ini dapat digunakan untuk menambahkan sumber daya tambahan sebagai berikut: ```yaml "resources": [ {"name": "intel.com/foo", "weight": 5}, {"name": "CPU", "weight": 3}, {"name": "Memory", "weight": 1} ] ``` Parameter `weight` adalah opsional dan diatur ke 1 jika tidak ditentukan. Selain itu, `weight` tidak dapat diatur ke nilai negatif. ### Bagaimana Fungsi Prioritas RequestedToCapacityRatioResourceAllocation Menilai Node Bagian ini ditujukan bagi kamu yang ingin memahami secara detail internal dari fitur ini. Di bawah ini adalah contoh bagaimana nilai dari Node dihitung untuk satu kumpulan nilai yang diberikan. ``` Sumber daya yang diminta intel.com/foo : 2 Memory: 256MB CPU: 2 Bobot dari sumber daya intel.com/foo : 5 Memory: 1 CPU: 3 FunctionShapePoint {{0, 0}, {100, 10}} Spesifikasi dari Node 1 Tersedia: intel.com/foo : 4 Memory : 1 GB CPU: 8 Digunakan: intel.com/foo: 1 Memory: 256MB CPU: 1 Nilai Node: intel.com/foo  = resourceScoringFunction((2+1),4) =  (100 - ((4-3)*100/4) =  (100 - 25) =  75 =  rawScoringFunction(75) = 7 Memory         = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) = 50 = rawScoringFunction(50) = 5 CPU            = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) = 37.5 = rawScoringFunction(37.5) = 3 NodeScore   =  (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) =  5 Spesifikasi dari Node 2 Tersedia: intel.com/foo: 8 Memory: 1GB CPU: 8 Digunakan: intel.com/foo: 2 Memory: 512MB CPU: 6 Nilai Node: intel.com/foo  = resourceScoringFunction((2+2),8) =  (100 - ((8-4)*100/8) =  (100 - 25) =  50 =  rawScoringFunction(50) = 5 Memory         = resourceScoringFunction((256+512),1024) = (100 -((1024-768)*100/1024)) = 75 = rawScoringFunction(75) = 7 CPU            = resourceScoringFunction((2+6),8) = (100 -((8-8)*100/8)) = 100 = rawScoringFunction(100) = 10 NodeScore   =  (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) =  7 ``` </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.


Question: <del> --- title: Bin Packing Sumber Daya untuk Sumber Daya Tambahan content_type: concept weight: 10 --- <!-- overview --> {{< feature-state for_k8s_version="1.16" state="alpha" >}} _Kube-scheduler_ dapat dikonfigurasikan untuk mengaktifkan pembungkusan rapat (_bin packing_) sumber daya bersama dengan sumber daya tambahan melalui fungsi prioritas `RequestedToCapacityRatioResourceAllocation`. Fungsi-fungsi prioritas dapat digunakan untuk menyempurnakan _kube-scheduler_ sesuai dengan kebutuhan. <!-- body --> ## Mengaktifkan _Bin Packing_ menggunakan RequestedToCapacityRatioResourceAllocation Sebelum Kubernetes 1.15, _kube-scheduler_ digunakan untuk memungkinkan mencetak skor berdasarkan rasio permintaan terhadap kapasitas sumber daya utama seperti CPU dan Memori. Kubernetes 1.16 menambahkan parameter baru ke fungsi prioritas yang memungkinkan pengguna untuk menentukan sumber daya beserta dengan bobot untuk setiap sumber daya untuk memberi nilai dari Node berdasarkan rasio permintaan terhadap kapasitas. Hal ini memungkinkan pengguna untuk _bin pack_ sumber daya tambahan dengan menggunakan parameter yang sesuai untuk meningkatkan pemanfaatan sumber daya yang langka dalam klaster yang besar. Perilaku `RequestedToCapacityRatioResourceAllocation` dari fungsi prioritas dapat dikontrol melalui pilihan konfigurasi yang disebut ` RequestToCapacityRatioArguments`. Argumen ini terdiri dari dua parameter yaitu `shape` dan `resources`. Shape memungkinkan pengguna untuk menyempurnakan fungsi menjadi yang paling tidak diminta atau paling banyak diminta berdasarkan nilai `utilization` dan `score`. Sumber daya terdiri dari `name` yang menentukan sumber daya mana yang dipertimbangkan selama penilaian dan `weight` yang menentukan bobot masing-masing sumber daya. Di bawah ini adalah contoh konfigurasi yang menetapkan `requestedToCapacityRatioArguments` pada perilaku _bin packing_ untuk sumber daya tambahan` intel.com/foo` dan `intel.com/bar` ```json { "kind" : "Policy", "apiVersion" : "v1", ... "priorities" : [ ... { "name": "RequestedToCapacityRatioPriority", "weight": 2, "argument": { "requestedToCapacityRatioArguments": { "shape": [ {"utilization": 0, "score": 0}, {"utilization": 100, "score": 10} ], "resources": [ {"name": "intel.com/foo", "weight": 3}, {"name": "intel.com/bar", "weight": 5} ] } } } ], } ``` **Fitur ini dinonaktifkan secara _default_** ### Tuning RequestedToCapacityRatioResourceAllocation Priority Function `shape` digunakan untuk menentukan perilaku dari fungsi `RequestedToCapacityRatioPriority`. ```yaml {"utilization": 0, "score": 0}, {"utilization": 100, "score": 10} ``` Argumen di atas memberikan Node nilai 0 jika utilisasi 0% dan 10 untuk utilisasi 100%, yang kemudian mengaktfikan perilaku _bin packing_. Untuk mengaktifkan dari paling yang tidak diminta, nilainya harus dibalik sebagai berikut. ```yaml {"utilization": 0, "score": 100}, {"utilization": 100, "score": 0} ``` `resources` adalah parameter opsional yang secara _default_ diatur ke: ``` yaml "resources": [ {"name": "CPU", "weight": 1}, {"name": "Memory", "weight": 1} ] ``` Ini dapat digunakan untuk menambahkan sumber daya tambahan sebagai berikut: ```yaml "resources": [ {"name": "intel.com/foo", "weight": 5}, {"name": "CPU", "weight": 3}, {"name": "Memory", "weight": 1} ] ``` Parameter `weight` adalah opsional dan diatur ke 1 jika tidak ditentukan. Selain itu, `weight` tidak dapat diatur ke nilai negatif. ### Bagaimana Fungsi Prioritas RequestedToCapacityRatioResourceAllocation Menilai Node Bagian ini ditujukan bagi kamu yang ingin memahami secara detail internal dari fitur ini. Di bawah ini adalah contoh bagaimana nilai dari Node dihitung untuk satu kumpulan nilai yang diberikan. ``` Sumber daya yang diminta intel.com/foo : 2 Memory: 256MB CPU: 2 Bobot dari sumber daya intel.com/foo : 5 Memory: 1 CPU: 3 FunctionShapePoint {{0, 0}, {100, 10}} Spesifikasi dari Node 1 Tersedia: intel.com/foo : 4 Memory : 1 GB CPU: 8 Digunakan: intel.com/foo: 1 Memory: 256MB CPU: 1 Nilai Node: intel.com/foo  = resourceScoringFunction((2+1),4) =  (100 - ((4-3)*100/4) =  (100 - 25) =  75 =  rawScoringFunction(75) = 7 Memory         = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) = 50 = rawScoringFunction(50) = 5 CPU            = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) = 37.5 = rawScoringFunction(37.5) = 3 NodeScore   =  (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) =  5 Spesifikasi dari Node 2 Tersedia: intel.com/foo: 8 Memory: 1GB CPU: 8 Digunakan: intel.com/foo: 2 Memory: 512MB CPU: 6 Nilai Node: intel.com/foo  = resourceScoringFunction((2+2),8) =  (100 - ((8-4)*100/8) =  (100 - 25) =  50 =  rawScoringFunction(50) = 5 Memory         = resourceScoringFunction((256+512),1024) = (100 -((1024-768)*100/1024)) = 75 = rawScoringFunction(75) = 7 CPU            = resourceScoringFunction((2+6),8) = (100 -((8-8)*100/8)) = 100 = rawScoringFunction(100) = 10 NodeScore   =  (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) =  7 ``` </del>

[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 .


Question: <del> --- title: Bin Packing Sumber Daya untuk Sumber Daya Tambahan content_type: concept weight: 10 --- <!-- overview --> {{< feature-state for_k8s_version="1.16" state="alpha" >}} _Kube-scheduler_ dapat dikonfigurasikan untuk mengaktifkan pembungkusan rapat (_bin packing_) sumber daya bersama dengan sumber daya tambahan melalui fungsi prioritas `RequestedToCapacityRatioResourceAllocation`. Fungsi-fungsi prioritas dapat digunakan untuk menyempurnakan _kube-scheduler_ sesuai dengan kebutuhan. <!-- body --> ## Mengaktifkan _Bin Packing_ menggunakan RequestedToCapacityRatioResourceAllocation Sebelum Kubernetes 1.15, _kube-scheduler_ digunakan untuk memungkinkan mencetak skor berdasarkan rasio permintaan terhadap kapasitas sumber daya utama seperti CPU dan Memori. Kubernetes 1.16 menambahkan parameter baru ke fungsi prioritas yang memungkinkan pengguna untuk menentukan sumber daya beserta dengan bobot untuk setiap sumber daya untuk memberi nilai dari Node berdasarkan rasio permintaan terhadap kapasitas. Hal ini memungkinkan pengguna untuk _bin pack_ sumber daya tambahan dengan menggunakan parameter yang sesuai untuk meningkatkan pemanfaatan sumber daya yang langka dalam klaster yang besar. Perilaku `RequestedToCapacityRatioResourceAllocation` dari fungsi prioritas dapat dikontrol melalui pilihan konfigurasi yang disebut ` RequestToCapacityRatioArguments`. Argumen ini terdiri dari dua parameter yaitu `shape` dan `resources`. Shape memungkinkan pengguna untuk menyempurnakan fungsi menjadi yang paling tidak diminta atau paling banyak diminta berdasarkan nilai `utilization` dan `score`. Sumber daya terdiri dari `name` yang menentukan sumber daya mana yang dipertimbangkan selama penilaian dan `weight` yang menentukan bobot masing-masing sumber daya. Di bawah ini adalah contoh konfigurasi yang menetapkan `requestedToCapacityRatioArguments` pada perilaku _bin packing_ untuk sumber daya tambahan` intel.com/foo` dan `intel.com/bar` ```json { "kind" : "Policy", "apiVersion" : "v1", ... "priorities" : [ ... { "name": "RequestedToCapacityRatioPriority", "weight": 2, "argument": { "requestedToCapacityRatioArguments": { "shape": [ {"utilization": 0, "score": 0}, {"utilization": 100, "score": 10} ], "resources": [ {"name": "intel.com/foo", "weight": 3}, {"name": "intel.com/bar", "weight": 5} ] } } } ], } ``` **Fitur ini dinonaktifkan secara _default_** ### Tuning RequestedToCapacityRatioResourceAllocation Priority Function `shape` digunakan untuk menentukan perilaku dari fungsi `RequestedToCapacityRatioPriority`. ```yaml {"utilization": 0, "score": 0}, {"utilization": 100, "score": 10} ``` Argumen di atas memberikan Node nilai 0 jika utilisasi 0% dan 10 untuk utilisasi 100%, yang kemudian mengaktfikan perilaku _bin packing_. Untuk mengaktifkan dari paling yang tidak diminta, nilainya harus dibalik sebagai berikut. ```yaml {"utilization": 0, "score": 100}, {"utilization": 100, "score": 0} ``` `resources` adalah parameter opsional yang secara _default_ diatur ke: ``` yaml "resources": [ {"name": "CPU", "weight": 1}, {"name": "Memory", "weight": 1} ] ``` Ini dapat digunakan untuk menambahkan sumber daya tambahan sebagai berikut: ```yaml "resources": [ {"name": "intel.com/foo", "weight": 5}, {"name": "CPU", "weight": 3}, {"name": "Memory", "weight": 1} ] ``` Parameter `weight` adalah opsional dan diatur ke 1 jika tidak ditentukan. Selain itu, `weight` tidak dapat diatur ke nilai negatif. ### Bagaimana Fungsi Prioritas RequestedToCapacityRatioResourceAllocation Menilai Node Bagian ini ditujukan bagi kamu yang ingin memahami secara detail internal dari fitur ini. Di bawah ini adalah contoh bagaimana nilai dari Node dihitung untuk satu kumpulan nilai yang diberikan. ``` Sumber daya yang diminta intel.com/foo : 2 Memory: 256MB CPU: 2 Bobot dari sumber daya intel.com/foo : 5 Memory: 1 CPU: 3 FunctionShapePoint {{0, 0}, {100, 10}} Spesifikasi dari Node 1 Tersedia: intel.com/foo : 4 Memory : 1 GB CPU: 8 Digunakan: intel.com/foo: 1 Memory: 256MB CPU: 1 Nilai Node: intel.com/foo  = resourceScoringFunction((2+1),4) =  (100 - ((4-3)*100/4) =  (100 - 25) =  75 =  rawScoringFunction(75) = 7 Memory         = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) = 50 = rawScoringFunction(50) = 5 CPU            = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) = 37.5 = rawScoringFunction(37.5) = 3 NodeScore   =  (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) =  5 Spesifikasi dari Node 2 Tersedia: intel.com/foo: 8 Memory: 1GB CPU: 8 Digunakan: intel.com/foo: 2 Memory: 512MB CPU: 6 Nilai Node: intel.com/foo  = resourceScoringFunction((2+2),8) =  (100 - ((8-4)*100/8) =  (100 - 25) =  50 =  rawScoringFunction(50) = 5 Memory         = resourceScoringFunction((256+512),1024) = (100 -((1024-768)*100/1024)) = 75 = rawScoringFunction(75) = 7 CPU            = resourceScoringFunction((2+6),8) = (100 -((8-8)*100/8)) = 100 = rawScoringFunction(100) = 10 NodeScore   =  (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) =  7 ``` </del>

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: * [`gcePersistentDisk`](#gcepersistentdisk) * [`vsphereVolume`](#vspherevolume) <del> ### flexVolume (deprecated) </del> <ins> ### flexVolume (deprecated)   {#flexvolume} </ins> {{< feature-state for_k8s_version="v1.23" state="deprecated" >}}

Problem: The text on is not working, it should point to these Check the page for the problem. Page to Update: Proposed Solution: It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text FlexVolume to and not to this . /kind document /assign /language en
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: The text on is not working, it should point to these Check the page for the problem. It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text FlexVolume to and not to this . /assign /language en 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
/triage accepted


Question: * [`gcePersistentDisk`](#gcepersistentdisk) * [`vsphereVolume`](#vspherevolume) <del> ### flexVolume (deprecated) </del> <ins> ### flexVolume (deprecated)   {#flexvolume} </ins> {{< feature-state for_k8s_version="v1.23" state="deprecated" >}}

Problem: The text on is not working, it should point to these Check the page for the problem. Page to Update: Proposed Solution: It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text FlexVolume to and not to this . /kind document /assign /language en
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: The text on is not working, it should point to these Check the page for the problem. It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text FlexVolume to and not to this . /assign /language en 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
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


Question: You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization. {{< note >}} <del> In versions of Kubernetes before v1.19, you must enable the `EvenPodsSpread` </del> <ins> In versions of Kubernetes before v1.18, you must enable the `EvenPodsSpread` </ins> [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the [API server](/docs/concepts/overview/components/#kube-apiserver) and the [scheduler](/docs/reference/generated/kube-scheduler/) in order to use Pod

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 documentation on Pod Topology Spread Constraints indicates: Proposed Solution: The documentation should read This feature went default-on when it hit Beta in 1.18 per the [Feature Gate Reference] () Page to Update:
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


Question: However, using the defined and public Secret type (`kubernetes.io/basic-auth`) helps other people to understand the purpose of your Secret, and sets a convention for what key names to expect. <del> The Kubernetes API verifies that the required keys are set for a Secret of this type. </del> ### SSH authentication Secrets

Hi Team As per the documentation link: Kube api-server is supposed to validate the keys for secret type: However, I have observed that secrets are still being created if the valid keys are not in the secret manifest. apiVersion: v1 kind: Secret metadata: name: secret-basic-auth type: stringData: username: admin # required field for
Thanks for mentioning this. What's not right about the documentation, in your opinion, /language en
As per documentation, for the secret type: , they keys (username, password) are validated during secret creation. However, I am able to generate this secret of type without mentioning password key in the manifest. Is the documentation correct? If yes, then validation is missing?
It sounds like you're saying that specifically is wrong. As well as removing that text, we make it clear that “must” means ”you are expected to ensure this” and not “your cluster enforces this“. /triage accepted If you want the cluster to enforce that those keys are set, you could make a feature request As an aside: would be nice to document some ValidatingAdmissionPolicies that do enforce this rule.
/assign I will create a PR for fixing this.
Fixed in /close
Closing this issue. <detailsIn response to : Fixed in /close 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: --- assignees: - bboreham <del> title: Weave Net Addon </del> <ins> title: Using Weave Net for NetworkPolicy </ins> --- The [Weave Net Addon](https://www.weave.works/docs/net/latest/kube-addon/) for Kubernetes comes with a Network Policy Controller.

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [X] Bug Report Problem: The link "build-tools/" doesn't work anymore and returns 404. Proposed Solution: Fix the link Page to Update:
Fixed. Thanks!


Question: --- assignees: - bboreham <del> title: Weave Net Addon </del> <ins> title: Using Weave Net for NetworkPolicy </ins> --- The [Weave Net Addon](https://www.weave.works/docs/net/latest/kube-addon/) for Kubernetes comes with a Network Policy Controller.

<!-- 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: Page url: in line 83, click PetSets guide occur 404 error. Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Fixed.


Question: --- assignees: - bboreham <del> title: Weave Net Addon </del> <ins> title: Using Weave Net for NetworkPolicy </ins> --- The [Weave Net Addon](https://www.weave.works/docs/net/latest/kube-addon/) for Kubernetes comes with a Network Policy Controller.

This is a... [ ] Feature Request [X] Bug Report Problem: link "Minikube installation guide" points to which is 404 Proposed Solution: fix the link by making it absolute: Page to Update:
Fixed.


Question: --- assignees: - bboreham <del> title: Weave Net Addon </del> <ins> title: Using Weave Net for NetworkPolicy </ins> --- The [Weave Net Addon](https://www.weave.works/docs/net/latest/kube-addon/) for Kubernetes comes with a Network Policy Controller.

<!-- 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: Multiple links on the page generate 404 Not Found Examples: (redirected from ) (redirected from ) Proposed Solution: fix the links Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Here is the full list of broken links on xhyve driver kvm (driver installation) xhyve (driver installation) See DRIVERS docker-env command minikube start minikube stop minikube delete full CLI docs


Question: --- assignees: - bboreham <del> title: Weave Net Addon </del> <ins> title: Using Weave Net for NetworkPolicy </ins> --- The [Weave Net Addon](https://www.weave.works/docs/net/latest/kube-addon/) for Kubernetes comes with a Network Policy Controller.

I wish /docs/user-guide/horizontal-pod-autoscaling/walkthrough/ actually contained the information, or at least a link to autoscaling by custom application logic (as referred to by the first sentence in the article - . The second half of this article seems like the correct target link -
Fixed. Thanks.


Question: <ins> --- reviewers: - bowei - zihongz title:  Debugging DNS Resolution content_type: task min-kubernetes-server-version: v1.6 --- <!-- overview --> This page provides hints on diagnosing DNS problems. ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} Your cluster must be configured to use the CoreDNS {{< glossary_tooltip text="addon" term_id="addons" >}} or its precursor, kube-dns. {{% version-check %}} <!-- steps --> ### Create a simple Pod to use as a test environment {{< codenew file="admin/dns/dnsutils.yaml" >}} Use that manifest to create a Pod: ```shell kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml ``` ``` pod/dnsutils created ``` …and verify its status: ```shell kubectl get pods dnsutils ``` ``` NAME      READY     STATUS    RESTARTS   AGE dnsutils   1/1       Running   0          <some-time> ``` Once that Pod is running, you can exec `nslookup` in that environment. If you see something like the following, DNS is working correctly. ```shell kubectl exec -i -t dnsutils -- nslookup kubernetes.default ``` ``` Server:    10.0.0.10 Address 1: 10.0.0.10 Name:      kubernetes.default Address 1: 10.0.0.1 ``` If the `nslookup` command fails, check the following: ### Check the local DNS configuration first Take a look inside the resolv.conf file. (See [Inheriting DNS from the node](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) and [Known issues](#known-issues) below for more information) ```shell kubectl exec -ti dnsutils -- cat /etc/resolv.conf ``` Verify that the search path and name server are set up like the following (note that search path may vary for different cloud providers): ``` search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal nameserver 10.0.0.10 options ndots:5 ``` Errors such as the following indicate a problem with the CoreDNS (or kube-dns) add-on or with associated Services: ```shell kubectl exec -i -t dnsutils -- nslookup kubernetes.default ``` ``` Server:    10.0.0.10 Address 1: 10.0.0.10 nslookup: can't resolve 'kubernetes.default' ``` or ```shell kubectl exec -i -t dnsutils -- nslookup kubernetes.default ``` ``` Server:    10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local nslookup: can't resolve 'kubernetes.default' ``` ### Check if the DNS pod is running Use the `kubectl get pods` command to verify that the DNS pod is running. ```shell kubectl get pods --namespace=kube-system -l k8s-app=kube-dns ``` ``` NAME                       READY     STATUS    RESTARTS   AGE ... coredns-7b96bf9f76-5hsxb   1/1       Running   0           1h coredns-7b96bf9f76-mvmmt   1/1       Running   0           1h ... ``` {{< note >}} The value for label `k8s-app` is `kube-dns` for both CoreDNS and kube-dns deployments. {{< /note >}} If you see that no CoreDNS Pod is running or that the Pod has failed/completed, the DNS add-on may not be deployed by default in your current environment and you will have to deploy it manually. ### Check for errors in the DNS pod Use the `kubectl logs` command to see logs for the DNS containers. For CoreDNS: ```shell kubectl logs --namespace=kube-system -l k8s-app=kube-dns ``` Here is an example of a healthy CoreDNS log: ``` .:53 2018/08/15 14:37:17 [INFO] CoreDNS-1.2.2 2018/08/15 14:37:17 [INFO] linux/amd64, go1.10.3, 2e322f6 CoreDNS-1.2.2 linux/amd64, go1.10.3, 2e322f6 2018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1c ``` See if there are any suspicious or unexpected messages in the logs. ### Is DNS service up? Verify that the DNS service is up by using the `kubectl get service` command. ```shell kubectl get svc --namespace=kube-system ``` ``` NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE ... kube-dns     ClusterIP   10.0.0.10      <none>        53/UDP,53/TCP        1h ... ``` {{< note >}} The service name is `kube-dns` for both CoreDNS and kube-dns deployments. {{< /note >}} If you have created the Service or in the case it should be created by default but it does not appear, see [debugging Services](/docs/tasks/debug-application-cluster/debug-service/) for more information. ### Are DNS endpoints exposed? You can verify that DNS endpoints are exposed by using the `kubectl get endpoints` command. ```shell kubectl get endpoints kube-dns --namespace=kube-system ``` ``` NAME       ENDPOINTS                       AGE kube-dns   10.180.3.17:53,10.180.3.17:53    1h ``` If you do not see the endpoints, see the endpoints section in the [debugging Services](/docs/tasks/debug-application-cluster/debug-service/) documentation. For additional Kubernetes DNS examples, see the [cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns) in the Kubernetes GitHub repository. ### Are DNS queries being received/processed? You can verify if queries are being received by CoreDNS by adding the `log` plugin to the CoreDNS configuration (aka Corefile). The CoreDNS Corefile is held in a {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} named `coredns`. To edit it, use the command: ``` kubectl -n kube-system edit configmap coredns ``` Then add `log` in the Corefile section per the example below: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: coredns namespace: kube-system data: Corefile: | .:53 { log errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 proxy . /etc/resolv.conf cache 30 loop reload loadbalance } ``` After saving the changes, it may take up to minute or two for Kubernetes to propagate these changes to the CoreDNS pods. Next, make some queries and view the logs per the sections above in this document. If CoreDNS pods are receiving the queries, you should see them in the logs. Here is an example of a query in the log: ``` .:53 2018/08/15 14:37:15 [INFO] CoreDNS-1.2.0 2018/08/15 14:37:15 [INFO] linux/amd64, go1.10.3, 2e322f6 CoreDNS-1.2.0 linux/amd64, go1.10.3, 2e322f6 2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f 2018/09/07 15:29:04 [INFO] Reloading complete 172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s ``` ## Known issues Some Linux distributions (e.g. Ubuntu) use a local DNS resolver by default (systemd-resolved). Systemd-resolved moves and replaces `/etc/resolv.conf` with a stub file that can cause a fatal forwarding loop when resolving names in upstream servers. This can be fixed manually by using kubelet's `--resolv-conf` flag to point to the correct `resolv.conf` (With `systemd-resolved`, this is `/run/systemd/resolve/resolv.conf`). kubeadm automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly. Kubernetes installs do not configure the nodes' `resolv.conf` files to use the cluster DNS by default, because that process is inherently distribution-specific. This should probably be implemented eventually. Linux's libc (a.k.a. glibc) has a limit for the DNS `nameserver` records to 3 by default. What's more, for the glibc versions which are older than glibc-2.17-222 ([the new versions update see this issue](https://access.redhat.com/solutions/58028)), the allowed number of DNS `search` records has been limited to 6 ([see this bug from 2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)). Kubernetes needs to consume 1 `nameserver` record and 3 `search` records. This means that if a local installation already uses 3 `nameserver`s or uses more than 3 `search`es while your glibc version is in the affected list, some of those settings will be lost. To work around the DNS `nameserver` records limit, the node can run `dnsmasq`, which will provide more `nameserver` entries. You can also use kubelet's `--resolv-conf` flag. To fix the DNS `search` records limit, consider upgrading your linux distribution or upgrading to an unaffected version of glibc. If you are using Alpine version 3.3 or earlier as your base image, DNS may not work properly due to a known issue with Alpine. Kubernetes [issue 30215](https://github.com/kubernetes/kubernetes/issues/30215) details more information on this. ## {{% heading "whatsnext" %}} - See [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). - Read [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/) </ins>

This page returns 404 not found.
Yup. It was moved over to a different folder ...
/language en
Thanks! Do you know what is the currently available link for the English doc? The search is not very helpful btw, the Chinese link is still working though...
Well, I think we should move it back. Proposing a fix now. If it turns out that team doesn't want to move it back, we may need to add a redirect entry as an alternative.
let's discuss the move back in this issue. Can you set out a case for reverting?
Sure. I'm assuming that there are audiences from different user groups reading the docs and even learn by doing. A long while ago, we (primarily chenopis) started an initiative to provider journeys for different group of users. Some of those efforts are still , archived into a directory. The idea was to help users find the materials they need based on their roles in operating or using Kubernetes. This background is where I came from. For cluster operators (or admins, or whatever you call them), they often times enjoy a higher privilege (aka more responsibilities) to keep the cluster running healthily. That means they need to ensure the following things work properly: access control and admission control storage provisioning and networking setup auditing, logging and monitoring upgrade cluster config secure cluster data and backup them properly ... These are not concerns of an application developer. An application developer uses the cluster to deploy, scale their applications. For example, they rarely have a say regarding when to evict a Pod out of a node and they cannot decide whether and which upstream DNS server is used. Similarly, a cluster operator doesn't care that much how application Helm charts are composed, version controlled. A production deployment is pretty different from the minikube one we use for learning and erring. So ... DNS and related tasks is not an application level thing. It is a cluster administering job. That is the reason I'm proposing this (partial) revert.


Question: Minikube 在用户计算机上的一个虚拟机内运行单节点 Kubernetes 集群。 你可以使用 Minikube <del> [在学习环境中尝试 Kubernetes](/zh-cn/docs/setup/learning-environment/). </del> <ins> [在学习环境中尝试 Kubernetes](/zh-cn/docs/setup/learning-environment/)。 </ins>

Hello, I noticed some punctuation errors on page /language zh
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


Question: or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed. <del> Nodes should be provisioned with the public root certificate for the cluster such that they can </del> <ins> Nodes should be provisioned with the public root {{< glossary_tooltip text="certificate" term_id="certificate" >}} for the cluster such that they can </ins> connect securely to the API server along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. <del> Pods that wish to connect to the API server can do so securely by leveraging a service account so </del> <ins> {{< glossary_tooltip text="Pods" term_id="pod" >}} that wish to connect to the API server can do so securely by leveraging a service account so </ins> that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. The `kubernetes` service (in `default` namespace) is configured with a virtual IP address that is <del> redirected (via `kube-proxy`) to the HTTPS endpoint on the API server. </del> <ins> redirected (via `{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`) to the HTTPS endpoint on the API server. </ins> The control plane components also communicate with the API server over the secure port. <del> As a result, the default operating mode for connections from the nodes and pods running on the </del> <ins> As a result, the default operating mode for connections from the nodes and pod running on the </ins> nodes to the control plane is secured by default and can run over untrusted and/or public networks. ## Control plane to node There are two primary communication paths from the control plane (the API server) to the nodes. <del> The first is from the API server to the kubelet process which runs on each node in the cluster. </del> <ins> The first is from the API server to the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} process which runs on each node in the cluster. </ins> The second is from the API server to any node, pod, or service through the API server's _proxy_ functionality.

This is a Feature Request What would you like to be There are terms that can use the addition of a glossary tooltip to show the meaning of the said term. There is no or reference section Some terms can use references like : , Why is this needed Rather than searching for the definitions of some terms , the references can help 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 The page needed to be updated here is :
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 feature /language en /sig docs
If the triage is accepted would be happy to contribute references I have searched while reading the concept. /assign
Worth doing, but the change I outline in is more valuable to work on.
here seems to be about the and page in particular. I'd agree with the general idea of making the content brief and putting extra information in the reference. For control-plane-node-communication page, I see your comment about adding a diagram there. Will try to add that as well.
For now, I'll push this commit, in case even if we shift this content to reference or another section, we would still need some of the links and references.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale


Question: other versions of Kubernetes, check the documentation for that release. By default, `spec.loadBalancerClass` is `nil` and a `LoadBalancer` type of Service uses the cloud provider's default load balancer implementation if the cluster is configured with <del> a cloud provider using the `--cloud-provider` component flag. </del> <ins> a cloud provider using the `--cloud-provider` component flag. </ins> If `spec.loadBalancerClass` is specified, it is assumed that a load balancer implementation that matches the specified class is watching for Services. Any default load balancer implementation (for example, the one provided by the cloud provider) will ignore Services that have this field set. `spec.loadBalancerClass` can be set on a Service of type `LoadBalancer` only. <del> Once set, it cannot be changed. </del> <ins> Once set, it cannot be changed. </ins> The value of `spec.loadBalancerClass` must be a label-style identifier, with an optional prefix such as "`internal-vip`" or "`example.com/internal-vip`". Unprefixed names are reserved for end-users.

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: marks the userspace kube-proxy as deprecated. This was missed from the v1.23 docs updates and . Proposed Solution: Mark the kube-proxy in userspace mode as deprecated. Page to Update: <!--Additional Information:--/sig network /language en /priority important-longterm
/lifecycle frozen /triage accepted
/assign


Question: This annotation is used to set [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost) which allows users to influence ReplicaSet downscaling order. The annotation parses into an `int32` type. <ins> ### cluster-autoscaler.kubernetes.io/enable-ds-eviction Example: `cluster-autoscaler.kubernetes.io/enable-ds-eviction: "true"` Used on: Pod This annotation controls whether a DaemonSet pod should be evicted by a ClusterAutoscaler. This annotation needs to be specified on DaemonSet pods in a DaemonSet manifest. When this annotation is set to `"true"`, the ClusterAutoscaler is allowed to evict a DaemonSet Pod, even if other rules would normally prevent that. To disallow the ClusterAutoscaler from evicting DaemonSet pods, you can set this annotation to `"false"` for important DaemonSet pods. If this annotation is not set, then the Cluster Autoscaler follows its overall behaviour (i.e evict the DaemonSets based on its configuration). {{< note >}} This annotation only impacts DaemonSet pods. {{< /note >}} </ins> ### kubernetes.io/ingress-bandwidth {{< note >}}

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 cluster autoscaler uses an annotation, . However, we don't list that annotation in Well-Known Labels, Annotations and Taints. Proposed Solution: Update Well-Known Labels, Annotations and Taints to mention the Pod annotation and why you might use it. We could mention that you typically set this annotation in the Pod template within a DaemonSet and that you don't set that annotation on the DaemonSet itself. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en
I would like to work on this. /assign /sig autoscaling
Fixed it here:
/triage accepted


Question: in that Pod based on the data in the ConfigMap. The Pod and the ConfigMap must be in the same {{< glossary_tooltip text="namespace" term_id="namespace" >}}. <ins> {{< note >}} The `spec` of a {{< glossary_tooltip text="static Pod" term_id="static-pod" >}} cannot refer to a ConfigMap or any other API objects. {{< /note >}} </ins> Here's an example ConfigMap that has some keys with single values, and other keys where the value looks like a fragment of a configuration format.

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: I saw an out-of-tree product mention that static pods "can not use" ConfigMaps and Secrets. I was unaware of such a prohibition. I went looking in the k8s website. I spent a lot of time not finding any mention of such a restriction. For example: mentions static pods but not the restriction; describes ConfigMap and Secret type volumes but does not mention the restriction; the Go sources for the relevant API types do not mention the restriction (). I eventually found the restriction wrt ConfigMap mentioned in , but I think it should not appear only there. Proposed Solution: Update either or both of the first two pages I cited that currently lack the restriction. Update the API types to mention the restriction. Page to Update: Listed above. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/triage accepted
I can work on this one. Thanks. /assign
I just realized there is an additional --- and more severe --- restriction on static pods. They can not have a ! As a corollary, they are not given a by default. For example, using a static pod: ... note that there is no ! is one place where this would be relevant.
The prohibition is even broader and simpler: the definition of a static pod can not refer to any other API object. For example, PersistentVolumeClaim is another thing that a static pod's definition can not reference.


Question: common use cases and suggested solutions. 1. Cluster running only non-proprietary (e.g. open-source) images.  No need to hide images. <del> - Use public images on the Docker hub. </del> <ins> - Use public images from a public registry </ins> - No configuration required. - Some cloud providers automatically cache or mirror public images, which improves availability and reduces the time to pull images. 1. Cluster running some proprietary images which should be hidden to those outside the company, but visible to all cluster users. <del> - Use a hosted private [Docker registry](https://docs.docker.com/registry/). - It may be hosted on the [Docker Hub](https://hub.docker.com/signup), or elsewhere. - Manually configure .docker/config.json on each node as described above. </del> <ins> - Use a hosted private registry - Manual configuration may be required on the nodes that need to access to private registry </ins> - Or, run an internal private registry behind your firewall with open read access. - No Kubernetes configuration is required. - Use a hosted container image registry service that controls image access

Ref: needs a rewrite. It mentions Docker (and Podman!) all over the place, which is a good indication that the docs are old enough to need a rewrite. At a minimum, remove mentions of Docker in these topics: /triage accepted /milestone 1.24
/assign
/assign
Reasked folks in Slack for correct disposition
Asked in the SIG Node slack channel:
To summarize the consensus from talking with folks about this issue, specifically the examples in Using a Private Registry section: The steps in the Using a Private Registry section are still valid. However, as written, it makes it sound like Docker is the only/recommended way to do this-which we dont want. We should be able to remove the docker examples and point folks to this page , which covers most of the same content with third party disclaimers already written into the examples. I plan to open a PR later this week with these changes!
Has anyone opened a PR for this issue? It seems to be referring to


Question: ### Stable Storage <del> Kubernetes creates one [PersistentVolume](/docs/concepts/storage/persistent-volumes/) for each VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass </del> <ins> For each VolumeClaimTemplate entry defined in a StatefulSet, each Pod receives one PersistentVolumeClaim. In the nginx example above, each Podreceives a single PersistentVolume with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass </ins> is specified, then the default StorageClass will be used. When a Pod is (re)scheduled onto a node, its `volumeMounts` mount the PersistentVolumes associated with its PersistentVolume Claims. Note that, the PersistentVolumes associated with the

Document's section: Currenty it says: Kubernetes creates one PersistentVolume for each VolumeClaimTemplate That is not wrong, but not exact. What about replacing it by something like this: Per each StatefulSet triggered pod Kubernetes creates a PersistentVolumeClaim object for each VolumeClaimTemplates entry defined in the StatefulSet object /language en
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
I would like to work on this /assign
Hi i have raised a this.
Thanks ;-)


Question: cat <<EOF >./kustomization.yaml configMapGenerator: - name: game-config-4 <del> labels: game-config: config-4 </del> <ins> options: labels: game-config: config-4 </ins> files: - configure-pod-container/configmap/game.properties EOF

This is a Bug Report While applying written in is triggering an error Whereas by removing the labels from the and Applying the kustomization directory to create the ConfigMap object get created successfully. <!--Required Information--Problem: cat <<EOF Here is the configmap created previously. Proposed Solution: Update it with suitable answer. Refer : for kustomization update. Page to Update:
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
/sig docs /language en
The unknown field was in this commit and it was not supported refer to the code We can add labels via refer to I can help open a PR to update the code sections.


Question: Now, re-run the test: ```console <del> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; do </del> <ins> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done </ins> client_address=104.132.1.79 ```


Question: Now, re-run the test: ```console <del> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; do </del> <ins> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done </ins> client_address=104.132.1.79 ```


Question: Now, re-run the test: ```console <del> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; do </del> <ins> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done </ins> client_address=104.132.1.79 ```


Question: Now, re-run the test: ```console <del> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; do </del> <ins> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done </ins> client_address=104.132.1.79 ```


Question: Now, re-run the test: ```console <del> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; do </del> <ins> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done </ins> client_address=104.132.1.79 ```


Question: ```shell kubectl describe -f myapp.yaml ``` <ins> 実行結果は下記のようになります。 </ins> ``` Name:          myapp-pod Namespace:     default [...] <del> Labels:        app=myapp </del> <ins> Labels:        app.kubernetes.io/name=MyApp </ins> Status:        Pending [...] Init Containers:

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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
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


Question:
{{ range .Params.cards }}

{{ .title }}

{{ .description }}

~This is Support~ In the , i am able to see under Kubernetes Documentation. Respective tiled content buttons are aligned respective the content length or size. As a user , i would like to see them aligned as a bordered tile content with buttons are aligned look like a row irrespective of tile content length. This improves the user experience Please let me know if drawings are needed to understand.So that i can take a capture of it and attach.
/area web-development /kind cleanup a mockup would be useful
/priority awaiting-more-evidence (adjust this once the discussion has made it clear)
- PFA.It is screenshot of button aligned.I have the tile border which is not the primary objective though(Just to border line the content) ! Hope this mockup helps.
/remove-priority awaiting-more-evidence /priority backlog
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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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 /lifecycle frozen /retitle Poor alignment between tiles and buttons on home page for docs
Reopened this issue. <detailsIn response to : /reopen /lifecycle frozen /retitle Poor alignment between tiles and buttons on home page for docs 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
/remove-kind cleanup /triage accepted


Question: title: Pod 优先级（Pod Priority） id: pod-priority date: 2019-01-31 <del> full_link: /zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority </del> <ins> full_link: /zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority </ins> short_description: > Pod 优先级表示一个 Pod 相对于其他 Pod 的重要性。

There is a bug: ,%E8%AE%BE%E4%B8%BA%20%2D997%E3%80%82 ""'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
/language zh /kind bug
/assign


Question: <ins> <svg width="580" height="400" xmlns="http://www.w3.org/2000/svg"> <g> <title>background</title> <rect x="-1" y="-1" width="506.34798" height="349.82619" id="canvas_background" fill="#fff" opacity="0"/> <g id="canvasGrid" display="none"> <rect opacity="0" id="svg_4" width="100%" height="100%" x="0" y="0" stroke-width="0" fill="url(#gridpattern)"/> </g> </g> <g> <title>Layer 1</title> <rect fill="#326ce5" stroke="#000" stroke-width="1.5" x="126.27611" y="84.45079" width="336.49766" height="242.99831" id="svg_1"/> <rect fill="#DDDDDD" stroke-width="0.5" x="127.2761" y="261.05662" width="95.3" height="66" id="svg_2" stroke="#000"/> <rect fill="#BBBBBB" stroke-opacity="null" x="222.4421" y="261.28292" width="108.3" height="66" id="svg_3" stroke="#000"/> <rect fill="#ffffff" stroke-width="0.5" stroke-opacity="null" x="330.77469" y="261.28292" width="131" height="66" id="svg_5" stroke="#000"/> <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="126.25112" y="28.72775" id="svg_6" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(3.8729541301727295,0,0,0.698510413795276,-358.40104965794853,12.1371268265946) " stroke="#000"/> <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="96.33037" y="92.52907" id="svg_9" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.6039765318373469,0,0,0.6213608286284256,43.920523540443796,7.5797796894100635) " stroke="#000">Node Capacity</text> <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="146.65172" y="483.69046" id="svg_10" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.5187438936507338,0,0,0.5165904901211577,58.14778751529779,47.720737964149194) " stroke="#000">kube-reserved</text> <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="333.31931" y="486.27149" id="svg_11" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.5187438936507338,0,0,0.5165904901211577,58.14778751529779,47.720737964149194) " stroke="#000">system-reserved</text> <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="559.50522" y="487.562" id="svg_12" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.5187438936507338,0,0,0.5165904901211577,58.14778751529779,47.720737964149194) " stroke="#000">eviction-threshold</text> <text fill="#ffffff" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="246.31519" y="182.62777" id="svg_14" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.8530217831379474,0,0,0.8530217831379474,32.26513711483058,11.272510077186126) " stroke="#000">allocatable</text> <text fill="#ffffff" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="191.56677" y="217.51295" id="svg_15" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.6610298739213645,0,0,0.6148439389614191,97.43948566238379,61.05811172356589) " stroke="#000">(available for pods)</text> <line fill="none" stroke="#000" stroke-width="null" stroke-opacity="null" fill-opacity="null" x1="221.6918" y1="348.02537" x2="222.35847" y2="348.02537" id="svg_19" transform="rotate(0.9628710746765137 222.02513122558057,348.0253906249988) "/> <line stroke="#000" stroke-linecap="square" id="svg_8" y2="261.50152" x2="462.85834" y1="261.50152" x1="125.8955" fill-opacity="null" stroke-opacity="null" fill="none"/> <line stroke="#000" stroke-linecap="square" id="svg_13" y2="328.33922" x2="331.2413" y1="261.98921" x1="331.2413" fill-opacity="null" stroke-opacity="null" fill="none"/> <line stroke="#000" stroke-linecap="square" id="svg_17" y2="327.36391" x2="222.00652" y1="261.50155" x1="222.00652" fill-opacity="null" stroke-opacity="null" fill="none"/> </g> </svg> </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 Replace the diagram in with a SVG-format vector equivalent. Consider switching from rows to columns - that will fit better into the available white space. Why is this needed There is an ASCII-art diagram in the page at This gets the point across but looks a bit unpolished, and readers might think that the feature is also not finished. Comments /kind cleanup /language en /priority backlog
! How about like this ? color also can talk about :)
I like that look. I would use the Kubernetes blue and gray colors - maybe blue for pods, gray for kube-reserved and system-reserved, no color (or white) for eviction-threshold.
all right. /assign


Question: --- <del> title: Intro to Windows support in Kubernetes </del> <ins> title: KubernetesのWindowsサポート概要 </ins> content_type: concept weight: 65 --- <!-- overview --> <del> Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the defacto standard container orchestrator, and the release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system. </del> <ins> Windowsアプリケーションは、多くの組織で実行されているサービスやアプリケーションの大部分を占めています。[Windowsコンテナ](https://aka.ms/windowscontainers)は、プロセスとパッケージの依存関係を一つにまとめる最新の方法を提供し、DevOpsプラクティスの使用とWindowsアプリケーションのクラウドネイティブパターンの追求を容易にします。Kubernetesは事実上、標準的なコンテナオーケストレータになりました。Kubernetes 1.14のリリースでは、Kubernetesクラスター内のWindowsノードでWindowsコンテナをスケジューリングする本番環境サポートが含まれたので、Windowsアプリケーションの広大なエコシステムにおいて、Kubernetesを有効的に活用できます。WindowsベースのアプリケーションとLinuxベースのアプリケーションに投資している組織は、ワークロードを管理する個別のオーケストレーターが不要となるため、オペレーティングシステムに関係なく導入全体の運用効率が向上します。 </ins> <!-- body --> <del> ## Windows containers in Kubernetes </del> <ins> ## KubernetesのWindowsコンテナ </ins> <del> To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers. </del> <ins> KubernetesでWindowsコンテナのオーケストレーションを有効にするには、既存のLinuxクラスターにWindowsノードを含めるだけです。Kubernetesの[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)でWindowsコンテナをスケジュールすることは、Linuxベースのコンテナをスケジュールするのと同じくらいシンプルで簡単です。 </ins> <del> In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). </del> <ins> Windowsコンテナを実行するには、Kubernetesクラスターに複数のオペレーティングシステムを含める必要があります。コントロールプレーンノードはLinux、ワーカーノードはワークロードのニーズに応じてWindowsまたはLinuxで実行します。Windows Server 2019は、サポートされている唯一のWindowsオペレーティングシステムであり、Windows（kubelet、[コンテナランタイム](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd)、kube-proxyを含む）で[Kubernetesノード](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)を有効にします。Windowsディストリビューションチャンネルの詳細については、[Microsoftのドキュメント](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19)を参照してください。 </ins> {{< note >}} <del> The Kubernetes control plane, including the [master components](/ja/docs/concepts/overview/components/), continues to run on Linux. There are no plans to have a Windows-only Kubernetes cluster. </del> <ins> [マスターコンポーネント](/ja/docs/concepts/overview/components/)を含むKubernetesコントロールプレーンは、Linuxで実行し続けます。WindowsのみのKubernetesクラスターを導入する計画はありません。 </ins> {{< /note >}} {{< note >}} <del> In this document, when we talk about Windows containers we mean Windows containers with process isolation. Windows containers with [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) is planned for a future release. </del> <ins> このドキュメントでは、Windowsコンテナについて説明する場合、プロセス分離のWindowsコンテナを意味します。[Hyper-V分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)のWindowsコンテナは、将来リリースが計画されています。 </ins> {{< /note >}} <del> ## Supported Functionality and Limitations </del> <ins> ## サポートされている機能と制限 </ins> <del> ### Supported Functionality </del> <ins> ### サポートされている機能 </ins> <del> #### Compute </del> <ins> #### コンピュート </ins> <del> From an API and kubectl perspective, Windows containers behave in much the same way as Linux-based containers. However, there are some notable differences in key functionality which are outlined in the limitation section. </del> <ins> APIとkubectlの観点から見ると、WindowsコンテナはLinuxベースのコンテナとほとんど同じように動作します。ただし、制限セクションで概説されている主要な機能には、いくつかの顕著な違いがあります。 </ins> <del> Let's start with the operating system version. Refer to the following table for Windows operating system support in Kubernetes. A single heterogeneous Kubernetes cluster can have both Windows and Linux worker nodes. Windows containers have to be scheduled on Windows nodes and Linux containers on Linux nodes. </del> <ins> オペレーティングシステムのバージョンから始めましょう。KubernetesのWindowsオペレーティングシステムのサポートについては、次の表を参照してください。単一の異種Kubernetesクラスターは、WindowsとLinuxの両方のワーカーノードを持つことができます。WindowsコンテナはWindowsノードで、LinuxコンテナはLinuxノードでスケジュールする必要があります。 </ins> <del> | Kubernetes version | Host OS version (Kubernetes Node) | | | </del> <ins> | Kubernetes バージョン | ホストOS バージョン (Kubernetes ノード) | | | </ins> | --- | --- | --- | --- | | | *Windows Server 1709* | *Windows Server 1803* | *Windows Server 1809/Windows Server 2019* | <del> | *Kubernetes v1.14* | Not Supported | Not Supported| Supported for Windows Server containers Builds 17763.* with Docker EE-basic 18.09 | </del> <ins> | *Kubernetes v1.14* | サポートされていません | サポートされていません| Windows Server containers Builds 17763.* と Docker EE-basic 18.09 がサポートされています | </ins> {{< note >}} <del> We don't expect all Windows customers to update the operating system for their apps frequently. Upgrading your applications is what dictates and necessitates upgrading or introducing new nodes to the cluster. For the customers that chose to upgrade their operating system for containers running on Kubernetes, we will offer guidance and step-by-step instructions when we add support for a new operating system version. This guidance will include recommended upgrade procedures for upgrading user applications together with cluster nodes. Windows nodes adhere to Kubernetes [version-skew policy](/ja/docs/setup/release/version-skew-policy/) (node to control plane versioning) the same way as Linux nodes do today. </del> <ins> すべてのWindowsユーザーがアプリのオペレーティングシステムを頻繁に更新することは望んでいません。アプリケーションのアップグレードは、クラスターに新しいノードをアップグレードまたは導入することを要求する必要があります。Kubernetesで実行されているコンテナのオペレーティングシステムをアップグレードすることを選択したお客様には、新しいオペレーティングシステムバージョンのサポート追加時に、ガイダンスと段階的な指示を提供します。このガイダンスには、クラスターノードと共にアプリケーションをアップグレードするための推奨アップグレード手順が含まれます。Windowsノードは、現在のLinuxノードと同じように、Kubernetes[バージョンスキューポリシー](/ja/docs/setup/release/version-skew-policy/)（ノードからコントロールプレーンのバージョン管理）に準拠しています。 </ins> {{< /note >}} {{< note >}} <del> The Windows Server Host Operating System is subject to the [Windows Server ](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) licensing. The Windows Container images are subject to the [Supplemental License Terms for Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula). </del> <ins> Windows Serverホストオペレーティングシステムには、[Windows Server](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)ライセンスが適用されます。Windowsコンテナイメージには、[Windowsコンテナの追加ライセンス条項](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)ライセンスが提供されます。 </ins> {{< /note >}} {{< note >}} <del> Windows containers with process isolation have strict compatibility rules, [where the host OS version must match the container base image OS version](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility). Once we support Windows containers with Hyper-V isolation in Kubernetes, the limitation and compatibility rules will change. </del> <ins> プロセス分離のWindowsコンテナには、厳格な互換性ルールがあります[ホストOSのバージョンはコンテナのベースイメージのOSバージョンと一致する必要があります](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility)。KubernetesでHyper-V分離のWindowsコンテナをサポートすると、制限と互換性ルールが変更されます。 </ins> {{< /note >}} <del> Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows. </del> <ins> Kubernetesの主要な要素は、WindowsでもLinuxと同じように機能します。このセクションでは、主要なワークロードイネーブラーのいくつかと、それらがWindowsにどのようにマップされるかについて説明します。 </ins> * [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) <del> A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers: </del> <ins> Podは、Kubernetesの基本的なビルディングブロックです。作成またはデプロイするKubernetesオブジェクトモデルの最小かつ最も単純なユニットです。WindowsとLinuxのコンテナを同じPodにデプロイすることはできません。Pod内のすべてのコンテナは、各ノードが特定のプラットフォームとアーキテクチャを表す単一のノードにスケジュールされます。次のPod機能、プロパティ、およびイベントがWindowsコンテナでサポートされています。: </ins> <del> * Single or multiple containers per Pod with process isolation and volume sharing * Pod status fields * Readiness and Liveness probes * postStart & preStop container lifecycle events * ConfigMap, Secrets: as environment variables or volumes </del> <ins> * プロセス分離とボリューム共有を備えたPodごとの単一または複数のコンテナ * Podステータスフィールド * ReadinessとLiveness Probe * postStartとpreStopコンテナのライフサイクルイベント * ConfigMap, Secrets: 環境変数またはボリュームとして </ins> * EmptyDir <del> * Named pipe host mounts * Resource limits </del> <ins> * 名前付きパイプホストマウント * リソース制限 </ins> * [Controllers](/ja/docs/concepts/workloads/controllers/) <del> Kubernetes controllers handle the desired state of Pods. The following workload controllers are supported with Windows containers: </del> <ins> Kubernetesコントローラは、Podの望ましい状態を処理します。次のワークロードコントローラーは、Windowsコンテナでサポートされています。: </ins> * ReplicaSet * ReplicationController

This is a Feature Request What would you like to be Translate docs/setup/production-environment/windows/intro-windows-in-kubernetes/ into Japanese Why is this needed This page has not been translated. Comments /language ja /assign
/close
Closing this issue. <detailsIn response to : /close 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:
 {{ with site.Home.OutputFormats.Get "rss" -}} <link rel="{{ .Rel }}" type="{{ .MediaType.Type }}" href="{{ .Permalink | safeURL }}" title="{{ site.Title }}">
   RSS Feed

   RSS Feed
   {{ end -}}
  Submit a Post

    @Kubernetesio

   on GitHub

  #kubernetes-users

  Overflow

  Forum

  Submit a Post

    @Kubernetesio

   on GitHub

  #kubernetes-users

  Overflow

  Forum

  Kubernetes

I have noticed that the blog meta links (e.g. the twitter link) on sidebar of blog pages are opening in the same tab, while on other sections of the website, they are opening in a new tab. What I would like to be updated- I would like to change the target attribute of the links in the blog section to "_blank" to make them open in a new tab when clicked. This helps improve the user experience by keeping the user on the current page while still allowing them to access the linked content. Impacted page Thanks!
I'm not sure opening each and every blog in a new tab or window is the right choice for everyone.
hi, it is only opening the sidebar links.
/triage accepted
/area web-development


Question: The following examples show some `crictl` commands and example output. <del> {{< warning >}} If you use `crictl` to create pod sandboxes or containers on a running Kubernetes cluster, the Kubelet will eventually delete them. `crictl` is not a general purpose workflow tool, but a tool that is useful for debugging. {{< /warning >}} </del> ### List pods List all pods:

This page is outdated according to the comment of this ticket, because if you follow the instructions, you always get an error like the one below in any worker node when you execute: where is:{ "metadata": { "name": "nginx-sandbox", "namespace": "default", "attempt": 1, "uid": "hdishd83djaidwnduwk28bcsb" }, "linux": { } } E0107 22:25:16. ] "RunPodSandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to setup network for sandbox "888e1ca106ad4e8439154c056cbf6d926b1417c43aba37f8a5052a916e5f8516": plugin type="calico" failed (add): pods "nginx-sandbox" not found" FATA[0000] run pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "888e1ca106ad4e8439154c056cbf6d926b1417c43aba37f8a5052a916e5f8516": plugin type="calico" failed (add): pods "nginx-sandbox" not found` and seemingly it is due to "calico daemonset watch apiserver to get a list of pods, and apply network configuration based on the pod spec." So, the page may be deleted or the list of sections below removed:
Page reported in issue: /language en
/retitle “Debugging Kubernetes nodes with crictl” is outdated
/sig node
/triage accepted
Funny, one of the reviewers of the doc, is the same person, that posted the note in the containerd issue, In fact, we don't recommend user to run and on a Kubernetes node , those commands are there just for some special debug case.
As per my investigation, all example commands work fine in the except for the mentioned sections. As per the referenced issue, I think it should be safe to delete the specific sections instead of a whole page. The documentation also has a warning message under section which refers to the sections that need to be deleted. So, if these sections are to be deleted then the warning message should be deleted as well.
still has the same example as included in . So it can very well be a bug.


Question: The following examples show some `crictl` commands and example output. <del> {{< warning >}} If you use `crictl` to create pod sandboxes or containers on a running Kubernetes cluster, the Kubelet will eventually delete them. `crictl` is not a general purpose workflow tool, but a tool that is useful for debugging. {{< /warning >}} </del> ### List pods List all pods:

/cc Would it be okay to delete these sections in the documentation? If so I would like to raise a PR for the same.
thank you! Please propose a PR with the changes. We may also link to the official docs.
/assign


Question: ### SSH tunnels <del> Kubernetes supports SSH tunnels to protect the control plane to nodes communication paths. In this </del> <ins> Kubernetes supports [SSH tunnels](https://www.ssh.com/academy/ssh/tunneling) to protect the control plane to nodes communication paths. In this </ins> configuration, the API server initiates an SSH tunnel to each node in the cluster (connecting to the SSH server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or service through the tunnel.


Question: ### cgroupfs driver {#cgroupfs-cgroup-driver} <del> The `cgroupfs` driver is the default cgroup driver in the kubelet. When the `cgroupfs` driver is used, the kubelet and the container runtime directly interface with the cgroup filesystem to configure cgroups. </del> <ins> The `cgroupfs` driver is the [default cgroup driver in the kubelet](docs/reference/config-api/kubelet-config.v1beta1). When the `cgroupfs` driver is used, the kubelet and the container runtime directly interface with the cgroup filesystem to configure cgroups. </ins> The `cgroupfs` driver is **not** recommended when [systemd](https://www.freedesktop.org/wiki/Software/systemd/) is the init system because systemd expects a single cgroup manager on <del> the system. Additionally, if you use [cgroup v2](/docs/concepts/architecture/cgroups) , use the `systemd` cgroup driver instead of `cgroupfs`. </del> <ins> the system. Additionally, if you use [cgroup v2](/docs/concepts/architecture/cgroups), use the `systemd` cgroup driver instead of `cgroupfs`. </ins> ### systemd cgroup driver {#systemd-cgroup-driver}

This section: I would add information like here: Note: In v1.22, if the user is not setting the cgroupDriver field under KubeletConfiguration, kubeadm will default it to systemd.
this section: already links to: PRs welcome with proposed improvements. /help /sig cluster-lifecycle
If someone wants to help here, I'm not sure what steps they should follow to assist. Because of that: /remove-help
/language en
I think the suggestion is to add something about to container-runtimes pages but I don't think that fits well on that page because it only covers the container runtime side. What could be though is that there's a note/reminder to ensure they are always the same. I can work on that if we agree what's what we want here.
hmm, looks like this is already covered too.
some additional feedback in
/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]:
/assign


Question: - [`kubectl`を使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を学ぶ - [config fileを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を学ぶ - [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を学ぶ <ins> - [SecretのAPIリファレンス](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)を読む </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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --About Some corrections need to be made. Why is this needed JSON in .dockerconfigjson dump is strange. Lack of options for kubectl command. And some more correction is needed. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja
/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]:
/remove-lifecycle rotten because the related PR is under reviewing /triage accepted


Question: Example: `node.kubernetes.io/out-of-service:NoExecute` <del> A user can manually add the taint to a Node marking it out-of-service. If the `NodeOutOfServiceVolumeDetach` </del> <ins> A user can manually add the taint to a Node marking it out-of-service. If the `NodeOutOfServiceVolumeDetach` </ins> [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled on <del> `kube-controller-manager`, and a Node is marked out-of-service with this taint, the pods on the node will be forcefully deleted if there are no matching tolerations on it and volume detach operations for the pods terminating on the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly on a different node. </del> <ins> `kube-controller-manager`, and a Node is marked out-of-service with this taint, the pods on the node will be forcefully deleted if there are no matching tolerations on it and volume detach operations for the pods terminating on the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly on a different node. </ins> {{< caution >}} Refer to

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: I have a node in Minikube that's labelled with the key . This looks intended, but doesn't document that label. Proposed Solution: Document that label; as a side effect, this registers it. I can guess what this label does but I don't actually know. If you pick this issue up, part of your task is to find out that detail. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig node /language en /priority backlog PS. If this label isn't supposed to be used any more, we should also mark it as deprecated.
/triage accepted
/assign


Question: title: Upgrading Windows nodes min-kubernetes-server-version: 1.17 content_type: task <del> weight: 50 </del> <ins> weight: 110 </ins> --- <!-- overview -->

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 page titled “Upgrading Linux Nodes” Why is this needed We have an for Windows. Someone who runs Linux worker nodes may well want to see a page just like that, but explaining what to do for their Linux-based node OS. It is OK to adapt existing pages and to link to them. Comments /sig cluster-lifecycle /priority backlog /language en
Hi there is a section on in the , which has the content for upgrading Linux worker nodes. I wonder do you want a separate document for it?
Yes. This issue is a request for a document just like but with Linux in the title. It is OK to adapt existing pages and to link to them.
right, i can recall the section only says: From the Windows node, upgrade kubeadm: and no addition for another os. This will be helpful. are you working on it?
Thanks, for the information!
Hi thanks for your comments. Yeah, I am working on it. I will soon open a PR for it.
/assign
/triage accepted
I have raised a PR: Please take a look!


Question: Internet to download the necessary files, while worker nodes do not. 3. These guide is tested OK on Ubuntu 14.04 LTS 64bit server, but it can not work with Ubuntu 15 which uses systemd instead of upstart. <del> 4. Dependencies of this guide: etcd-2.2.1, flannel-0.5.5, k8s-1.1.4, may work with higher versions. </del> <ins> 4. Dependencies of this guide: etcd-2.2.1, flannel-0.5.5, k8s-1.1.8, may work with higher versions. </ins> 5. All the remote servers can be ssh logged in without a password by using key authentication.

The script actually defaults to k8s version 1.1.8, but the docs says it is 1.1.4
Thank you for the PR, Mike!


Question: can find each other via `localhost`. They can also communicate with each other using standard inter-process communications like SystemV semaphores or POSIX shared memory.  Containers in different pods have distinct IP addresses <del> and can not communicate by IPC. </del> <ins> and can not communicate by IPC without [special configuration](/docs/concepts/policy/pod-security-policy/). These containers usually communicate with each other via Pod IP addresses. </ins> Applications within a pod also have access to shared volumes, which are defined as part of a pod and are made available to be mounted into each application's

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [x] Feature Request [ ] Bug Report Problem: In the 4th paragraph in the "What is a Pod?" section, there is a sentence: "Containers in different pods have distinct IP addresses and can not communicate by IPC." The paragraph seems to imply that different pods communicate via IP. But it is not clarified. Proposed Solution: Please clarify how different pods communicate since they cannot use IPC. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /assign


Question: ## Node Allocatable <del> ```text Node Capacity --------------------------- |     kube-reserved       | |-------------------------| |     system-reserved     | |-------------------------| |    eviction-threshold   | |-------------------------| |                         | |      allocatable        | |   (available for pods)  | |                         | |                         | --------------------------- ``` </del> <ins> ![node capacity](/images/docs/node-capacity.svg) </ins> `Allocatable` on a Kubernetes node is defined as the amount of compute resources that are available for pods. The scheduler does not over-subscribe