Question: other = " प्रलेखन अब सक्रिय रूप से मेंटेन नहीं है। वर्तमान में आप जो संस्करण देख रहे हैं वह एक स्टैटिक स्नैपशॉट है। अप-टू-डेट प्रलेखन के लिए, देखें " [deprecation_file_warning]  other = "डेप्रिकॉटेड"   other = "डेप्रिकेटेड" [dockershim_message] other = """1.24 संस्करण के बाद से Dockershim को कुबेरनेट्स परियोजना से हटा दिया गया हैं। अधिक जानकारी के लिए Dockershim रिमूवल एफएक्यू पढ़ें।"""  [docs_label_browse] other = "प्रलेखन ब्राउज़ करें"

Updated with new strings from Didn't remove any strings from , even if they're missing from
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
/language hi
Completed.


Question:
 <svg aria-roledescription="stateDiagram" viewBox="0 0 410.99609375 474" style="max-width: 100%;" class="statediagram" xmlns="http://www.w3.org/2000/svg" width="871px" id="graph-div" height="730px" xmlns:xlink="http://www.w3.org/1999/xlink"><g><defs><marker orient="auto" markerUnits="strokeWidth" markerHeight="14" markerWidth="20" refY="7" refX="19" id="statediagram-barbEnd"><path d="M 19,7 L9,13 L14,7 L9,1 Z"></path></marker></defs><g class="root"><g class="clusters"></g><g class="edgePaths"><path marker-end="url(#statediagram-barbEnd)" style="fill:none" class="edge-thickness-normal transition" id="edge182" d="M150.61328125,22L150.61328125,26.166666666666668C150.61328125,30.333333333333332,150.61328125,38.666666666666664,150.61328125,47C150.61328125,55.333333333333336,150.61328125,63.666666666666664,150.61328125,67.83333333333333L150.61328125,72"></path><path marker-end="url(#statediagram-barbEnd)" style="fill:none" class="edge-thickness-normal transition" id="edge183" d="M150.61328125,111L150.61328125,115.16666666666667C150.61328125,119.33333333333333,150.61328125,127.66666666666667,150.61328125,136C150.61328125,144.33333333333334,150.61328125,152.66666666666666,150.61328125,156.83333333333334L150.61328125,161"></path><path marker-end="url(#statediagram-barbEnd)" style="fill:none" class="edge-thickness-normal transition" id="edge184" d="M111.91983545353982,274L118.36874308628319,267.8333333333333C124.81765071902653,261.6666666666667,137.71546598451326,249.33333333333334,144.16437361725664,237C150.61328125,224.66666666666666,150.61328125,212.33333333333334,150.61328125,206.16666666666666L150.61328125,200"></path><path marker-end="url(#statediagram-barbEnd)" style="fill:none" class="edge-thickness-normal transition" id="edge185" d="M109.82829784292036,200L96.93048257743364,206.16666666666666C84.03266731194691,212.33333333333334,58.237036780973455,224.66666666666666,51.78812914823009,237C45.339221515486734,249.33333333333334,58.237036780973455,261.6666666666667,64.68594441371683,267.8333333333333L71.13485204646018,274"></path><path marker-end="url(#statediagram-barbEnd)" style="fill:none" class="edge-thickness-normal transition" id="edge186" d="M208.9366703539823,200L227.38081904498526,206.16666666666666C245.82496773598822,212.33333333333334,282.7132651179941,224.66666666666666,301.15741380899703,237C319.6015625,249.33333333333334,319.6015625,261.6666666666667,319.6015625,267.8333333333333L319.6015625,274"></path><path marker-end="url(#statediagram-barbEnd)" style="fill:none" class="edge-thickness-normal transition" id="edge187" d="M319.6015625,313L319.6015625,317.1666666666667C319.6015625,321.3333333333333,319.6015625,329.6666666666667,319.6015625,338C319.6015625,346.3333333333333,319.6015625,354.6666666666667,319.6015625,358.8333333333333L319.6015625,363"></path><path marker-end="url(#statediagram-barbEnd)" style="fill:none" class="edge-thickness-normal transition" id="edge188" d="M319.6015625,402L319.6015625,406.1666666666667C319.6015625,410.3333333333333,319.6015625,418.6666666666667,319.6015625,427C319.6015625,435.3333333333333,319.6015625,443.6666666666667,319.6015625,447.8333333333333L319.6015625,452"></path></g><g class="edgeLabels"><g class="edgeLabel"><g transform="translate(0, 0)" class="label"><rect height="0" width="0" ry="0" rx="0"></rect><foreignObject height="0" width="0">

</foreignObject></g></g><g class="edgeLabel"><g transform="translate(0, 0)" class="label"><rect height="0" width="0" ry="0" rx="0"></rect><foreignObject height="0" width="0">

</foreignObject></g></g><g transform="translate(150.61328125, 237)" class="edgeLabel"><g transform="translate(-89.5078125, -12)" class="label"><rect height="24" width="179.015625" ry="0" rx="0"></rect><foreignObject height="24" width="179.015625">
scheduling gate removed
</foreignObject></g></g><g transform="translate(32.44140625, 237)" class="edgeLabel"><g transform="translate(-8.6640625, -12)" class="label"><rect height="24" width="17.328125" ry="0" rx="0"></rect><foreignObject height="24" width="17.328125">
no
</foreignObject></g></g><g transform="translate(319.6015625, 237)" class="edgeLabel"><g transform="translate(-11.546875, -12)" class="label"><rect height="24" width="23.09375" ry="0" rx="0"></rect><foreignObject height="24" width="23.09375">
yes
</foreignObject></g></g><g class="edgeLabel"><g transform="translate(0, 0)" class="label"><rect height="0" width="0" ry="0" rx="0"></rect><foreignObject height="0" width="0">

</foreignObject></g></g><g class="edgeLabel"><g transform="translate(0, 0)" class="label"><rect height="0" width="0" ry="0" rx="0"></rect><foreignObject height="0" width="0">

</foreignObject></g></g></g><g class="nodes"><g transform="translate(150.61328125, 91.5)" id="state-s1-183" class="node k8s statediagram-state"><rect height="39" width="101.4921875" y="-19.5" x="-50.74609375" style="" class="basic label-container"></rect><g transform="translate(-43.24609375, -12)" style="" class="label"><foreignObject height="24" width="86.4921875">
pod created
</foreignObject></g></g><g transform="translate(91.52734375, 293.5)" id="state-s2-185" class="node k8s statediagram-state"><rect height="39" width="167.0546875" y="-19.5" x="-83.52734375" style="" class="basic label-container"></rect><g transform="translate(-76.02734375, -12)" style="" class="label"><foreignObject height="24" width="152.0546875">
pod scheduling gated
</foreignObject></g></g><g transform="translate(319.6015625, 293.5)" id="state-s3-187" class="node k8s statediagram-state"><rect height="39" width="166.7890625" y="-19.5" x="-83.39453125" style="" class="basic label-container"></rect><g transform="translate(-75.89453125, -12)" style="" class="label"><foreignObject height="24" width="151.7890625">
pod scheduling ready
</foreignObject></g></g><g transform="translate(319.6015625, 382.5)" id="state-s4-188" class="node k8s statediagram-state"><rect height="39" width="100.015625" y="-19.5" x="-50.0078125" style="" class="basic label-container"></rect><g transform="translate(-42.5078125, -12)" style="" class="label"><foreignObject height="24" width="85.015625">
pod running
</foreignObject></g></g><g transform="translate(150.61328125, 180.5)" id="state-if-186" class="node k8s statediagram-state"><rect height="39" width="189.234375" y="-19.5" x="-94.6171875" style="" class="basic label-container"></rect><g transform="translate(-87.1171875, -12)" style="" class="label"><foreignObject height="24" width="174.234375">
empty scheduling gates?
</foreignObject></g></g><g transform="translate(150.61328125, 15)" id="state-root_start-182" class="node default"><circle height="14" width="14" r="7" class="state-start"></circle></g><g transform="translate(319.6015625, 459)" id="state-root_end-188" class="node default"><circle height="14" width="14" r="7" class="state-start"></circle><circle height="10" width="10" r="5" class="state-end"></circle></g></g></g></g></svg>   No newline at end of file

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: has a diagram, but it doesn't use Kubernetes colors. Proposed Solution: Copy the colors from an example in and then apply those colors to the items in the diagram. Page to Update: /priority backlog
/triage accepted
/assign


Question: I componenti del Control Plane sono responsabili di tutte le decisioni globali sul cluster (ad esempio, lo scheduling) oltre che a rilevare e rispondere agli eventi del cluster (ad esempio, l'avvio di un nuovo {{< glossary_tooltip text="pod" term_id="pod">}} quando il valore `replicas` di un deployment non è soddisfatto). I componenti della Control Plane possono essere eseguiti su qualsiasi nodo del cluster stesso. Solitamente, per semplicità, gli script di installazione tendono a eseguire tutti i componenti della Control Plane sulla stessa macchina, separando la Control Plane dai workload dell'utente. <del> Vedi [creare un cluster in High-Availability](/docs/admin/high-availability/) per un esempio di un'installazione multi-master. </del> <ins> Vedi [creare un cluster in High-Availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) per un esempio di un'installazione multi-master. </ins> ### kube-apiserver

From the link to is broken
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
Page related to issue: /language it
/retitle [it] Broken link for "Create a cluster in High-Availability" in Kubernetes Components page /kind bug
/assign
can i contribute to this
The link is broken in every component !
/assign


Question: | Driver | OS | HostFolder | VM | | --- | --- | --- | --- | <del> | VirtualBox | Linux | /home | /hosthome | | VirtualBox | macOS | /Users | /Users | | VirtualBox | Windows | C://Users | /c/Users | | VMware Fusion | macOS | /Users | /mnt/hgfs/Users | | Xhyve | macOS | /Users | /Users | </del> <ins> | VirtualBox | Linux | `/home` | `/hosthome` | | VirtualBox | macOS | `/Users` | `/Users` | | VirtualBox | Windows | `C://Users` | `/c/Users` | | VMware Fusion | macOS | `/Users` | `/mnt/hgfs/Users` | | Xhyve | macOS | `/Users` | `/Users` | </ins> ## Private Container Registries

This is an enhancement 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 I'd like to use monospace () text for the paths in the two rightmost columns in the table: HostFolder VM Why is this needed Improved styling. It's a minor thing that's nice to have. Comments /kind cleanup /language en
/assign
If anyone would like to work on this, please feel free to open a pull request.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /remove-lifecycle rotten /good-first-issue 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
Hey I would like to work on this.
Anyone who'd like to open a PR that addresses this issue is welcome to. Dive in!
I am working on this, will submit a PR shortly.


Question: --- title: Opening a pull request <del> slug: new-content </del> content_type: concept weight: 10 card:

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: is returning 404 Proposed Solution: The correct link is at but that still seems kinda wrong just from what the path looks like. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue Seems like straight forward fix to adjust the link 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: If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions. <del> <img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080"> </del> <!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit --> <ins> ![Flowchart for Extension](/docs/concepts/extend-kubernetes/flowchart.png) </ins> ## API Extensions ### User-Defined Types Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`.

Images which are located in are blocked by enterprise firewall, any plan to move the images to other places such as
Hi Can you identify the images that are blocked? For example, mention the URL of the documentation page that uses those images.
This page, , all images are blocked, such as
This will affect all users behind a state-level censoring filter that blocks Google Docs. /kind cleanup /triage accepted /language en
/assign


Question:
other = "báo cáo một vấn đề" [layouts_docs_partials_feedback_thanks]  other = "Cảm ơn vì đã phản hồi. Nếu bạn có một câu hỏi cụ thể, có thể trả lời về cách sử dụng Kubernetes, hãy hỏi nó trên"   other = "Cảm ơn bạn đã phản hồi. Nếu bạn có một câu hỏi cụ thể và có thể trả lời về cách sử dụng Kubernetes, hãy đặt nó trên"  [layouts_docs_search_fetching]  other = "Đang lấy kết quả..."   other = "Đang tìm kết quả..." [legacy_repos_message] other = """Các kho lưu trữ gói cũ (`apt.kubernetes.io` và `yum.kubernetes.io`) đã bị [lạc thú và đóng băng từ ngày 13 tháng 9, 2023](/blog/2023/08/31/legacy-package-repository-deprecation/). **Sử dụng [các kho lưu trữ mới được đặt tại `pkgs.k8s.io`](/blog/2023/08/15/pkgs-k8s-io-introduction/) được khuyến nghị mạnh mẽ và yêu cầu để cài đặt các phiên bản Kubernetes phát hành sau ngày 13 tháng 9, 2023.** Các kho cũ đã lạc thú, và nội dung của chúng, có thể bị xóa bất kỳ lúc nào trong tương lai và mà không có thêm thông báo. Các kho lưu trữ mới cung cấp tải về cho các phiên bản Kubernetes bắt đầu từ v1.24.0."""  [main_by] other = "bởi" [main_cncf_project]  other = """Chúng tôi là một dự án CNCF
"""   other = """Chúng tôi là một dự án tốt nghiệp từ CNCF
"""  [main_community_explore] other = "Khám phá cộng đồng"

Đề nghị thay thế "lạc thú" bằng "lỗi thời" !
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
Please raise the issue in english putting the language code before the issue in [] example [vi] Issue title here It will be good practice to write the description and title of the issue in English only.
Thank you! BTW i'd commited about this change, waiting for review.
Fixed in


Question: To bootstrap initial roles and role bindings: * Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings. <del> * If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization. </del> ## Command-line utilities

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: states: However, there is no such option in current Kubernetes. At least, I couldn't see it. As far as I can tell, the mechanisms that would work are: to perform the bootstrap when authenticated as a member of . Because this is an API server restriction, you can't configure an extra authorizer during initial bootstrap (such as a webhook authorizer). However, once any principal is bound to a ClusterRole that is allowed to escalate, it's all good and further bootstrapping can take place as that cluster role. Proposed Solution: Remove that item from the page. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /sig auth
/assign
/triage accepted
I see that you haven't worked on this for long, so I stepped up and did this. Thank you for your interest /assign
/unassign


Question:
<button id="desktopShowVideoButton" onclick="kub.showVideo()">वीडियो देखें</button>

  अक्टूबर 11-15, 2021 को KubeCon North America में भाग लें   अप्रैल 18-21, 2023 KubeCon + CloudNativeCon Europe में भाग लें

  मई 17-20, 2022 को KubeCon Europe में भाग लें   6-9 नवंबर, 2023 को KubeCon + CloudNativeCon North America में भाग लें

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. --Update the page to reflect the latest KubeCon dates for 2023. The KubeCon dates for 2023 are outdated on this page as compared to the English version. Page Address: File path in repository: Why is this needed To keep the dates in Hindi sync with the ones in the English version. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --Go to the file path in the repository and do the following changes: On line 46On line 51: /language hi /good-first-issue /help
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --<!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Update the page to reflect the latest KubeCon dates for 2023. The KubeCon dates for 2023 are outdated on this page as compared to the English version. File path in repository: To keep the dates in Hindi sync with the ones in the English version. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required).

--Go to the file path in the repository and do the following changes: /good-first-issue /help </details
/triage accepted
/assign
/assign
/priority backlog
Hey May I know whether this issue still needs to be fixed and is open?
A for this issue has been raised already.
hi for some reason i cant find an html index file in the path content/hi . there are _index files in the common resources and the docs files but they dont have much to edit. I would be really grateful if you could kindly help me out.
/assign
/assign
PTAL at
hi, is this issue assigned to anyone currently? I volunteer to fix this
Hi Sagar, i have already made pr for this issue.
sorry for the mess, Contributing for the first time. I was wondering why isn't this issue closed.
Thanks for showing interest! You can browse through other issues and start working on one you find of your type.
/unassign
/assign


Question: ``` Serviços possuem endereço IP dedicado e são disponibilizados para o contêiner via DNS, <del> se possuírem [DNS addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/) habilitado. </del> <ins> se possuírem [DNS addon](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/cluster/addons/dns/) habilitado. </ins>

Parent issue: Replace the deprecated shortcode with the shortcode in the Brazilian Portuguese localized docs. /assign /triage accepted /language pt


Question:
for kube-proxy official documentation.

apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration   	...    ...

The KubeletConfiguration type should be used to change the configurations that will be passed to all kubelet instances deployed in the cluster. If this object is not provided or provided only partially, kubeadm applies defaults.

See https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ or

The indentation of the example configuration is messy. !
/kind bug /language en page:
Also Consider to remove the exist in the same page under . Note: This page is automatically generated, you are not allowed to directly change the documentation page.
/retitle Messy indentation on kubeadm config reference page
/priority backlog We'd prioritize other improvements over this one. /triage accepted
/assign This is because the Golang source code contains TAB characters instead of SPACEs as a convention, and those TABs are messing up the YAML snippet. I'll work on this.
PR sent for website. PR sent for the generator.


Question: このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。 <del> すべてのコンポーネントが結び付けられたKubernetesクラスターの図を次に示します。 ![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.svg) </del> <ins> {{< figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetesのコンポーネント" caption="Kubernetesクラスターを構成するコンポーネント" class="diagram-large" >}} </ins> <!-- body -->

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: spec: containers: - name: php-apache <del> image: k8s.gcr.io/hpa-example </del> <ins> image: registry.k8s.io/hpa-example </ins> ports: - containerPort: 80 resources:

If we are using as our custom image, why do the documentation starts by telling the user to build an image from Dockerfile provided and the code?
Page:
/retitle HorizontalPodAutoscaler walkthrough page recommends unnecessary container image build /kind bug /language en /triage accepted Thanks for reporting this.
I could take this up /assign


Question: {{< tabs name="k8s_kubelet_and_kubectl" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} <del> # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version </del> <ins> # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version </ins> apt-mark unhold kubelet kubectl &&  <del> apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 &&  </del> <ins> apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 &&  </ins> apt-mark hold kubelet kubectl - # since apt-get version 1.1 you can also use the following method apt-get update &&  <del> apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 </del> <ins> apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 </ins> {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} <del> # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes </del> <ins> # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes </ins> {{% /tab %}} {{< /tabs >}}

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 page https://v1- explains how to upgrade a Kubernetes cluster created with kubeadm from version 1.20.x to version 1.21.x, and from version 1.21.x to 1.21.y. (Should be from version 1.19.x to version 1.20.x, and from version 1.20.x to 1.20.y.) Proposed Solution: In Replace =- =- ... Page to Update: https://v1- <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/assign
I think we should fix the shortcode to use the documented version, rather than the most recent release. /sig cluster-lifecycle /language en
the intent behind seems to be misleading if is fed at build time pointing at the latest current k8s version. while extending the latestVersion shortcodes i expected to be static and hardcoded per k/website release branch. i can send PRs for this but i'd need to understand more about the "documented" version that you mentioned. i.e. making latestVersion fixed to 1.20 in the 1.20 release branch seems reasonable to me.
^ for additional opinions.
Despite a misleading name, is supposed to use not . AIUI.
i can see is being used in a few places: should all of these be modified to use or only the shortcodes in ? and for which branches - and ?
is useful, it does represent the most recent release.
ok, i can PR the change for 1.20, and master since this is only a problem for the kubeadm upgrade docs. is also used here, but the versions there are just examples. https://v1-
here are the PRs:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at .

/lifecycle stale
/remove-lifecycle stale
/triage accepted
/priority-important longterm
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority-important longterm 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
/priority important-longterm


Question: <del> apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 </del> <ins> apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 </ins> kind: Deployment metadata: name: redis-slave

<!-- 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: Deployment yaml file: mysql- api version does not fit 1.9 version: apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 kind: Deployment Proposed Solution: change apiVersion to: apps/v1 Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 9 ! <!--Additional Information:--


Question: ## ラベルの使用 <del> - `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。 </del> <ins> - `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの __セマンティック属性__ を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。 </ins> セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。 <del> オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が_適用_されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。 </del> <ins> オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が _適用_ されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。 </ins> - デバッグ用にラベルを操作できます。Kubernetesコントローラー（ReplicaSetなど）とServiceはセレクターラベルを使用してPodとマッチするため、Podから関連ラベルを削除すると、コントローラーによって考慮されたり、Serviceによってトラフィックを処理されたりすることがなくなります。既存のPodのラベルを削除すると、そのコントローラーはその代わりに新しいPodを作成します。これは、「隔離」環境で以前の「ライブ」Podをデバッグするのに便利な方法です。対話的にラベルを削除または追加するには、[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)を使います。

ref: ! [x] [x] [x] [ ] content/ja/docs/concepts/configuration/manage-resources- [ ] [x] content/ja/docs/concepts/configuration/pod-priority- [x] [x] [ ] content/ja/docs/concepts/containers/runtime- [x] content/ja/docs/concepts/overview/kubernetes- [x] content/ja/docs/concepts/extend-kubernetes/api-extension/custom- [x] content/ja/docs/concepts/overview/working-with- [x] content/ja/docs/concepts/overview/working-with-objects/common- [x] content/ja/docs/concepts/overview/working-with-objects/field- [x] content/ja/docs/concepts/overview/working-with- [x] content/ja/docs/concepts/overview/working-with- [ ] content/ja/docs/concepts/scheduling-eviction/assign-pod- [ ] content/ja/docs/concepts/scheduling-eviction/kube- [x] content/ja/docs/concepts/scheduling-eviction/taint-and- [x] [x] content/ja/docs/concepts/security/pod-security- [x] content/ja/docs/concepts/services- [x] content/ja/docs/concepts/storage/persistent- [x] [x] content/ja/docs/concepts/workloads/controllers/cron- [x] [x] [x] [x] content/ja/docs/concepts/workloads/pods/pod- [x] content/ja/docs/reference/access-authn- [x] content/ja/docs/reference/access-authn- [x] content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster- [x] content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting- [ ] content/ja/docs/tasks/access-application-cluster/web-ui- [x] content/ja/docs/tasks/debug-application-cluster/get-shell-running- [x] content/ja/docs/tasks/run-application/horizontal-pod-autoscale- [x] content/ja/docs/tasks/run-application/run-single-instance-stateful- [x] content/ja/docs/tutorials/stateful-application/basic-stateful- [x] content/ja/docs/tutorials/stateful- (grep) /language ja
/triage accepted
/assign
/kind bug
I'm facing same issue lol :smiley: Feel free to mention me for review if create PRs for this.


Question: ``` {{< note >}} <del> This uses the command line tool [`jq`](https://stedolan.github.io/jq/) to populate the base64-encoded </del> <ins> This uses the command line tool [`jq`](https://jqlang.github.io/jq/) to populate the base64-encoded </ins> content in the `.status.certificate` field. If you do not have `jq`, you can also save the JSON output to a file, populate this field manually, and upload the resulting file.

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 download page for is now (previously ) Proposed Solution: Throughout the English pages, replace the old download URL with the new one. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /priority backlog /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The download page for is now (previously ) Throughout the English pages, replace the old download URL with the new one. <!--Kubernetes Version:--/language en /priority backlog /triage accepted /help </details
I want to help with this. /assign
Hello I would like to work on this issue are you working on the issue?
I have riasd PR to help with this issue.


Question: <ins> --- reviewers: - ptux title: アプリケーションのトラブルシューティング content_type: concept --- <!-- overview --> このガイドは、Kubernetesにデプロイされ、正しく動作しないアプリケーションをユーザーがデバッグするためのものです。 これは、自分のクラスターをデバッグしたい人のためのガイドでは *ありません*。 そのためには、[debug-cluster](/docs/tasks/debug-application-cluster/debug-cluster)を確認する必要があります。 <!-- body --> ## 問題の診断 トラブルシューティングの最初のステップは切り分けです。何が問題なのでしょうか？ Podなのか、レプリケーションコントローラなのか、それともサービスなのか？ * [Debugging Pods](#debugging-pods) * [Debugging Replication Controllers](#debugging-replication-controllers) * [Debugging Services](#debugging-services) ### Podのデバッグ デバッグの第一歩は、Podを見てみることです。 以下のコマンドで、Podの現在の状態や最近のイベントを確認します。 ```shell kubectl describe pods ${POD_NAME} ``` Pod内のコンテナの状態を見てください。 すべて`Running`ですか？ 最近、再起動がありましたか？ Podの状態に応じてデバッグを続けます。 #### PodがPendingのまま Podが`Pending` で止まっている場合、それはノードにスケジュールできないことを意味します。 一般に、これはある種のリソースが不十分で、スケジューリングできないことが原因です。 上の`kubectl describe ...`コマンドの出力を見てください。 なぜあなたのPodをスケジュールできないのか、スケジューラーからのメッセージがあるはずです。 理由は以下の通りです。 * **リソースが不足しています。** クラスタのCPUまたはメモリーを使い果たした可能性があります。Podを削除するか、リソース要求を調整するか、クラスタに新しいノードを追加する必要があります。詳しくは[Compute Resources document](/docs/concepts/configuration/manage-resources-containers/)を参照してください。 * **あなたが使用しているのは`hostPort`**です。Podを`hostPort`にバインドすると、そのPodがスケジュールできる場所が限定されます。ほとんどの場合、`hostPort`は不要なので、Serviceオブジェクトを使ってPodを公開するようにしてください。もし`hostPort` が必要な場合は、Kubernetes クラスタのノード数だけ Pod をスケジュールすることができます。 #### Podがwaitingのまま Podが `Waiting` 状態で止まっている場合、ワーカーノードにスケジュールされていますが、そのマシン上で実行することはできません。この場合も、`kubectl describe ...` の情報が参考になるはずです。`Waiting`状態のポッドの最も一般的な原因は、イメージの取り出しに失敗することです。 確認すべきことは3つあります。 * イメージの名前が正しいかどうか確認してください。 * イメージをリポジトリにプッシュしましたか？ * あなたのマシンで手動で`docker pull <image>`を実行し、イメージをプルできるかどうか確認してください。 #### Podがクラッシュするなどの不健全な状態 Podがスケジュールされると、[Debug Running Pods](/docs/tasks/debug-application-cluster/debug-running-pod/)で説明されているメソッドがデバッグに利用できるようになります。 #### Podが期待する通りに動きません Podが期待した動作をしない場合、ポッドの記述（ローカルマシンの `mypod.yaml` ファイルなど）に誤りがあり、ポッド作成時にその誤りが黙って無視された可能性があります。Pod記述のセクションのネストが正しくないか、キー名が間違って入力されていることがよくあり、そのため、そのキーは無視されます。たとえば、`command`のスペルを`commnd`と間違えた場合、Podは作成されますが、あなたが意図したコマンドラインは使用されません。 まずPodを削除して、`--validate` オプションを付けて再度作成してみてください。 例えば、`kubectl apply --validate -f mypod.yaml`と実行します。 command`のスペルを`commnd`に間違えると、以下のようなエラーになります。 ```shell I0805 10:43:25.129850   46757 schema.go:126] unknown field: commnd I0805 10:43:25.129973   46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842 pods/mypod ``` <!-- TODO: Now that #11914 is merged, this advice may need to be updated --> 次に確認することは、apiserver上のPodが、作成しようとしたPod（例えば、ローカルマシンのyamlファイル）と一致しているかどうかです。 例えば、`kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml` を実行して、元のポッドの説明である`mypod.yaml`とapiserverから戻ってきた`mypod-on-apiserver.yaml`を手動で比較してみてください。 通常、"apiserver" バージョンには、元のバージョンにはない行がいくつかあります。これは予想されることです。 しかし、もし元のバージョンにある行がapiserverバージョンにない場合、これはあなたのPod specに問題があることを示している可能性があります。 ### レプリケーションコントローラのデバッグ レプリケーションコントローラはかなり単純なものです。 彼らはPodを作ることができるか、できないか、どちらかです。 もしPodを作成できないのであれば、[instructions above](#debugging-pods)を参照して、Podをデバッグしてください。 また、`kubectl describe rc ${CONTROLLER_NAME}`を使用すると、レプリケーションコントローラに関連するイベントをイントロスペクトすることができます。 ### サービスのデバッグ サービスは、ポッドのセット全体でロードバランシングを提供します。 サービスが正しく動作しない原因には、いくつかの一般的な問題があります。 以下の手順は、サービスの問題をデバッグするのに役立つはずです。 まず、サービスのエンドポイントが存在することを確認します。 全てのサービスオブジェクトに対して、apiserverは `endpoints` リソースを利用できるようにします。 このリソースは次のようにして見ることができます。 ```shell kubectl get endpoints ${SERVICE_NAME} ``` エンドポイントがサービスのメンバーとして想定されるPod数と一致していることを確認してください。 例えば、3つのレプリカを持つnginxコンテナ用のサービスであれば、サービスのエンドポイントには3つの異なるIPアドレスが表示されるはずです。 #### サービスにエンドポイントがありません エンドポイントが見つからない場合は、サービスが使用しているラベルを使用してポッドをリストアップしてみてください。 ラベルがあるところにServiceがあると想像してください。 ```yaml ... spec: - selector: name: nginx type: frontend ``` セレクタに一致するPodを一覧表示するには、次のコマンドを使用します。 ```shell kubectl get pods --selector=name=nginx,type=frontend ``` リストがServiceを提供する予定のPodと一致することを確認します。 Podの`containerPort`がServiceの`targetPort`と一致することを確認します。 #### ネットワークトラフィックが転送されません 詳しくは[debugging service](/docs/tasks/debug-application-cluster/debug-service/)を参照してください。 ## {{% heading "whatsnext" %}} 上記のいずれの方法でも問題が解決しない場合は、以下の手順に従ってください。 [Debugging Service document](/docs/tasks/debug-application-cluster/debug-service/)で、`Service` が実行されていること、`Endpoints`があること、`Pods`が実際にサービスを提供していること、DNS が機能していること、IPtablesルールがインストールされていること、kube-proxyが誤作動を起こしていないようなことを確認してください。 トラブルシューティングドキュメント](/docs/tasks/debug-application-cluster/troubleshooting/)に詳細が記載されています。 </ins>

Translate into Japanese. This page has not been translated. /language ja /assign
PR:
/triage accepted


Question: [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. ``` <del> 1.  CNI 제공자 플러그인을 수동으로 업그레이드한다. </del> <ins> -  CNI 제공자 플러그인을 수동으로 업그레이드한다. </ins> CNI(컨테이너 네트워크 인터페이스) 제공자는 자체 업그레이드 지침을 따를 수 있다. [애드온](/docs/concepts/cluster-administration/addons/) 페이지에서

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Broken layout on "kubeadm " ! Proposed Solution: Check and apply upstream changes. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ko
/assign
/unassign This issue already has been assigned to .


Question: {{< /note >}} <del> 2.  Start the Redis command line interface: </del> <ins> 2.  Start the MongoDB command line interface: </ins> ```shell <del> redis-cli -p 7000 </del> <ins> mongosh --port 28015 </ins> ``` <del> 3.  At the Redis command line prompt, enter the `ping` command: </del> <ins> 3.  At the MongoDB command line prompt, enter the `ping` command: </ins> ``` <del> ping </del> <ins> db.runCommand( { ping: 1 } ) </ins> ``` A successful ping request returns: ``` <del> PONG </del> <ins> { ok: 1 } </ins> ``` ### Optionally let _kubectl_ choose the local port {#let-kubectl-choose-local-port}

uses manifests However, these files were removed in . The new example is using mongodb instead of redis, and so, the document needs to be updated overall. The page to update:
/language en
/kind bug /language en /priority backlog /triage accepted /help Thanks
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /kind bug /language en /priority backlog /triage accepted </details
/assign

On Forward a local port to a port on the Pod section this should be
/triage needs-information
Could you please link the page
This page
/triage accepted /kind bug /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /kind bug /help 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-triage needs-information
/assign


Question: Default RBAC policies grant scoped permissions to control-plane components, nodes, and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace <del> (beyond discovery permissions given to all authenticated users). </del> <ins> (beyond the permissions given by [API discovery roles](#discovery-roles)). </ins> While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions. Here are two approaches for managing this transition:

The phrase "beyond discovery permissions given to all authenticated users" in these two sections seems inaccurate. It is quite possible to guess that it references to namely , , , but because of "discovery permissions" phrase it seems to only refer to . It would be better to use different wording, for example: beyond the permissions given by beyond the permissions given by and groups beyond the permissions given by , , cluster roles
/language en /sig docs /kind feature
/retitle Ambiguity in 'beyond discovery permissions' wording in "Using RBAC Authorization" page
/sig auth
/triage accepted A clarification seems reasonable.
/assign
PR working on this issue.


Question: CSI node plugins need to perform various privileged operations like scanning of disk devices and mounting of file systems. These operations <del> differ for each host operating system. For Linux worker nodes, containerized CSI node node plugins are typically deployed as privileged containers. For Windows worker nodes, </del> <ins> differ for each host operating system. For Linux worker nodes, containerized CSI node plugins are typically deployed as privileged containers. For Windows worker nodes, </ins> privileged operations for containerized CSI node plugins is supported using [csi-proxy](https://github.com/kubernetes-csi/csi-proxy), a community-managed, stand-alone binary that needs to be pre-installed on each Windows node.

Declared "CSIMigration" feature gate only exists in . According to "CSIMigration" could be a switchable feature gate, but it looks like it is always on and cannot be switched off, so it it's strange that it's mentioned in the v1.27 documentation. All of this is probably more or less OK, as it's suitable for earlier versions of Kubernetes especially since there are deprecation warnings. But it’s also unclear for which components this feature gate is intended. According to it's intended for . <brIt is not clear for which components "CSIMigrationAzureFile" feature gate is intended. <brIt is not clear which controller manager is meant — cloud controller manager or kube-controller-manager. According to it's intended for . It is not clear for which components "CSIMigrationRBD" feature gate is intended: <brIt is not clear for which components "SizeMemoryBackedVolumes" feature gate is intended. <brThe description of "nodeExpandSecretRef" field does not start with a new line in the list. <brThe double word "node".
/language en
/assign RakshitKumar04
Let's stop mentioning in You can specify feature gates for all Kubernetes components (some might be no-ops). We could document that, but it'd be better to track that change as a separate issue. Let's remove the double use of node Let's fix the formatting for these are useful things to point out. Thank you! If you find more, you can help further by opening one issue per thing that will need fixing.
/triage accepted
If you prefer to track this as separate issue, whether I should do something extra or not?
If you're willing to file a separate issue about that clarification please do.
I created separate issue , so this issue should be closed after solving everything except point 2.
Hey, should I raise a PR That fixes the following typos here? The description of "nodeExpandSecretRef" field does not start with a new line in the list. The double word "node". For Linux worker nodes, containerized CSI node node plugins are typically deployed as privileged containers.
If it leads to a documentation fix, sure. Sorry, but I don't know enough about the workflow adopted here. I just feel it is my duty to help make the documentation better and I do my best.
Hey, Should I raise a PR correcting the documentation?


Question: {% capture overview %} ## Overview <del> Running Kubernetes locally has obvious development advantages, such as lower cost and faster iteration than constantly deploying and tearing down clusters on a public cloud. Ideally a Kubernetes developer can spawn all the instances locally and test code as they commit. This page will show you how to deploy a cluster on a local machine. </del> <ins> Running Kubernetes locally has obvious development advantages, such as lower cost and faster iteration than constantly deploying and tearing down clusters on a public cloud. Ideally, a Kubernetes developer can spawn all necessary nodes inside local containers and test new configurations as they are committed. This page will show you how to deploy a cluster to LXD containers on a local machine. </ins> {% endcapture %} <del> The purpose of using [LXD](https://linuxcontainers.org/lxd/) on a local machine is to emulate the same deployment that a user would use in a cloud or bare metal. Each node is treated as a machine, with the same characteristics as production. </del> <ins> The purpose of using [LXD](https://linuxcontainers.org/lxd/) on a local machine is to emulate the same deployment that a user would use in a cloud or bare metal. Each node is treated as a machine, with the same characteristics as production. Each node is a separate container, which runs Docker containers and `kubectl` inside (see [Cluster Intro](https://kubernetes.io/docs/tutorials/kubernetes-basics/cluster-intro/) for more info). </ins> {% capture prerequisites %} ## Prerequisites

Per today's SIG-Docs meeting, we want to localize the contributor cheatsheet. The actual content in the below link: The translated content would be put into repo as well.
/kind feature
+1
Per-language task issues were created: Chinese: Korean: Japanese: German: Spanish: French: Indonesian: Portuguese: Italian: Hindi: /cc
/cc
Wonderful, thank you so much! o/
+1
+1
How is localization managed inside the community repository? It is not a hugo website so I am not sure about how the different languages are managed there.
For this specifically it would probably be best to mimic the format used in the root of the website repo. Within the contributor-cheatsheet directory add a . We can then update the welcome message bot to include links to the translated copies
Thanks for opening this. For English, I'd like this issue to include adding a section to , below Ways to Contribute: Other localizations can include that section with a link to their localization-specific cheatsheet.
I see your point, I will file a PR now.
Taking the lead for the French translation
Translation of the localize contributor cheatsheet in Korean is done. (ref : kubernetes/community)
I'm working on Ukrainian uk localization.
/reopen accidentally closed by
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
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
checkin /remove-lifecycle stale
Current state as of 15th Aug 2019(Feel free to edit when it has to be changed) [x] Chinese: [x] Korean: [x] Japanese: [x] German: [x] Spanish: [x] French: [x] Indonesian: [x] Portuguese: [x] Italian: [x] Hindi:
/lifecycle frozen /priority backlog
any progress so far? Would be glad to join forces)
Can we start an Oriya [or] localization?

I would love to take lead in doing this. Let me know your thoughts about it.
All ten tasks are completed and merged. Closing this epic. Feel free to file a new issue/epic if there are other localization efforts to be covered. /close
Closing this issue. <detailsIn response to : All ten tasks are completed and merged. Closing this epic. Feel free to file a new issue/epic if there are other localization efforts to be covered. /close </details

This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: It is not clear if LXD nodes are running Docker containers.
cc:
Thanks for the report. Yes, the LXD nodes serve as "machines" for running kubelet, the docker processes are then run inside of LXD. I'll put up a pull request to include a diagram and description
Yes. Took time to figure it out.
if you have time, we really appreciate if you can send a patch to the documentation to make ease other people’s potential pains in the future.
see PR above.
Thanks.


Question: deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ / EOF <del> curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg - </del> <ins> curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add - curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg add - </ins> sudo apt-get update sudo apt-get install cri-o cri-o-runc

[UBUNTU 20.04] specifies the following command: This runs into the following error: Update the command to: Or... use the command which is also mentioned on the
Thanks for reporting this. I wonder if we should also recommend that readers ? /kind bug /triage accepted /priority important-longterm /language en /sig node
That is a possibility. But I think it would be logical to take over the official documentation of docker.
Did PR help here? /triage needs-information /remove-triage accepted
/retitle Incorrect commands for adding PGP keys to APT configuration
/triage accepted /remove-triage needs-information


Question: Kubernetes. They needed to be pushed to some registry to allow them to be used by Kubernetes. <ins> ## Known issues ### Some filesystem metrics are missing and the metrics format is different The Kubelet `/metrics/cadvisor` endpoint provides Prometheus metrics, as documented in [Metrics for Kubernetes system components](/docs/concepts/cluster-administration/system-metrics/). If you install a metrics collector that depends on that endpoint, you might see the following issues: - The metrics format on the Docker node is `k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>` but the format on other runtime is different. For example, on containerd node it is `<container-id>`. - Some filesystem metrics are missing, as follows: ``` container_fs_inodes_free container_fs_inodes_total container_fs_io_current container_fs_io_time_seconds_total container_fs_io_time_weighted_seconds_total container_fs_limit_bytes container_fs_read_seconds_total container_fs_reads_merged_total container_fs_sector_reads_total container_fs_sector_writes_total container_fs_usage_bytes container_fs_write_seconds_total container_fs_writes_merged_total ``` #### Workaround You can mitigate this issue by using [cAdvisor](https://github.com/google/cadvisor) as a standalone daemonset. 1. Find the latest [cAdvisor release](https://github.com/google/cadvisor/releases) with the name pattern `vX.Y.Z-containerd-cri` (for example, `v0.42.0-containerd-cri`). 2. Follow the steps in [cAdvisor Kubernetes Daemonset](https://github.com/google/cadvisor/tree/master/deploy/kubernetes) to create the daemonset. 3. Point the installed metrics collector to use the cAdvisor `/metrics` endpoint which provides the full set of [Prometheus container metrics](https://github.com/google/cadvisor/blob/master/docs/storage/prometheus.md). Alternatives: - Use alternative third party metrics collection solution. - Collect metrics from the Kubelet summary API that is served at `/stats/summary`. </ins> ## {{% heading "whatsnext" %}} - Read [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) to understand your next steps

/kind feature /sig node docs for the flag pod-infra-container-image as dockershim is removed (also tracked here: ) how to transition from using this flag to Contained setting when migrating off dockershim Also see
/sig docs
/triage accepted
I'm not quite sure what needs to happen with this issue specifically. Is the umbrella issue going to cover this? What needs to change in relation to this issue?
Can you please describe more?
similar to this: The flag is deprecated. On migration - users needs to stop using this flag and instead configure the container runtime with the proper configuration setting. For containerd it is a
/milestone 1.24
Users should stop using the flag only when using a container runtime that supports image pinning. At the moment there's work being done on the containerd side. Other CRIs only have issues created for implementing image pining:
The current situation is that you end up with two (or more) versions of pod-infra-container: Depending on the actual versions of kubernetes and the container runtime being involved.
The pod-infra-container-image flag is only mentioned in two files currently. The one in reference docs will go away when reference docs are rebuilt for 1.24. The mention in will be removed in PR to be named later. If there are new feature to replace image pining for other runtimes, please create a new issue.
removes the option. So we should close this issue once that PR merges.
The dockershim work is ongoing, but as 1.24 is releasing today, i'm clearing the milestone. /milestone clear
The final instance of --pod-infra-container-image was removed with . /close
Closing this issue. <detailsIn response to : The final instance of --pod-infra-container-image was removed 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 this bug was suggesting to add a note to dockershim migration document to suggest customers what to replace this flag with on migration off dockershim. See comment This document will benefit from this instruction: This is one of the flags, other flags not documented in the migration document and causing confusion (see report: ):
Reopened this issue.

<detailsIn response to : /reopen This is one of the flags, other flags not documented in the migration document and causing confusion (see report: ): 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
For cri-dockerd, it is called :-) Eventually it will also be possible to set using configuration files: But I believe the current status (editing flags in systemd unit) is documented properly, on the container runtime page.
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
Would it be appropriate to link right before starts? We could add a line asking our audience to refer to the linked guide to understand how to get Kubelet working with containerd. If that doesn't work, where else would you recommend placing it?

This is a Feature Request Port this: to the migration guide documentation: as a known issue. Note, CRI-O behavior may be different.
/sig node
/language en
Is the ask here to port the Google doc into the Kubernetes docs or just link to the Google documentation (which isn't necessarily allowed)?
We can't really do either, unless Google licenses to the CNCF. We could write new docs to highlight the same known issue (what's the issue? - I deliberated haven't looked).
Here is the GH issue: These metrics are missing in endpoint with Containerd (they were present with Dockershim): Also the format of container name dimension of many metrics was with dockershim, but the format on the containerd node is . This is coming from this file: that even has an internesting note that this is implementaiton details, but changing it will likely break somethings (btw, maybe this may be noted as well in the list of known issues). So workaround for both issues (missing metrics and the name of metric dimension) is to use a standalone cAdvisor, and use one of the releases with the suffix "-containerd-cri"
That sounds quite involved - should we open a related issue to track explaining how folks would do that?
Do we have a document that can be followed for using a standalone cadvisor? I checked the tags in cadvisor and turns out 2 versions have containerd as suffix but none have the "-containerd-cri" suffix. Ex: v0.41.0-containerd-fix-rc.2 Does the latest version v0.44.0 contain the fix?
can you please help here?
The fix was in I think but not sure which releases contain it
So what do we need to do next, Align versions?
/assign
Yeah I'm not sure how to tell which version has the changes. It's for sure in 0.43.x but the current "Latest" tag is 0.39.x and doesn't seem to have the fix. I think we should wait for or to verify.
It looks like updates the page's docker-specific information related to cAdvisor to be more generic to container runtimes. Would that be enough to address this issue or does more runtime-specific information need to be ?
what's your opinion in respect of ?

It's due to it being reverted in which is a real bummer for those of us using GKE and the default for new node pools is containerd.
/triage accepted
What should the next steps on this issue look like?
my thoughts: This doesn't belong on the suggested page because it's specific to containerd. I'd say let's update as follows: In Before you begin, add a line to "Read the known issues section" Add a section at the end, before What's Next, called "Known issues after migrating" Add "Versions of containerd prior to 0.45.0 didn't collect some metrics in the endpoint. For a list of missing metrics, refer to . To collect these metrics, install a containerd package that is version 0.45.0 or later that has the suffix." In , mention "To avoid the missing metrics in [Known issues after migrating](#known-issues-after-migrating), install a containerd package that is version 0.45.0 or later that has the suffix."
According to the comment at the only current work-around for containerd users is to deploy and scrape a standalone cadvisor daemonset, built from the branch. The stats exposed by the kubelet will be broken until 1.25 or 1.26 when is complete. Since it is the kubelet's cadvisor that is broken (and I would argue that it is broken/regressed by this issue), it should be covered in the kubernetes docs.
Is there a more involved process then than just installing the package?
it's not a package, it's a branch of the cadvisor project: I'm not sure if they're publishing binaries or images from that branch. A sample DaemonSet is available, which could be modified to use :
Could we say: "To collect these metrics, . Set the $VERSION variable to any cAdvisor version that has the suffix, such as " ?
I think that needs more work, for example the default DaemonSet only mounts the docker socket path; it does not mount the containerd socket, and even when I modify it to do so the metrics appear to be missing most of the important labels. Perhaps has some suggestions.

This feels like it would need to be its own task page, possibly linked from our existing Metrics doc as well
I've put a ready to run temporary solution here
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]:
/remove-lifecycle stale


Question: they could be running CoreDNS Pods or other critical workloads. For more information see [Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/). - All containers are restarted after upgrade, because the container spec hash value is changed. <ins> - To verify that the kubelet service has successfully restarted after the kubelet has been upgraded, you can execute `systemctl status kubelet`  or view the service logs with `journalctl -xeu kubelet`. </ins> <!-- steps -->

For the Redhat when upgrading the kubelet you should have following for Restart kubelet sudo systemctl daemon-reload sudo systemctl stop kubelet ps -ef | grep kubelet (verfiy kubelet stopped kill process if not stopped) sudo systemctl start kubelet
hi, i'm not sure what issue you are reporting. can you elaborate? /kind support
/triage needs-information
/sig cluster-lifecycle I think is asking for a detailed walkthrough of how to restart a service on RedHat-like hosts, and then to verify that the restarted service is healthy. There's some value in this but also we need to bear in mind that systemd and Linux are not the only options for nodes, and that we could instead declare “you should know how to restart services and verify that they are healthy” as a prerequisite. Any Kubernetes-specific way to verify that a kubelet is healthy is valid and we should document it.
Hey can I work on this issue?
we could add the following bullet point here: would you like to send a PR for that?
/kind feature /remove-triage needs-information /triage accepted /retitle kubeadm-upgrade: add note about verifying the kubelet service status
/assign


Question: the Node is not considered for preemption. {{< /note >}} <del> If a pending Pod has inter-pod affinity to one or more of the lower-priority Pods on the Node, the inter-Pod affinity rule cannot be satisfied in the absence of those lower-priority Pods. In this case, the scheduler does not preempt any Pods on the Node. Instead, it looks for another Node. The scheduler might find a suitable Node or it might not. There is no guarantee that the pending Pod can be scheduled. </del> <ins> If a pending Pod has inter-pod {{< glossary_tooltip text="affinity" term_id="affinity" >}} to one or more of the lower-priority Pods on the Node, the inter-Pod affinity rule cannot be satisfied in the absence of those lower-priority Pods. In this case, the scheduler does not preempt any Pods on the Node. Instead, it looks for another Node. The scheduler might find a suitable Node or it might not. There is no guarantee that the pending Pod can be scheduled. </ins> Our recommended solution for this problem is to create inter-Pod affinity only towards equal or higher priority Pods.

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 should use a glossary tooltip for “affinity” Why is this needed Kubernetes uses the term “affinity” to mean a specific thing. A tooltip (and the hyperlink it implies) helps a reader learn more about this term if they are not sure. Comments /language en
/triage accepted
Hey, I will like to work on this !! Please let me know how can I proceed with this !! !!
/assign


Question: <ins> --- title: पॉड विघटन (Pod Disruption) id: pod-disruption date: 2021-05-12 full_link: /docs/concepts/workloads/pods/disruptions/ short_description: > पॉड विघटन वह प्रक्रिया है जिसके द्वारा नोड्स पर पॉड्स को स्वेच्छा से या अनैच्छिक रूप से समाप्त कर दिया जाता है। aka: related: - pod - container tags: - operation --- [पॉड विघटन](/docs/concepts/workloads/pods/disruptions/) वह प्रक्रिया है जिसके द्वारा नोड्स पर पॉड्स को स्वेच्छा से या अनैच्छिक रूप से समाप्त कर दिया जाता है। <!--more--> स्वैच्छिक विघटन एप्लीकेशन मालिक या फिर क्लस्टर प्रशासक अभिप्रायपूर्वक चालू करते है। अनैच्छिक विघटन अनजाने में होते है और वो अपरिहार्य वजह से उत्पन्न हो सकते हैं जैसे कि नोड्स के पास संसाधन ख़तम हो जाना या आकस्मिक विलोपन। </ins>

If this is your first contribution, visit for information on how to get started. Review a few to see which content you have to change and which you leave unchanged. Make sure your base, target branch is and create a working branch called . Create a file called content/hi/docs/reference/glossary/pod- Copy the content of to the file you created Localize the content. Push your change and create a pull request. Completing this feature issue fixes part of /language hi /triage accepted
Hi , i can work on this issue. Please assign it to me.
/assign Thank you!


Question:
Build your cloud native career

Kubernetes is at the core of the cloud native movement. Training and certifications from the Linux Foundation and our training partners lets you invest in your career, learn Kubernetes, and make your cloud native projects successful.

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update to mention the qualification. Why is this needed There's now a KCNA qualification that you can train for. Comments /kind feature /language en /priority important-longterm
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted 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
/assign (I just modified the in the training folder, please LMK if that was not the right way)
That's how we do it. As a separate issue: it'd be nice to convert that to a kind of HTML that's closer to what Docsy renders our site to.


Question: [build.environment] NODE_VERSION = "10.20.0" <del> HUGO_VERSION = "0.111.3" </del> <ins> HUGO_VERSION = "0.120.3" </ins> [context.production.environment] HUGO_BASEURL = "https://kubernetes.io/"

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update Hugo to (or later), by editing Update 2024-01-01: v0.121.1 would be ideal. Why is this needed There are some security fixes for Go that we might want to pull in. Comments /sig security /sig docs
/triage accepted /priority important-longterm
/assign I'd like to help with this
I think just editing the won't work, Would need to update some images or makefile as well?
We use ~magic~ technology so that the one edit is all you need to do.
To test it locally, edit the configuration and then run:
Alright sounds good, I'll do the needful


Question: Some kubelet garbage collection features are deprecated in favor of eviction: <del> | Existing Flag | New Flag | Rationale | | ------------- | -------- | --------- | | `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection | | `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior | | `--maximum-dead-containers` | - | deprecated once old logs are stored outside of container's context | | `--maximum-dead-containers-per-container` | - | deprecated once old logs are stored outside of container's context | | `--minimum-container-ttl-duration` | - | deprecated once old logs are stored outside of container's context | </del> <ins> | Existing Flag | Rationale | | ------------- | --------- | | `--maximum-dead-containers` | deprecated once old logs are stored outside of container's context | | `--maximum-dead-containers-per-container` | deprecated once old logs are stored outside of container's context | | `--minimum-container-ttl-duration` | deprecated once old logs are stored outside of container's context | </ins> ### Eviction thresholds

We say that the ImageGCHighThresholdPercent/ImageGCLowThresholdPercent config option is deprecated for evictionHard settings but this is not true. ImageGC uses and for Garbage collection so these flags are not We should update our documentation to reflect this.
/language en /sig docs /kind bug
/assign
/sig scheduling
/remove-sig scheduling /sig node Eviction is done in kubelet which is in sig-node's domain.
/triage accepted indeed this needs to be clarified. We unlikely will remove these flags soon. So need to fix up docs


Question:
other = "Không" [feedback_question]  other = "Trang này có hữu ích?"   other = "Trang này có hữu ích không?"  [feedback_yes] other = "Có"  [final_patch_release] other = "Bản phát hành Patch cuối cùng" [inline_list_separator] other = ","  [input_placeholder_email_address] other = "địa chỉ email"  [javascript_required] other = "Cần [kích hoạt](https://www.enable-javascript.com/) JavaScript để xem nội dung này" [katacoda_message] other = """
Tắt các bài hướng dẫn tương tác

Các bài hướng dẫn tương tác trên trang web này đang bị tắt. Dự án Kubernetes hy vọng sẽ tái thiết lập một tùy chọn học tương tác tương tự trong dài hạn.

Quyết định tắt đó là kết quả của cuộc [sáp nhập](https://www.oreilly.com/content/oreilly-acquires-katacoda-and-a-new-way-for-2-5m-customers-to-learn/) của O'Reilly Media với Katacoda vào năm 2019.

Kubernetes rất biết ơn O'Reilly và Katacoda đã giúp đỡ nhiều người bắt đầu học Kubernetes.

Các bài hướng dẫn sẽ ngừng hoạt động sau ngày 31th tháng 3, 2023. Để biết thêm thông tin, xem "Bài hướng dẫn Kubernetes miễn phí trên Katacoda sẽ dừng lại từ ngày 31/03/2023."
""" [latest_release] other = "Bản phát hành mới nhất:"  [latest_version] other = "phiên bản mới nhất."  [layouts_blog_pager_next] other = "Tiếp theo >>"  [layouts_blog_pager_prev] other = "<< Trước"  [layouts_blog_pager_next] other = "Sau >>"  [layouts_case_studies_list_tell] other = "Kể câu chuyện của bạn" [layouts_docs_glossary_aka]  other = "Cũng được biết đến như là"   other = "Còn được biết đến là" [layout_docs_glossary_architecture_description] other = "Các thành phần bên trong của Kubernetes." [layout_docs_glossary_architecture_name] other = "Kiến trúc" [layouts_docs_glossary_click_details_after] other = "dưới đây để có một giải thích chi tiết hơn cho bất kỳ thuật ngữ cụ thể nào." [layouts_docs_glossary_click_details_before] other = "Nhấp vào" [layout_docs_glossary_community_description] other = "Liên quan đến sự phát triển mã nguồn mở của Kubernetes." [layout_docs_glossary_community_name] other = "Cộng đồng" [layout_docs_glossary_core-object_description] other = "Loại nguồn lực mà Kubernetes hỗ trợ theo mặc định." [layout_docs_glossary_core-object_name] other = "Đối tượng Core"  [layouts_docs_glossary_description]  other = "Bảng chú giải này được kì vọng là một danh sách hoàn thiện, được chuẩn hóa về thuật ngữ Kubernetes. Nó bao gồm các thuật ngữ kỹ thuật dành riêng cho Kubernetes, cũng như các thuật ngữ chung hơn cung cấp ngữ cảnh hữu ích"   other = "Bảng từ vựng này được thiết kế để là một danh sách toàn diện, chuẩn hóa các thuật ngữ của Kubernetes. Nó bao gồm các thuật ngữ kỹ thuật cụ thể cho Kubernetes, cũng như các thuật ngữ tổng quát mang lại ngữ cảnh hữu ích."  [layouts_docs_glossary_deselect_all] other = "Bỏ chọn tất cả"  [layouts_docs_glossary_click_details_after] other = "danh mục dưới đây để giải thích rõ hơn cho các thuật ngữ cụ thể"   [layout_docs_glossary_extension_description] other = "Các tùy chỉnh được hỗ trợ của Kubernetes."   [layouts_docs_glossary_click_details_before] other = "Click vào"   [layout_docs_glossary_extension_name] other = "Phần mở rộng"  [layouts_docs_glossary_filter]  other = "Lọc các thuật ngữ theo tags"   other = "Lọc các thuật ngữ theo các thẻ của chúng" [layout_docs_glossary_fundamental_description] other = "Quan trọng đối với người dùng Kubernetes lần đầu tiên." [layout_docs_glossary_fundamental_name] other = "Cơ bản" [layout_docs_glossary_networking_description] other = "Cách các thành phần Kubernetes trò chuyện với nhau (và với các chương trình bên ngoài cụm)." [layout_docs_glossary_networking_name] other = "Mạng" [layout_docs_glossary_operation_description] other = "Bắt đầu và duy trì Kubernetes." [layout_docs_glossary_operation_name] other = "Hoạt động" [layout_docs_glossary_security_description] other = "Giữ cho các ứng dụng Kubernetes an toàn và bảo mật." [layout_docs_glossary_security_name] other = "Bảo mật"  [layouts_docs_glossary_select_all] other = "Chọn tất cả"  [layout_docs_glossary_storage_description] other = "Cách các ứng dụng Kubernetes xử lý dữ liệu lâu dài." [layout_docs_glossary_storage_name] other = "Lưu trữ" [layout_docs_glossary_tool_description] other = "Phần mềm giúp làm cho Kubernetes dễ sử dụng hoặc tốt hơn." [layout_docs_glossary_tool_name] other = "Công cụ" [layout_docs_glossary_user-type_description] other = "Đại diện cho một loại người dùng Kubernetes phổ biến." [layout_docs_glossary_user-type_name] other = "Loại Người dùng" [layout_docs_glossary_workload_description] other = "Các ứng dụng đang chạy trên Kubernetes." [layout_docs_glossary_workload_name] other = "Khối công việc"  [layouts_docs_partials_feedback_improvement]  other = "đề xuất cải tiến"   other = "đề xuất một cải tiến"  [layouts_docs_partials_feedback_issue]  other = "Tạo một issue trên Github repo nến bạn muốn "   other = """Mở một vấn đề trong [Kho GitHub](https://www.github.com/kubernetes/website/) nếu bạn muốn """  [layouts_docs_partials_feedback_or] other = "hoặc"

Đề nghị thay thế "lạc thú" bằng "lỗi thời" !
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
Please raise the issue in english putting the language code before the issue in [] example [vi] Issue title here It will be good practice to write the description and title of the issue in English only.
Thank you! BTW i'd commited about this change, waiting for review.
Fixed in


Question: <!-- overview --> <del> This page explains how to configure the kubelet cgroup driver to match the container </del> <ins> This page explains how to configure the kubelet's cgroup driver to match the container </ins> runtime cgroup driver for kubeadm clusters. ## {{% heading "prerequisites" %}}

says the default value for is . says: The latter does not say, that prior to 1.23 (thus 1.22, 1.21, 1.20) the default was and was later changed to . It says, that in the nearly end-of-life 1.22 the default is . Later contains: In the above text, it is nowhere stated, that there is a plan to switch the default value of KubeletConfiguration.cgroupDriver from cgroupfs to systemd. The last citation suggests, that will perform implicit switch from to . This is strengthened by the fact about 1.22, where the implicit (default) value seems to be . All in all, the above information stipulates, that in 1.22 the default value was , not it is and in the future will use as implicit (default) value again . In the lack of discussion in the documentation why the defauls change back and forth, this does not make sense,
the kubelet default is cgroupfs and it's not clear if the kubelet graduates cgroupv2 support to GA the value will change. afaik, cgroupfs does not support v2. in any case this can be a disruptive change. kubeadm changed its default to systemd because the kubelet in kubeadm setups is managed by systemd. the reason is explained here long term, the cgroup driver detail should not be exposed to users, but that is blocked on some cri work. /kind support
Ah, so the default cgroup driver for kubelet is cgroupfs, while for kubeadm the default is systemd. This shall be spelled explicitly, as it is counter-intuitive. My understanding so far is, that the systemd-driver supports kernel’s cgroup v2, while kubernetes’ cgroup-driver does not support kernel’s cgroup v2. This shall also be spelled explicitly, as it is confusing.
It sounds like the thing to call out is that, in the kubeadm docs, we should explicitly say that the setting that kubeadm applies by default is an override to the built-in kubelet default. Does that sound right?
Yes. Ideally kubeadm and kubelet shall explicitly state, that their default is distinct from the default of the other tool.

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]:
/remove-lifecycle stale /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /remove-lifecycle stale /help </details
/triage accepted
/assign


Question: metadata: name: kube-dns-autoscaler namespace: kube-system <del> labels: addonmanager.kubernetes.io/mode: Reconcile </del> --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: system:kube-dns-autoscaler <del> labels: addonmanager.kubernetes.io/mode: Reconcile </del> rules: - apiGroups: [""] resources: ["nodes"]

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: mentions an annotation prefix that is deprecated / not actually official. Proposed Solution: Remove all mention of annotations from that page. Page to Update: and specifically Additional Information: This is a follow-up to /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
/retitle Remove labels from ”Autoscale the DNS Service in a Cluster”
/assign


Question: <del> --- title: トポロジーを意識したヒント content_type: concept weight: 100 --- <!-- overview --> {{< feature-state for_k8s_version="v1.23" state="beta" >}} *Topology Aware Hint*は、クライアントがendpointをどのように使用するかについての提案を含めることにより、トポロジーを考慮したルーティングを可能にします。このアプローチでは、EndpointSliceおよび/またはEndpointオブジェクトの消費者が、これらのネットワークエンドポイントへのトラフィックを、それが発生した場所の近くにルーティングできるように、メタデータを追加します。 たとえば、局所的にトラフィックをルーティングすることで、コストを削減したり、ネットワークパフォーマンスを向上させたりできます。 <!-- body --> ## 動機 Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。 *Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー(リージョンとゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 EndpointSliceコントローラーは、各endpointのトポロジー(リージョンとゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。 ## Topology Aware Hintを使う `service.kubernetes.io/topology-aware-hints`アノテーションを`auto`に設定すると、サービスに対してTopology Aware Hintを有効にすることができます。これはEndpointSliceコントローラーが安全と判断した場合に、トポロジーヒントを設定するように指示します。 重要なのは、これはヒントが常に設定されることを保証するものではないことです。 ## 使い方 {#implementation} この機能を有効にする機能は、EndpointSliceコントローラーとkube-proxyの2つのコンポーネントに分かれています。このセクションでは、各コンポーネントがこの機能をどのように実装しているか、高レベルの概要を説明します。 ### EndpointSliceコントローラー {#implementation-control-plane} この機能が有効な場合、EndpointSliceコントローラーはEndpointSliceにヒントを設定する役割を担います。 コントローラーは、各ゾーンに比例した量のendpointを割り当てます。 この割合は、そのゾーンで実行されているノードの[割り当て可能な](/ja/docs/task/administer-cluster/reserve-compute-resources/#node-allocatable)CPUコアを基に決定されます。 たとえば、あるゾーンに2つのCPUコアがあり、別のゾーンに1つのCPUコアしかない場合、コントローラーは2つのCPUコアを持つゾーンに2倍のendpointを割り当てます。 次の例は、ヒントが入力されたときのEndpointSliceの様子を示しています。 ```yaml apiVersion: discovery.k8s.io/v1 kind: EndpointSlice metadata: name: example-hints labels: kubernetes.io/service-name: example-svc addressType: IPv4 ports: - name: http protocol: TCP port: 80 endpoints: - addresses: - "10.1.2.3" conditions: ready: true hostname: pod-1 zone: zone-a hints: forZones: - name: "zone-a" ``` ### kube-proxy {#implementation-kube-proxy} kube-proxyは、EndpointSliceコントローラーによって設定されたヒントに基づいて、ルーティング先のendpointをフィルター処理します。ほとんどの場合、これはkube-proxyが同じゾーン内のendpointにトラフィックをルーティングできることを意味します。コントローラーが別のゾーンからendpointを割り当てて、ゾーン間でendpointがより均等に分散されるようにする場合があります。これにより、一部のトラフィックが他のゾーンにルーティングされます。 ## セーフガード 各ノードのKubernetesコントロールプレーンとkube-proxyは、Topology Aware Hintを使用する前に、いくつかのセーフガードルールを適用します。これらがチェックアウトされない場合、kube-proxyは、ゾーンに関係なく、クラスター内のどこからでもendpointを選択します。 1. **endpointの数が不十分です:** クラスター内のゾーンよりもendpointが少ない場合、コントローラーはヒントを割り当てません。 2. **バランスの取れた割り当てを実現できません:** 場合によっては、ゾーン間でendpointのバランスの取れた割り当てを実現できないことがあります。たとえば、ゾーンaがゾーンbの2倍の大きさであるが、endpointが2つしかない場合、ゾーンaに割り当てられたendpointはゾーンbの2倍のトラフィックを受信する可能性があります。この「予想される過負荷」値が各ゾーンの許容しきい値を下回ることができない場合、コントローラーはヒントを割り当てません。重要なことに、これはリアルタイムのフィードバックに基づいていません。それでも、個々のendpointが過負荷になる可能性があります。 3. **1つ以上のノードの情報が不十分です:** ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。 4. **1つ以上のendpointにゾーンヒントが存在しません:** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。 5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを1つも見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。 ## 制約事項 * Serviceで`externalTrafficPolicy`または`internalTrafficPolicy`が`Local`に設定されている場合、Topology Aware Hintは使用されません。同じServiceではなく、異なるServiceの同じクラスターで両方の機能を使用することができます。 * このアプローチは、ゾーンのサブセットから発信されるトラフィックの割合が高いサービスではうまく機能しません。代わりに、これは着信トラフィックが各ゾーンのノードの容量にほぼ比例することを前提としています。 * EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。 * EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip text="toleration" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。 * これはオートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。 ## {{% heading "whatsnext" %}} * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。 </del>

This is a Feature Request What would you like to be The ja documents should be updated about Topology Aware Routing. (Related: ) Why is this needed The ja documents are outdated about Topology Aware Routing. Comments /language ja /assign
/triage accepted


Question:
 {{ $feed := getJSON .Site.Params.cveFeedBucket }} {{ if ne $feed.version "https://jsonfeed.org/version/1.1" }} {{ warnf "CVE feed shortcode. KEP-3203: CVE feed does not comply with JSON feed v1.1." }} {{ end }}   {{- $url := .Site.Params.cveFeedBucket }} {{- $feed := "" -}}  {{- with resources.GetRemote $url -}} {{- if .Err -}}  {{- $message := printf "Failed to retrieve CVE data: %s" .Err -}} {{- if eq hugo.Environment "production" -}} {{- errorf $message -}} {{- else -}} {{- warnf $message -}} {{- end -}} {{- else -}}  {{- $feed = .Content | transform.Unmarshal -}} {{- if ne $feed.version "https://jsonfeed.org/version/1.1" -}} {{- $warningMessage := "CVE feed shortcode. KEP-3203: CVE feed does not comply with JSON feed v1.1." -}} {{- if eq hugo.Environment "production" -}} {{- errorf $warningMessage -}} {{- else -}} {{- warnf $warningMessage -}} {{- end -}} {{- end -}} {{- end -}} {{- else -}}  {{- $message := printf "Unable to fetch CVE data from the specified URL: %q" $url -}} {{- if eq hugo.Environment "production" -}} {{- errorf $message -}} {{- else -}} {{- warnf $message -}} {{- end -}} {{- end -}}  {{ if ne $feed nil }}

{{ T "cve_table" }} {{ printf (T "cve_table_date_format_string") ($feed._kubernetes_io.updated_at | time.Format (T "cve_table_date_format")) }}

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 Migrate to instead of Hugo's Why is this needed Upstream Hugo has deprecated , which we use. We should aim to migrate to use ; see Comments We may need to upgrade to a newer Hugo as part of this work, or related to it. /area web-development /lifecycle frozen
/triage accepted /priority backlog
Let me see if I can assist with this. Edit: Proposed fix in /assign


Question: ] ``` <del> If the `status` of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), then the [node controller](#node-controller) triggers {{< glossary_tooltip text="API-initiated eviction" term_id="api-eviction" >}} for all Pods assigned to that node. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the API server is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node. The node controller does not force delete pods until it is confirmed that they have stopped running in the cluster. You can see the pods that might be running on an unreachable node as being in the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from Kubernetes causes all the Pod objects running on the node to be deleted from the API server and frees up their names. </del> When problems occur on nodes, the Kubernetes control plane automatically creates [taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that match the conditions <del> affecting the node. The scheduler takes the Node's taints into consideration when assigning a Pod to a Node. Pods can also have {{< glossary_tooltip text="tolerations" term_id="toleration" >}} that let them run on a Node even though it has a specific taint. See [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition) </del> <ins> affecting the node.  An example of this is when the `status` of the Ready condition remains `Unknown` or `False` for longer than the kube-controller-manager's `NodeMonitorGracePeriod`, which defaults to 40 seconds.  This will cause either an `node.kubernetes.io/unreachable` taint, for an `Unknown` status, or a `node.kubernetes.io/not-ready` taint, for a `False` status, to be added to the Node. These taints affect pending pods as the scheduler takes the Node's taints into consideration when assigning a pod to a Node. Existing pods scheduled to the node may be evicted due to the application of `NoExecute` taints. Pods may also have {{< glossary_tooltip text="tolerations" term_id="toleration" >}} that let them schedule to and continue running on a Node even though it has a specific taint. See [Taint Based Evictions](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) and [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition) </ins> for more details. ### Capacity and Allocatable {#capacity}

This page talks about but the page referred does not contain anything about . Looks like either Nodes is outdated or kube-controller-manager is missing this documentation.
Page:
was deprecated in k8s v1.26 and will remove in k8s v1.27 Here is the PR:
As it is deprecated we have to mention this as a note in the docs for v1.26 and in v1.27, remove this from the docs. Let's wait for others members, what they think about it.
/kind bug /sig apps
/retitle Stale or incorrect information in Nodes concept page
/remove-sig apps It's nice if people who deprecate a thing also track a docs update issue. However, I wouldn't expect SIG Apps to pick this up.
yeah, that will be really helpful.
/triage accepted
Could you please take a look?
/triage accepted
/assign
thanks for the PR. It is Ok for v1.27. But I have one concern regarding v1.26 if we click on as mentioned above, we can't find as it is deprecated in v1.26. Either we have to remove this from v1.26 also or mention the Note in v1.26 docs regarding the depreciation.
It is mentioned under till k8s v1.25. Here is the following link for it: https://v1-
Hi , Your thoughts on this
This issue has not been updated in over 1 year, and should be re-triaged. You can: Confirm that this issue is still relevant with (org members only) Close this issue with For more details on the triage process, see /remove-triage accepted
closing this issue, as it was resolved by PR /close
Closing this issue. <detailsIn response to : closing this issue, as it was resolved by PR 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: For example: <del> ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: csr-creator rules: - apiGroups: - certificates.k8s.io resources: - certificatesigningrequests verbs: - create - get - list - watch ``` </del> <ins> {{< codenew file="access/certificate-signing-request/clusterrole-create.yaml" >}} </ins> To allow approving a CertificateSigningRequest:

/language zh
/reopen This was incorrectly
Reopened this issue. <detailsIn response to : /reopen This was incorrectly 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
/assign