Question: <del> --- title: Participating in SIG Docs content_type: concept weight: 60 card: name: contribute weight: 60 --- <!-- overview --> SIG Docs is one of the [special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) within the Kubernetes project, focused on writing, updating, and maintaining the documentation for Kubernetes as a whole. See [SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs) for more information about the SIG. SIG Docs welcomes content and reviews from all contributors. Anyone can open a pull request (PR), and anyone is welcome to file issues about content or comment on pull requests in progress. You can also become a [member](#members), [reviewer](#reviewers), or [approver](#approvers). These roles require greater access and entail certain responsibilities for approving and committing changes. See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for more information on how membership works within the Kubernetes community. The rest of this document outlines some unique ways these roles function within SIG Docs, which is responsible for maintaining one of the most public-facing aspects of Kubernetes -- the Kubernetes website and documentation. <!-- body --> ## Roles and responsibilities - **Anyone** can contribute to Kubernetes documentation. To contribute, you must [sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) and have a GitHub account. - **Members** of the Kubernetes organization are contributors who have spent time and effort on the Kubernetes project, usually by opening pull requests with accepted changes. See [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for membership criteria. - A SIG Docs **Reviewer** is a member of the Kubernetes organization who has expressed interest in reviewing documentation pull requests, and has been added to the appropriate GitHub group and `OWNERS` files in the GitHub repository by a SIG Docs Approver. - A SIG Docs **Approver** is a member in good standing who has shown a continued commitment to the project. An approver can merge pull requests and publish content on behalf of the Kubernetes organization. Approvers can also represent SIG Docs in the larger Kubernetes community. Some duties of a SIG Docs approver, such as coordinating a release, require a significant time commitment. ## Anyone Anyone can do the following: - Open a GitHub issue against any part of Kubernetes, including documentation. - Provide non-binding feedback on a pull request. - Help to localize existing content - Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). - Use the `/lgtm` Prow command (short for "looks good to me") to recommend the changes in a pull request for merging. {{< note >}} If you are not a member of the Kubernetes organization, using `/lgtm` has no effect on automated systems. {{< /note >}} After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also: - Open a pull request to improve existing content, add new content, or write a blog post or case study. ## Members Members are contributors to the Kubernetes project who meet the [membership criteria](https://github.com/kubernetes/community/blob/master/community-membership.md#member). SIG Docs welcomes contributions from all members of the Kubernetes community, and frequently requests reviews from members of other SIGs for technical accuracy. Any member of the [Kubernetes organization](https://github.com/kubernetes) can do the following: - Everything listed under [Anyone](#anyone) - Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request. - Use the `/hold` command to prevent a pull request from being merged, if the pull request already has the LGTM and approve labels. - Use the `/assign` comment to assign a reviewer to a pull request. ### Becoming a member After you have successfully submitted at least 5 substantive pull requests, you can request [membership](https://github.com/kubernetes/community/blob/master/community-membership.md#member) in the Kubernetes organization. Follow these steps: 1.  Find two reviewers or approvers to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership. Ask for sponsorship in the [#sig-docs channel on the Kubernetes Slack instance](https://kubernetes.slack.com) or on the [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). {{< note >}} Don't send a direct email or Slack direct message to an individual SIG Docs member. {{< /note >}} 2.  Open a GitHub issue in the `kubernetes/org` repository to request membership. Fill out the template using the guidelines at [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md). 3.  Let your sponsors know about the GitHub issue, either by at-mentioning them in the GitHub issue (adding a comment with `@<GitHub-username>`) or by sending them the link directly, so that they can add a `+1` vote. 4.  When your membership is approved, the github admin team member assigned to your request updates the GitHub issue to show approval and then closes the GitHub issue. Congratulations, you are now a member! If your membership request is not accepted, the membership committee provides information or steps to take before applying again. ## Reviewers Reviewers are members of the [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) GitHub group. Reviewers review documentation pull requests and provide feedback on proposed changes. Reviewers can: - Do everything listed under [Anyone](#anyone) and [Members](#members) - Document new features - Triage and categorize issues - Review pull requests and provide binding feedback - Create diagrams, graphics assets, and embeddable screencasts and videos - Edit user-facing strings in code - Improve code comments ### Assigning reviewers to pull requests Automation assigns reviewers to all pull requests. You can request a review from a specific reviewer with a comment on the pull request: `/assign [@_github_handle]`. To indicate that a pull request is technically accurate and requires no further changes, a reviewer adds a `/lgtm` comment to the pull request. If the assigned reviewer has not yet reviewed the content, another reviewer can step in. In addition, you can assign technical reviewers and wait for them to provide a `/lgtm` comment. For a trivial change or one that needs no technical review, SIG Docs [approvers](#approvers) can provide the `/lgtm` as well. An `/approve` comment from a reviewer is ignored by automation. ### Becoming a reviewer When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), you can become a SIG Docs reviewer. Reviewers in other SIGs must apply separately for reviewer status in SIG Docs. To apply, open a pull request to add yourself to the `reviewers` section of the [top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) in the `kubernetes/website` repository. Assign the PR to one or more current SIG Docs approvers. If your pull request is approved, you are now a SIG Docs reviewer. [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) will assign and suggest you as a reviewer on new pull requests. If you are approved, request that a current SIG Docs approver add you to the [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) GitHub group. Only members of the `kubernetes-website-admins` GitHub group can add new members to a GitHub group. ## Approvers Approvers are members of the [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) GitHub group. See [SIG Docs teams and automation](#sig-docs-teams-and-automation) for details. Approvers can do the following: - Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers) - Publish contributor content by approving and merging pull requests using the `/approve` comment. If someone who is not an approver leaves the approval comment, automation ignores it. - Participate in a Kubernetes release team as a docs representative - Propose improvements to the style guide - Propose improvements to docs tests - Propose improvements to the Kubernetes website or other tooling If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on a change that doesn't need additional technical review. ### Becoming an approver When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), you can become a SIG Docs approver. Approvers in other SIGs must apply separately for approver status in SIG Docs. To apply, open a pull request to add yourself to the `approvers` section of the [top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) in the `kubernetes/website` repository. Assign the PR to one or more current SIG Docs approvers. If your pull request is approved, you are now a SIG Docs approver. [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) will assign and suggest you as a reviewer on new pull requests. If you are approved, request that a current SIG Docs approver add you to the [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) GitHub group. Only members of the `kubernetes-website-admins` GitHub group can add new members to a GitHub group. ### Approver responsibilities Approvers improve the documentation by reviewing and merging pull requests into the website repository. Because this role carries additional privileges, approvers have additional responsibilities: - Approvers can use the `/approve` command, which merges PRs into the repo. A careless merge can break the site, so be sure that when you merge something, you mean it. - Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content). If you ever have a question, or you're not sure about something, feel free to call for additional review. - Verify that Netlify tests pass before you `/approve` a PR. <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlify tests must pass before approving" /> - Visit the Netlify page preview for a PR to make sure things look good before approving. - Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this rotation. See [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) for more details. ## SIG Docs chairperson Each SIG, including SIG Docs, selects one or more SIG members to act as chairpersons. These are points of contact between SIG Docs and other parts of the Kubernetes organization. They require extensive knowledge of the structure of the Kubernetes project as a whole and how SIG Docs works within it. See [Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) for the current list of chairpersons. ## SIG Docs teams and automation Automation in SIG Docs relies on two different mechanisms for automation: GitHub groups and OWNERS files. ### GitHub groups The SIG Docs group defines two teams on GitHub: - [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) - [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) Each can be referenced with their `@name` in GitHub comments to communicate with everyone in that group. These teams overlap, but do not exactly match, the groups used by the automation tooling. For assignment of issues, pull requests, and to support PR approvals, the automation uses information from OWNERS files. ### OWNERS files and front-matter The Kubernetes project uses an automation tool called prow for automation related to GitHub issues and pull requests. The [Kubernetes website repository](https://github.com/kubernetes/website) uses two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins): - blunderbuss - approve These two plugins use the [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) files in the top level of the `kubernetes/website` GitHub repository to control how prow works within the repository. An OWNERS file contains a list of people who are SIG Docs reviewers and approvers. OWNERS files can also exist in subdirectories, and can override who can act as a reviewer or approver of files in that subdirectory and its descendents. For more information about OWNERS files in general, see [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). In addition, an individual Markdown file can list reviewers and approvers in its front-matter, either by listing individual GitHub usernames or GitHub groups. The combination of OWNERS files and front-matter in Markdown files determines the advice PR owners get from automated systems about who to ask for technical and editorial review of their PR. ## How merging works When a pull request is merged to the branch used to publish content (currently `master`), that content is published and available to the world. To ensure that the quality of our published content is high, we limit merging pull requests to SIG Docs approvers. Here's how it works. - When a pull request has both the `lgtm` and `approve` labels, has no `hold` labels, and all tests are passing, the pull request merges automatically. - Kubernetes organization members and SIG Docs approvers can add comments to prevent automatic merging of a given pull request (by adding a `/hold` comment or withholding a `/lgtm` comment). - Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment. - Only SIG Docs approvers can merge a pull request by adding an `/approve` comment. Some approvers also perform additional specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or [SIG Docs chairperson](#sig-docs-chairperson). ## {{% heading "whatsnext" %}} For more information about contributing to the Kubernetes documentation, see: - [Contributing new content](/docs/contribute/overview/) - [Reviewing content](/docs/contribute/review/reviewing-prs) - [Documentation style guide](/docs/contribute/style/) </del>

Parent issue: Part 1 of the reorganization effort for the participating section.
/language en
/priority important-longterm
/assign


Question: 1. Apply the frontend Service from the `frontend-service.yaml` file: <ins> <!--- for local testing of the content via relative file path kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml --> </ins> ```shell kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml ``` <del> <!--- for local testing of the content via relative file path kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml --> </del> 1. Query the list of Services to verify that the frontend Service is running: ```shell

4 ordered lists have wrong indexes. For example, the number below should be 3. ! Page to update: /language en /kind cleanup
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: weight: 10 --- <del> {{% thirdparty-content %}} `crictl` is a command-line interface for {{<glossary_tooltip term_id="cri" text="CRI">}}-compatible container runtimes. You can use it to inspect and debug container runtimes and applications on a Kubernetes node. `crictl` and its source are hosted in the [cri-tools](https://github.com/kubernetes-sigs/cri-tools) repository. This page provides a reference for mapping common commands for the `docker` command-line tool into the equivalent commands for `crictl`. ## Mapping from docker CLI to crictl The exact versions for the mapping table are for `docker` CLI v1.40 and `crictl` v1.19.0. This list is not exhaustive. For example, it doesn't include experimental `docker` CLI commands. </del> {{< note >}} <del> The output format of `crictl` is similar to `docker` CLI, despite some missing columns for some CLI. Make sure to check output for the specific command if your command output is being parsed programmatically. {{< /note >}} ### Retrieve debugging information {{< table caption="mapping from docker cli to crictl - retrieve debugging information" >}} docker cli | crictl | Description | Unsupported Features -- | -- | -- | -- `attach` | `attach` | Attach to a running container | `--detach-keys`, `--sig-proxy` `exec` | `exec` | Run a command in a running container | `--privileged`, `--user`, `--detach-keys` `images` | `images` | List images | `info` | `info` | Display system-wide information | `inspect` | `inspect`, `inspecti` | Return low-level information on a container, image or task | `logs` | `logs` | Fetch the logs of a container | `--details` `ps` | `ps` | List containers | `stats` | `stats` | Display a live stream of container(s) resource usage statistics | Column: NET/BLOCK I/O, PIDs `version` | `version` | Show the runtime (Docker, ContainerD, or others) version information | {{< /table >}} ### Perform Changes {{< table caption="mapping from docker cli to crictl - perform changes" >}} docker cli | crictl | Description | Unsupported Features -- | -- | -- | -- `create` | `create` | Create a new container | `kill` | `stop` (timeout = 0) | Kill one or more running container | `--signal` `pull` | `pull` | Pull an image or a repository from a registry | `--all-tags`, `--disable-content-trust` `rm` | `rm` | Remove one or more containers | `rmi` | `rmi` | Remove one or more images | `run` | `run` | Run a command in a new container | `start` | `start` | Start one or more stopped containers | `--detach-keys` `stop` | `stop` | Stop one or more running containers | `update` | `update` | Update configuration of one or more containers | `--restart`, `--blkio-weight` and some other resource limit not supported by CRI. {{< /table >}} ### Supported only in crictl </del> <ins> This page is being directed to https://v1-24.docs.kubernetes.io/docs/reference/tools/map-crictl-dockercli/ because of the [removal of dockershim from crictl in v1.24](https://github.com/kubernetes-sigs/cri-tools/issues/870). As per our community policy, deprecated documents are not maintained beyond next three versions. The reason for deprecation is explained in [Dockershim-FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/). </ins> <del> {{< table caption="mapping from docker cli to crictl - supported only in crictl" >}} crictl | Description -- | -- `imagefsinfo` | Return image filesystem info `inspectp` | Display the status of one or more pods `port-forward` | Forward local port to a pod `pods` | List pods `runp` | Run a new pod `rmp` | Remove one or more pods `stopp` | Stop one or more running pods {{< /table >}} </del>  No newline at end of file <ins> {{</ note >}} </ins>

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: https://v1- still says that the page will be removed in v1.27 doesn't, and the page is still there. I agree with not removing the page outright. However, could we perhaps replace that whole page with a link to https://v1- and a brief note about why we have done so? Proposed Solution: Replace that whole page with a link to https://v1- and a brief note about why we have done so? We can also backport it so that https://v1- https://v1- link to https://v1- as well Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /sig node /kind bug /milestone 1.28
We can do something like:
/triage accepted
/assign
I'd start the work and should i backport v1.26 and ,v1.27 as well?
Raised a PR , adding the link to redirect to v1.24 , Please confirm if i should backport v1.26 content just the same as well.
Hi, Raised a for change in v1.27 docs. should I do the change in v1.26 ?
Added v1.26 changes in , PTAL!!


Question: 1. 次のコマンドにより、最新リリースをダウンロードしてください: ``` <del> curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl" </del> <ins> curl -LO "https://dl.k8s.io/release/$(curl -LS https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" </ins> ``` <del> 特定のバージョンをダウンロードする場合、コマンドの`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`の部分を特定のバージョンに書き換えてください。 </del> <ins> 特定のバージョンをダウンロードする場合、コマンドの`$(curl -LS https://dl.k8s.io/release/stable.txt)`の部分を特定のバージョンに書き換えてください。 </ins> たとえば、Linuxへ{{< param "fullversion" >}}のバージョンをダウンロードするには、次のコマンドを入力します: ``` <del> curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl </ins> ``` 2. kubectlバイナリを実行可能にしてください。

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: ExpirationSeconds is the requested duration of validity of the service account token. As the token approaches expiration, the kubelet volume plugin will proactively rotate the service account token. The kubelet will start trying to rotate the token if the token is older than 80 percent of its time to live or if the token is older than 24 hours.Defaults to 1 hour and must be at least 10 minutes. <del> ### Local / Temporary Directory {#Local / Temporary Directory} </del> <ins> ### Local / Temporary Directory {#Local-Temporary-Directory} </ins> - **emptyDir** (EmptyDirVolumeSource)

This is a Bug Report The issue is outlined in:
/triage accepted
/kind cleanup
Hi Thanks for opening a PR to fix this issue! /assign


Question: that has higher precedence than the kubeadm-provided kubelet unit file. ```sh <ins> cat << EOF > /etc/systemd/system/kubelet.service.d/kubelet.conf # Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs". # Replace the value of "containerRuntimeEndpoint" for a different container runtime if needed. # apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration cgroupDriver: systemd address: 127.0.0.1 containerRuntimeEndpoint: unix:///var/run/containerd/containerd.sock staticPodPath: /etc/kubernetes/manifests EOF </ins> cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf [Service] ExecStart= <del> # Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs". # Replace the value of "--container-runtime-endpoint" for a different container runtime if needed. ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock </del> <ins> ExecStart=/usr/bin/kubelet --config=/etc/systemd/system/kubelet.service.d/kubelet.conf </ins> Restart=always EOF

When starting kubelet with the provided unit file in , kubelet crashes, stating that all of the specified flags are either deprecated or completely unknown: If this service file is no longer valid, the documentation should not include it.
/language en /kind support
it seems kubeadm and kubernete versions are mismatching. In kubernetes v1-27, the --container-runtime flag has been removed. ref:
there is an open pr to cleanup the removed flag just remove it to continue your setup. there is no plan to remove the other deprecated kubelet flags anytime soon because they are widely used. in the example we can use a kubeletconfiguration instead. pr welcome to change the example to use --config. /priority backlog /triage accepted /sig cluster-lifecycle
/retitle migrate deprecated flags to config in kubeadm HA etcd page
steps edit this section change the example to this /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : steps </details
/assign
Raised PR, please confirm the changes.


Question: [handbook-patch-release]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/patch-release-team.md [k-sig-release-releases]: https://git.k8s.io/sig-release/releases [patches]: /patch-releases.md <del> [psc]: https://git.k8s.io/community/committee-product-security/README.md </del> <ins> [src]: https://git.k8s.io/community/committee-product-security/README.md </ins> [release-team]: https://git.k8s.io/sig-release/release-team/README.md [security-release-process]: https://git.k8s.io/security/security-release-process.md

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 change We should find the term “product security committee” anywhere within the English-language docs, and replace that term with “security response committee”. We don't need to revise any blog articles. If we feel there are some blog articles where an exception is justified, I'd revise those in a separate PR per article as the review process is different. Why is this needed renamed the product security committee to “Security Response Committee” Comments /language en /sig docs /sig security /help /triage accepted Relevant to
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --We should find the term “product security committee” anywhere within the English-language docs, and replace that term with “security response committee”. We don't need to revise any blog articles. If we feel there are some blog articles where an exception is justified, I'd revise those in a separate PR per article as the review process is different. renamed the product security committee to “Security Response Committee” /language en /sig docs /sig security /help /triage accepted Relevant to Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/priority backlog
thanks , PR's are incoming org wide for the change.
Hi, I would like to take this up /assign


Question: returns a non-zero exit code if the Deployment has exceeded the progression deadline. ```shell <del> kubectl rollout status deployment.v1.apps/nginx-deployment </del> <ins> kubectl rollout status deployment/nginx-deployment </ins> ``` The output is similar to this: ```

I am following the minikube tutorial () and find two different ways to getting the roll-out status of an deployment: vs. I am using locally: What is the difference between these two? Might be a good idea to add a node to step number 3 which explains this.
I think that an appropriate improvement that's in line with your comment is to change to run instead. That sounds reasonable to do. /language en /kind cleanup /triage accepted /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 : I think that an appropriate improvement that's in line with your comment is to change to run instead. /language en /kind cleanup /triage accepted /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
/retitle Multiple way to refer to Deployment resource confusing in Deployment concept page
/assign


Question: font-weight: bold; } <del> /* .fullbutton { padding: 3% !important; } */ </del> } @media (max-width:1000px) {

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: (Despite the PR has been merged, it seems that the error still exists. So opening an issue here. ) From the PR : [As-is] ! ! [To-be] ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--CC /area web-development
/triage accepted
Hello Thanks for reporting this issue. May i kindly know some more details to reproduce the issue. 1) Browser & Version ? 2) Resolution of your display ? I'm trying to reproduce it on wide viewport !
Hello Here is the info of my env: Windows 10 Enterprise 20H2 Google Chrome 97.0.4692.99 (64bit) Monitor resolution: 3840 1600 Chrome window size: [1868 1592] ! [1868 1592] [3767 1600] ! [3767 * 1600]
I can replicate this with Chromium and with Firefox.
/priority backlog
Thanks for the information. Please can you assign this issue to me.
try this Prow command: /assign ravikiranr26 (reply in a comment with that command on a line by itself)
/assign ravikiranr26


Question: NetworkPolicies allow you to specify rules for traffic flow within your cluster, and also between Pods and the outside world. Your cluster must use a network plugin that supports NetworkPolicy enforcement. --- <!-- overview --> <del> If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster.  NetworkPolicies are an application-centric construct which allow you to specify how a {{< glossary_tooltip text="pod" term_id="pod">}} is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network. NetworkPolicies apply to a connection with a pod on one or both ends, and are not relevant to other connections. </del> <ins> If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster. NetworkPolicies are an application-centric construct which allow you to specify how a {{< glossary_tooltip text="pod" term_id="pod">}} is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network. NetworkPolicies apply to a connection with a pod on one or both ends, and are not relevant to other connections. </ins> <del> The entities that a Pod can communicate with are identified through a combination of the following 3 identifiers: </del> <ins> The entities that a Pod can communicate with are identified through a combination of the following 3 identifiers: </ins> 1. Other pods that are allowed (exception: a pod cannot block access to itself) 2. Namespaces that are allowed <del> 3. IP blocks (exception: traffic to and from the node where a Pod is running is always allowed, regardless of the IP address of the Pod or the node) </del> <ins> 3. IP blocks (exception: traffic to and from the node where a Pod is running is always allowed, regardless of the IP address of the Pod or the node) </ins> <del> When defining a pod- or namespace- based NetworkPolicy, you use a {{< glossary_tooltip text="selector" term_id="selector">}} to specify what traffic is allowed to and from the Pod(s) that match the selector. </del> <ins> When defining a pod- or namespace- based NetworkPolicy, you use a {{< glossary_tooltip text="selector" term_id="selector">}} to specify what traffic is allowed to and from the Pod(s) that match the selector. </ins> Meanwhile, when IP based NetworkPolicies are created, we define policies based on IP blocks (CIDR ranges). <!-- body --> ## Prerequisites <del> Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect. </del> <ins> Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect. </ins> ## The Two Sorts of Pod Isolation <del> There are two sorts of isolation for a pod: isolation for egress, and isolation for ingress.  They concern what connections may be established.  "Isolation" here is not absolute, rather it means "some restrictions apply".  The alternative, "non-isolated for $direction", means that no restrictions apply in the stated direction.  The two sorts of isolation (or not) are declared independently, and are both relevant for a connection from one pod to another. By default, a pod is non-isolated for egress; all outbound connections are allowed.  A pod is isolated for egress if there is any NetworkPolicy that both selects the pod and has "Egress" in its `policyTypes`; we say that such a policy applies to the pod for egress.  When a pod is isolated for egress, the only allowed connections from the pod are those allowed by the `egress` list of some NetworkPolicy that applies to the pod for egress.  The effects of those `egress` lists combine additively. By default, a pod is non-isolated for ingress; all inbound connections are allowed.  A pod is isolated for ingress if there is any NetworkPolicy that both selects the pod and has "Ingress" in its `policyTypes`; we say that such a policy applies to the pod for ingress.  When a pod is isolated for ingress, the only allowed connections into the pod are those from the pod's node and those allowed by the `ingress` list of some NetworkPolicy that applies to the pod for ingress.  The effects of those `ingress` lists combine additively. Network policies do not conflict; they are additive. If any policy or policies apply to a given pod for a given direction, the connections allowed in that direction from that pod is the union of what the applicable policies allow. Thus, order of evaluation does not affect the policy result. For a connection from a source pod to a destination pod to be allowed, both the egress policy on the source pod and the ingress policy on the destination pod need to allow the connection. If either side does not allow the connection, it will not happen. </del> <ins> There are two sorts of isolation for a pod: isolation for egress, and isolation for ingress. They concern what connections may be established. "Isolation" here is not absolute, rather it means "some restrictions apply". The alternative, "non-isolated for $direction", means that no restrictions apply in the stated direction.  The two sorts of isolation (or not) are declared independently, and are both relevant for a connection from one pod to another. By default, a pod is non-isolated for egress; all outbound connections are allowed. A pod is isolated for egress if there is any NetworkPolicy that both selects the pod and has "Egress" in its `policyTypes`; we say that such a policy applies to the pod for egress. When a pod is isolated for egress, the only allowed connections from the pod are those allowed by the `egress` list of some NetworkPolicy that applies to the pod for egress. The effects of those `egress` lists combine additively. By default, a pod is non-isolated for ingress; all inbound connections are allowed. A pod is isolated for ingress if there is any NetworkPolicy that both selects the pod and has "Ingress" in its `policyTypes`; we say that such a policy applies to the pod for ingress. When a pod is isolated for ingress, the only allowed connections into the pod are those from the pod's node and those allowed by the `ingress` list of some NetworkPolicy that applies to the pod for ingress. The effects of those `ingress` lists combine additively. Network policies do not conflict; they are additive. If any policy or policies apply to a given pod for a given direction, the connections allowed in that direction from that pod is the union of what the applicable policies allow. Thus, order of evaluation does not affect the policy result. For a connection from a source pod to a destination pod to be allowed, both the egress policy on the source pod and the ingress policy on the destination pod need to allow the connection. If either side does not allow the connection, it will not happen. </ins> ## The NetworkPolicy resource {#networkpolicy-resource} <del> See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) reference for a full definition of the resource. </del> <ins> See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) reference for a full definition of the resource. </ins> An example NetworkPolicy might look like this: {{< codenew file="service/networking/networkpolicy.yaml" >}} {{< note >}} <del> POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy. </del> <ins> POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy. </ins> {{< /note >}} <del> __Mandatory Fields__: As with all other Kubernetes config, a NetworkPolicy needs `apiVersion`, `kind`, and `metadata` fields.  For general information about working with config files, see </del> <ins> __Mandatory Fields__: As with all other Kubernetes config, a NetworkPolicy needs `apiVersion`, `kind`, and `metadata` fields.  For general information about working with config files, see </ins> [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), and [Object Management](/docs/concepts/overview/working-with-objects/object-management). <del> __spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace. </del> <ins> **spec**: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace. </ins> <del> __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace. </del> <ins> **podSelector**: Each NetworkPolicy includes a `podSelector` which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace. </ins> <del> __policyTypes__: Each NetworkPolicy includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules. </del> <ins> **policyTypes**: Each NetworkPolicy includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules. </ins> <del> __ingress__: Each NetworkPolicy may include a list of allowed `ingress` rules.  Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`. </del> <ins> **ingress**: Each NetworkPolicy may include a list of allowed `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`. </ins> <del> __egress__: Each NetworkPolicy may include a list of allowed `egress` rules.  Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`. </del> <ins> **egress**: Each NetworkPolicy may include a list of allowed `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`. </ins> So, the example NetworkPolicy: <del> 1. isolates "role=db" pods in the "default" namespace for both ingress and egress traffic (if they weren't already isolated) 2. (Ingress rules) allows connections to all pods in the "default" namespace with the label "role=db" on TCP port 6379 from: </del> <ins> 1. isolates `role=db` pods in the `default` namespace for both ingress and egress traffic (if they weren't already isolated) 1. (Ingress rules) allows connections to all pods in the `default` namespace with the label `role=db` on TCP port 6379 from: * any pod in the `default` namespace with the label `role=frontend` * any pod in a namespace with the label `project=myproject` * IP addresses in the ranges `172.17.0.0`–`172.17.0.255` and `172.17.2.0`–`172.17.255.255` (ie, all of `172.17.0.0/16` except `172.17.1.0/24`) </ins> <del> * any pod in the "default" namespace with the label "role=frontend" * any pod in a namespace with the label "project=myproject" * IP addresses in the ranges 172.17.0.0–172.17.0.255 and 172.17.2.0–172.17.255.255 (ie, all of 172.17.0.0/16 except 172.17.1.0/24) 3. (Egress rules) allows connections from any pod in the "default" namespace with the label "role=db" to CIDR 10.0.0.0/24 on TCP port 5978 </del> <ins> 1. (Egress rules) allows connections from any pod in the `default` namespace with the label `role=db` to CIDR `10.0.0.0/24` on TCP port 5978 </ins> <del> See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. </del> <ins> See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. </ins> ## Behavior of `to` and `from` selectors <del> There are four kinds of selectors that can be specified in an `ingress` `from` section or `egress` `to` section: </del> <ins> There are four kinds of selectors that can be specified in an `ingress` `from` section or `egress` `to` section: </ins> <del> __podSelector__: This selects particular Pods in the same namespace as the NetworkPolicy which should be allowed as ingress sources or egress destinations. </del> <ins> **podSelector**: This selects particular Pods in the same namespace as the NetworkPolicy which should be allowed as ingress sources or egress destinations. </ins> <del> __namespaceSelector__: This selects particular namespaces for which all Pods should be allowed as ingress sources or egress destinations. </del> <ins> **namespaceSelector**: This selects particular namespaces for which all Pods should be allowed as ingress sources or egress destinations. </ins> <del> __namespaceSelector__ *and* __podSelector__: A single `to`/`from` entry that specifies both `namespaceSelector` and `podSelector` selects particular Pods within particular namespaces. Be careful to use correct YAML syntax; this policy: </del> <ins> **namespaceSelector** *and* **podSelector**: A single `to`/`from` entry that specifies both `namespaceSelector` and `podSelector` selects particular Pods within particular namespaces. Be careful to use correct YAML syntax. For example: </ins> ```yaml ...

I spent one hour to do one sample exercice about network policy because of your wrong configuration !!! +++++++++++++++++++++ policyTypes: # should remove space in the 2nd & 3rd line Ingress Egress ++++++++++++++++++++++ egress: to: ipBlock: cidr: 10.0.0.0/24 ports: # "-" is missing before ports protocol: TCP port: 5978
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Invalid manifest in Network Policies page Thanks for reporting the bug /kind bug /language en Please paste in the entire invalid manifest (surround it by <tt`</ttif you can) so we know which part of the page is wrong. We could guess, but it's easier if you're explicit about this
/triage accepted /assign


Question: title: Persistent Volume Claim id: persistent-volume-claim date: 2018-04-12 <del> full_link: /docs/concepts/storage/persistent-volumes/ </del> <ins> full_link: /docs/concepts/storage/persistent-volumes/#persistentvolumeclaims </ins> short_description: > Claims storage resources defined in a PersistentVolume so that it can be mounted as a volume in a container.

Problem: The text on should point to these Check the page for the problem. Page to Update: Proposed Solution: It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text PersistentVolumeClaim to and not to this . /kind document /assign /language en
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: The text on should point to these Check the page for the problem. It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text PersistentVolumeClaim to and not to this . /assign /language en Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: {{< glossary_definition term_id="api-eviction" length="short" >}} </br> <!-- <del> You can request eviction by directly calling the Eviction API using a client of the kube-apiserver, like the `kubectl drain` command. This creates an `Eviction` object, which causes the API server to terminate the Pod. </del> <ins> You can request eviction by calling the Eviction API directly, or programmatically using a client of the {{<glossary_tooltip term_id="kube-apiserver" text="API server">}}, like the `kubectl drain` command. This creates an `Eviction` object, which causes the API server to terminate the Pod. </ins> API-initiated evictions respect your configured [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination). <ins> Using the API to create an Eviction object for a Pod is like performing a policy-controlled [`DELETE` operation](/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod) on the Pod. </ins> --> <del> 你可以通过 kube-apiserver 的客户端，比如 `kubectl drain` 这样的命令，直接调用 Eviction API 发起驱逐。 </del> <ins> 你可以通过直接调用 Eviction API 发起驱逐，也可以通过编程的方式使用 {{<glossary_tooltip term_id="kube-apiserver" text="API 服务器">}}的客户端来发起驱逐， 比如 `kubectl drain` 命令。 </ins> 此操作创建一个 `Eviction` 对象，该对象再驱动 API 服务器终止选定的 Pod。 API 发起的驱逐将遵从你的

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


Question: <ins> --- layout: blog title: "Kubernetes 1.26: 我们现在正在对二进制发布工件进行签名!" date: 2022-12-12 slug: kubernetes-release-artifact-signing --- <!-- layout: blog title: "Kubernetes 1.26: We're now signing our binary release artifacts!" date: 2022-12-12 slug: kubernetes-release-artifact-signing --> <!-- **Author:** Sascha Grunert --> **作者：** Sascha Grunert **译者：** XiaoYang Zhang (HUAWEI) <!-- The Kubernetes Special Interest Group (SIG) Release is proud to announce that we are digitally signing all release artifacts, and that this aspect of Kubernetes has now reached _beta_. --> Kubernetes 特别兴趣小组 SIG Release 自豪地宣布，我们正在对所有发布工件进行数字签名，并且 Kubernetes 在这一方面现已达到 **Beta**。 <!-- Signing artifacts provides end users a chance to verify the integrity of the downloaded resource. It allows to mitigate man-in-the-middle attacks directly on the client side and therefore ensures the trustfulness of the remote serving the artifacts. The overall goal of out past work was to define the used tooling for signing all Kubernetes related artifacts as well as providing a standard signing process for related projects (for example for those in [kubernetes-sigs][k-sigs]). --> 签名工件为终端用户提供了验证下载资源完整性的机会。 它可以直接在客户端减轻中间人攻击，从而确保远程服务工件的可信度。 过去工作的总体目标是定义用于对所有 Kubernetes 相关工件进行签名的工具， 以及为相关项目（例如 [kubernetes-sigs][k-sigs] 中的项目）提供标准签名流程。 [k-sigs]: https://github.com/kubernetes-sigs <!-- We already signed all officially released container images (from Kubernetes v1.24 onwards). Image signing was alpha for v1.24 and v1.25. For v1.26, we've added all **binary artifacts** to the signing process as well! This means that now all [client, server and source tarballs][tarballs], [binary artifacts][binaries], [Software Bills of Material (SBOMs)][sboms] as well as the [build provenance][provenance] will be signed using [cosign][cosign]. Technically speaking, we now ship additional `*.sig` (signature) and `*.cert` (certificate) files side by side to the artifacts for verifying their integrity. --> 我们已经对所有官方发布的容器镜像进行了签名（从 Kubernetes v1.24 开始）。 在 v1.24 版本和 v1.25 版本中，镜像签名是 alpha 版本。 在 v1.26 版本中，我们将所有的 **二进制工件** 也加入到了签名过程中！ 这意味着现在所有的[客户端、服务器和源码压缩包][tarballs]、[二进制工件][binaries]、[软件材料清单（SBOM）][sboms] 以及[构建源][provenance]都将使用 [cosign][cosign] 进行签名！ 从技术上讲，我们现在将额外的 `*.sig`（签名）和 `*.cert`（证书）文件与工件一起发布以用于验证其完整性。 [tarballs]: https://github.com/kubernetes/kubernetes/blob/release-1.26/CHANGELOG/CHANGELOG-1.26.md#downloads-for-v1260 [binaries]: https://gcsweb.k8s.io/gcs/kubernetes-release/release/v1.26.0/bin [sboms]: https://dl.k8s.io/release/v1.26.0/kubernetes-release.spdx [provenance]: https://dl.k8s.io/kubernetes-release/release/v1.26.0/provenance.json [cosign]: https://github.com/sigstore/cosign <!-- To verify an artifact, for example `kubectl`, you can download the signature and certificate alongside with the binary. I use the release candidate `rc.1` of v1.26 for demonstration purposes because the final has not been released yet: --> 要验证一个工件，例如 `kubectl`，你可以在下载二进制文件的同时下载签名和证书。 我使用 v1.26 的候选发布版本 `rc.1` 来演示，因为最终版本还没有发布： ```shell curl -sSfL https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl -o kubectl curl -sSfL https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.sig -o kubectl.sig curl -sSfL https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.cert -o kubectl.cert ``` <!-- Then you can verify `kubectl` using [`cosign`][cosign]: --> 然后你可以使用 [`cosign`][cosign] 验证 `kubectl`： ```shell COSIGN_EXPERIMENTAL=1 cosign verify-blob kubectl --signature kubectl.sig --certificate kubectl.cert ``` ``` tlog entry verified with uuid: 5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 index: 8173886 Verified OK ``` <!-- The UUID can be used to query the [rekor][rekor] transparency log: --> 可用 UUID 查询 [rekor][rekor] 透明日志： [rekor]: https://github.com/sigstore/rekor ```shell rekor-cli get --uuid 5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 ``` ``` LogID: c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d Index: 8173886 IntegratedTime: 2022-11-30T18:59:07Z UUID: 24296fb24b8ad77a5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 Body: { "HashedRekordObj": { "data": { "hash": { "algorithm": "sha256", "value": "982dfe7eb5c27120de6262d30fa3e8029bc1da9e632ce70570e9c921d2851fc2" } }, "signature": { "content": "MEQCIH0e1/0svxMoLzjeyhAaLFSHy5ZaYy0/2iQl2t3E0Pj4AiBsWmwjfLzrVyp9/v1sy70Q+FHE8miauOOVkAW2lTYVug==", "publicKey": { "content": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN2akNDQWthZ0F3SUJBZ0lVRldab0pLSUlFWkp3LzdsRkFrSVE2SHBQdi93d0NnWUlLb1pJemowRUF3TXcKTnpFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUjR3SEFZRFZRUURFeFZ6YVdkemRHOXlaUzFwYm5SbApjbTFsWkdsaGRHVXdIaGNOTWpJeE1UTXdNVGcxT1RBMldoY05Nakl4TVRNd01Ua3dPVEEyV2pBQU1Ga3dFd1lICktvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUVDT3h5OXBwTFZzcVFPdHJ6RFgveTRtTHZSeU1scW9sTzBrS0EKTlJDM3U3bjMreHorYkhvWVkvMUNNRHpJQjBhRTA3NkR4ZWVaSkhVaWFjUXU4a0dDNktPQ0FXVXdnZ0ZoTUE0RwpBMVVkRHdFQi93UUVBd0lIZ0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREF6QWRCZ05WSFE0RUZnUVV5SmwxCkNlLzIzNGJmREJZQ2NzbXkreG5qdnpjd0h3WURWUjBqQkJnd0ZvQVUzOVBwejFZa0VaYjVxTmpwS0ZXaXhpNFkKWkQ4d1FnWURWUjBSQVFIL0JEZ3dOb0UwYTNKbGJDMXpkR0ZuYVc1blFHczRjeTF5Wld4bGJtY3RjSEp2WkM1cApZVzB1WjNObGNuWnBZMlZoWTJOdmRXNTBMbU52YlRBcEJnb3JCZ0VFQVlPL01BRUJCQnRvZEhSd2N6b3ZMMkZqClkyOTFiblJ6TG1kdmIyZHNaUzVqYjIwd2dZb0dDaXNHQVFRQjFua0NCQUlFZkFSNkFIZ0FkZ0RkUFRCcXhzY1IKTW1NWkhoeVpaemNDb2twZXVONDhyZitIaW5LQUx5bnVqZ0FBQVlUSjZDdlJBQUFFQXdCSE1FVUNJRXI4T1NIUQp5a25jRFZpNEJySklXMFJHS0pqNkQyTXFGdkFMb0I5SmNycXlBaUVBNW4xZ283cmQ2U3ZVeXNxeldhMUdudGZKCllTQnVTZHF1akVySFlMQTUrZTR3Q2dZSUtvWkl6ajBFQXdNRFpnQXdZd0l2Tlhub3pyS0pWVWFESTFiNUlqa1oKUWJJbDhvcmlMQ1M4MFJhcUlBSlJhRHNCNTFUeU9iYTdWcGVYdThuTHNjVUNNREU4ZmpPZzBBc3ZzSXp2azNRUQo0c3RCTkQrdTRVV1UrcjhYY0VxS0YwNGJjTFQwWEcyOHZGQjRCT2x6R204K093PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=" } } } } ``` <!-- The `HashedRekordObj.signature.content` should match the content of the file `kubectl.sig` and `HashedRekordObj.signature.publicKey.content` should be identical with the contents of `kubectl.cert`. It is also possible to specify the remote certificate and signature locations without downloading them: --> `HashedRekordObj.signature.content` 应与 `kubectl.sig` 的内容匹配， `HashedRekordObj.signature.publicKey.content` 应与 `kubectl.cert` 的内容匹配。 也可以指定远程证书和签名的位置而不下载它们： ```shell COSIGN_EXPERIMENTAL=1 cosign verify-blob kubectl  --signature https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.sig  --certificate https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.cert ``` ``` tlog entry verified with uuid: 5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 index: 8173886 Verified OK ``` <!-- All of the mentioned steps as well as how to verify container images are outlined in the official documentation about how to [Verify Signed Kubernetes Artifacts][docs]. In one of the next upcoming Kubernetes releases we will working making the global story more mature by ensuring that truly all Kubernetes artifacts are signed. Beside that, we are considering using Kubernetes owned infrastructure for the signing (root trust) and verification (transparency log) process. --> 有关如何[验证已签名的 Kubernetes 工件][docs]的官方文档中概述了所有提到的步骤以及如何验证容器镜像。 在下一个即将发布的 Kubernetes 版本中，我们将通过确保真正对所有 Kubernetes 工件进行签名来使之在全球更加成熟。 除此之外，我们正在考虑使用 Kubernetes 自有的基础设施来进行签名（根信任）和验证（透明日志）过程。 <!-- [docs]: /docs/tasks/administer-cluster/verify-signed-artifacts --> [docs]: /zh-cn/docs/tasks/administer-cluster/verify-signed-artifacts <!-- ## Getting involved If you're interested in contributing to SIG Release, then consider applying for the upcoming v1.27 shadowing program (watch for the announcement on [k-dev][k-dev]) or join our [weekly meeting][meeting] to say _hi_. --> ## 参与其中  {#getting-involved} 如果你有兴趣为 SIG Release 做贡献，请考虑申请即将推出的 v1.27 影子计划（观看 [k-dev][k-dev] 上的公告）或参加我们的[周例会][meeting]。 <!-- We're looking forward to making even more of those awesome changes for future Kubernetes releases. For example, we're working on the [SLSA Level 3 Compliance in the Kubernetes Release Process][slsa] or the [Renaming of the kubernetes/kubernetes default branch name to `main`][kkmain]. --> 我们期待着在未来的 Kubernetes 版本中做出更多了不起的改变。例如，我们正在致力于 [Kubernetes 发布过程中的 SLSA 3 级合规性][slsa]或将 [kubernetes/kubernetes 默认分支名称重命名为 `main`][kkmain]。 <!-- Thank you for reading this blog post! I'd like to use this opportunity to give all involved SIG Release folks a special shout-out for shipping this feature in time! --> 感谢你阅读这篇博文！我想借此机会向所有参与的 SIG Release 人员表示特别地感谢，感谢他们及时推出这一功能！ <!-- Feel free to reach out to us by using the [SIG Release mailing list][mail] or the [#sig-release][slack] Slack channel. --> 欢迎使用 [SIG Release 邮件列表][mail]或 [#sig-release][slack] Slack 频道与我们联系。 [mail]: https://groups.google.com/g/kubernetes-sig-release [slsa]: https://github.com/kubernetes/enhancements/issues/3027 [kkmain]: https://github.com/kubernetes/enhancements/issues/2853 [slack]: http://slack.k8s.io [k-dev]: https://groups.google.com/a/kubernetes.io/g/dev [meeting]: http://bit.ly/k8s-sig-release-meeting <!-- ## Additional resources - [Signing Release Artifacts Enhancement Proposal](https://github.com/kubernetes/enhancements/issues/3031) --> ## 附加资源  {#additional-resources} - [签名发布工件增强提案](https://github.com/kubernetes/enhancements/issues/3031) </ins>  No newline at end of file

This is a Feature Request This page has no Chinese version What would you like to be Translate Chinese version for blog2022-12-12-kubernetes-release-artifact- Comments /language zh /assign
/triage accepted


Question: kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}' # The following command achieves the desired result <del> kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image' </del> <ins> kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).metadata.name' </ins> ``` {{< /note >}}

Last paragraph, last code example should be in the first example the result is the in the second now it is
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Page related to issue: /language en
/kind bug
/assign


Question: VolumeAttributes stores driver-specific properties that are passed to the CSI driver. Consult your driver's documentation for supported values. <del> ### Alpha level {#Alpha level} </del> <ins> ### Alpha level {#Alpha-level} </ins> - **ephemeral** (EphemeralVolumeSource)

This is a Bug Report The issue is outlined in:
/triage accepted
/kind cleanup
Hi Thanks for opening a PR to fix this issue! /assign


Question: {{% /capture %}} <ins> {{% capture cleanup %}} To delete the Services, enter this command: kubectl delete services frontend hello To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command: kubectl delete deployment frontend hello {{% /capture %}} </ins> {{% capture whatsnext %}}

Problem: The page is missing the Cleaning up topic Proposed Solution: Add the commands that delete the created services and deployments Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/assign


Question: The following table includes a list of all the supported resource types and their abbreviated aliases. <del> (This output can be retrieved from `kubectl api-resources`, and was accurate as of Kubernetes 1.13.3.) </del> <ins> (This output can be retrieved from `kubectl api-resources`, and was accurate as of Kubernetes 1.19.1.) </ins> <del> | Resource Name | Short Names | API Group | Namespaced | Resource Kind | </del> <ins> | NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND | </ins> |---|---|---|---|---| <del> | `bindings` | | | true | Binding| </del> <ins> | `bindings` | | | true | Binding | </ins> | `componentstatuses` | `cs` | | false | ComponentStatus | | `configmaps` | `cm` | | true | ConfigMap | | `endpoints` | `ep` | | true | Endpoints | <ins> | `events` | `ev` | | true | Event | </ins> | `limitranges` | `limits` | | true | LimitRange | | `namespaces` | `ns` | | false | Namespace | | `nodes` | `no` | | false | Node |

This is a Bug Report Problem: The resource type list on is about v1.13.3 which is too old. We are not obliged to keep the list updated on every release, but having the list updated to a supported version is still desireable. Proposed Solution: Update the list to reflect what we have today. Page to Update:
ref:
/assign
fixed. /close
Closing this issue. <detailsIn response to : fixed. /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: /docs/concepts/configuration/container-command-arg/     /docs/tasks/inject-data-application/define-command-argument-container/ 301 /docs/concepts/configuration/container-command-args/     /docs/tasks/inject-data-application/define-command-argument-container/     301 /docs/concepts/configuration/manage-compute-resources-container/ /docs/concepts/configuration/manage-resources-containers/ 301 <ins> /docs/concepts/configuration/resource-bin-packing/      /docs/concepts/scheduling-eviction/resource-bin-packing/ 301 </ins> /docs/concepts/configuration/scheduler-perf-tuning/      /docs/concepts/scheduling-eviction/scheduler-perf-tuning/    301 /docs/concepts/configuration/scheduling-framework/     /docs/concepts/scheduling-eviction/scheduling-framework/    301 /docs/concepts/configuration/taint-and-toleration/     /docs/concepts/scheduling-eviction/taint-and-toleration/ 301

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Migrate the content from into somewhere inside Why is this needed is not about configuration in the way that ConfigMap and Secret are; instead, it's much more about scheduling. Comments /language en /kind cleanup Initially, a straightforward cut-and-paste would be fine, so I'll mark this as: /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --Migrate the content from into somewhere inside is not about configuration in the way that ConfigMap and Secret are; instead, it's much more about scheduling. /language en /kind cleanup /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
Also see
/assign
BTW, this change also means adding a from to the new URL.


Question: webhooks or validating admission controllers will permit the request to finish. If you disable the MutatingAdmissionWebhook, you must also disable the <del> `MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1` </del> <ins> `MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1` </ins> group/version via the `--runtime-config` flag (both are on by default in versions >= 1.9).

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: ### Loadbalancing <del> An Ingress controller is bootstrapped with some load balancing policy settings that it applies to all Ingress, such as the load balancing algorithm, backend weight scheme, and others. More advanced load balancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://git.k8s.io/contrib/service-loadbalancer). With time, we plan to distill load balancing patterns that are applicable cross platform into the Ingress resource. </del> <ins> An Ingress controller is bootstrapped with some load balancing policy settings that it applies to all Ingress, such as the load balancing algorithm, backend weight scheme, and others. More advanced load balancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://github.com/kubernetes/ingress-nginx/blob/master/docs/catalog.md). With time, we plan to distill load balancing patterns that are applicable cross platform into the Ingress resource. </ins> It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) which allow you to achieve the same end result. Please review the controller specific docs to see how they handle health checks ([nginx](https://git.k8s.io/ingress-nginx/README.md), [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).

<!-- 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: Ingress documentation contains a link to a project () that is deprecated. Proposed Solution: Update the link and the docs to point , which lists non-cloud ingress alternatives. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--