Question: # # A match exists between an image and a matchImage when all of the below are true: # - Both contain the same number of domain parts and each part matches. <del> # - The URL path of an imageMatch must be a prefix of the target image URL path. # - If the imageMatch contains a port, then the port must match in the image as well. </del> <ins> # - The URL path of an matchImages must be a prefix of the target image URL path. # - If the matchImages contains a port, then the port must match in the image as well. </ins> # # Example values of matchImages: # - 123456789.dkr.ecr.us-east-1.amazonaws.com

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 word appears 3 times: But the exact name of field is actually. Proposed Solution: In , [L85-L86] [L144-L145] And optionally, we might wrap with backticks; like: through the whole doc. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign
AFAIK we use backticks only for API Resource names per the style guide. We don't need to have the backticks to wrap matchImages. I agree with the rest of the suggestion, though. /triage accepted
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on /unassign
I would like to give a try on this. /assign


Question: ## {{% heading "whatsnext" %}} <del> * Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling/scheduler-perf-tuning/) </del> <ins> * Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) </ins> * Baca tentang [pertimbangan penyebarang topologi pod](/id/docs/concepts/workloads/pods/pod-topology-spread-constraints/) * Baca [referensi dokumentasi](/docs/reference/command-line-tools-reference/kube-scheduler/) untuk _kube-scheduler_ * Pelajari tentang [mengkonfigurasi beberapa penjadwal](/docs/tasks/administer-cluster/configure-multiple-schedulers/)

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

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

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


Question:
{{/* Link directly to documentation etc., if possible. */}} {{ $langPage := cond (gt (len .Translations) 0) . .Site.Home }}       {{ $langPage.Language.LanguageName }}
 {{ range $langPage.Translations }} {{ .Language.LanguageName }} {{ end }}
   No newline at end of file

Kubernetes website does not respond to language change
This is because .... we are not using the cached jquery script. We are downloading from which is sometimes blocked from China.


Question: ### containerd 설치 {{< tabs name="tab-cri-containerd-installation" >}} <del> {{< tab name="Ubuntu 16.04" >}} </del> <ins> {{% tab name="Ubuntu 16.04" %}} </ins> ```shell # (containerd 설치)

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Broken layout for tabs on "Container runtimes" page as below. ! Proposed Solution: TBD Page to Update: /language ko <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/retitle Broken layout for tabs on "Container runtimes" page in Korean
This problem is due to incorrect tab code. We should fix this like the below: (Line 71, 125, 126, 180) to
/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 : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hey folks, I'm happy to help you with this /assign


Question: Чтобы загрузить определенную версию, вставьте в фрагмент команды `$(curl -LS https://dl.k8s.io/release/stable.txt)` нужную версию. <del> Например, команда загрузки версии {{< param "fullversion" >}} для Linux будет выглядеть следующим образом: </del> <ins> Например, команда загрузки версии {{< skew currentPatchVersion >}} для Linux будет выглядеть следующим образом: </ins> ``` <del> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/linux/amd64/kubectl </ins> ``` 2. Сделайте двоичный файл kubectl исполняемым:

Problem: Based on , I have created this issue/task to help update the [ru] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website/content/ru" /home/rdlugyhe/kubernetes/k8s-website/content/ru/docs/tasks/tools/install- 33: Например, для установки версии {{< param "fullversion" }} на Linux введите: 36: {{< param "fullversion" }}/bin/linux/amd64/kubectl 110: Например, для установки версии {{< param "fullversion" }} на macOS введите: 113: {{< param "fullversion" }}/bin/darwin/amd64/kubectl 175: 1. Загрузите последний релиз {{< param "fullversion" }} по этой ссылке. 180: {{< param "fullversion" }} In the branch, I found: Results for "fullversion" in "k8s-website/content/ru" /home/rdlugyhe/kubernetes/k8s-website/content/ru/docs/concepts/containers/container- 44: DNS, если включен . /home/rdlugyhe/kubernetes/k8s-website/content/ru/docs/setup/learning- 222: чтобы запустить Minikube из-под версии {{< param "fullversion" }}, вам нужно выполнить следующую команду: 225: minikube start --kubernetes-version {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ru/docs/tasks/tools/install- 36: Например, команда загрузки версии {{< param "fullversion" }} для Linux будет выглядеть следующим образом 39: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 116: Например, команда загрузки версии {{< param "fullversion" }} для macOS будет выглядеть следующим образом 119: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 183: 1.

Загрузите последнюю версию {{< param "fullversion" }} по этой ссылкеe


Question: 在该 Shell中，查看 `labels` 文件： ```shell <del> /# cat /etc/labels </del> <ins> /# cat /etc/podinfo/labels </ins> ``` <!--

the file labels and annotations should be in the directory /etc/podinfo not /etc !
Hi What's the URL of the web page that isn't right? /triage needs-information
/triage accepted
/assign


Question: * [Troubleshooting your application](/docs/user-guide/application-troubleshooting) - Useful for users who are deploying code into Kubernetes and wondering why it is not working. * [Troubleshooting your cluster](/docs/admin/cluster-troubleshooting) - Useful for cluster administrators and people whose Kubernetes cluster is unhappy. <del> You should also check the [known issues](/docs/user-guide/known-issues) for the release you're using. </del> <ins> You should also check the known issues for the [release](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md) you're using. </ins> ### Getting help

This page is woefully out of date: docs/user-guide/known-issues/ We should move the content to the 1.0 release notes and delete the page. cc
already contains this info. I'll delete the file.
cc I can't see how to delete a file using this new edit-in-place interface. Maybe it's a permission issue?
These items are all in flight - But I have no power to assign or merge anything.
Nice work, David. :)


Question: ## Resource Types - [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration)

links to in the table, but does not exist. Probably it should be linked to another page?
/triage accepted /kind bug /assign


Question: <!-- Services have dedicated IP addresses and are available to the Container via DNS, <del> if [DNS addon](https://releases.k8s.io/{{< skew currentPatchVersion >}}/cluster/addons/dns/) is enabled. </del> <ins> if [DNS addon](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/cluster/addons/dns/) is enabled. </ins> --> 服务具有专用的 IP 地址。如果启用了 <del> [DNS 插件](https://releases.k8s.io/{{< skew currentPatchVersion >}}/cluster/addons/dns/)， </del> <ins> [DNS 插件](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/cluster/addons/dns/)， </ins> 可以在容器中通过 DNS 来访问服务。 ## {{% heading "whatsnext" %}}

<!--Required Information--Problem: We've deprecated the param () and now English documents are using instead. (by ) All the other documents need to change into or appropriatly. Since several languages are involved, I'd like to share this issue to check all localizations complete the task. Proposed Solution: For each localization team, search and change appropriately. (See the reference, ) Please check the following task box if the localization task is complete. Page to Update: [x] de [x] es [x] fr [x] hi [x] id [x] ja [x] ko [x] pt-br [x] ru [x] vi [ ] zh-ch [previously done]Once all localizations have switched over, we can remove the parameter from the site.
/assign for the Korean contents.
PR: [ko] Replace deprecated fullversion shortcode for Korean :) The task for Korean can be completed after is merged into the main branch.
/assign For Brazilian Portuguese changes
/triage accepted
/assign For Hindi changes
The Brazilian Portuguese localization has replaced all occurrences via /.
/assign for french content
/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
/remove-help
I reopened as there is one more page to fix.
Really done! Thanks folks. /close
Closing this issue. <detailsIn response to : Really done! Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: <ins> --- title: Gateway API content_type: concept description: >- Gateway API is a family of API kinds that provide dynamic infrastructure provisioning and advanced traffic routing. weight: 55 --- <!-- overview --> Make network services available by using an extensible, role-oriented, protocol-aware configuration mechanism. [Gateway API](https://gateway-api.sigs.k8s.io/) is an {{<glossary_tooltip text="add-on" term_id="addons">}} containing API [kinds](https://gateway-api.sigs.k8s.io/references/spec/) that provide dynamic infrastructure provisioning and advanced traffic routing. <!-- body --> ## Design principles The following principles shaped the design and architecture of Gateway API: * __Role-oriented:__ Gateway API kinds are modeled after organizational roles that are responsible for managing Kubernetes service networking: * __Infrastructure Provider:__ Manages infrastructure that allows multiple isolated clusters to serve multiple tenants, e.g. a cloud provider. * __Cluster Operator:__ Manages clusters and is typically concerned with policies, network access, application permissions, etc. * __Application Developer:__ Manages an application running in a cluster and is typically concerned with application-level configuration and [Service](/docs/concepts/services-networking/service/) composition. * __Portable:__ Gateway API specifications are defined as [custom resources](docs/concepts/extend-kubernetes/api-extension/custom-resources) and are supported by many [implementations](https://gateway-api.sigs.k8s.io/implementations/). * __Expressive:__ Gateway API kinds support functionality for common traffic routing use cases such as header-based matching, traffic weighting, and others that were only possible in [Ingress](/docs/concepts/services-networking/ingress/) by using custom annotations. * __Extensible:__ Gateway allows for custom resources to be linked at various layers of the API. This makes granular customization possible at the appropriate places within the API structure. ## Resource model Gateway API has three stable API kinds: * __GatewayClass:__ Defines a set of gateways with common configuration and managed by a controller that implements the class. * __Gateway:__ Defines an instance of traffic handling infrastructure, such as cloud load balancer. * __HTTPRoute:__ Defines HTTP-specific rules for mapping traffic from a Gateway listener to a representation of backend network endpoints. These endpoints are often represented as a {{<glossary_tooltip text="Service" term_id="service">}}. Gateway API is organized into different API kinds that have interdependent relationships to support the role-oriented nature of organizations. A Gateway object is associated with exactly one GatewayClass; the GatewayClass describes the gateway controller responsible for managing Gateways of this class. One or more route kinds such as HTTPRoute, are then associated to Gateways. A Gateway can filter the routes that may be attached to its `listeners`, forming a bidirectional trust model with routes. The following figure illustrates the relationships of the three stable Gateway API kinds: {{< figure src="/docs/images/gateway-kind-relationships.svg" alt="A figure illustrating the relationships of the three stable Gateway API kinds" class="diagram-medium" >}} ### GatewayClass {#api-kind-gateway-class} Gateways can be implemented by different controllers, often with different configurations. A Gateway must reference a GatewayClass that contains the name of the controller that implements the class. A minimal GatewayClass example: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: example-class spec: controllerName: example.com/gateway-controller ``` In this example, a controller that has implemented Gateway API is configured to manage GatewayClasses with the controller name `example.com/gateway-controller`. Gateways of this class will be managed by the implementation's controller. See the [GatewayClass](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.GatewayClass) reference for a full definition of this API kind. ### Gateway {#api-kind-gateway} A Gateway describes an instance of traffic handling infrastructure. It defines a network endpoint that can be used for processing traffic, i.e. filtering, balancing, splitting, etc. for backends such as a Service. For example, a Gateway may represent a cloud load balancer or an in-cluster proxy server that is configured to accept HTTP traffic. A minimal Gateway resource example: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: example-gateway spec: gatewayClassName: example-class listeners: - name: http protocol: HTTP port: 80 ``` In this example, an instance of traffic handling infrastructure is programmed to listen for HTTP traffic on port 80. Since the `addresses` field is unspecified, an address or hostname is assigned to the Gateway by the implementation's controller. This address is used as a network endpoint for processing traffic of backend network endpoints defined in routes. See the [Gateway](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.Gateway) reference for a full definition of this API kind. ### HTTPRoute {#api-kind-httproute} The HTTPRoute kind specifies routing behavior of HTTP requests from a Gateway listener to backend network endpoints. For a Service backend, an implementation may represent the backend network endpoint as a Service IP or the backing Endpoints of the Service. An HTTPRoute represents configuration that is applied to the underlying Gateway implementation. For example, defining a new HTTPRoute may result in configuring additional traffic routes in a cloud load balancer or in-cluster proxy server. A minimal HTTPRoute example: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: example-httproute spec: parentRefs: - name: example-gateway hostnames: - "www.example.com" rules: - matches: - path: type: PathPrefix value: /login backendRefs: - name: example-svc port: 8080 ``` In this example, HTTP traffic from Gateway `example-gateway` with the Host: header set to `www.example.com` and the request path specified as `/login` will be routed to Service `example-svc` on port `8080`. See the [HTTPRoute](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.HTTPRoute) reference for a full definition of this API kind. ## Request flow Here is a simple example of HTTP traffic being routed to a Service by using a Gateway and an HTTPRoute: {{< figure src="/docs/images/gateway-request-flow.svg" alt="A diagram that provides an example of HTTP traffic being routed to a Service by using a Gateway and an HTTPRoute" class="diagram-medium" >}} In this example, the request flow for a Gateway implemented as a reverse proxy is: 1. The client starts to prepare an HTTP request for the URL `http://www.example.com` 2. The client's DNS resolver queries for the destination name and learns a mapping to one or more IP addresses associated with the Gateway. 3. The client sends a request to the Gateway IP address; the reverse proxy receives the HTTP request and uses the Host: header to match a configuration that was derived from the Gateway and attached HTTPRoute. 4. Optionally, the reverse proxy can perform request header and/or path matching based on match rules of the HTTPRoute. 5. Optionally, the reverse proxy can modify the request; for example, to add or emove headers, based on filter rules of the HTTPRoute. 6. Lastly, the reverse proxy forwards the request to one or more backends. ## Conformance Gateway API covers a broad set of features and is widely implemented. This combination requires clear conformance definitions and tests to ensure that the API provides a consistent experience wherever it is used. See the [conformance](https://gateway-api.sigs.k8s.io/concepts/conformance/) documentation to understand details such as release channels, support levels, and running conformance tests. ## Migrating from Ingress Gateway API is the successor to the [Ingress](/docs/concepts/services-networking/ingress/) API. However, it does not include the Ingress kind. As a result, a one-time conversion from your existing Ingress resources to Gateway API resources is necessary. Refer to the [ingress migration](https://gateway-api.sigs.k8s.io/guides/migrating-from-ingress/#migrating-from-ingress) guide for details on migrating Ingress resources to Gateway API resources. ## {{% heading "whatsnext" %}} Instead of Gateway API resources being natively implemented by Kubernetes, the specifications are defined as [Custom Resources](docs/concepts/extend-kubernetes/api-extension/custom-resources) supported by a wide range of [implementations](https://gateway-api.sigs.k8s.io/implementations/). [Install](https://gateway-api.sigs.k8s.io/guides/#installing-gateway-api) the Gateway API CRDs or follow the installation instructions of your selected implementation. After installing an implementation, use the [Getting Started](https://gateway-api.sigs.k8s.io/guides/) guide to help you quickly start working with Gateway API. {{< note >}} Make sure to review the documentation of your selected implementation to understand any caveats. {{< /note >}} Refer to the [API specification](https://gateway-api.sigs.k8s.io/reference/spec/) for additional details of all Gateway API kinds. </ins>

This is a Feature Request What would you like to be High level documentation for Gateway API with links out to https://gateway- This should include the following: new "Gateway API" page between Service and Ingress in This should provide a high level overview of Gateway API, with a focus on content that is unlikely to become stale. This can likely take some content from both https://gateway- and https://gateway- and would help increase the discoverability of Gateway API. the "Ingress" page to note that the API is effectively frozen and all new features are being to Gateway API (with a corresponding link to the page by 1). the section on the "Service" page that references Ingress and Gateway API to give more prominence to Gateway API. Why is this needed With the upcoming graduation of Gateway API to GA (x-ref ), it's past time to cover it in Kubernetes docs. Comments I'd previously talked with about this at a high level, but definitely let me know if you've got any suggestions for how we can scope/adjust this differently. /sig network /assign
checkout the gateway API in the section and look out for the bugs
/triage accepted /priority important-longterm
How about adding a short link eg that redirects (302) to https://gateway- ?
I'd put Service, Ingress, then Gateway - and leave it in that order until most new clusters include Gateway as an add-on.
Also see


Question: ### Bare Pods <del> Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node.  A ReplicationController delegates local container restarts to some agent on the node (for example, Kubelet or Docker). </del> <ins> Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node.  A ReplicationController delegates local container restarts to some agent on the node, such as the kubelet. </ins> ### Job

Umbrella issue: Originating issue: (partially fixes) File: URL: Line 207 contains The code sample includes docker mentions. Action: remove the phrase. Add warning about code samples potentially breaking. Test code samples on a cluster with a different runtime and on a cluster with cri-dockerd and Docker. File: URL: Line 65 contains Docker Hub as an example. Action: keep, since it's an example image. File: URL: Last sentence in line 392 contains Docker as an example. Action: Rephrase to "some agent on the node, such as the kubelet" File: URL: Line 142 and 273 have Docker as an example. Action: Line 142: remove "or Docker". Line 273: rephrase to "some agent on the node, such as the kubelet." File: URL: Line 35 - 48: Uses Docker to describe what Pods are. Action: reword the overview of a Pod to describe it without a reliance on a third party. Use content from our Glossary. File: /concepts/workloads/pods/init- URL: Output in line 189 and 190 seem to use docker as the runtime. Action: not sure. Replace example output with the output while using containerd or cri-o? File: /concepts/workloads/pods/pod- URL: Line 208 uses docker as the container ID example Action: keep as-is. /sig docs /language en /help-wanted
/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 : /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
Hi, Can I work on this?
yup, go for it! If you run into issues or have questions, feel free to ask here or on Slack :) /assign
Hi, good evening, I wanted to clarify something in I have to implement the code using cri-dockerd and Docker right? Different runtime means we have to use containerd, runC or CRI-O right??
that's my understanding. If you use a container runtime that's not docker and also not one of the ones you listed, that's also fine.
Need any help here?
Hi are you working on this issue already? If not I'd like to tackle this issue :)
Yeah I'm working I have corrected the simple text changes but I'm having trouble running containerd on my system for replacing docker examples as mentioned in the issue, you can work on this if you want
kindly unassign yourself from this issue, so that other people can take it up. Thanks! Are you working on this?
/milestone 1.24
Sorry, I didn't know I had to unassign it by myself. I thought only a contributor will have this authority. Now I know and have unassigned myself.
If no one is working on this issue can you assign this issue to me .
Sure you can go ahead. Anytime, you can assign yourself by commenting on particular issue you want to work. For now, I am assigning this to you. /assign
Thank you Meha for assigning me for this issue . Let me know you that i am new in this open source contribution journey and indeed so much of guidance to move forward it will be very helpful if you can do this for me in anyway. Meha Bhalodiya
Hi did you need any help with this issue to move it along?
Clearing the 1.24 milestone. This can be to subsequent milestones if needed. /milestone clear
It's been a while since the last update. PRs to address this issue are welcome (by any contributor). /priority important-longterm
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on it!

Thank you /unassign
/assign
hi the context in the 5th issue from the top is quite unclear to me what I understand is that the I have to remove reference of docker with pods and redefine it as below plz help me with this While Kubernetes supports more {{< glossarytooltip text="container runtimes" termid="container-runtime" }} than just Docker, is the most commonly known runtime. {{< /note }} The Pod is the smallest and simplest Kubernetes object which is a set of Linux namespaces, cgroups, and potentially other facets of isolation . Within a Pod , the individual applications may have further sub-isolations applied. A Pod represents a set of running on your cluster. ) A Pod is typically set up to run a single primary container. It can also run optional sidecar containers that add supplementary features like logging.
what I suggest you do is open a PR to work on that and show your initial thinking, and also write a PR description that explains how you approached the challenge. Then, a reviewer can comment on both the intent and the changes you've made. A word of warning, though. This particular sub-task calls for a strong ability to explain a technical concept. If you're not comfortable with that, it's OK to pick a different subtask from the list that looks easier to tackle.
sure thanks for the suggestion
Is this issue still needed to be worked upon?
Yes you can pick it up if you want to work on
/assign
Hey let me know if you are not working on this, I can pick it up :)
Go ahead and work on this issue. I'd love to see what changes you bring:)
/unassign
Thanks /assign
At this point we're pretty unlikely to be testing things on docker as a runtime given it hasn't been supported for multiple releases (unless using cri-dockerd, which may have it's own breakage). Also, FWIW, generally workloads should not be container runtime sensitive, though some unusual edge cases exist mostly which are also technically configurable etc. and can be different even using the same runtime.


Question: requests: storage: 20Gi --- <del> apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 </del> <ins> apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 </ins> kind: Deployment metadata: name: mysql

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x ] Bug Report Problem: Deployment yaml file: mysql- api version does not fit 1.9 version: apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 kind: Deployment Proposed Solution: change apiVersion to: apps/v1 Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 9 ! <!--Additional Information:--


Question: condition `serving`.  You can find more details on how to implement connections draining in the tutorial [Pods And Endpoints Termination Flow](/docs/tutorials/services/pods-and-endpoint-termination-flow/) <del> {{<note>}} If you don't have the `EndpointSliceTerminatingCondition` feature gate enabled in your cluster (the gate is on by default from Kubernetes 1.22, and locked to default in 1.26), then the Kubernetes control plane removes a Pod from any relevant EndpointSlices as soon as the Pod's termination grace period _begins_. The behavior above is described when the feature gate `EndpointSliceTerminatingCondition` is enabled. {{</note>}} {{<note>}} Beginning with Kubernetes 1.29, if your Pod includes one or more sidecar containers (init containers with an Always restart policy), the kubelet will delay sending the TERM signal to these sidecar containers until the last main container has fully terminated. The sidecar containers will be terminated in the reverse order they are defined in the Pod spec. This ensures that sidecar containers continue serving the other containers in the Pod until they are no longer needed. Note that slow termination of a main container will also delay the termination of the sidecar containers. If the grace period expires before the termination process is complete, the Pod may enter emergency termination. In this case, all remaining containers in the Pod will be terminated simultaneously with a short grace period. </del> <ins> <a id="pod-termination-beyond-grace-period" /> </ins> <del> Similarly, if the Pod has a preStop hook that exceeds the termination grace period, emergency termination may occur. In general, if you have used preStop hooks to control the termination order without sidecar containers, you can now remove them and allow the kubelet to manage sidecar termination automatically. {{</note>}} </del> <ins> 1. The kubelet ensures the Pod is shut down and terminated 1. When the grace period expires, if there is still any container running in the Pod, the kubelet triggers forcible shutdown. The container runtime sends `SIGKILL` to any processes still running in any container in the Pod. The kubelet also cleans up a hidden `pause` container if that container runtime uses one. 1. The kubelet transitions the Pod into a terminal phase (`Failed` or `Succeeded` depending on the end state of its containers). 1. The kubelet triggers forcible removal of the Pod object from the API server, by setting grace period to 0 (immediate deletion). 1. The API server deletes the Pod's API object, which is then no longer visible from any client. </ins> <del> 1. When the grace period expires, the kubelet triggers forcible shutdown. The container runtime sends `SIGKILL` to any processes still running in any container in the Pod. The kubelet also cleans up a hidden `pause` container if that container runtime uses one. 1. The kubelet transitions the Pod into a terminal phase (`Failed` or `Succeeded` depending on the end state of its containers). This step is guaranteed since version 1.27. 1. The kubelet triggers forcible removal of Pod object from the API server, by setting grace period to 0 (immediate deletion). 1. The API server deletes the Pod's API object, which is then no longer visible from any client. </del> ### Forced Pod termination {#pod-termination-forced}

work not well. Not sure how to fix it. This issue has spreaded to the currently. <img width="550" alt="image" src=""
/triage accepted
/language en
For a likely fix, see


Question: Here is the `Dockerfile` for the web server: ```shell <del> FROM node:0.10.40 </del> <ins> FROM node:4.4 </ins> RUN mkdir -p /usr/src/app WORKDIR /usr/src/app

NodeJS 0.10 is going into security-only release mode very soon. The first version of 0.10 was released in March 2013, so it's over 3 years old. It would be great if we could update the tutorial/dockerfile to list the latest (or at least a newer) nodejs version.
Resolved by, thanks to


Question: The output displays that the ReplicaSet was created: ``` <del> NAME                      DESIRED   CURRENT   READY     AGE redis-master-765d459796   1         1         1         1m </del> <ins> NAME               DESIRED   CURRENT   READY   AGE mongo-75f59d57f4   1         1         1       3m12s </ins> ``` <del> 2. Create a Service to expose Redis on the network: </del> <ins> 2. Create a Service to expose MongoDB on the network: </ins> ```shell <del> kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml </del> <ins> kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml </ins> ``` The output of a successful command verifies that the Service was created: ``` <del> service/redis-master created </del> <ins> service/mongo created </ins> ``` Check the Service created: ```shell <del> kubectl get service redis-master </del> <ins> kubectl get service mongo </ins> ``` The output displays the service created: ``` <del> NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE redis-master   ClusterIP   10.0.0.213   <none>        6379/TCP   27s </del> <ins> NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE mongo   ClusterIP   10.96.41.183   <none>        27017/TCP   11s </ins> ``` <del> 3. Verify that the Redis server is running in the Pod, and listening on port 6379: </del> <ins> 3. Verify that the MongoDB server is running in the Pod, and listening on port 27017: </ins> ```shell <del> # Change redis-master-765d459796-258hz to the name of the Pod kubectl get pod redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"n"}}' </del> <ins> # Change mongo-75f59d57f4-4nd6q to the name of the Pod kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"n"}}' </ins> ``` <del> The output displays the port for Redis in that Pod: </del> <ins> The output displays the port for MongoDB in that Pod: </ins> ``` <del> 6379 </del> <ins> 27017 </ins> ``` <del> (this is the TCP port allocated to Redis on the internet). </del> <ins> (this is the TCP port allocated to MongoDB on the internet). </ins> ## Forward a local port to a port on the Pod

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

On Forward a local port to a port on the Pod section this should be
/triage needs-information
Could you please link the page
This page
/triage accepted /kind bug /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /kind bug /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-triage needs-information
/assign


Question: 1.  パッチを当てたバージョンのeasyrsa3をダウンロードして解凍し、初期化します。 <del> curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz </del> <ins> curl -LO https://dl.k8s.io/easy-rsa/easy-rsa.tar.gz </ins> tar xzf easy-rsa.tar.gz cd easy-rsa-master/easyrsa3 ./easyrsa init-pki

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: There are still references to instead of is the correct advertised download host and will eventually move to be fastly shielding a fully community-owned bucket ref: Proposed Solution: Replace with Also replace any references with using if applicable. Page to Update: Assorted e.g. , <!--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
hi Not a problem, didn't see anyone assigned to this issue. I am unassigning myself and assigning it to you. /unassign
/assign
Hi, I found a small issue with your proposed changes regarding one of the URLs, which is mentioned twice in the file. While returns as expected, I am getting an nginx-rendered HTML page saying for the new command () instead. As I understand, it happens due to the redirect configured on the new web server. Thus, works fine for me (it returns as expected).
i see Let me update it, thanks your work
Just done, please review all of PRs
Thanks!
And yes: These will need to follow redirects, in the future the tentative plan is it will redirect to a CDN in front of a different bucket created in a fully project / SIG-K8s-Infra controlled GCP or AWS account. I would recommend for downloading with curl more generally, even in docs / usage for other hosts.


Question: Used on: Namespaces <del> When the `NamespaceDefaultLabelName` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled, the Kubernetes API server sets this label on all namespaces. The label value is set to the name of the namespace. </del> <ins> The Kubernetes API server (part of the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}) sets this label on all namespaces. The label value is set to the name of the namespace. You can't change this label's value. </ins> This is useful if you want to target a specific namespace with a label {{< glossary_tooltip text="selector" term_id="selector" >}}.

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 docs for  say that this label is set on namespaces when you enable a feature gate, . However that's no longer true. In current Kubernetes the control plane always sets that label on namespaces. Proposed Solution: Reword that section to make it clear that the control plane always sets that label Page to Update: Kubernetes Version: v1.22 Additional Information: /language en /kind bug /help /priority backlog
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The docs for  say that this label is set on namespaces when you enable a feature gate, . However that's no longer true. In current Kubernetes the control plane always sets that label on namespaces. Reword that section to make it clear that the control plane always sets that label Kubernetes Version: v1.22 /language en /kind bug /help /priority backlog </details
/triage accepted
Hi, I would like to work on this issue. /assign
Any questions about how to fix it?
I have a few technical questions: the sets the label on the namespaces instead of enabling the , so there would be no role of K8s API server in this process? will the set label on the namespaces? I mean will it do it automatically or we need to do something to set the labels like enabling something?
The API server is part of the control plane - see The component within the control plane that sets the label isn't a detail we need to specify here.

All we need to mention is that it happens, and phrase it to make it clear it's not optional.
Just to be clear that the will set the labels of the namespace and this setting of the labels is compulsorily (i.e. it is not optional).?
(also, we'll get the API Machinery folks to check technical accuracy anyway - it's not on the docs contributors to thoroughly verify this kind of detail).
Okay thanks . I now have an idea on how to fix the issue, I will file the PR soon :)
I have a doubt: The phrase which tells that ,would it be better to included it as a shortcode or it should be kept as a normal text.?
the best way for folks to review your proposed changes is to open a pull request. (Also: anyone else who wants to work on this is welcome to - please liaise with if that's feasible).
I have filed a PR but if anyone wants to work on this they are welcome to share their suggestions in the PR Conversation. Thanks.


Question: ## डॉक्स में योगदान देना <del> आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में कोई भी परिवर्तन करना चाहते हैं, और जब आप उन परिवर्तनों को हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं। </del> <ins> आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में परिवर्तन करने के बाद जब आप उनको हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं। </ins> एक बार जब आपका pull request बन जाता है, तो एक कुबरनेट्स समीक्षक स्पष्ट, कार्रवाई योग्य प्रतिक्रिया प्रदान करने की जिम्मेदारी लेगा। pull request के मालिक के रूप में, **यह आपकी जिम्मेदारी है कि आप कुबरनेट्स समीक्षक द्वारा प्रदान की गई प्रतिक्रिया को संबोधित करने के लिए अपने pull request को संशोधित करें।**

Problem: The sentence below in the README- seems to be incomplete "अपने fork में कोई भी परिवर्तन करना चाहते हैं, और जब आप उन परिवर्तनों को हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं।" the first part i.e "अपने fork में कोई भी परिवर्तन करना चाहते हैं" makes no proper connection with the other part
/assign
We always like to have better sentence structure. What solution do you recommend?
/language hi /retitle [hi] Fix README-
I think starting the statement with " इस fork में आप अपने इच्छा अनुसार परिवर्तन कर सकते है " would sound more correct as well as it would go with the flow with the entire statement
We need to mean the same as
अपने fork में कोई भी परिवर्तन करना चाहते हैं (existing one) -this means "want to make any changes to your fork" which is a kind of question to user while we want to convey a assertive sentence that developers can make changes to their fork if you get what I mean
Exactly, we need to mean . You can refer the version I stated above. Using seems unnecessary, is more straight forward.
"want to make any changes to your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it. "

this is what the (hi) translation sounds to me I guess that is abrupt and if you want then we can go for " इस fork में आप बदलाव कर सकते है "
How about "अपने fork ~के~ में परिवर्तन करने के में बाद जब आप उनको हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं"
perfect to me
Thanks, I see you have assigned yourself. You can make a PR.
if you want you can go with your PR what say ?
Why did you unassign. You can make a PR, else this could be a with some tweaks to issue description.
/triage accepted
/assign
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
You need to PR to for things to change here. /reopen


Question: This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet. <del> 1.  Uncordon the control plane node: </del> <ins> -  Uncordon the control plane node: </ins> ```shell # replace <cp-node-name> with the name of your control plane node

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--indentation issue Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--18 <!--Additional Information:--fix the page indentation
/sig cluster-lifecycle docs hi, can you show which section you think is wrong or maybe provide a screenshot?
/sig cluster-lifecycle docs Attached screenshots
i don't see the attachments, possibly because you replied via email. try adding them using the GitHub web UI.
! ! ! !
Page alignment or indentation not proper looks.
ok, i can confirm this. hi, was this broken by this PR, or maybe something on the hugo side changed recently?
The Hugo upgrade was PR
/kind bug /priority important-longterm
I've tried to make a work around for this. It looks like tabs shortcodes with code snippets inside them don't play well with shortcodes (see issue ).
I will take a stab at cleaning this up assuming work isn't currently being done. We might have to adjust the page slightly until capture is removed. /assign
I can share some WIP in case it helps
thanks for taking a look and
oof, sorry I saw this after I opened the PR. That does help! I was scratching my head on some of these bugs. Let me know if you want me to modify my PR to incorporate some of your suggestions or vice versa. I was poking fun of the page on twitter and felt obligated to try to fix it :smile:
Busy at the moment I'm afraid. Feel free to snarf any bits that look useful.


Question: {{ $show := cond (or (lt $ulNr $ulShow) $activePath (and (not $shouldDelayActive) (eq $s.Parent $p.Parent)) (and (not $shouldDelayActive) (eq $s.Parent $p)) (and (not $shouldDelayActive) ($p.IsDescendant $s.Parent))) true false -}} {{ $mid := printf "m-%s" ($s.RelPermalink | anchorize) -}} {{ $pages_tmp := where (union $s.Pages $s.Sections).ByWeight ".Params.toc_hide" "!=" true -}} <ins> {{/* We get untranslated subpages below to make sure we build all levels of the sidenav in localizationed docs sets */}} {{ with site.Params.language_alternatives -}} {{ range . }} {{ with (where $.section.Translations ".Lang" . ) -}} {{ $p := index . 0 -}} {{ $pages_tmp = where ( $pages_tmp | lang.Merge (union $p.Pages $p.Sections)) ".Params.toc_hide" "!=" true -}} {{ end -}} {{ end -}} {{ end -}} </ins> {{ $pages := $pages_tmp | first $sidebarMenuTruncate -}} {{ $withChild := gt (len $pages) 0 -}} {{ $manualLink := cond (isset $s.Params "manuallink") $s.Params.manualLink ( cond (isset $s.Params "manuallinkrelref") (relref $s $s.Params.manualLinkRelref) $s.RelPermalink) -}}

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 , sub-items are not displayed in sidebar tree. ! FYI Chinese version: ! Japanese version: ! English version: ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
zh: Some Chinese-translated files exist in ko: No Korean-translated file exists in I guess this is the reason why the sidebars of version and version are displayed differently. FYI: On 2021-03-19, the -version sidebar was like this: (screenshot is from the issue ) Even if no Korean-translated file exists in , sub-items are displayed (which are the links to the English version of subcommands). !
/triage accepted
This will affect all localizations /priority important-soon
/retitle [l10n] Sub-items are not displayed in sidebar tree
/area web-development
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
Can I work on this issue?
Sure! Please go ahead!

/remove-lifecycle rotten
/assign
/lifecycle frozen
/unassign
/assign I'd like to take a look at this
To summarize: Localizations should have the same links listed in their side nav as in the english language docs, regardless of whether the pages have been translated. This is because there is a "fallback" set up to display a link to the english language docs if a page has not yet been translated. The fallback links to english docs for generated reference docs (kubeadm docs) are missing in localize docs sets. (or anyone else), does this sound accurate? I'd like to make sure i understand whats broken before trying to troubleshoot hugo/docsy/mystery code section :)
I've been spending time investigating this and learning how the navigation is built :) I believe i've found the issue. I'll try to summarize below, but I think this is a template issue which should be addressed by docsy. There is a check in () that compares all the pages and sections and then filters out pages that have . We then test for the number of child pages, to determine if we continue to build the next level down in the navigation tree. At this point, because some localizations have the Kubeadm page translated, this check will only find the translated file (files in the kubeadm/generated folder are filtered out bc the file has ). The logic as written determines that kubeadm has no child pages, because it doesn't know about the English pages at this point. This means the rest of the kubadm sub pages links will not be built in the navigation. Theres There is a check later in that merges the localized pages with the missing the English language pages and to inserts links to untranslated pages in the side nav. (). But it only gets to this point if there are child pages, because its wrapped in a conditional (). In my testing i the checking for untranslated pages, replacing lines 49-51 to be the following. This appears to add in the links that were missing. <img width="1569" alt="Screen Shot 2022-09-09 at 11 27 38 AM" src="https://user-"If we agree that this looks and is a docsy issue, I can open an issue there and propose the solution. cc: I would appreciated your thoughts on this, thanks!


Question: The `--vm-driver=xhyve` flag specifies that you are using Docker for Mac. The default VM driver is VirtualBox. <ins> Note if `minikube start --vm-driver=xhyve` is unsuccessful due to the error: ``` Error creating machine: Error in driver during machine creation: Could not convert the UUID to MAC address: exit status 1 ``` Then the following may resolve the `minikube start --vm-driver=xhyve` issue: ``` rm -rf ~/.minikube sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve ``` </ins> Now set the Minikube context. The context is what determines which cluster `kubectl` is interacting with. You can see all your available contexts in the `~/.kube/config` file.

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: I encounter this error when running the step on the Hello Minikube tutorial: Proposed Solution: The solution by from a worked for me: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
resolved with


Question: <!-- The tables below include the known endpoints for supported operating systems: <del> {{< tabs name="container_runtime" >}} {{% tab name="Linux" %}} </del> --> 下面的表格包括被支持的操作系统的已知端点。

(kubeadm) []
/triage accepted /kind bug /assign /language zh


Question: <ins> apiVersion: apps/v1 kind: Deployment metadata: name: php-apache spec: selector: matchLabels: run: php-apache replicas: 1 template: metadata: labels: run: php-apache spec: containers: - name: php-apache image: k8s.gcr.io/hpa-example ports: - containerPort: 80 resources: limits: cpu: 500m requests: cpu: 200m --- apiVersion: v1 kind: Service metadata: name: php-apache labels: run: php-apache spec: ports: - port: 80 selector: run: php-apache </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 Thank you for filing issue~


Question: to be reachable from outside your cluster. - [Ingress](/docs/concepts/services-networking/ingress/) provides extra functionality specifically for exposing HTTP applications, websites and APIs. <ins> - [Gateway API](/docs/concepts/services-networking/gateway/) is an {{<glossary_tooltip text="add-on" term_id="addons">}} that provides an expressive, extensible, and role-oriented family of API kinds for modeling service networking. </ins> - You can also use Services to [publish services only for consumption inside your cluster](/docs/concepts/services-networking/service-traffic-policy/).

This is a Feature Request What would you like to be High level documentation for Gateway API with links out to https://gateway- This should include the following: new "Gateway API" page between Service and Ingress in This should provide a high level overview of Gateway API, with a focus on content that is unlikely to become stale. This can likely take some content from both https://gateway- and https://gateway- and would help increase the discoverability of Gateway API. the "Ingress" page to note that the API is effectively frozen and all new features are being to Gateway API (with a corresponding link to the page by 1). the section on the "Service" page that references Ingress and Gateway API to give more prominence to Gateway API. Why is this needed With the upcoming graduation of Gateway API to GA (x-ref ), it's past time to cover it in Kubernetes docs. Comments I'd previously talked with about this at a high level, but definitely let me know if you've got any suggestions for how we can scope/adjust this differently. /sig network /assign
checkout the gateway API in the section and look out for the bugs
/triage accepted /priority important-longterm
How about adding a short link eg that redirects (302) to https://gateway- ?
I'd put Service, Ingress, then Gateway - and leave it in that order until most new clusters include Gateway as an add-on.
Also see


Question: handled.  We encourage the curious to check out Docker's documentation for this feature. Kubernetes allows you to override both the image's default command (docker `Entrypoint`) and args <del> (docker `Cmd`) with the `Command` and `Args` fields of `Container`.  The rules are: </del> <ins> (docker `Cmd`) with the `command` and `args` fields of `container`.  The rules are: </ins> <del> 1.  If you do not supply a `Command` or `Args` for a container, the defaults defined by the image will be used 2.  If you supply a `Command` but no `Args` for a container, only the supplied `Command` will be used; the image's default arguments are ignored 3.  If you supply only `Args`, the image's default command will be used with the arguments you supply 4.  If you supply a `Command` **and** `Args`, the image's defaults will be ignored and the values you supply will be used </del> <ins> 1.  If you do not supply a `command` or `args` for a container, the defaults defined by the image will be used. 2.  If you supply a `command` but no `args` for a container, only the supplied `command` will be used; the image's default arguments are ignored. 3.  If you supply only `args`, the image's default command will be used with the arguments you supply. 4.  If you supply a `command` **and** `args`, the image's defaults will be ignored and the values you supply will be used. </ins> Here are examples for these rules in table format <del> | Image `Entrypoint` |    Image `Cmd`   | Container `Command` |  Container `Args`  |    Command Run   | </del> <ins> | Image `Entrypoint` |    Image `Cmd`   | Container `command` |  Container `args`  |    Command Run   | </ins> |--------------------|------------------|---------------------|--------------------|------------------| |     `[/ep-1]`      |   `[foo bar]`    |   <not set>   |   <not set>  | `[ep-1 foo bar]` | |     `[/ep-1]`      |   `[foo bar]`    |      `[/ep-2]`      |   <not set>  |     `[ep-2]`     |

Some of our docs, such as those copied from design docs, refer to Go types and field names rather than API resource names and json field names. For example, in the following doc, is a Go field name. would be the json field name: A more important example to fix is this one, which mentions and repeatedly rather than and : There's no example on that page, either. The example is here: I wouldn't fix these one by one, but instead would address it as we clean up or replace each doc. cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
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
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
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


Question: - [CSI provisioner](#vsphere-provisioner-csi): `csi.vsphere.vmware.com` - [vCP provisioner](#vcp-provisioner): `kubernetes.io/vsphere-volume` <del> In-tree provisioners are [deprecated](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi). For more information on the CSI provisioner, see [Kubernetes vSphere CSI Driver](https://vsphere-csi-driver.sigs.k8s.io/) and [vSphereVolume CSI migration](/docs/concepts/storage/volumes/#vsphere-csi-migration). </del> <ins> In-tree provisioners are [deprecated](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi). For more information on the CSI provisioner, see [Kubernetes vSphere CSI Driver](https://vsphere-csi-driver.sigs.k8s.io/) and [vSphereVolume CSI migration](/docs/concepts/storage/volumes/#vsphere-csi-migration). </ins> #### CSI Provisioner {#vsphere-provisioner-csi} <del> The vSphere CSI StorageClass provisioner works with Tanzu Kubernetes clusters. For an example, refer to the [vSphere CSI repository](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml). </del> <ins> The vSphere CSI StorageClass provisioner works with Tanzu Kubernetes clusters. For an example, refer to the [vSphere CSI repository](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml). </ins> #### vCP Provisioner

There's a section for ReclaimPolicy, which states that this can be or . It is not clear as to what those states mean, there's NO explanation. I was researching how to expand disk, and one guide says that the must be , but I cannot find reference as to what this means. My expectation was that these would be explained what they mean, rather than this is the only do option.
Page related to issue: /retitle Lack of explanation for options - Retain and Delete /language en
These concepts are well explained in 'concepts/storage/persistent-'. Maybe a pointer or two suffices?
Please refer link here you will find the brief introduction about the retain or delete. I think this link will be helpful to understand.
/assign
/triage accepted


Question: ## Trusting TLS in a cluster <del> Trusting the [custom CA](#a-note-to-cluster-administrators) from an application running as a pod usually requires </del> <ins> Trusting the [custom CA](#configuring-your-cluster-to-provide-signing) from an application running as a pod usually requires </ins> some extra application configuration. You will need to add the CA certificate bundle to the list of CA certificates that the TLS client or server trusts. For example, you would do this with a golang TLS config by parsing the certificate

This is a Bug Report Problem: Following below hyperlinks are not working under task: and The reason for it is it both redirects to but the is changed to in this PR: Proposed Solution: Changed to for both dedicated CA and custom CA. Page to Update:
Also, the hyperlinks for both dedicated CA and custom CA were in this PR:
/assign /sig auth
Fixed it here:
/language en /triage accepted Thanks for spotting this
you're welcome!


Question: Kubernetes assigns this Service an IP address (sometimes called the "cluster IP"), which is used by the Service proxies <del> (see [Virtual IPs and service proxies](#virtual-ips-and-service-proxies) below). </del> <ins> (see [Virtual IP addressing mechanism](#virtual-ip-addressing-mechanism) below). </ins> The controller for the Service selector continuously scans for Pods that match its selector, and then POSTs any updates to an Endpoint object

This is a Bug Report Problem: The Link for under is wrong. It doesn't redirect anywhere. It is redirected to the following link: instead of that, it should redirect to . contains the context of . Proposed Solution: Virtual IPs and service proxies should redirect to instead of Page to Update:
/assign /sig network /sig docs
Fixed it here:
/triage accepted


Question: clear: both; } <del> .body-content > h3, .body-content > h4, .body-content > h5, .body-content > h6, .body-content > p, .body-content > ul > li, .body-content > ul > li { width: 52%; } .body-content table { </del> <ins> .body-content > * { </ins> width: 52%; }

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: Stylesheet does not limit width of <olfor larger screens. The config details in overflow its container. (I use mozilla firefox if it's required) Proposed Solution: Find a way to add, "width:52%;" attribute for <oltags in Stylesheet under " screen and (min-width: 992px)" Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/kind bug /language en I'll try to make a PR to fix this if its fine.
I'm not sure that fixing just for elements is the right approach. Maybe fix it for or, if there need to be exceptions, ?
/priority important-longterm
I see. I suggested changing just <oltag previously since the generated stylesheet had mentioned for lot of them individually.
I built website locally and navigated to "http://localhost:1313/docs/reference/generated/kubectl/kubectl-commands#config". It says error 404. When i manually add .html to the url then i can view the page. Is this normal?


Question: <ins> --- reviewers: title: ロールベースアクセスコントロールのグッドプラクティス description: > クラスター運用者向けの適切なRBAC設計の原則と実践方法 content_type: concept weight: 60 --- <!-- overview --> Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}}は、クラスターユーザーやワークロードがその役割を果たすために、必要なリソースへのアクセスしかできないようにするための重要なセキュリティコントロールです。 クラスターユーザーの権限を設計する際には、クラスター管理者が特権昇格が発生しうる領域を理解し、セキュリティインシデントを引き起こすリスクを減らすことが重要です。 ここで説明するグッドプラクティスは、一般的な[RBACドキュメント](/ja/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)と併せて読むことを推奨します。 <!-- body --> ## 一般的なグッドプラクティス ### 最小特権の原則 理想的には、ユーザーやサービスには最小限の権限のみ割り当てるべきです。 権限は、その操作に明示的に必要なものだけを使用するべきです。 クラスターによって異なりますが、一般的なルールは次のとおりです: - 可能であれば、namespaceレベルで権限を割り当てます。 特定のnamespace内でのみユーザーに権限を与えるため、ClusterRoleBindingsではなくRoleBindingsを使用します。 - 可能であれば、ワイルドカード権限を提供しないでください。特に全てのリソースへの権限を提供しないでください。 Kubernetesは拡張可能なシステムであるため、ワイルドカードアクセスを提供すると、クラスター内に現存するすべてオブジェクトタイプだけでなく、将来作成されるすべてのオブジェクトタイプにも権限が与えられてしまいます。 - 管理者は特に必要でない限り、`cluster-admin`アカウントを使用すべきではありません。 権限の低いアカウントに[偽装権限](/ja/docs/reference/access-authn-authz/authentication/#user-impersonation)を提供することで、クラスターリソースの誤った変更を回避できます。 - `system:masters`グループにユーザーを追加しないでください。 このグループのメンバーであるユーザーは、すべてのRBAC権限をバイパスし、常に制限のないスーパーユーザーアクセス権限を持ちます。この権限はRoleBindingsまたはClusterRoleBindingsを削除しても取り消すことができません。 余談ですが、クラスターが認可ウェブフックを使用している場合、このグループのメンバーシップもそのウェブフックをバイパスします(そのグループのメンバーであるユーザーからのリクエストがウェブフックに送信されることはありません) ### 特権トークンの配布を最小限に抑える {#least-privilege} 理想的には、Podには強力な権限が付与されたサービスアカウントを割り当てられるべきではありません。 (例えば、[特権昇格リスク](#privilege-escalation-risks)にリストされている権限)。 強力な権限が必要な場合は、次のプラクティスを検討してください: - 強力なPodを実行するノードの数を制限します。 実行する任意のDaemonSetが必要であることを確認し、コンテナエスケープの影響範囲を制限するために最小限の権限で実行されるようにします。 - 信頼できない、または公開されたPodと強力なPodを一緒に実行しないようにする。 信頼できない、または信頼度の低いPodと一緒に実行されないようにするために、[TaintsとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)、[NodeAffinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)、または[PodAntiAffinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)の使用を検討してください。 信頼性の低いPodが**制限付き**Podセキュリティ標準を満たしていない場合は、特に注意してください。 ### 強化 Kubernetesは、すべてのクラスターに必要とは限らないアクセスをデフォルトで提供します。 デフォルトで提供されるRBAC権限を確認することで、セキュリティを強化する機会が得られます。 一般的に、`system:`アカウントに提供される権限を変更するべきではありませんが、クラスター権限を強化するためのオプションがいくつか存在します: - `system:unauthenticated`グループのバインディングを確認し、可能であれば削除します。 これにより、ネットワークレベルでAPIサーバーに接続できるすべてのユーザーにアクセスが許可されます。 - `automountServiceAccountToken: false`を設定することで、サービスアカウントトークンのデフォルトの自動マウントを回避します。 詳細については、[デフォルトのサービスアカウントトークンの使用](/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)を参照してください。 Podにこの値を設定すると、サービスアカウント設定が上書きされ、サービスアカウントトークンを必要とするワークロードは引き続きそれをマウントできます。 ### 定期的なレビュー 冗長なエントリや特権昇格の可能性がないか、定期的にKubernetes RBAC設定を確認することが不可欠です。 攻撃者が削除されたユーザーと同じ名前のユーザーアカウントを作成できる場合、特にそのユーザーに割り当てられた権限を自動的に継承できます。 ## Kubernetes RBAC - 特権昇格リスク　{#privilege-escalation-risks} Kubernetes RBAC内には、ユーザーやサービスアカウントがクラスター内で特権昇格したり、クラスター外のシステムに影響を与えたりすることができる権限がいくつかあります。 このセクションは、クラスター運用者が意図した以上のクラスターへのアクセスを誤って許可しないようにするために注意を払うべき領域を示すことを目的としています。 ### Secretのリスト 一般に、Secretに対する`get`アクセスを許可すると、ユーザーがその内容を読むことができることは明らかです。 また、`list`および`watch`アクセスも、ユーザーがSecretの内容を明らかにすること事実上可能にします。 例えば、Listレスポンスが返却される(例: `kubectl get secrets -A -o yaml`)と、そのレスポンスにはすべてのSecretの内容が含まれます。 ### ワークロードの作成 Namespace内でワークロード(PodやPodを管理する[ワークロードリソース](/ja/docs/concepts/workloads/controllers/))を作成する権限により、そのnamespace内のSecret、ConfigMap、PersistentVolumeなどのPodにマウントできる他の多くのリソースへのアクセスが暗黙的に許可されます。 さらに、Podは任意の[ServiceAccount](/docs/reference/access-authn-authz/service-accounts-admin/)として実行できるため、ワークロードを作成する権限もまた、そのnamespace内の任意のサービスアカウントのAPIアクセスレベルを暗黙的に許可します。 特権付きPodを実行できるユーザーは、そのアクセス権を使用してノードへのアクセスを取得し、さらに特権昇格させる可能性があります。 適切に安全で隔離されたPodを作成できるユーザーや他のプリンシパルを完全に信頼していない場合は、**ベースライン**または**制限付き**Podセキュリティ標準を強制する必要があります。 [Podのセキュリティアドミッション](/ja/docs/concepts/security/pod-security-admission/)や他の(サードパーティ)メカニズムを使用して、その強制を実装できます。 これらの理由から、namespaceは異なる信頼レベルやテナンシーを必要とするリソースを分離するために使用されるべきです。 [最小特権](#least-privilege)の原則に従い、最小限の権限セットを割り当てることがベストプラクティスとされていますが、namespace内の境界は弱いと考えるべきです。 ### 永続ボリュームの作成 誰か、または何らかのアプリケーションが、任意のPersistentVolumeを作成する権限を持っている場合、そのアクセスには`hostPath`ボリュームの作成も含まれており、これはPodが関連づけられたノードの基盤となるホストファイルシステムにアクセスできることを意味します。 その権限を与えることはセキュリティリスクとなります。 ホストファイルシステムに制限のないアクセス権を持つコンテナが特権昇格する方法は数多くあり、これには他のコンテナからのデータの読み取りや、Kubeletなどのシステムサービスの資格情報の悪用が含まれます。 PersistentVolumeオブジェクトを作成する権限を許可するのは、次の場合に限定するべきです: - ユーザー(クラスター運用者)が、作業にこのアクセスを必要としており、かつ信頼できる場合。 - 自動プロビジョニングのために設定されたPersistentVolumeClaimに基づいてPersistentVolumeを作成するKubernetesコントロールコンポーネント。 これは通常、KubernetesプロバイダーまたはCSIドライバーのインストール時に設定されます。 永続ストレージへのアクセスが必要な場合、信頼できる管理者がPersistentVolumeを作成し、制約のあるユーザーはPersistentVolumeClaimを使用してそのストレージにアクセスするべきです。 ### ノードの`proxy`サブリソースへのアクセス ノードオブジェクトのプロキシサブリソースへのアクセス権を持つユーザーは、Kubelet APIに対する権限を持ち、権限を持つノード上のすべてのPodでコマンドを実行できます。 このアクセスは監査ログやアドミッションコントロールをバイパスするため、このリソースに権限を付与する際には注意が必要です。 ### Escalate動詞 一般的に、RBACシステムはユーザーが所有する権限以上のクラスターロールを作成できないようにします。 この例外は`escalate`動詞です。 [RBACのドキュメント](/ja/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)に記載されているように、この権限を持つユーザーは事実上特権昇格させることができます。 ### Bind動詞 `escalate`動詞と同様に、ユーザーにこの権限を付与すると、特権昇格に対するKubernetesビルトインの保護をバイパスし、ユーザーがすでに持っていない権限を持つロールへのバインディングを作成できるようになります。 ### Impersonate動詞 この動詞は、ユーザーがクラスター内の他のユーザーになりすまし、そのユーザーの権限を取得することを可能にします。 権限を付与する場合は、なりすましアカウントを介して過剰な権限を取得できないように注意する必要があります。 ### CSRと証明書の発行 CSR APIは、CSRに対する`create`権限と`certificatesigningrequests/approval`に対する`update`権限を持つユーザーが、クラスターに対して認証するための新しいクライアント証明書を作成できるようにします。 これらのクライアント証明書は、Kubernetesシステムコンポーネントの重複を含む任意の名前を持つことができます。 これにより、特権昇格が可能になります。 ### トークンリクエスト `serviceaccounts/token`に対する`create`権限を持つユーザーは、既存のサービスアカウント用のトークンを発行するためのTokenRequestsを作成できます。 ### アドミッションウェブフックの制御 `validatingwebhookconfigurations`または`mutatingwebhookconfigurations`を制御するユーザーは、クラスターに許可された任意のオブジェクトを読み取ることができるウェブフックを制御し、ウェブフックを変更する場合は許されたオブジェクトも変更できます。 ### Namespaceの変更 Namespaceオブジェクトにおいて**patch**操作を実行できるユーザーは(そのアクセス権を持つロールへのnamespace付きのRoleBindingを通じて)namespaceのラベルを変更できます。 Podのセキュリティアドミッションが使用されているクラスターでは、ユーザーは管理者が意図したより緩いポリシーをnamespaceに設定できる場合があります。 NetworkPolicyが使用されているクラスターでは、ユーザーは管理者が意図していないサービスへのアクセスを間接的に許可するラベルを設定できる場合があります。 ## Kubernetes RBAC - サービス拒否リスク {#denial-of-service-risks} ### オブジェクト作成によるサービス拒否 {#object-creation-dos} クラスター内のオブジェクトを作成する権限を持つユーザーは、[etcd used by Kubernetes is vulnerable to OOM attack](https://github.com/kubernetes/kubernetes/issues/107325)で議論されているように、オブジェクトのサイズや数に基づいてサービス拒否を引き起こすほど大きなオブジェクトを作成できる可能性があります。 これは、半信頼または信頼されていないユーザーにシステムへの限定的なアクセスが許可されている場合、特にマルチテナントクラスターに関係する可能性があります。 この問題を緩和するための1つのオプションとして、[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/#object-count-quota)を使用して作成可能なオブジェクトの量を制限することが考えられます。 ## {{% heading "whatsnext" %}} * RBACについてさらに詳しく知るには、[RBACのドキュメント](/ja/docs/reference/access-authn-authz/rbac/)を参照してください。 </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 /help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request Original: /language ja /help /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: You will need to have the following tools installed: <del> - `cosign` ([install guide](https://docs.sigstore.dev/cosign/installation/)) </del> <ins> - `cosign` ([install guide](https://docs.sigstore.dev/cosign/system_config/installation/)) </ins> - `curl` (often provided by your operating system) - `jq` ([download jq](https://jqlang.github.io/jq/download/))

in this page the link about Verify Signed Kubernetes Artifacts for install cosign changed --- !
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. 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
It is a documentation issue, Docs issues are implemented in . Please open in this repo.
/transfer website
/assign
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig doc 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
/kind bug /kind documentation


Question: <ins> --- layout: blog title: "k8s.gcr.io 镜像仓库将从 2023 年 4 月 3 日起被冻结" date: 2023-02-06 slug: k8s-gcr-io-freeze-announcement --- <!-- layout: blog title: "k8s.gcr.io Image Registry Will Be Frozen From the 3rd of April 2023" date: 2023-02-06 slug: k8s-gcr-io-freeze-announcement --> <!-- **Authors**: Mahamed Ali (Rackspace Technology) --> **作者**：Mahamed Ali (Rackspace Technology) **译者**：Michael Yao (Daocloud) <!-- The Kubernetes project runs a community-owned image registry called `registry.k8s.io` to host its container images. On the 3rd of April 2023, the old registry `k8s.gcr.io` will be frozen and no further images for Kubernetes and related subprojects will be pushed to the old registry. This registry `registry.k8s.io` replaced the old one and has been generally available for several months. We have published a [blog post](/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/) about its benefits to the community and the Kubernetes project. This post also announced that future versions of Kubernetes will not be available in the old registry. Now that time has come. --> Kubernetes 项目运行一个名为 `registry.k8s.io`、由社区管理的镜像仓库来托管其容器镜像。 2023 年 4 月 3 日，旧仓库 `k8s.gcr.io` 将被冻结，Kubernetes 及其相关子项目的镜像将不再推送到这个旧仓库。 `registry.k8s.io` 这个仓库代替了旧仓库，这个新仓库已正式发布七个月。 我们也发布了一篇[博文](/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/)阐述新仓库给社区和 Kubernetes 项目带来的好处。这篇博客再次宣布后续版本的 Kubernetes 将不可用于旧仓库。这个时刻已经到来。 <!-- What does this change mean for contributors: - If you are a maintainer of a subproject, you will need to update your manifests and Helm charts to use the new registry. --> 这次变更对贡献者意味着： - 如果你是某子项目的 Maintainer，你将需要更新清单 (manifest) 和 Helm Chart 才能使用新仓库。 <!-- What does this change mean for end users: - 1.27 Kubernetes release will not be published to the old registry. - Patch releases for 1.24, 1.25, and 1.26 will no longer be published to the old registry from April. Please read the timelines below for details of the final patch releases in the old registry. - Starting in 1.25, the default image registry has been set to `registry.k8s.io`. This value is overridable in `kubeadm` and `kubelet` but setting it to `k8s.gcr.io` will fail for new releases after April as they won’t be present in the old registry. - If you want to increase the reliability of your cluster and remove dependency on the community-owned registry or you are running Kubernetes in networks where external traffic is restricted, you should consider hosting local image registry mirrors. Some cloud vendors may offer hosted solutions for this. --> 这次变更对终端用户意味着： - Kubernetes 1.27 版本将不会发布到旧仓库。 - 1.24、1.25 和 1.26 版本的补丁从 4 月份起将不再发布到旧仓库。请阅读以下时间线，了解旧仓库最终补丁版本的详情。 - 从 1.25 开始，默认的镜像仓库已设置为 `registry.k8s.io`。`kubeadm` 和 `kubelet` 中的这个镜像仓库地址是可覆盖的，但设置为 `k8s.gcr.io` 将在 4 月份之后的新版本中失败， 因为旧仓库将没有这些版本了。 - 如果你想提高集群的可靠性，不想再依赖社区管理的镜像仓库，或你正在外部流量受限的网络中运行 Kubernetes， 你应该考虑托管本地镜像仓库的镜像。一些云供应商可能会为此提供托管解决方案。 <!-- ## Timeline of the changes - `k8s.gcr.io` will be frozen on the 3rd of April 2023 - 1.27 is expected to be released on the 12th of April 2023 - The last 1.23 release on `k8s.gcr.io` will be 1.23.18 (1.23 goes end-of-life before the freeze) - The last 1.24 release on `k8s.gcr.io` will be 1.24.12 - The last 1.25 release on `k8s.gcr.io` will be 1.25.8 - The last 1.26 release on `k8s.gcr.io` will be 1.26.3 --> ## 变更时间线   {#timeline-of-changes} - `k8s.gcr.io` 将于 2023 年 4 月 3 日被冻结 - 1.27 预计于 2023 年 4 月 12 日发布 - `k8s.gcr.io` 上的最后一个 1.23 版本将是 1.23.18（1.23 在仓库冻结前进入不再支持阶段） - `k8s.gcr.io` 上的最后一个 1.24 版本将是 1.24.12 - `k8s.gcr.io` 上的最后一个 1.25 版本将是 1.25.8 - `k8s.gcr.io` 上的最后一个 1.26 版本将是 1.26.3 <!-- ## What's next Please make sure your cluster does not have dependencies on old image registry. For example,  you can run this command to list the images used by pods: --> ## 下一步   {#whats-next} 请确保你的集群未依赖旧的镜像仓库。例如，你可以运行以下命令列出 Pod 使用的镜像： ```shell kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" | tr -s '[[:space:]]' 'n' | sort | uniq -c ``` <!-- There may be other dependencies on the old image registry. Make sure you review any potential dependencies to keep your cluster healthy and up to date. --> 旧的镜像仓库可能存在其他依赖项。请确保你检查了所有潜在的依赖项，以保持集群健康和最新。 <!-- ## Acknowledgments __Change is hard__, and evolving our image-serving platform is needed to ensure a sustainable future for the project. We strive to make things better for everyone using Kubernetes. Many contributors from all corners of our community have been working long and hard to ensure we are making the best decisions possible, executing plans, and doing our best to communicate those plans. --> ## 致谢   {#acknowledgments} __改变是艰难的__，但只有镜像服务平台演进才能确保 Kubernetes 项目可持续的未来。 我们努力为 Kubernetes 的每个使用者提供更好的服务。从社区各个角落汇聚而来的众多贡献者长期努力工作， 确保我们能够做出尽可能最好的决策、履行计划并尽最大努力传达这些计划。 <!-- Thanks to Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine, Davanum Srinivas, Mahamed Ali, and Tim Hockin from SIG K8s Infra, Brian McQueen, and Sergey Kanzhelev from SIG Node, Lubomir Ivanov from SIG Cluster Lifecycle, Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, and Stephen Augustus from SIG Release, Bob Killen and Kaslin Fields from SIG Contribex, Tim Allclair from the Security Response Committee. Also a big thank you to our friends acting as liaisons with our cloud provider partners: Jay Pipes from Amazon and Jon Johnson Jr. from Google. --> 衷心感谢： - 来自 SIG K8s Infra 的 Aaron Crickenberger、Arnaud Meukam、Benjamin Elder、Caleb Woodbine、Davanum Srinivas、Mahamed Ali 和 Tim Hockin - 来自 SIG Node 的 Brian McQueen 和 Sergey Kanzhelev - 来自 SIG Cluster Lifecycle 的 Lubomir Ivanov - 来自 SIG Release 的 Adolfo García Veytia、Jeremy Rickard、Sascha Grunert 和 Stephen Augustus - 来自 SIG Contribex 的 Bob Killen 和 Kaslin Fields - 来自 Security Response Committee（安全响应委员会）的 Tim Allclair 此外非常感谢负责联络各个云提供商合作伙伴的朋友们：来自 Amazon 的 Jay Pipes 和来自 Google 的 Jon Johnson Jr. </ins>

This blog has not zh version yet. I will localize it recently. Open this issue to avoid any possible dup. /assign /language zh /kind blog
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : This blog has not zh version yet. I will localize it recently. /language zh /kind blog Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: ## डेप्लॉयमेंट बनाएँ <del> कुबेरनेट्स [*पॉड*](/hi/docs/concepts/workloads/pods/) एक या अधिक कंटेनरों का एक समूह है, </del> <ins> कुबेरनेट्स [*पॉड*](/docs/concepts/workloads/pods/) एक या अधिक कंटेनरों का एक समूह है, </ins> जो प्रशासन और नेटवर्किंग के उद्देश्यों के लिए एक साथ बंधे होते हैं। इस ट्यूटोरियल के पॉड में केवल एक कंटेनर है। कुबेरनेट्स <del> [*डेप्लॉयमेंट*](/hi/docs/concepts/workloads/controllers/deployment/) आपके पॉड के स्वास्थ्य की </del> <ins> [*डेप्लॉयमेंट*](/docs/concepts/workloads/controllers/deployment/) आपके पॉड के स्वास्थ्य की </ins> जाँच करता है और यदि पॉड बंद हो जाता है तो पॉड के कंटेनर को पुनः आरंभ करता है। पॉड्स के निर्माण और स्केलिंग को प्रबंधित करने के लिए डेप्लॉयमेंट अनुशंसित तरीका है।

Problem: There are broken link in page. Proposed Solution: --Page to Update:
/triage accepted
/assign
Is the issue still open, anyone working?
Yes, I'm working on it!!
/area localization
I think has already raised a PR!
PR working on this issue


Question: * Fetch the `cluster-info` file from the API Server: ```shell <del> kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/    //" | tee cluster-info.yaml </del> <ins> kubectl -n kube-public get cm cluster-info -o jsonpath='{.data.kubeconfig}' | tee cluster-info.yaml </ins> ``` The output is similar to this:

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --The current documentation for suggests the use of a combination of with / to extract the contents of the field from the ConfigMap. However, has the option that allows us to extract such field without the need of parsing it through /. What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Update the command to use instead. Why is this needed It provides data extraction with less steps and less risk of error if the content format changes in the future. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --N/A /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: ### MutatingAdmissionWebhook {#mutatingadmissionwebhook} <del> {{< feature-state for_k8s_version="v1.13" state="beta" >}} </del> This admission controller calls any mutating webhooks which match the request. Matching webhooks are called in serial; each one may modify the object if it desires.

This is a Bug Report It's not a bug, just an outdated doc thing. Problem: The MutatingWebhookConfiguration and ValidatingWebhookConfiguration APIs have been promoted to in . But the docs still show that they are in beta state at and . Proposed Solution: the description from the two plug-ins. the descriptions of the two plug-ins if they need an update too. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
I'm investigating this issue, hope I can send a PR for this after someone triaged/confirmed it. /assign
/triage accepted


Question: the `spec.renewTime` field for the Lease. The Kubernetes control plane uses the time stamp of this field to determine the availability of this `Node`. <del> See [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats) for more details. </del> <ins> See [Node Lease objects](/docs/concepts/architecture/nodes/#node-heartbeats) for more details. </ins> ## Leader election

This is a Bug Report The link provided for [Node Lease objects] is wrong <!--Required Information--Problem: The provided link is navigating to top of the page not to corresponding sub section. Proposed Solution: URL link should be Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en
/assign
/triage accepted


Question: ```sh # Linux <del> curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-linux-amd64 -o kompose </del> <ins> curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-linux-amd64 -o kompose </ins> # macOS <del> curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-darwin-amd64 -o kompose </del> <ins> curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-darwin-amd64 -o kompose </ins> # Windows <del> curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-windows-amd64.exe -o kompose.exe </del> <ins> curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-windows-amd64.exe -o kompose.exe </ins> chmod +x kompose sudo mv ./kompose /usr/local/bin/kompose

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

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

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


Question: You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short: --> <del> ## Service 安全 </del> <ins> ## 保护 Service {#securing-the-service} </ins> <del> 到现在为止，我们只在集群内部访问了 Nginx server。在将 Service 暴露到 Internet 之前，我们希望确保通信信道是安全的。对于这可能需要： </del> <ins> 到现在为止，我们只在集群内部访问了 Nginx 服务器。在将 Service 暴露到因特网之前，我们希望确保通信信道是安全的。 为实现这一目的，可能需要： </ins> <del> * https 自签名证书（除非已经有了一个识别身份的证书） * 使用证书配置的 Nginx server </del> <ins> * 用于 HTTPS 的自签名证书（除非已经有了一个识别身份的证书） * 使用证书配置的 Nginx 服务器 </ins> * 使证书可以访问 Pod 的 [Secret](/zh/docs/concepts/configuration/secret/) <del> 可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/) 获取所有上述内容，简明示例如下： </del> <ins> 你可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/staging/https-nginx/) 获取所有上述内容。你需要安装 go 和 make 工具。如果你不想安装这些软件，可以按照 后文所述的手动执行步骤执行操作。简要过程如下： </ins> ```shell make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt

Nginx https 404
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
Hi It sounds like you wanted to provide feedback about a web page. Which web page was that? /triage needs-information