Question: {{ T "caution" | safeHTML }} {{ T "thirdparty_message" | safeHTML }}

Per our discussion in today's SIG Docs: Sections of the site, like will always have some degree of 3rd party content, due to the fact that a k8s developer must implement an external networking CNI. The majority of post-3rd party content KEP PR's we get that actually involve third party content are to pages like this one. A part of the reasons is that a change like the KEP requires initial communication (which was well done) but also ongoing communication. This change proposes the following: Create a reusable Note or similar shortcode for pages that fall under . The note should: Be translatable (use a key) Warn people that they must use a 3rd party plugin/software for this step Indicate that per the projects are listed alphabetically Indicate that additions to this list/page must directly provide a solution for this step of an implementation (i.e. for the cluster networking page, projects listed must provide a networking solution – no 'nice to haves' that make networking easier or somehow nicer.) Link to the content guidelines for more info on acceptable additions to the page.
/assign /area web-development /priority important-longterm
/language en
Wording for review: This section contains links to third party projects which provide functionality required by Kubernetes. The Kubernetes project authors are not responsible for these projects. Projects are listed alphabetically, in accordance with [CNCF website guidelines]. To add a project to this list, read the <a href="/contribute/style/content-guide/#third-party-content"content guide</abefore submitting a change.
Related:
How about:
LGTM, I'll go ahead and implement. Thank you for the edit!
Hello , Some late feedback (sorry I missed the meeting): Since this is a "special" note, I think it warrants a different color on the left hand border. Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? The language in the third party content message is a bit obtuse. When this label is applied, can the reader assume that all content on the page falls under these guidelines? This sentence, "Kubernetes project authors are not responsible for these projects" seems repetitive. Third party implies an external source and outside of the project's domain.

Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? All good feedback. How would you phrase it differently?
Hi. I am not entirely sure. The text is okay, though, it may not be clear about what is "required for Kubernetes to function". What do you want readers to do: determine if their project belongs in the section (read the content guide) read the content as third party content (Sig Docs is hosting the links but not responsible for the content on the page)? [One idea:] This section links to third party projects and follows [CNCF website guidelines] by listing projects alphabetically. [Do you want to suggest adding content or not?] If you are considering adding content in this section, read the before submitting a change. [Do you need a statement about content responsibility?]
Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? I think this is a good suggestion. I'll update the PR. What do you want readers to do: This section links to third party projects and follows [CNCF website guidelines] by listing projects alphabetically. If you are considering adding content in this section, read the content guide before submitting a change. Is this blocking for the PR? If we can't come up with a concrete alternative, I'd prefer to merge the PR, re-open this issue, and continue to work on the wording. Would that be okay,
Sure . I think what you have is fine. As an aside, did you consider using the theme's shortcode (which has a parameter)? It may work as well as wrapping the "third party content" shortcode in a note/warning shortcode. I think you can set the attribute too.
I'm imagining a one-line shortcode that, when rendered, closely matches the styles of existing callouts. I'd rather not use callouts from the Docsy theme because that's different from our existing callouts (something to handle in a separate issue, I feel). Wording-wise I'm happy to see something merged and leave room to iterate. Would you be happy to implement that?
Hi.

I agree, let's get this change moving forward with a single line shortcode with similar styling to the existing callouts. The shortcode would use two template strings: one variable for the message title and another variable for the message body. In the future, I could imagine a flexible interface or more generic shortcode that accepts at least one argument: the name of the variable representing the message title.


Question: content_type: concept weight: 30 --- <!-- reviewers: - pweil-

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: page garbled. ! /language zh
I suddenly saw this page showing garbled characters today. Can you take a look?
Looking into this.
raised a PR for diagnosis looks like the cached version of the HTML is corrupted. It is not treated as HTML media type. Dummy PR for this:
/triage accepted


Question: *API server* mengisi *field* tertentu dengan nilai *default* pada konfigurasi *live* jika nilai *field-field* tersebut tidak dispesifikasikan ketika objek dibuat. <del> Berikut adalah sebuah *file* konfigurasi untuk sebuah Deployment. File berikut tidak menspesifikasikan `strategy`: </del> <ins> Berikut adalah sebuah *file* konfigurasi untuk sebuah Deployment. Berkas berikut tidak menspesifikasikan `strategy`: </ins> {{< codenew file="application/simple_deployment.yaml" >}}

This issue is intended for contributor workshop as part of Cloud Native Day Indonesia on 7th Nov 2020. Please don't take it if you are not part of the workshop. There are several old translated pages that contain the english glossary "file", supposed to use Indonesian "berkas" as per KBBI. Please claim the task to fix them by giving comments on this Github issue. /language id Tasks to fix "file" -"berkas": [x] docs/tasks/manage-kubernetes-objects/imperative-[x] docs/tasks/manage-kubernetes-objects/declarative-[ ] docs/tasks/manage-kubernetes-objects/imperative-[ ] docs/tasks/configure-pod-container/configure-pod-[ ] docs/tasks/administer-cluster/sysctl-[ ] [x] [ ] docs/concepts/storage/storage-[ ] docs/concepts/services-networking/connect-applications-[ ] docs/concepts/services-[x] [x] docs/concepts/cluster-
/triage accepted
/assign
I'm taking this page docs/tasks/manage-kubernetes-objects/imperative-
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
i'm taking this page docs/tasks/manage-kubernetes-objects/declarative-
may i change this file:
thanks feel free to raise the PR and link this issue
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I take this page :
please let me change another part. I will try to change this file
sure just mention this issue number when you raise the pull request /reopen
Reopened this issue. <detailsIn response to : please let me change another part sure just mention this issue number when you raise the pull request 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-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: <!-- body --> <ins> ## Загальний процес 1. Виберіть одне з [найбільш витребуваних ішьюзів](https://github.com/kubernetes-i18n-ukrainian/website/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+no%3Aassignee+label%3A%22most+wanted%22) або [будь-яке ішью](https://github.com/kubernetes-i18n-ukrainian/website/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+no%3Aassignee) і залиште в ньому коментар на кшталт "Працюю над цим". Ми надішлемо вам запрошення до організації  та закріпимо цей ішьюз за вами.</sup> 2. Зробіть форк [k/website](https://github.com/kubernetes/website). 3. Прочитайте цей документ. 4. Перекладіть 5. Створіть пул-реквест в [k/website](https://github.com/kubernetes/website). Якщо вам знадобиться допомога, зареєструйтеся в [Slack Kubernetes](https://slack.k8s.io/), приєднайтеся до каналу [`#kubernetes-docs-uk`](https://kubernetes.slack.com/archives/CSKCYN138) і спитайте там. ### Отримання допомоги Якщо ви виявили проблеми з перекладеним вмістом, [створіть проблему на k/website](https://github.com/kubernetes/website/issues/new/choose) за допомогою `/language uk`. [kubernetes-i18n-ukrainian/website](https://github.com/kubernetes-i18n-ukrainian/website) слід використовувати лише для спрощення процесу локалізації. ### Існуючі проблеми/оновлення локалізації Якщо ви виявили проблеми з перекладеним вмістом і не можете негайно їх виправити, [створіть ішью у k/website](https://github.com/kubernetes/website/issues/new/choose) з описом що не так, на якій сторінці (посилання) і додайте в опис ішью з нового рядка `/language uk`. [kubernetes-i18n-ukrainian/website](https://github.com/kubernetes-i18n-ukrainian/website) слід використовувати лише для спрощення процесу локалізації. </ins> ## Правила перекладу {#правила-перекладу} * Скопіюйте оригінал і додайте його перед перекладом у якості коментаря. Це потрібно для спрощення відслідковування змін і процесу ревью. Приклади: [для Markdown](https://github.com/kubernetes/website/blob/7774cc9f3582c5f94e40245cdd5855e3c206177e/content/uk/docs/tutorials/hello-minikube.md#L23-L35), [для YAML](https://github.com/kubernetes/website/blob/7774cc9f3582c5f94e40245cdd5855e3c206177e/content/uk/docs/tutorials/hello-minikube.md#L8-L14).

Hey folks! to one of or .<br<supIf you have troubles with assign - just leave message in issue like "Work on this" and I send invite to org and assign this issue to you</supfork of . . . PR to . If you need any help - join channel in and feel free to ask. If you found any issues with translated content - with . should be used only for simplify localization progress. /assign /language uk /kind feature /priority backlog /lifecycle frozen
/area localization
Hi As a sig-docs localization subproject lead, I would like to check if this issue remains useful and if there's a general willingness to keep it open as is. (sig-docs is endeavoring to manage the quantity of open issues.)
Hi If you can suggest how to better point newcomers to what that should do - I'm all ears. In theory, it could be moved to , but I'm not sure that someone will go to it, as in repo README there are no mentions that in localization README could be something specific for localization, and "go check it first and only then general contribution guides"
Hi :) Thanks for the feedback. I think the Ukrainian team can create and share the guide to tentative contributors. And feel free to utilize README- for something specific for localization. Also, you can keep this issue as well if you think it is still useful. We are just checking if there is not useful open issues.


Question: <!-- image source for flowchart: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit --> <del> {{< figure src="/docs/concepts/extend-kubernetes/flowchart.png" </del> <ins> {{< figure src="/docs/concepts/extend-kubernetes/flowchart.svg" </ins> alt="Flowchart with questions about use cases and guidance for implementers. Green circles indicate yes; red circles indicate no." class="diagram-large" caption="Flowchart guide to select an extension approach" >}}

In the "Extension point choice flowchart", answering yes to the first questions leads to: Go the "Adding APIs" Section" There's a grammar error and a punctuation error, but major problem is that there is no such section on that page. It should read: Go to "API extensions"
Page related issue /language en /sig docs
This issue is talking about the first section of this diagram at given page ! /kind feature
Thank you for your reply but basically this approach is not the good practice The issue has been defined by the and the link to redirect to that page is not been provided so it has been provided by and you are giving the screenshot of that issue means it does not looks good. Requesting you for the good approach. Its asking like the issue is denoted by the description and then by link and then by image.
When i saw this issue, it was having relevant explanation, and link of the page by niranjan but i felt an image is missing to understand the issue better like - where this "Go the adding API server is written" in whole page and where we need to make change. So, i just one image. Generally, i don't put pic of an issue like this. When i approach an issue i first try to understand it, then verify it then label it and then try to discuss about its causes and possible solutions in proper way that won't look odd to anyone. But here forgive me if this looked odd to you, thank you for your feedback. Now i will take care even more.
/priority backlog /triage accepted For more tips about diagram improvements, see
/retitle Wrong wording in diagram at
Hi! I think I'll be able to solve this one. Also, I think this diagram's made using instead of I should remake it using the same tool, right? /assign
Using is fine It'd be nice to also use Kubernetes colors - maybe a second PR?
That sounds good! Sure, I can create a second PR after this one. And just to clarify, should I open a new issue for it, or can I proceed directly with the pull request? I'm a new contributor to the Kubernetes project :)
You can proceed directly with a PR, no need to raise a new issue for it.


Question: Check your pods' IPs: ```shell <del> kubectl get pods -l run=my-nginx -o yaml | grep podIP podIP: 10.244.3.4 podIP: 10.244.2.5 </del> <ins> kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs POD_IP [map[ip:10.244.3.4]] [map[ip:10.244.2.5]] </ins> ``` You should be able to ssh into any node in your cluster and use a tool such as `curl` to make queries against both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same `containerPort`, and access them from any other pod or node in your cluster using the assigned IP address for the Service. If you want to arrange for a specific port on the host Node to be forwarded to backing Pods, you can - but the networking model should mean that you do not need to do so.

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 section tells to run the following command: kubectl get pods -l run=my-nginx -o yaml | grep podIP When I run this command, I get the following output: % kubectl get pods -l run=my-nginx -o yaml | grep podIP f:podIP: {} f:podIPs: podIP: 172.17.0.6 podIPs: f:podIP: {} f:podIPs: podIP: 172.17.0.7 podIPs: Proposed Solution: I'd use -custom-columns rather than grep to obtain the pods IP: kubectl get pods -l run=my-nginx -o custom- Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: <ins> --- title: CIDR id: cidr date: 2019-11-12 full_link: short_description: > CIDRは、IPアドレスの範囲を記述するための表記法であり、さまざまなネットワークを構成するために使用されています。 aka: tags: - networking --- CIDR(Classless Inter-Domain Routing)はIPアドレスの範囲を記述するための表記法であり、さまざまなネットワークを構成するために使用されています。 <!--more--> Kubernetesでは、各{{< glossary_tooltip text="Node" term_id="node" >}}に対して、CIDRで記述されている開始アドレスとサブネットマスクを通してIPアドレスの範囲が割り当てられます。これにより、Nodeは各{{< glossary_tooltip text="Pod" term_id="pod" >}}に一意のIPアドレスを割り当てることができます。CIDRはもともとIPv4の概念でしたが、IPv6もサポートされるように拡張されています。 </ins>

This is a Feature Request What would you like to be Translate into Japanese Why is this needed There is no Japanese translation for this page Comments File to translate: Original: Japanese Localization document:
/area localization /language ja /good-first-issue
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 : /area localization /language ja /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
/triage accepted
/assign


Question: these Pod Security Standards: ```shell <del> kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml </del> <ins> kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.24.0 --config /tmp/pss/cluster-config.yaml </ins> ``` The output is similar to this: ``` Creating cluster "psa-with-cluster-pss" ... <del> ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 </del> <ins> ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 </ins> ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹

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: Apply Pod Security Standards at the Cluster Level documents Pod Security admission defaults, but for Kubernetes v1.23 rather than any more recent release. Proposed Solution: Either: Edit to automatically render with the version of Kubernetes being documented Update for Kubernetes v1.24 Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /priority backlog /lifecycle frozen /triage accepted
What would need to change here? The Kubernetes minor version in the commands or also the version in the intro paragraph? (wouldn't that remain 1.23 since that's when the feature went beta?)
The tutorial shows you how to deploy a v1.23.x cluster; it should be v1.24. Maybe if we don't specify any version explicitly, that's good enough (I haven't checked, and I'm not very familiar with ). Making that version always match the latest release is left as an exercise for the reaser.
Hi, I have a question if we automatically render the Kubernetes version being documented for the page, would it be okay to mention something along the lines of : ? Thanks.
You can use this shortcode to show the version: See for an example.
Great, now I can try to work on this issue on the lines of the example. Thanks. /assign


Question: ### Security <del> Enabling the GenericEphemeralVolume feature allows users to create PVCs indirectly if they can create Pods, even if they do not have permission to create PVCs directly. Cluster administrators must be aware of this. If this does not fit their security model, they should use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) </del> <ins> Using generic ephemeral volumes allows users to create PVCs indirectly if they can create Pods, even if they do not have permission to create PVCs directly. Cluster administrators must be aware of this. If this does not fit their security model, they should use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) </ins> that rejects objects like Pods that have a generic ephemeral volume. The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#storage-resource-quota)

It is quite unclear from that the feature "GenericEphemeralVolume" is a feature gate because its design does not follow the guideline. The following steps should be done: write the feature gate name as inline code, e.g. change the wording from "feature" to "feature gate" Also there is no information about the components on which this feature gate can be enabled. But! This feature gate is only in . Looks like it's not a feature gate now. Consider removing it from the page.
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 en
/retitle "Ephemeral Volumes" page references the usage of a deprecated feature gate
/sig storage
feature gate has been removed in , the text needs to be updated.
/assign


Question: --- title: 使用命令式的方式管理 Kubernetes 对象 <del> redirect_from: - "/docs/concepts/tools/kubectl/object-management-using-imperative-commands/" - "/docs/concepts/tools/kubectl/object-management-using-imperative-commands.html" </del> --- {% capture overview %}

This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: This link: redirects to this page: The link is found here: Proposed Solution: Fix the redirect for /docs/user-guide/working-with-resources Page to Update: Redirect for
Yeah, it's confusing. Why it's P3? How hard to fix it? How I can help?
I know what the problem is and will submit a PR shortly. None of the pages in the /cn directory should have the directive at the top of the page. For example, currently, /cn/docs/tutorials/object-management-kubectl/object- has this set at the top of the page:
Wow! Thank you!!
Ok, nothing should be redirected to the /cn pages anymore. Cheers


Question: 更改 `/var/lib/kubelet/config.conf` 或 `/var/lib/kubelet/kubeadm-flags.env` 后需要重启 kubelet。 <del> {{% heading "whatsnext" %}} </del> <ins> ## {{% heading "whatsnext" %}} </ins> <!-- - [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade) - [Customizing components with the kubeadm API](/docs/setup/production-environment/tools/kubeadm/control-plane-flags) - [Certificate management with kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs) <ins> - [Find more about kubeadm set-up](/docs/reference/setup-tools/kubeadm/) </ins> --> - [升级 kubeadm 集群](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade) - [使用 kubeadm API 自定义组件](/zh-cn/docs/setup/production-environment/tools/kubeadm/control-plane-flags) <del> - [使用 kubeadm 管理证书](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs) </del>  No newline at end of file <ins> - [使用 kubeadm 管理证书](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs) - [进一步了解 kubeadm 设置](/zh-cn/docs/reference/setup-tools/kubeadm/) </ins>

Path: content/zh cn/docs/tasks/administrator cluster/kubeadm/kubeadm
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
In the submission, the English document was updated, but the Chinese document was not updated
/language zh
/assign
I want to synchronize this update to content/zh cn/docs/tasks/administrator cluster/kubeadm/kubeadm and translate it
/kind document
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /kind document Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-kind bug


Question: However, if the Pod has a `restartPolicy` of Never, and an init container fails during startup of that Pod, Kubernetes treats the overall Pod as failed. --> 如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 <del> 然而，如果 Pod 对应的 `restartPolicy` 值为 "Never"，Kubernetes 不会重新启动 Pod。 </del> <ins> 然而，如果 Pod 对应的 `restartPolicy` 值为 "Never"，并且 Pod 的 Init 容器失败， 则 Kubernetes 会将整个 Pod 状态设置为失败。 </ins> <!-- To specify an init container for a Pod, add the `initContainers` field into

If a Pod's init container fails, the kubelet repeatedly restarts that init container until it succeeds. However, if the Pod has a restartPolicy of Never, and an init container fails during startup of that Pod, Kubernetes treats the overall Pod as failed. Pod Init kubelet Init Pod restartPolicy "Never"Kubernetes Pod “restartPolicy” podPodKuneletPodFailedInit container
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
/triage accepted
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /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
/language chinese
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /language chinese 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
/language zh
/assign


Question: The CertificateSigningRequest object includes a PEM-encoded PKCS#10 signing request in the `spec.request` field. The CertificateSigningRequest denotes the _signer_ (the recipient that the request is being made to) using the `spec.signerName` field. <ins> Note that `spec.signerName` is a required key after api version `certificates.k8s.io/v1`. </ins> Once created, a CertificateSigningRequest must be approved before it can be signed. Depending on the signer selected, a CertificateSigningRequest may be automatically approved

This is a Bug Report Problem: Doc is not aligned with latest kubernetes version 1.19.2: With version 1.19.2, is mandatory. Also signer is not supported in the list at: Proposed Solution: Specify in yaml definition Remove section Page to Update:
Just checked, the is a required field since 1.19.0 in group, but it is not required in the group. It makes sense to fix the example so that the YAML works. /sig auth
changed the apiVersion without actually updating required fields for v1
cc
About proposal "Remove section" of this issue, the v1.19 release notes indicates: Ref: Can you create a PR for this?
The documentation should remain until v1beta1 is no longer supported
I am happy to create a PR, but I am not able to push a branch to this repo. I have already signed CLA but still get: Any idea? Did I miss something in contribution doc? I will have a look at that again.
push it to your own clone, then use github to raise a pull request.
Great thanks. PR on the way then. :)


Question: criSocket: "/var/run/dockershim.sock"   taints:     - key: "kubeadmNode"        value: "master"         value: "someValue"        effect: "NoSchedule"   kubeletExtraArgs:     v: 4

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: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc


Question: /docs/contribute/write-new-topic/        /docs/home/contribute/write-new-topic/ 301 /docs/contribute/start/        /docs/contribute/ 301 /docs/contribute/intermediate/        /docs/contribute/ 301 <ins> /docs/contribute/new-content/overview/        /docs/contribute/new-content/ 301 </ins> /docs/deprecate/     /docs/reference/using-api/deprecation-policy/ 301 /docs/deprecated/     /docs/reference/using-api/deprecation-policy/ 301

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 Copy the page contents from into Redirect to (edit ) Delete Why is this needed The page at is an overview for the “Contributing new content” new section. Making this change means that is detailed, rather than blank. Comments /language en /good-first-issue /sig contributor-experience
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 : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --- Copy the page contents from into Redirect to The page at is an overview for the “Contributing new content” new section. Making this change means that is detailed, rather than blank. /language en /good-first-issue /sig contributor-experience 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
Please try some other alternatives. Let's be cautious when moving pages. Every relocation has to be replicated into all localizations. It may look straightforward for English to add a redirect entry. The fact is we may need to a dozen of redirect entries for all localizations. I don't see a compelling reason to move pages like this.
Perhaps it'd help to have some tooling to make it easy to copy redirects to a localization? Would that toil reduction change your mind
hello i want to work on this issue.
/assign
Hi , Happy to take care of this, but to be safe... Was there a consensus on how to handle the redirects for this issue? Thank you.
/triage accepted what would you like to know about redirects?
/assign
/assign
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
is this issue still open? if yes, can I contribute to this?


Question: Overhead represents the resource overhead associated with running a pod for a given RuntimeClass. This field will be autopopulated at admission time by the RuntimeClass admission controller. If the RuntimeClass admission controller is enabled, overhead must not be set in Pod create requests. The RuntimeClass admission controller will reject Pod create requests which have the overhead already set. If RuntimeClass is configured and selected in the PodSpec, Overhead will be set to the value defined in the corresponding RuntimeClass, otherwise it will remain unset and treated as zero. More info: https://git.k8s.io/enhancements/keps/sig-node/688-pod-overhead/README.md This field is beta-level as of Kubernetes v1.18, and is only honored by servers that enable the PodOverhead feature.  ### Alpha level - **ephemeralContainers** ([]<a href="{{< ref "../workload-resources/pod-v1#EphemeralContainer" >}}">EphemeralContainer) *Patch strategy: merge on key `name`* List of ephemeral containers run in this pod. Ephemeral containers may be run in an existing pod to perform user-initiated actions such as debugging. This list cannot be specified when creating a pod, and it cannot be modified by updating the pod spec. In order to add an ephemeral container to an existing pod, use the pod's ephemeralcontainers subresource. This field is beta-level and available on clusters that haven't disabled the EphemeralContainers feature gate.  ### Deprecated

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


Question: - lavalamp title: Controlling Access to the Kubernetes API content_type: concept <ins> weight: 50 </ins> --- <!-- overview -->

This is a Feature Request What would you like to be A section in the Kubernetes documentation to provide users with best practice guidelines and references to Kubernetes projects and solutions for multi-tenancy. This can be a new section in . Why is this needed Kubernetes is commonly used by multiple teams and to run multiple applications. The has been chartered with defining multi-tenancy models for Kubernetes and making these easy to consume for end users. The group has produced multiple projects like , , and and published blog posts on and the projects (, ). The HNC and Virtual Cluster projects have “graduated” from the working group and are now managed under SIG-auth and SIG-cluster-lifecycle. However, multi-tenancy remains a confusing and complex topic for Kubernetes users, especially beginners. Having a section on multi-tenancy in the Kubernetes documentation, with links to projects, would be helpful to all users. Comments If this seems like a good idea, the Multi-Tenancy WG can take the lead to propose a draft document. cc:
Happy for multitenancy WG to take this forward - also, that WG is welcome to triage this as accepted. Please also explore whether you can put new content within three of the existing sections: and, that way, avoid adding a new section to the concept list - we already have quite a few. of course, it's also fine to add new Task or Reference pages that cover multi-tenancy aspects.
/language en
/triage accepted
See also
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
/wg multi-tenancy
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg multi-tenancy 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
/wg multitenancy


Question: 1. `kubernetes/website` 리포지터리 내 [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에 여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다. <del> {{< note >}} 자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-reviews` 에 추가한다. {{< /note >}} 1. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에 </del> <ins> {{< note >}} 자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-reviews` 에 추가한다. {{< /note >}} 2. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에 </ins> 나열된 사용자 이름)에게 지정한다. 승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면,

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In - , number is wrong in numbered list. ! Proposed Solution: Fix indent in Page to Update: - <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/kind cleanup /language ko /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 : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: In - , number is wrong in numbered list. Fix indent in - <!--Kubernetes Version:--/language ko /good-first-issue </details
/assign
GitHub didn't allow me to assign the following users: yuswift. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
/triage accepted


Question: [コンセプト](/ja/docs/concepts/)では、Kubernetesのアーキテクチャと各コンポーネントの動作について説明し、[セットアップ](/ja/docs/setup/)では、使い始めるための実用的な手順を提供しています。 [タスク](/ja/docs/tasks/) は、よく使われるタスクの実行方法を示し、 [チュートリアル](/ja/docs/tutorials/)は、実世界の業界特有、またはエンドツーエンドの開発シナリオ、より包括的なウォークスルーとなります。 <del> [リファレンス](/ja/docs/reference/)セクションでは、[Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)や[`kubectl`](/docs/reference/kubectl/overview/)などのコマンドラインインターフェース(CLI)に関する詳しいドキュメントが提供されています。 </del> <ins> [リファレンス](/ja/docs/reference/)セクションでは、[Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)や[`kubectl`](/docs/reference/kubectl/)などのコマンドラインインターフェース(CLI)に関する詳しいドキュメントが提供されています。 </ins> ## ヘルプ!私の質問はカバーされていません!今すぐ助けてください!

This is a Feature Request What would you like to be We need to update according to the English text, because it is outdated. Why is this needed "Questions", "Stack Overflow" and "Bugs and feature requests" sections are outdated. Questions: Change the URL /docs/reference/kubectl/overview/ to /docs/reference/kubectl/ for . Stack Overflow: Update the statement for how to ask a new question. Bugs and feature requests: Change "Docker version" to "container runtime version". Comments /language ja
/triage accepted
/assign


Question: args: ["-c", "while true; do echo hello; sleep 10;done"] ``` <del> ## Notes This table summarizes the field names used by Docker and Kubernetes. |              Description               |    Docker field name   | Kubernetes field name | |----------------------------------------|------------------------|-----------------------| |  The command run by the container      |   Entrypoint           |      command          | |  The arguments passed to the command   |   Cmd                  |      args             | When you override the default Entrypoint and Cmd, these rules apply: * If you do not supply `command` or `args` for a Container, the defaults defined in the Docker image are used. * If you supply a `command` but no `args` for a Container, only the supplied `command` is used. The default EntryPoint and the default Cmd defined in the Docker image are ignored. * If you supply only `args` for a Container, the default Entrypoint defined in the Docker image is run with the `args` that you supplied. * If you supply a `command` and `args`, the default Entrypoint and the default Cmd defined in the Docker image are ignored. Your `command` is run with your `args`. Here are some examples: | Image Entrypoint   |    Image Cmd     | Container command   |  Container args    |    Command run   | |--------------------|------------------|---------------------|--------------------|------------------| |     `[/ep-1]`      |   `[foo bar]`    |   <not set>   |   <not set>  | `[ep-1 foo bar]` | |     `[/ep-1]`      |   `[foo bar]`    |      `[/ep-2]`      |   <not set>  |     `[ep-2]`     | |     `[/ep-1]`      |   `[foo bar]`    |   <not set>   |     `[zoo boo]`    | `[ep-1 zoo boo]` | |     `[/ep-1]`      |   `[foo bar]`    |   `[/ep-2]`         |     `[zoo boo]`    | `[ep-2 zoo boo]` | </del> ## {{% heading "whatsnext" %}} * Learn more about [configuring pods and containers](/docs/tasks/). * Learn more about [running commands in a container](/docs/tasks/debug-application-cluster/get-shell-running-container/). * See [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).

URL: File: /tasks/inject-data-application/define-command-argument- Remove the entire Notes section. Clean up the page so that there's no mention of a specific runtime. /sig docs /language en
I would remove the entire section. Docker is far from the only alternative to Kubernetes. If someone wanted to, we could accept a blog article that compares Docker, Kubernetes, Nomad, etc for how you specify these things. But it's fine if that blog is never submitted. /triage accepted
to me this is more about comparing Docker Swarm to Kubernetes. I think it's a good bit of tidying but I'm not sure it's needed for the dockershim removal work.


Question: --- reviewers: <del> title: Configuring kubelet Garbage Collection </del> <ins> title: Garbage collection for container images </ins> content_type: concept weight: 70 --- <!-- overview --> <del> Garbage collection is a helpful function of kubelet that will clean up unused images and unused containers. Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes. </del> <ins> Garbage collection is a helpful function of kubelet that will clean up unused [images](/docs/concepts/containers/#container-images) and unused [containers](/docs/concepts/containers/). Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes. </ins> External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist.

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 a page about performing a particular task, but it lives in the Concepts section. Tasks should be in the tasks section. Proposed Solution: Change the title of the page to “Garbage collection for container images” Hyperlink from within to the page (remember, this PR will just cover the English localization) Page to Update: Additional Information: /kind cleanup /language en /sig node /help Relevant to issue It is OK to clean up the content of the page beyond what this issue describes. Check whether it makes sense to remove the section. This could be because we or because the information is out of date.
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 : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: is a page about performing a particular task, but it lives in the Concepts section. Tasks should be in the tasks section. Change the title of the page to “Garbage collection for container images” Move the page inside Additional Information: /kind cleanup /language en /sig node /help Check whether it makes sense to remove the section. This could be because we or because the information is out of date. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
No. I don't agree to this movement. The reason is that garbage collection is an administrator job. However, is mostly about concepts an end user need to know.

If needed, we can add links to make sure users can learn what's happening behind the scene. Page movement like this is harmful rather than helpful.
I've revised the issue description /retitle Retitle “Configuring kubelet Garbage Collection” and add incoming links
/assign
To confirm, the goal of this issue is to: retitle the GC concept page (not move the page or retitle the file)? link from the containers concept page to the GC concept page
Note: I found 2 Garbage Collection concept pages: The "cluster-administration" GC concept page focuses on the kubelet flags. This page is not listed in the "cluster-administration" index page. Could the index page list the GC page under the "Managing a Cluster" section? A side note, where is defined?


Question: <ins> --- title: スケジューリングフレームワーク content_type: concept weight: 90 --- <!-- overview --> {{< feature-state for_k8s_version="v1.19" state="stable" >}} スケジューリングフレームワークはKubernetesのスケジューラーに対してプラグイン可能なアーキテクチャです。 このアーキテクチャは、既存のスケジューラーに新たに「プラグイン」としてAPI群を追加するもので、プラグインはスケジューラー内部にコンパイルされます。このAPI群により、スケジューリングの「コア」の軽量かつ保守しやすい状態に保ちながら、ほとんどのスケジューリングの機能をプラグインとして実装することができます。このフレームワークの設計に関する技術的な情報についてはこちらの[スケジューリングフレームワークの設計提案][kep]をご覧ください。 [kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md <!-- body --> # フレームワークのワークフロー スケジューリングフレームワークは、いくつかの拡張点を定義しています。スケジューラープラグインは、1つ以上の拡張点で呼び出されるように登録します。これらのプラグインの中には、スケジューリングの決定を変更できるものから、単に情報提供のみを行うだけのものなどがあります。 この1つのPodをスケジュールしようとする各動作は**Scheduling Cycle**と**Binding Cycle**の2つのフェーズに分けられます。 ## Scheduling Cycle & Binding Cycle Scheduling CycleではPodが稼働するNodeを決定し、Binding Cycleではそれをクラスターに適用します。この2つのサイクルを合わせて「スケジューリングコンテキスト」と呼びます。 Scheduling CycleではPodに対して1つ1つが順番に実行され、Binding Cyclesでは並列に実行されます。 Podがスケジューリング不能と判断された場合や、内部エラーが発生した場合、Scheduling CycleまたはBinding Cycleを中断することができます。その際、Podはキューに戻され再試行されます。 ## 拡張点 次の図はPodに対するスケジューリングコンテキストとスケジューリングフレームワークが公開する拡張点を示しています。この図では「Filter」がフィルタリングのための「Predicate」、「Scoring」がスコアリングのための「Priorities」機能に相当します。 1つのプラグインを複数の拡張点に登録することで、より複雑なタスクやステートフルなタスクを実行することができます。 {{< figure src="/images/docs/scheduling-framework-extensions.png" title="scheduling framework extension points" class="diagram-large">}} ### QueueSort {#queue-sort} これらのプラグインはスケジューリングキュー内のPodをソートするために使用されます。このプラグインは、基本的に`Less(Pod1, Pod2)`という関数を提供します。また、このプラグインは、1つだけ有効化できます。 ### PreFilter {#pre-filter} これらのプラグインは、Podに関する情報を前処理したり、クラスターやPodが満たすべき特定の条件をチェックするために使用されます。もし、PreFilterプラグインのいずれかがエラーを返した場合、Scheduling Cycleは中断されます。 ### Filter FilterプラグインはPodを実行できないNodeを候補から除外します。各Nodeに対して、スケジューラーは設定された順番でFilterプラグインを呼び出します。もし、いずれかのFilterプラグインが途中でそのNodeを実行不可能とした場合、残りのプラグインではそのNodeは呼び出されません。Nodeは同時に評価されることがあります。 ### PostFilter {#post-filter} これらのプラグインはFilterフェーズで、Podに対して実行可能なNodeが見つからなかった場合にのみ呼び出されます。このプラグインは設定された順番で呼び出されます。もしいずれかのPostFilterプラグインが、あるNodeを「スケジュール可能(Schedulable)」と目星をつけた場合、残りのプラグインは呼び出されません。典型的なPostFilterの実装はプリエンプション方式で、他のPodを先取りして、Podをスケジューリングできるようにしようとします。 ### PreScore {#pre-score} これらのプラグインは、Scoreプラグインが使用する共有可能な状態を生成する「スコアリングの事前」作業を行うために使用されます。このプラグインがエラーを返した場合、Scheduling Cycleは中断されます。 ### Score {#scoring} これらのプラグインはフィルタリングのフェーズを通過したNodeをランク付けするために使用されます。スケジューラーはそれぞれのNodeに対して、それぞれのscoringプラグインを呼び出します。スコアの最小値と最大値の範囲が明確に定義されます。[NormalizeScore](#normalize-scoring)フェーズの後、スケジューラーは設定されたプラグインの重みに従って、全てのプラグインからNodeのスコアを足し合わせます。 ### NormalizeScore {#normalize-scoring} これらのプラグインはスケジューラーが最終的なNodeの順位を計算する前にスコアを修正するために使用されます。この拡張点に登録されたプラグインは、同じプラグインの[Score](#scoring)の結果を使用して呼び出されます。各プラグインはScheduling Cycle毎に、1回呼び出されます。 例えば、`BlinkingLightScorer`というプラグインが、点滅する光の数に基づいてランク付けをするとします。 ```go func ScoreNode(_ *v1.pod, n *v1.Node) (int, error) { return getBlinkingLightCount(n) } ``` ただし、`NodeScoreMax`に比べ、点滅をカウントした最大値の方が小さい場合があります。これを解決するために、`BlinkingLightScorer`も拡張点に登録する必要があります。 ```go func NormalizeScores(scores map[string]int) { highest := 0 for _, score := range scores { highest = max(highest, score) } for node, score := range scores { scores[node] = score*NodeScoreMax/highest } } ``` NormalizeScoreプラグインが途中でエラーを返した場合、Scheduling Cycleは中断されます。 {{< note >}} 「Reserveの事前」作業を行いたいプラグインは、NormalizeScore拡張点を使用してください。 {{< /note >}} ### Reserve {#reserve} Reserve拡張を実装したプラグインには、ReserveとUnreserve　という2つのメソッドがあり、それぞれ`Reserve` と`Unreserve`と呼ばれる2つの情報スケジューリングフェーズを返します。 実行状態を保持するプラグイン（別名「ステートフルプラグイン」）は、これらのフェーズを使用して、Podに対してNodeのリソースが予約されたり予約解除された場合に、スケジューラーから通知を受け取ります。 Reserveフェーズは、スケジューラーが実際にPodを指定されたNodeにバインドする前に発生します。このフェーズはスケジューラーがバインドが成功するのを待つ間にレースコンディションの発生を防ぐためにあります。 各Reserveプラグインの`Reserve`メソッドは成功することも失敗することもあります。もしどこかの`Reserve`メソッドの呼び出しが失敗すると、後続のプラグインは実行されず、Reserveフェーズは失敗したものとみなされます。全てのプラグインの`Reserve`メソッドが成功した場合、Reserveフェーズは成功とみなされ、残りのScheduling CycleとBinding Cycleが実行されます。 Unreserveフェーズは、Reserveフェーズまたは後続のフェーズが失敗した場合に、呼び出されます。この時、**全ての**Reserveプラグインの`Unreserve`メソッドが、`Reserve`メソッドの呼び出された逆の順序で実行されます。このフェーズは予約されたPodに関連する状態をクリーンアップするためにあります。 {{< caution >}} `Unreserve`メソッドの実装は冪等性を持つべきであり、この処理で問題があった場合に失敗させてはなりません。 {{< /caution >}} <!-- ### Permit --> ### Permit _Permit_ プラグインは、各PodのScheduling Cycleの終了時に呼び出され、候補Nodeへのバインドを阻止もしくは遅延させるために使用されます。permitプラグインは次の3つのうちどれかを実行できます。 1.  **承認(approve)**  全てのPermitプラグインから承認(approve)されたPodは、バインド処理へ送られます。 1.  **拒否(deny)**  もしどれか1つのPermitプラグインがPodを拒否(deny)した場合、そのPodはスケジューリングキューに戻されます。 これは[Reserveプラグイン](#reserve)内のUnreserveフェーズで呼び出されます。 1.  **待機(wait)** (タイムアウトあり)  もしPermitプラグインが「待機(wait)」を返した場合、そのPodは内部の「待機中」Podリストに保持され、このPodに対するBinding Cycleは開始されるものの、承認(approve)されるまで直接ブロックされます。もしタイムアウトが発生した場合、この**待機(wait)**は**deny**へ変わり、対象のPodはスケジューリングキューに戻されると共に、[Reserveプラグイン](#reserve)のUnreserveフェーズが呼び出されます。 {{< note >}} どのプラグインも「待機中」Podリストにアクセスして、それらを承認(approve)することができますが(参考:[`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle))、その中の予約済みPodのバインドを承認(approve)できるのはPermitプラグインだけであると予想します。承認(approve)されたPodは、[PreBind](#pre-bind)フェーズへ送られます。 {{< /note >}} ### PreBind {#pre-bind} これらのプラグインは、Podがバインドされる前に必要な作業を行うために使用されます。例えば、Podの実行を許可する前に、ネットワークボリュームをプロビジョニングし、Podを実行予定のNodeにマウントすることができます。 もし、いずれかのPreBindプラグインがエラーを返した場合、Podは[拒否](#reserve)され、スケジューリングキューに戻されます。 ### Bind これらのプラグインはPodをNodeにバインドするために使用されます。このプラグインは全てのPreBindプラグインの処理が完了するまで呼ばれません。それぞれのBindプラグインは設定された順序で呼び出されます。このプラグインは、与えられたPodを処理するかどうかを選択することができます。もしPodを処理することを選択した場合、**残りのBindプラグインは全てスキップされます。** ### PostBind {#post-bind} これは単に情報提供のための拡張点です。Post-bindプラグインはPodのバインドが成功した後に呼び出されます。これはBinding Cycleの最後であり、関連するリソースのクリーンアップに使用されます。 ## プラグインAPI プラグインAPIには2つの段階があります。まず、プラグインを登録し設定することです。そして、拡張点インターフェースを使用することです。このインターフェースは次のような形式をとります。 ```go type Plugin interface { Name() string } type QueueSortPlugin interface { Plugin Less(*v1.pod, *v1.pod) bool } type PreFilterPlugin interface { Plugin PreFilter(context.Context, *framework.CycleState, *v1.pod) error } // ... ``` ## プラグインの設定 スケジューラーの設定でプラグインを有効化・無効化することができます。Kubernetes v1.18以降を使用しているなら、ほとんどのスケジューリング[プラグイン](/docs/reference/scheduling/config/#scheduling-plugins)は使用されており、デフォルトで有効になっています。 デフォルトのプラグインに加えて、独自のスケジューリングプラグインを実装し、デフォルトのプラグインと一緒に使用することも可能です。詳しくは[スケジューラープラグイン](https://github.com/kubernetes-sigs/scheduler-plugins)をご覧下さい。 Kubernetes v1.18以降を使用しているなら、プラグインのセットをスケジューラープロファイルとして設定し、様々な種類のワークロードに適合するように複数のプロファイルを定義することが可能です。詳しくは[複数のプロファイル](/docs/reference/scheduling/config/#multiple-profiles)をご覧下さい。 </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Japanese. Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted


Question:
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>

  Attend KubeCon NA virtually on November 17-20, 2020   Attend KubeCon North America on October 11-15, 2021

  Attend KubeCon EU virtually on May 4 – 7, 2021   Revisit KubeCon EU 2021

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In , when user clicks , ! user lands on , which is for KubeCon & CloudNativeCon North America 2021. Proposed Solution: In , [As-is] [To-be] Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/triage accepted


Question: Non-preempting pods may still be preempted by other, high-priority pods. <del> `PreemptionPolicy` defaults to `PreemptLowerPriority`, </del> <ins> `preemptionPolicy` defaults to `PreemptLowerPriority`, </ins> which will allow pods of that PriorityClass to preempt lower-priority pods (as is existing default behavior). <del> If `PreemptionPolicy` is set to `Never`, </del> <ins> If `preemptionPolicy` is set to `Never`, </ins> pods in that PriorityClass will be non-preempting. An example use case is for data science workloads. A user may submit a job that they want to be prioritized above other workloads, but do not wish to discard existing work by preempting running pods. <del> The high priority job with `PreemptionPolicy: Never` will be scheduled </del> <ins> The high priority job with `preemptionPolicy: Never` will be scheduled </ins> ahead of other queued pods, as soon as sufficient cluster resources "naturally" become free.

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In , the field is written, incorrectly, as (in some places). Proposed Solution: Fix the capitalization to camelCase. /sig scheduling Relevant as there's a plan to the feature. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /priority backlog
/triage accepted
/cc
/assgin
PR for GA list here:
(In my view), should wait for to merge.
Yes, I will add in to wait.


Question: I could've used any trace backend, but decided to use Jaeger, since it is one of the most popular open-source tracing projects.  I deployed [the Jaeger All-in-one container](https://hub.docker.com/r/jaegertracing/all-in-one) in my cluster, deployed [the OpenTelemetry collector](https://github.com/open-telemetry/opentelemetry-collector) on my control-plane node ([example](https://github.com/dashpole/dashpole_demos/tree/master/otel/controlplane)), and captured traces like this one: <del> ![Jaeger screenshot showing API server and etcd trace](https://user-images.githubusercontent.com/3262098/128613151-91cb925c-4886-4f05-a12a-771c6cbe9807.png) </del> <ins> ![Jaeger screenshot showing API server and etcd trace](/images/blog/2021-09-03-api-server-tracing/example-trace-1.png "Jaeger screenshot showing API server and etcd trace") </ins> The teal lines are from the API Server, and includes it serving a request to `/api/v1/nodes`, and issuing a grpc `Range` RPC to ETCD.  The yellow-ish line is from ETCD handling the `Range` RPC.

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: adds a blog article but the images are not hosted within ; they should be. Proposed Solution: Create a PR that adds those images (see other articles that use images for examples) into this repo, and change the article's Markdown source to use them. It might be easiest to make a directory for the article, again following how other articles do it. Page to Update: (after the 3rd of September 2021). It's OK to fix it now. Additional Information: /language en /area blog /kind cleanup /priority important-soon
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
/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 : /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
Hi, I would like to take this up /assign


Question: each kube-apiserver. You can inspect Leases owned by each kube-apiserver by checking for lease objects in the `kube-system` namespace <del> with the name `kube-apiserver-<sha256-hash>`. Alternatively you can use the label selector `k8s.io/component=kube-apiserver`: </del> <ins> with the name `kube-apiserver-<sha256-hash>`. Alternatively you can use the label selector `apiserver.kubernetes.io/identity=kube-apiserver`: </ins> ```shell <del> kubectl -n kube-system get lease -l k8s.io/component=kube-apiserver </del> <ins> kubectl -n kube-system get lease -l apiserver.kubernetes.io/identity=kube-apiserver </ins> ``` ``` NAME                                        HOLDER                                                                           AGE <del> kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a   kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a_9cbf54e5-1136-44bd-8f9a-1dcd15c346b4   5m33s kube-apiserver-dz2dqprdpsgnm756t5rnov7yka   kube-apiserver-dz2dqprdpsgnm756t5rnov7yka_84f2a85d-37c1-4b14-b6b9-603e62e4896f   4m23s kube-apiserver-fyloo45sdenffw2ugwaz3likua   kube-apiserver-fyloo45sdenffw2ugwaz3likua_c5ffa286-8a9a-45d4-91e7-61118ed58d2e   4m43s </del> <ins> apiserver-07a5ea9b9b072c4a5f3d1c3702        apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05        5m33s apiserver-7be9e061c59d368b3ddaf1376e        apiserver-7be9e061c59d368b3ddaf1376e_84f2a85d-37c1-4b14-b6b9-603e62e4896f        4m23s apiserver-1dfef752bcb36637d2763d1868        apiserver-1dfef752bcb36637d2763d1868_c5ffa286-8a9a-45d4-91e7-61118ed58d2e        4m43s </ins> ``` The SHA256 hash used in the lease name is based on the OS hostname as seen by that API server. Each kube-apiserver should be

The command showed nothing. But this command worked. It looks like the labels have been changed and now the example is different from the real state of version 1.27.3.
Page related to issue: /language en
/retitle Incorrect label in kubectl command for inspecting Leases for kube-apiserver
Judging from the k8s upstream code, this label has indeed been changed and the documentation needs to be updated. /cc for confirm
/sig apps
/assign
/sig api-machinery
/triage accepted
/assign


Question: - **rules.http.paths.pathType** (string), required <del> PathType determines the interpretation of the Path matching. PathType can be one of the following values: * Exact: Matches the URL path exactly. * Prefix: Matches based on a URL path prefix split by '/'. Matching is </del> <ins> PathType determines the interpretation of the Path matching. PathType can be one of the following values: * Exact: Matches the URL path exactly. * Prefix: Matches based on a URL path prefix split by '/'. Matching is </ins> done on a path element by element basis. A path element refers is the list of labels in the path split by the '/' separator. A request is a match for path p if every p is an element-wise prefix of p of the request path. Note that if the last element of the path is a substring of the last element in request path, it is not a match (e.g. /foo/bar matches /foo/bar/baz, but does not match /foo/barbaz). * ImplementationSpecific: Interpretation of the Path matching is up to the IngressClass. Implementations can treat this as a separate PathType or treat it identically to Prefix or Exact path types.

There is a display bug in section of and values are not displayed properly as is. ! I guess the list of values should be looking like this: Exact: Matches the URL path exactly. Prefix: Matches based on a URL path prefix split by '/'. Matching is done on a path element by element basis. A path element refers is the list of labels in the path split by the '/' separator. A request is a match for path p if every p is an element-wise prefix of p of the request path. Note that if the last element of the path is a substring of the last element in request path, it is not a match (e.g. /foo/bar matches /foo/bar/baz, but does not match /foo/barbaz). ImplementationSpecific: Interpretation of the Path matching is up to the IngressClass. Implementations can treat this as a separate PathType or treat it identically to Prefix or Exact path types. Implementations are required to support all path types.
/retitle Display bug in section of Ingress API referenc /sig docs /language en /triage accepted /priority backlog This could be seen as a feature request for the that generates API reference docs.
/retitle Display bug in section of Ingress API reference
/retitle Display bug in section of Ingress API referenc
/assign


Question: <ins> --- title: Check whether Dockershim deprecation affects you content_type: task reviewers: - SergeyKanzhelev weight: 20 --- <!-- overview --> The `dockershim` component of Kubernetes allows to use Docker as a Kubernetes's {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. Kubernetes' built-in `dockershim` component was deprecated in release v1.20. This page explains how your cluster could be using Docker as a container runtime, provides details on the role that `dockershim` plays when in use, and shows steps you can take to check whether any workloads could be affected by `dockershim` deprecation. ## Finding if your app has a dependencies on Docker {#find-docker-dependencies} If you are using Docker for building your application containers, you can still run these containers on any container runtime. This use of Docker does not count as a dependency on Docker as a container runtime. When alternative container runtime is used, executing Docker commands may either not work or yield unexpected output. This is how you can find whether you have a dependency on Docker: 1. Make sure no privileged Pods execute Docker commands. 2. Check that scripts and apps running on nodes outside of Kubernetes infrastructure do not execute Docker commands. It might be: - SSH to nodes to troubleshoot; - Node startup scripts; - Monitoring and security agents installed on nodes directly. 3. Third-party tools that perform above mentioned privileged operations. See [Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents) for more information. 4. Make sure there is no indirect dependencies on dockershim behavior. This is an edge case and unlikely to affect your application. Some tooling may be configured to react to Docker-specific behaviors, for example, raise alert on specific metrics or search for a specific log message as part of troubleshooting instructions. If you have such tooling configured, test the behavior on test cluster before migration. ## Dependency on Docker explained {#role-of-dockershim} A [container runtime](/docs/concepts/containers/#container-runtimes) is software that can execute the containers that make up a Kubernetes pod. Kubernetes is responsible for orchestration and scheduling of Pods; on each node, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} uses the container runtime interface as an abstraction so that you can use any compatible container runtime. In its earliest releases, Kubernetes offered compatibility with just one container runtime: Docker. Later in the Kubernetes project's history, cluster operators wanted to adopt additional container runtimes. The CRI was designed to allow this kind of flexibility - and the kubelet began supporting CRI. However, because Docker existed before the CRI specification was invented, the Kubernetes project created an adapter component, `dockershim`. The dockershim adapter allows the kubelet to interact with Docker as if Docker were a CRI compatible runtime. You can read about it in [Kubernetes Containerd integration goes GA](/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/) blog post. ![Dockershim vs. CRI with Containerd](/images/blog/2018-05-24-kubernetes-containerd-integration-goes-ga/cri-containerd.png) Switching to Containerd as a container runtime eliminates the middleman. All the same containers can be run by container runtimes like Containerd as before. But now, since containers schedule directly with the container runtime, they are not visible to Docker. So any Docker tooling or fancy UI you might have used before to check on these containers is no longer available. You cannot get container information using `docker ps` or `docker inspect` commands. As you cannot list containers, you cannot get logs, stop containers, or execute something inside container using `docker exec`. {{< note >}} If you're running workloads via Kubernetes, the best way to stop a container is through the Kubernetes API rather than directly through the container runtime (this advice applies for all container runtimes, not just Docker). {{< /note >}} You can still pull images or build them using `docker build` command. But images built or pulled by Docker would not be visible to container runtime and Kubernetes. They needed to be pushed to some registry to allow them to be used by Kubernetes. </ins>

This is a Feature Request I want to ask a new documentation section under describing various aspects of moving away from Dockershim to other runtimes. One document I am working with is: There are more sub-topics will be there. Is there any concerns with creating this section? It will be relatively short-lived, but definitely beneficial for k8s users. What would you like to be Section under regarding migrating away from Dockershim. Why is this needed Since this announcement: there are a still things needed clarification which raise questions. /sig node
A Task page is the right kind of content to add. Are you considering adding a section inside ? I would add that rather than one inside - the deeper structure can be OK so long as we make sure there are lots of links to it. When that content disappears, where will we redirect to? I assume we'd want to add redirects
what do you think of this: Is it the right structure?
Hi . I started to read through PR . The location under tasks seems fine, though, you could create a new sub-directory () under tasks so that the content is not lost in the section. The new section could be titled something like: "Manage Dockershim migration" or "Migrate from Dockershim". What do you think about creating an outline (in this issue) of the sub-tasks to include in this section?
this was my original idea of a location, but suggested to place it under the administer section. looking at the content, should it be moved to it's own section? Some topics like monitoring agents is more of an application management than administering of a cluster.
My concerns from before stand, but they're not hard don't-do-this objections.
/triage accepted anyway
Hi . I'll spend some time to read the PR and doc. After a quick read, I think it probably make sense to separate the content from the tasks. Again, it is a good idea to write an outline of the content. This may help to determine where to put the content once the content is created.
Hope this is okay: /assign


Question: `-o custom-columns=<spec>` | [カスタムカラム](#custom-columns)のコンマ区切りのリストを使用して、テーブルを表示します。 `-o custom-columns-file=<filename>` | `<filename>`ファイル内の[カスタムカラム](#custom-columns)のテンプレートを使用して、テーブルを表示します。 `-o json`     | JSON形式のAPIオブジェクトを出力します。 <del> `-o jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。 `-o jsonpath-file=<filename>` | `<filename>`ファイル内の[jsonpath](/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。 </del> <ins> `-o jsonpath=<template>` | [jsonpath](/ja/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。 `-o jsonpath-file=<filename>` | `<filename>`ファイル内の[jsonpath](/ja/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。 </ins> `-o name`     | リソース名のみを表示します。 `-o wide`     | 追加情報を含めて、プレーンテキスト形式で出力します。Podの場合は、Node名が含まれます。 `-o yaml`     | YAML形式のAPIオブジェクトを出力します。

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate reference/kubectl/jsonpath/ into Japanese. Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted


Question: be reserved for the system as a whole and for Kubernetes system daemons respectively. <del> {{< note >}} Before Kubernetes version 1.20, PID resource limiting with Node-level reservations required enabling the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` to work. {{< /note >}} </del> ## Pod PID limits Kubernetes allows you to limit the number of processes running in a Pod. You

This is a Bug Report <!--Required Information--From k8s v1.24 the and are no longer available as a feature gate in k8s. From v1.25 there is a separate document that contains information on feature gates that have been removed i.e. . In the and feature gate link to the page which is incorrect, instead of that, it should be page. The information for both feature gates is on the Feature Gates (removed) page not on the Feature Gates page. Proposed Solution: SupportNodePidsLimit and SupportPodPidsLimit feature gates should be linked to instead of Page to Update:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind documentation /assign
For GA'ed feature or deprecated feature, if the gate is removed, we may want to remove the linking texts altogether rather than having existing text pointing to the outdate gate names.
Hi Just want to confirm it: So for this, you want to remove the whole note section for both feature gates, because both feature gates are removed. Am I understanding right?
is it seems good to you?
I meant this: move the "removed" feature to the dedicated page, if this is not done yet. The "removed" features will stay there for the sole purpose of reference. For all texts (including notes) that reference these gates, remove those references. If a feature is deprecated and removed, those texts may well become invalid. If a feature is GA'ed and removed, those texts may be still valid, but the reference to the gate should disappear.
Thanks, for your response.
and both feature gates were graduated in v1.20 and removed in v1.23. Both are present on the dedicated page i.e. . So I will remove the reference to these gates.
I will create PR for it soon.
Fixed it here:


Question: {{< note >}} If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value. <ins> In that case, you can create a secret directly. See [Create a Secret by providing credentials on the command line](#create-a-secret-by-providing-credentials-on-the-command-line). </ins> {{< /note >}} ## Create a Secret based on existing credentials {#registry-secret-existing-credentials}

But the document doesn't say what to do in this kind of case. Creating a secret using --from-file in this case won't work; instead have to create the secret by passing the --docker-server etc arguments.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: <ins> id: volume name: Volume full-link: kubernetes.io/docs/concepts/storage/volumes/ related: - pod - container - secret tags: - core-object - fundamental short-description: > A directory containing data, accessible to the containers in a {% glossary_tooltip text="pod" term_id="pod" %}. long-description: > A Kubernetes volume lives as long as the {% glossary_tooltip text="pod" term_id="pod" %} that encloses it. Consequently, a volume outlives any {% glossary_tooltip text="containers" term_id="container" %} that run within the {% glossary_tooltip text="pod" term_id="pod" %}, and data is preserved across {% glossary_tooltip text="container" term_id="container" %} restarts. </ins>

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [x] Feature Request [ ] Bug Report Problem: Now that the revamped has been launched, we need to add more terms to the list. Proposed Solution: Add missing terms at Kubernetes doc sprints. Here is the original glossary list from : [ ] Aggregation Layer [ ] Annotation ( [x] Certificate ( [x] Cloud Controller Manager (CCM) [ ] Cloud Provider [ ] ConfigMap ( ) [ ] Container Environment Variable [ ] Container Lifecycle Hook [x] Controller Manager [x] Cron Job [x] Custom Resource Definition (formerly Third Party Resource) (Cheryl) [ ] DaemonSet (Brad) [x] Deployment [ ] Device Plugin [ ] Disruption [x] docker ( [x] Dynamic Volume Provisioning ( [x] Etcd (Tina) [ ] Extension [ ] Federation [ ] Garbage Collection [x] Horizontal Pod Autoscaling ( [ ] HostAliases [x] Image (Chris) [x] Ingress Resource [x] Init Container [x] Job (Ryan) [ ] kube-proxy [ ] kubelet ( [x] Label [ ] Logging [ ] Name [x] Namespace [ ] Network Plugin [x] Network Policy (Radhika) [x] Node [x] Persistent Volume (Tina) [x] Pod [ ] Pod Disruption Budget [ ] Pod Lifecycle [ ] Pod Preset [ ] Pod Priority [x] Pod Security Policy (Radhika) [ ] Preemption [ ] Proxy [x] Replica Set (Ivange) [ ] Replication Controller (Chris) [ ] Resource Quota ( [ ] rkt [x] Secret [x] Security Context ( [ ] Selector [x] Service [x] Service Account ( [x] Stateful Set (formerly Pet Set) [x] Storage Class [ ] supervisord [ ] Sysctls [ ] Taint [ ] Toleration [x] Volume (Jared) [x] Volume Plugin ( [x] fluentd ( Page to Update: Add YAML files to directory using the format outline in . They should then automatically show up in For example, has this: A glossary definition can refer to other glossary terms. Here's .

The definition of Deployment uses {% glossarytooltip %} to refer to the definition of Pod: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.9 <!--Additional Information:--
Third Party Resource has been deprecated. Custom Resource Definition now replaces it.
I just : [ ] Aggregation Layer [ ] Certificate [ ] Cloud Controller Manager (CCM) [ ] Cloud Provider [ ] Container Environment Variable [ ] Container Lifecycle Hook [ ] Controller Manager [ ] Custom Resource Definition [ ] Device Plugin [ ] Disruption [ ] Dynamic Volume Provisioning [ ] Extension [ ] Federation [ ] Garbage Collection [ ] HostAliases [ ] Init Container [ ] Label [ ] Logging [ ] Network Plugin [ ] Pod Disruption Budget [ ] Pod Lifecycle [ ] Pod Preset [ ] Pod Priority [ ] Preemption [ ] Proxy [ ] Selector [ ] Storage Class [ ] Sysctls [ ] Taint [ ] Toleration [x] Etcd
It would be nice to have a glossary for as well. Most users who search for CRDs would want to search for too.
It would be nice to add Volume Plugin to the list.
Label appears to already be to the glossary -
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 stale
/remove-lifecycle rotten still some terms left
would the label suit here? this also looks like something new contributors could tackle! :) might be nice as well.
Yes, for sure. The glossary is probably the easiest thing to contribute to, especially for new contributors. =)
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
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale fejta-bot <:
I would like to have a glossary for Most users who search for setting up custom rules for namespace access also search for
I updated your list and these are the ones that still haven't been written yet [ ] Device Plugin [ ] Disruption [ ] Extension [ ] Federation [ ] Garbage Collection [ ] HostAliases [ ] Logging [ ] Network Plugin [ ] Pod Disruption Budget [ ] Pod Lifecycle [ ] Pod Priority [ ] Preemption [ ] Proxy [ ] Sysctls
I would like to work on this
/assign
GitHub didn't allow me to assign the following users: sourabh1031. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
I worked on adding HostAliases, Pod Priority, Extension and Preemption to the Glossary page, Please feel free to pick others.
/language en
I suggest: update the issue description with a new list that clearly shows what terms are missing. (If it helps, I can draw up the list and then someone with edit access can paste it in).
Is it OK to skip terms for: Federation (deprecated) (not relevant to v1.15 cluster operators) ?
If the above 3 PRs get merged, I think it'd be OK to close this issue as implemented.
/priority backlog because most of the work is done
/status active
All remaining work (that is listed) is already started /remove-good-first-issue
Issues go stale after 90d of inactivity. Mark the issue as fresh with .

Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
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
Also see
is this OK to /close?
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Related: Add object to glossary


Question: ### 服务控制器   {#service-controller} {{< glossary_tooltip text="服务（Service）" term_id="service" >}}与受控的负载均衡器、 <del> IP 地址、网络包锅里煮、目标健康检查等云基础设施组件集成。 </del> <ins> IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。 </ins> 服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。 你所创建的 Service 资源会需要这些组件服务。

/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


Question: {{< blocks/kubernetes-features >}} <del> {{< blocks/case-studies >}} </del>  No newline at end of file <ins> {{< blocks/case-studies >}} </ins>

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In , when user clicks , ! user lands on , which is for KubeCon & CloudNativeCon North America 2021. Proposed Solution: In , [As-is] [To-be] Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/triage accepted


Question: ``` For more information about the `TracingConfiguration` struct, see <del> [API server config API (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/#apiserver-k8s-io-v1beta1-TracingConfiguration). </del> <ins> [API server config API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration). </ins> ## Stability

Hi, this page has a link which is 404, but I can't find this page in kubernetes website.
In this PR the page: has been removed. should point to the latest page link: /assign
/triage accepted
I could not find the description in the latest page link Is that missing?
Yes, I also checked this struct just now, it doesn't exist in the This struct was removed in version v1. Not sure about the upgrade status of this struct. /cc
There were some nits in the reference generator. We are fixing them and then regenerate the references.
TracingConfiguration is still alpha, and thus doesn't exist in the v1 version of the API.
/kind bug /language en
So do we need to create a new page containing the TracingConfiguration struct so that we can link to it? Or link to the kubernetes TracingConfiguration code line: Which one do you prefer or have a better suggestion?
I'll create a PR updating the config APIs. As for the TracingConfiguration type, it is only part of the v1alpha1 version. This means the current code is incorrect and the v1alpha1 reference needs to be back. This warrants a separate PR.
First PR created
Second PR created /assign


Question: ## GMSA limitations When using the [ContainerD runtime for Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) accessing restricted network shares via the GMSA domain identity fails. The container will recieve the identity of and calls from `nltest.exe /query` will work.  It is recommended to use the [Docker EE runtime](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee) if access to network shares is required.  The Windows Server team is working on resolving the issue in the Windows Kernel and will release a patch to resolve this issue in the future. Look for updates on the [Microsoft Windows Containers issue tracker](https://github.com/microsoft/Windows-Containers/issues/44). --> <del> ## GMSA 的局限 </del> <ins> ## GMSA 的局限  {#gmsa-limitations} </ins> 在使用 [Windows 版本的 ContainerD 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) 时，通过 GMSA 域身份标识访问受限制的网络共享资源时会出错。

/language zh /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 : /language zh /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
/triage accepted
/assign


Question: Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve. content_type: concept <del> weight: 20 </del> <ins> weight: 90 </ins> --- <!-- overview -->

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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
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 : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign


Question: Use `activeDeadlineSeconds` on the Pod to prevent init containers from failing forever. The active deadline includes init containers. <del> However it is recommended to use `activeDeadlineSeconds` if user deploy their application </del> <ins> However it is recommended to use `activeDeadlineSeconds` only if teams deploy their application </ins> as a Job, because `activeDeadlineSeconds` has an effect even after initContainer finished. The Pod which is already running correctly would be killed by `activeDeadlineSeconds` if you set.

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: Proposed Solution: to to to to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Closest issue I could find related to this
Is the issue open? I would be happy to work on it. Thank you.
Do you mind testing it on your local environment. I think the documentation is correct.
/triage needs-information
/kind support
Perhaps the words "Pod" and "Job" may have been misleading. I think "Job" refers to a container that complete in a certain period. In other words, this explanation means the following. The activeDeadlineSeconds is recommended to be use for containers (Pod) that complete after a certain period. It should not be used for containers (Pod) that will run forever.
I would suggest the following. How about it? before: after:
/close Please re-open if you believe this clarification ("only if" instead of "if") is important
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details