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/#csi-migration-5). </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}

Problem: The text on redirects to the correct link should be For the problem, check the page . Proposed Solution: It should resolve this issue by removing the context link and editing the text to enhance the document line. Page to Update: Update the link on text vSphereVolume CSI migration as and not 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 redirects to the correct link should be It should resolve this issue by removing the context link and editing the text to enhance the document line. /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: <del> --- title: マスターとノード間の通信 content_type: concept weight: 20 --- <!-- overview --> 本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)およびクラスター間のコミュニケーション経路についてまとめます。 この文書の目的は、信頼できないネットワーク上(またはクラウドプロバイダ上の完全にパブリックなIP上)でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。 <!-- body --> ## クラスターからマスターへの通信 クラスターからマスターへのすべての通信経路は、APIサーバーで終端します(他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません)。 一般的には、1つ以上の形式のクライアント[認証](/ja/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。 特に[匿名のリクエスト](/docs/reference/access-authn-authz/authentication/#anonymous-requests)または[サービスアカウントトークン](/docs/reference/access-authn-authz/authentication/#service-account-tokens)が許可されている場合は、1つまたは複数の[認証](/docs/reference/access-authn-authz/authorization/)を有効にする必要があります。 ノードには、有効なクライアント認証情報を使って安全にAPIサーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。 たとえば、GKEのデフォルト設定では、kubeletに提供されるクライアント認証情報はクライアント証明書の形式です。 kubeletのクライアント証明書を自動プロビジョニングする方法については、[kubelet TLSブートストラッピング](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)を参照してください。 APIサーバーに接続したいPodは、サービスアカウントを利用することで接続を安全にすることができます。そうすることで、Podが作成されたときにKubernetesがパブリックなルート証明書と有効なBearer TokenをPodに自動的に挿入します。 `kubernetes`サービスには(すべてのネームスペースで)、APIサーバー上のHTTPSエンドポイントに(kube-proxy経由で)リダイレクトされる仮想IPアドレスが設定されています。 マスターコンポーネントは、セキュアなポートを介してクラスターAPIサーバーとも通信します。 その結果、クラスター(ノードとそのノードで実行されているPod)からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。 ## マスターからクラスターへの通信 マスター(APIサーバー)からクラスターへの通信には、2つの主要な通信経路があります。 1つ目は、APIサーバーからクラスター内の各ノードで実行されるkubeletプロセスへの通信です。 2つ目は、APIサーバーのプロキシ機能を介した、APIサーバーから任意のノード、Pod、またはサービスへのアクセスです。 ### APIサーバーからkubeletへの通信 APIサーバーからkubeletへの接続は以下の目的で使用されます: * Podのログを取得する * 実行中のPodに(kubectlを通して)接続する * kubeletのポート転送機能を提供する これらの接続は、kubeletのHTTPSエンドポイントで終了します。 デフォルトでは、APIサーバーはkubeletが提供する証明書を検証しないため、接続は中間者攻撃を受けやすく、**安全でない**信頼できないネットワークやパブリックなネットワークを介して実行されることになります。 この接続を検証するには、`--kubelet-certificate-authority`フラグを使用して、kubeletが提供する証明書を確認するために使用するルート証明書バンドルをAPIサーバーに提供します。 それができない場合は、信頼できないネットワークやパブリックなネットワークを介した接続を回避するために、必要に応じてAPIサーバーとkubeletの間でSSHトンネリングを使用してください。 最後に、kubeletのAPIを保護するために[kubeletの認証認可](/docs/admin/kubelet-authentication-authorization/)を有効にする必要があります。 ### APIサーバーからノード、Pod、サービスへの通信 APIサーバーからノード、Pod、またはサービスへの接続はデフォルトで平文のHTTP接続になるため、認証も暗号化もされません。 API URL内のノード、Pod、またはサービス名に`https:`を付けることで安全なHTTPS接続で実行できますが、HTTPSエンドポイントから提供される証明書を検証したりクライアントの資格情報を提供したりすることはありませんし、暗号化されているという完全性を保証するものでもありません。 これらの接続を信頼できないネットワークや公衆ネットワークを介して実行するのは、現時点において安全ではありません。 ### SSHトンネル Kubernetesはマスターからクラスターへの通信経路を保護するためにSSHトンネルをサポートしています。 この設定では、APIサーバーはクラスター内の各ノード(ポート22でlistenしているsshサーバーに接続)へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。 このトンネルにより、ノードが実行されているネットワークの外部にトラフィックが公開されないようにします。 SSHトンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。 </del>

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 into Japanese. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This file for the original page was renamed from to , and some updates. ref: The file for the Japanese page is not renamed yet. So, "" remains and "Communication between Nodes and the Control Plane" for ja does not exist. Japanese page also needs to be updated in the same way. /assign


Question: <ins> --- reviewers: - ramrodo - krol3 - electrocucaracha title: Volúmenes efímeros content_type: concept weight: 30 --- <!-- overview --> Este documento describe _volúmenes efímeros_ en Kubernetes. Se sugiere tener conocimiento previo sobre [volúmenes](/docs/concepts/storage/volumes/), en particular PersistentVolumeClaim y PersistentVolume. <!-- body --> Algunas aplicaciones requieren almacenamiento adicional, pero no les preocupa si esos datos se almacenan de manera persistente entre reinicios. Por ejemplo, los servicios de caché a menudo tienen limitaciones de tamaño de memoria y pueden trasladar datos poco utilizados a un almacenamiento más lento que la memoria, con un impacto mínimo en el rendimiento general. Otras aplicaciones esperan que algunos datos de entrada de solo lectura estén presentes en archivos, como datos de configuración o claves secretas. Los _volúmenes efímeros_ están diseñados para estos casos de uso. Debido a que los volúmenes siguen el ciclo de vida del Pod y se crean y eliminan junto con el Pod, los Pods pueden detenerse y reiniciarse sin estar limitados a la disponibilidad de algún volumen persistente. Los volúmenes efímeros se especifican _en línea_ en la especificación del Pod, lo que simplifica la implementación y gestión de aplicaciones. ### Tipos de volúmenes efímeros Kubernetes admite varios tipos diferentes de volúmenes efímeros para diversos propósitos: - [emptyDir](/docs/concepts/storage/volumes/#emptydir): vacíos al inicio del Pod, con el almacenamiento proveniente localmente del directorio base de kubelet (generalmente el disco raíz) o la RAM. - [configMap](/docs/concepts/storage/volumes/#configmap), [downwardAPI](/docs/concepts/storage/volumes/#downwardapi), [secret](/docs/concepts/storage/volumes/#secret): inyectar diferentes tipos de datos de Kubernetes en un Pod. - [CSI volúmenes efímeros](#csi-ephemeral-volumes): Similar a los tipos de volumen anteriores, pero proporcionados por controladores especiales {{< glossary_tooltip text="CSI" term_id="csi" >}} que [soportan específicamente esta característica](https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html) - [volúmenes efímeros genéricos](#generic-ephemeral-volumes), que pueden proporcionar todos los controladores de almacenamiento que también admiten volúmenes persistentes `emptyDir`, `configMap`, `downwardAPI`, `secret` se proporcionan como [almacenamiento efímero local](/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage). Ellos son administrados por kubelet en cada nodo. Los volúmenes efímeros CSI _deben_ ser proporcionados por controladores de almacenamiento CSI de terceros. Los volúmenes efímeros genéricos _pueden_ ser proporcionados por controladores de almacenamiento CSI de terceros, pero también por cualquier otro controlador de almacenamiento que admita la provisión dinámica. Algunos controladores CSI están escritos específicamente para volúmenes efímeros CSI y no admiten la provisión dinámica; por lo tanto, no se pueden utilizar para volúmenes efímeros genéricos. La ventaja de utilizar controladores de terceros es que pueden ofrecer funcionalidades que Kubernetes en sí mismo no admite, como el almacenamiento con características de rendimiento diferentes al disco gestionado por kubelet o la inyección de datos diversos. ### Volúmenes efímeros de CSI {{< feature-state for_k8s_version="v1.25" state="stable" >}} {{< note >}} Los volúmenes efímeros CSI solo son compatibles con un subconjunto de controladores CSI. La [lista de controladores](https://kubernetes-csi.github.io/docs/drivers.html) CSI de Kubernetes muestra cuáles controladores admiten volúmenes efímeros. {{< /note >}} Conceptualmente, los volúmenes efímeros CSI son similares a los tipos de volumen `configMap`, `downwardAPI` y `secret`: el almacenamiento se gestiona localmente en cada nodo y se crea junto con otros recursos locales después de que un Pod ha sido programado en un nodo. Kubernetes ya no tiene ningún concepto de reprogramación de Pods en esta etapa. La creación de volúmenes debe ser poco propensa a fallos, de lo contrario, el inicio del Pod queda atascado. En particular, [la programación de Pods con conciencia de la capacidad de almacenamiento](/docs/concepts/storage/storage-capacity/) _no_ está admitida para estos volúmenes. Actualmente, tampoco están cubiertos por los límites de uso de recursos de almacenamiento de un Pod, porque eso es algo que kubelet solo puede aplicar para el almacenamiento que administra él mismo. Aquí tienes un ejemplo de manifiesto para un Pod que utiliza almacenamiento efímero CSI: ```yaml kind: Pod apiVersion: v1 metadata: name: my-csi-app spec: containers: - name: my-frontend image: busybox:1.28 volumeMounts: - mountPath: "/data" name: my-csi-inline-vol command: ["sleep", "1000000"] volumes: - name: my-csi-inline-vol csi: driver: inline.storage.kubernetes.io volumeAttributes: foo: bar ``` Los `volumeAttributes` determinan qué volumen es preparado por el controlador. Estos atributos son específicos de cada controlador y no están estandarizados. Consulta la documentación de cada controlador CSI para obtener instrucciones adicionales. ### Restricciones del conductor CSI Los volúmenes efímeros CSI permiten a los usuarios proporcionar `volumeAttributes` directamente al controlador CSI como parte de la especificación del Pod. Un controlador CSI que permite `volumeAttributes` que normalmente están restringidos a administradores NO es adecuado para su uso en un volumen efímero en línea. Por ejemplo, los parámetros que normalmente se definen en la clase de almacenamiento no deben estar expuestos a los usuarios a través del uso de volúmenes efímeros en línea. Los administradores del clúster que necesiten restringir los controladores CSI que se pueden utilizar como volúmenes en línea dentro de una especificación de Pod pueden hacerlo mediante: - Eliminar `Ephemeral` de `volumeLifecycleModes` en la especificación de CSIDriver, lo que evita que los controladores CSI admitan volúmenes efímeros en línea. - Usando un [webhook de admisión](/docs/reference/access-authn-authz/extensible-admission-controllers/) para restringir el uso de este controlador. ### Volúmenes efímeros genéricos {{< feature-state for_k8s_version="v1.23" state="stable" >}} Los volúmenes efímeros genéricos son similares a los volúmenes `emptyDir` en el sentido de que proporcionan un directorio por Pod para datos temporales que generalmente está vacío después de la provisión. Pero también pueden tener características adicionales: - El almacenamiento puede ser local o conectado a la red. - Los volúmenes pueden tener un tamaño fijo que los Pods no pueden exceder. - Los volúmenes pueden tener algunos datos iniciales, dependiendo del controlador y los parámetros. - Se admiten operaciones típicas en los volúmenes, siempre que el controlador las soporte, incluyendo [instantáneas](/docs/concepts/storage/volume-snapshots/), [clonación](/docs/concepts/storage/volume-pvc-datasource/), [cambiar el tamaño](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims), y [seguimiento de la capacidad de almacenamiento](/docs/concepts/storage/storage-capacity/). Ejemplo: ```yaml kind: Pod apiVersion: v1 metadata: name: my-app spec: containers: - name: my-frontend image: busybox:1.28 volumeMounts: - mountPath: "/scratch" name: scratch-volume command: ["sleep", "1000000"] volumes: - name: scratch-volume ephemeral: volumeClaimTemplate: metadata: labels: type: my-frontend-volume spec: accessModes: ["ReadWriteOnce"] storageClassName: "scratch-storage-class" resources: requests: storage: 1Gi ``` ### Ciclo de vida y reclamo de volumen persistente La idea clave de diseño es que los [parámetros para una solicitud de volumen](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1-core) se permiten dentro de una fuente de volumen del Pod. Se admiten etiquetas, anotaciones y todo el conjunto de campos para una PersistentVolumeClaim. Cuando se crea un Pod de este tipo, el controlador de volúmenes efímeros crea entonces un objeto PersistentVolumeClaim real en el mismo espacio de nombres que el Pod y asegura que la PersistentVolumeClaim se elimine cuando se elimina el Pod. Eso desencadena la vinculación y/o aprovisionamiento de volúmenes, ya sea de inmediato si el {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} utiliza la vinculación inmediata de volúmenes o cuando el Pod está programado provisionalmente en un nodo (modo de vinculación de volumen `WaitForFirstConsumer`). Este último se recomienda para volúmenes efímeros genéricos, ya que permite al planificador elegir libremente un nodo adecuado para el Pod. Con la vinculación inmediata, el planificador está obligado a seleccionar un nodo que tenga acceso al volumen una vez que esté disponible. En términos de [propiedad de recursos](/docs/concepts/architecture/garbage-collection/#owners-dependents), un Pod que tiene almacenamiento efímero genérico es el propietario de la PersistentVolumeClaim(s) que proporciona ese almacenamiento efímero. Cuando se elimina el Pod, el recolector de basura de Kubernetes elimina la PVC, lo que suele desencadenar la eliminación del volumen, ya que la política de recuperación predeterminada de las clases de almacenamiento es eliminar los volúmenes. Puedes crear almacenamiento local cuasi-efímero utilizando una StorageClass con una política de recuperación de `retain`: el almacenamiento sobrevive al Pod y, en este caso, debes asegurarte de que la limpieza del volumen se realice por separado. Mientras estas PVC existen, pueden usarse como cualquier otra PVC. En particular, pueden ser referenciadas como fuente de datos en la clonación o creación de instantáneas de volúmenes. El objeto PVC también contiene el estado actual del volumen. ### Nomenclatura de PersistentVolumeClaim. La nomenclatura de las PVC creadas automáticamente es determinista: el nombre es una combinación del nombre del Pod y el nombre del volumen, con un guion medio (`-`) en el medio. En el ejemplo anterior, el nombre de la PVC será `my-app-scratch-volume`. Esta nomenclatura determinista facilita la interacción con la PVC, ya que no es necesario buscarla una vez que se conocen el nombre del Pod y el nombre del volumen. La nomenclatura determinista también introduce un posible conflicto entre diferentes Pods (un Pod "pod-a" con el volumen "scratch" y otro Pod con nombre "pod" y volumen "a-scratch" terminan teniendo el mismo nombre de PVC "pod-a-scratch") y entre Pods y PVCs creadas manualmente. Estos conflictos se detectan: una PVC solo se utiliza para un volumen efímero si se creó para el Pod. Esta comprobación se basa en la relación de propiedad. Una PVC existente no se sobrescribe ni se modifica. Pero esto no resuelve el conflicto, ya que sin la PVC adecuada, el Pod no puede iniciarse. {{< caution >}} Ten cuidado al nombrar Pods y volúmenes dentro del mismo espacio de nombres para evitar que se produzcan estos conflictos. {{< /caution >}} ### Seguridad El uso de volúmenes efímeros genéricos permite a los usuarios crear PVC de forma indirecta si pueden crear Pods, incluso si no tienen permiso para crear PVC directamente. Los administradores del clúster deben ser conscientes de esto. Si esto no encaja en su modelo de seguridad, deberían utilizar un [webhook de admisión](/docs/reference/access-authn-authz/extensible-admission-controllers/) que rechace objetos como Pods que tienen un volumen efímero genérico. La cuota normal del [espacio de nombres para PVC](/docs/concepts/policy/resource-quotas/#storage-resource-quota) sigue aplicándose, por lo que incluso si a los usuarios se les permite utilizar este nuevo mecanismo, no pueden utilizarlo para eludir otras políticas. ## {{% heading "whatsnext" %}} ### Volúmenes efímeros gestionados por kubelet Ver [almacenamiento efímero local](/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage). ### Volúmenes efímeros de CSI - Para obtener más información sobre el diseño, consulta el [KEP de Volúmenes efímeros en línea de CSI](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md). - Para obtener más información sobre el desarrollo futuro de esta función, consulte el [problema de seguimiento de mejoras #596](https://github.com/kubernetes/enhancements/issues/596). ### Volúmenes efímeros genéricos - Para obtener más información sobre el diseño, consulta el [KEP de Volúmenes efímeros genéricos en línea](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md). </ins>

This is a Feature Request What would you like to be Localize to Spanish Why is this needed There is no Spanish localization for this file. Comments /triage accepted /kind feature /language es /sig docs
could you add a comment here to assign this to you, please?
Hello I would love to translate this page!
Hello , I have already translated the file to Spanish, Can you Please assign me this issue?
Since this issue was initially created to be assigned to I'll give this to her. Thanks for participating in the Kubernetes Website project. The Spanish translation team would like to help you with your contribution, so please share your goals and skills in order to help you better. We also encourage new contributors to participate in their native speaking language.
/assign edithturn


Question: queue excess requests, or * `time-out`, indicating that the request was still in the queue when its queuing time limit expired. <ins> * `cancelled`, indicating that the request is not purge locked and has been ejected from the queue. </ins> * `apiserver_flowcontrol_dispatched_requests_total` is a counter vector (cumulative since server start) of requests that began

(1) The user-facing changes in are not yet reflected in the doc. (2) There are four possible values for the of a rejection ("concurrency-limit", "queue-full", "time-out", and "cancelled") but "cancelled" is not listed in the doc. The relevant page is /sig api-machinery
APF is for "API Priority and Fairness" just for people looking into this issue. /triage accepted /priority important-longterm
Please feel free to change it again if it is not correct. /retitle "API Priority and Fairness" doc must be updated
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale


Question: {{ T "katacoda_removal_warning" | markdownify }}

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 For pages that use Katacoda, add a warning about its removal. Why is this needed Prompted by and Comments /priority critical-urgent /language en /triage accepted


Question: A kubectl plugin that allows you to convert manifests from one version of a Kubernetes API to a different version. headless: true <ins> _build: list: never render: never publishResources: false </ins> --- A plugin for Kubernetes command-line tool `kubectl`, which allows you to convert manifests between different API

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 source Markdown needs to exist for pages such as but we don't need to make those turn into actual web pages. Proposed Solution: Edit every file within : Page to Update: and its contents /area web-development /help /priority backlog /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 : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The source Markdown needs to exist for pages such as but we don't need to make those turn into actual web pages. Edit every file within : Page to Update: and its contents /help /priority backlog /good-first-issue </details
/retitle Include files for install are rendered and served /triage accepted
/assign
/unassign
Thanks !


Question: to run a particular command or override the image's defaults, there are two additional fields that we can use: <del> 1.  `Command`: Controls the actual command run by the image 2.  `Args`: Controls the arguments passed to the command </del> <ins> 1.  `command`: Controls the actual command run by the image 2.  `args`: Controls the arguments passed to the command </ins> ### How docker handles command and arguments

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:
 --- title: kube-apiserver Admission (v1) content_type: tool-reference package: admission.k8s.io/v1 ---   ## 资源类型 - [AdmissionReview](#admission-k8s-io-v1-AdmissionReview) ## `AdmissionReview`     {#admission-k8s-io-v1-AdmissionReview}
AdmissionReview 描述准入评审请求/响应。

字段	描述

apiVersion
string	admission.k8s.io/v1

kind
string	AdmissionReview

request
 AdmissionRequest
request 描述准入请求的属性。

response
 AdmissionResponse
response 描述准入响应的属性。

 ## `AdmissionRequest`     {#admission-k8s-io-v1-AdmissionRequest}  **出现在：** - [AdmissionReview](#admission-k8s-io-v1-AdmissionReview)
AdmissionRequest 描述准入请求的 admission.Attributes。

字段	描述

uid [必需]
 k8s.io/apimachinery/pkg/types.UID
uid 是用于标识单个请求/响应的标识符。它允许我们区分在其他情况下完全相同的请求实例（并行请求、在先前请求未修改时的请求等）。 uid 的目的是跟踪 KAS（Kubernetes Admission Server）和 WebHook 之间的轮询（请求/响应），而不是用户请求。 它适用于在 WebHook 和 API 服务器之间建立日志条目上的关联，从而服务于审计或调试目的。

kind [必需]
 meta/v1.GroupVersionKind
kind 是正被提交的对象的全限定类别名称（例如 v1.Pod 或 autoscaling.v1.Scale）。

resource [必需]
 meta/v1.GroupVersionResource
resource 是正被请求的资源的全限定名称（例如 v1.pods）。

subResource
 string
subResource 是正被请求的子资源——如果存在的话（例如 "status" 或 "scale"）。

requestKind
 meta/v1.GroupVersionKind
requestKind 是原始 API 请求的完全限定类别名称（例如 v1.Pod 或 autoscaling.v1.Scale）。 如果此字段被指定且不同于 "kind" 中的值，则执行等效的匹配和转换。

例如，如果 Deployment 可以通过 apps/v1 和 apps/v1beta1 进行修改，并且 Webhook 注册了 apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"] 和 matchPolicy: Equivalent 的规则，那么指向 apps/v1beta1 Deployment 的 API 请求将被转换并发送到 Webhook， 其中 kind: {group:"apps", version:"v1", kind:"Deployment"} （与 Webhook 注册的规则匹配）并且 requestKind: {group:"apps", version:"v1beta1", kind:"Deployment"}（指示原始 API 请求的类别）。

参阅文档了解 Webhook 配置类型中 "matchPolicy" 字段的更多细节。

requestResource
 meta/v1.GroupVersionResource
requestResource 是原始 API 请求的全限定资源名称（例如 v1.pods）。 如果此字段被指定且不同于 "resource" 中的值，则执行等效的匹配和转换。

例如，如果 Deployment 可以通过 apps/v1 和 apps/v1beta1 修改，并且 Webhook 注册了 apiGroups:["apps"], apiVersions:["v1"], resources: ["deployments"] 和 matchPolicy: Equivalent 的规则，那么指向 apps/v1beta1 Deployment 的 API 请求将被转换并发送到 Webhook， 其中 resource: {group:"apps", version:"v1", resource:"deployments"} （与 Webhook 注册的资源匹配）以及 requestResource: {group:"apps", version:"v1beta1", resource:"deployments"}（指示原始 API 请求的资源）。

参阅文档了解 Webhook 配置类型中 "matchPolicy" 字段的更多细节。

requestSubResource
 string
requestSubResource 是可能存在的、原始 API 所请求的子资源（例如 "status" 或 "scale"）。 如果此字段被指定且不同于 "subResource" 中的值，则执行等效的匹配和转换。 参阅文档了解 Webhook 配置类型中的 "matchPolicy" 字段。

name
 string
name 是出现在请求中的对象的名称。客户端在执行 CREATE 操作时，可以忽略此命令并依赖服务器生成此名称。 如果是这种情况，此字段将包含一个空白字符串。

namespace
 string
namespace 是与请求（如果有的话）关联的命名空间。

operation [必需]
 Operation
operation 是正在执行的操作。这可能不同于请求的操作， 例如 patch 可以造成 CREATE 或 UPDATE 操作。

userInfo [必需]
 authentication/v1.UserInfo
userInfo 是发出请求的用户的相关信息。

object
 k8s.io/apimachinery/pkg/runtime.RawExtension
object 是来自传入请求的对象。

oldObject
 k8s.io/apimachinery/pkg/runtime.RawExtension
oldObject 是现有的对象。只有 DELETE 和 UPDATE 请求中此字段会有值。

dryRun
 bool
dryRun 表示此请求的修改绝对不会被持久化。默认为 false。

options
 k8s.io/apimachinery/pkg/runtime.RawExtension
options 是正在执行的操作的操作选项结构。 例如 meta.k8s.io/v1.DeleteOptions 或 meta.k8s.io/v1.CreateOptions。 所设置的值可能不同于调用方所提供的选项。例如 patch 请求执行的操作可能是 CREATE，那这种情况下即使调用方提供了 meta.k8s.io/v1.PatchOptions，options 也将是 meta.k8s.io/v1.CreateOptions。

 ## `AdmissionResponse`     {#admission-k8s-io-v1-AdmissionResponse}  **出现在：** - [AdmissionReview](#admission-k8s-io-v1-AdmissionReview)
AdmissionResponse 描述准入响应。

字段	描述

uid [必需]
 k8s.io/apimachinery/pkg/types.UID
uid 是标识单独请求/响应的标识符。 它必须从相应的 AdmissionRequest 复制过来。

allowed [必需]
 bool
allowed 表示准入请求是否被允许。

status
 meta/v1.Status
status 包含为什么准入请求被拒绝的额外细节。 如果 "Allowed" 的值为 "true"，则不会以任何方式使用此字段。

patch
 []byte
patch 操作的主体。目前 Kubernetes 仅支持实现了 RFC 6902 的 "JSONPatch"。

patchType
 PatchType
patch 的类型。目前 Kubernetes 仅允许 "JSONPatch"。

auditAnnotations
 map[string]string
auditAnnotations 是由远程准入控制器设置的非结构化键值映射（例如 error=image-blacklisted）。 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 准入控制器将在键前缀中使用准入 Webhook 名称 （例如 imagepolicy.example.com/error=image-blacklisted）。auditAnnotations 将由准入 Webhook 提供，向此请求的审计日志添加额外的上下文。

warnings
 []string
warnings 是警告消息的列表，返回给发出请求的 API 客户端。 这些警告消息描述客户端在进行 API 请求时应该纠正或注意的问题。 如果可能的话，将 warnings 限制在 120 个字符以内。 如果 warnings 中的消息超过 256 个字符，或 warnings 数量过多，可能会被截断。

 ## `Operation`     {#admission-k8s-io-v1-Operation}  （`string` 的别名） **出现在：** - [AdmissionRequest](#admission-k8s-io-v1-AdmissionRequest)
Operation 是正在检查准入控制时资源操作的类型。
 ## `PatchType`     {#admission-k8s-io-v1-PatchType}  （`string` 的别名） **出现在：** - [AdmissionResponse](#admission-k8s-io-v1-AdmissionResponse)
PatchType 是用于表示所变更对象的补丁类型。

File not yet localized to zh-cn.
/sig docs /language zh /area localization
/triage accepted
Localization will not solve the API problems lookout for the bugs in the API code to solve the problems
/assign


Question: After running the command you should restart the control plane Pods. This is required since dynamic certificate reload is currently not supported for all components and certificates. <del> [Static Pods](/docs/tasks/configure-pod-containerstatic-pod/) are managed by the local kubelet </del> <ins> [Static Pods](/docs/tasks/configure-pod-container/static-pod/) are managed by the local kubelet </ins> and not by the API Server, thus kubectl cannot be used to delete and restart them. To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/` and wait for 20 seconds (see the `fileCheckFrequency` value in [KubeletConfiguration struct](/docs/

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: Static Pods link on page is missing. Proposed Solution: Perhaps one of the followings works. the broken link on certificate renewal page. page Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign I can work on this.
Fixed it here:


Question: <!-- Do not edit this file directly. Get the latest from https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/zh.md --> <del> ## 云原生计算基金会（CNCF）社区行为准则 1.0 版本 </del> <ins> ## 云原生计算基金会（CNCF）社区行为准则 1.2 版本 </ins> ### 贡献者行为准则 <del> 作为这个项目的贡献者和维护者，为了建立一个开放和受欢迎的社区， 我们保证尊重所有通过报告问题、发布功能请求、更新文档、提交拉取请求或补丁以及其他活动做出贡献的人员。 </del> <ins> 作为 CNCF 社区的贡献者和维护者，我们努力建设一个开放和受欢迎的社区，我们承诺尊重所有上报 Issue、发布功能需求、更新文档、提交 PR 或补丁的贡献者以及其他相关活动的所有参与者。 </ins> <del> 我们致力于让参与此项目的每个人都不受骚扰， 无论其经验水平、性别、性别认同和表达、性取向、残疾、个人外貌、体型、人种、种族、年龄、宗教或国籍等。 </del> <ins> 我们致力于让参与此项目的每个人都不受骚扰，无论其经验水平、性别、性别认同和表达、性取向、残疾、个人外貌、体型、人种、种族、年龄、宗教或国籍等。 ## 范围 当某个人代表项目或其社区时，本行为准则适用于项目空间和公共空间。 ### CNCF 活动行为准则 云原生计算基金会（CNCF）活动受 Linux 基金会[活动行为准则](https://events.linuxfoundation.org/code-of-conduct/)管辖，该行为准则可在活动页面获得。 其旨在与 CNCF 行为准则兼容。 ## 我们的标准 对社区贡献具有积极正向作用的行为包括： * 表现出对他人的共情和善意 * 尊重不同的意见、观点和经验 * 提出和优雅地接受建设性的反馈 * 有担当，如因自己的错误影响到别人能适时道歉，吸取经验教训 * 关注点不只放在如何让我们自己受益，还能着眼于整个社区 </ins> 不可接受的参与者行为包括： <del> -	使用性语言或图像 -	人身攻击 -	挑衅、侮辱或贬低性评论 -	公开或私下骚扰 -	未经明确许可，发布他人的私人信息，比如地址或电子邮箱 -	其他不道德或不专业的行为 </del> <ins> * 使用性语言或图像以及任何类型的性关注和性倾向 * 挑衅、侮辱或贬低性评论以及人身或政治攻击 * 公开或私下骚扰 * 未经明确许可，发布他人的私密信息，比如地址或电子邮箱 * 其他可能视为不道德或不专业的行为 </ins> <del> 项目维护者有权利和责任删除、编辑或拒绝评论、提交、代码、维基编辑、问题和其他不符合本行为准则的贡献。 </del> <ins> 项目维护者有权利和责任删除、编辑或拒绝不符合本行为准则的评论、提交、编写代码、编辑维基、提问和其它贡献。 </ins> 通过采用本行为准则，项目维护者承诺将这些原则公平且一致地应用到这个项目管理的各个方面。 不遵守或不执行行为准则的项目维护者可能被永久地从项目团队中移除。 <del> 当个人代表项目或其社区时，本行为准则适用于项目空间和公共空间。 </del> <ins> ## 上报 </ins> <del> 如需举报侮辱、骚扰或其他不可接受的行为， 你可发送邮件至 <conduct@kubernetes.io> 联系 [Kubernetes行为守则委员会](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)。 其他事务请联系CNCF项目维护专员，或发送邮件至 <mishi@linux.com> 联系我们的调解员Mishi Choudhary。 </del> <ins> 对于 Kubernetes 社区中出现的事件，请发送邮件至 <conduct@kubernetes.io> 联系 [Kubernetes 行为准则委员会](https://git.k8s.io/community/committee-code-of-conduct)。 预计你可以在三个工作日内收到答复。 </ins> <del> 本行为准则改编自《贡献者契约》（ https://contributor-covenant.org ）1.2.0 版本， 可在 https://contributor-covenant.org/version/1/2/0/ 查看。 </del> <ins> 对于其他项目、或与项目无关或影响到多个 CNCF 项目的事件，请通过 conduct@cncf.io 联系 [CNCF 行为准则委员会](https://www.cncf.io/conduct/committee/)。 你也可以联系 [CNCF 行为准则委员会](https://www.cncf.io/conduct/committee/)的任何成员提交你的报告。 包括匿名提交报告在内有关如何提交报告的更多详细指示， 请参阅我们的[事件解决程序](https://www.cncf.io/conduct/procedures/)。 预计你可以在三个工作日内收到答复。 </ins> <del> ### CNCF 活动行为准则 </del> <ins> ## 执行 Kubernetes 项目的[行为准则委员会](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)负责解决 Kubernetes 项目有关的行为准则问题。 对于未设立行为准则委员会或没有行为准则事件应变人员的其他所有项目，以及与项目无关或影响到多个项目的事件， [CNCF 行为准则委员会](https://www.cncf.io/conduct/committee/)负责解决行为准则问题。 有关更多信息，请参阅我们的[管辖及逐级上报政策](https://www.cncf.io/conduct/jurisdiction/)。 这两个委员会将尝试以零惩罚平息事件，但可能自行决定将相关人员从项目或 CNCF 社区中移除。 ## 致谢 </ins> <del> 云原生计算基金会（CNCF）活动受 Linux 基金会《[行为准则](https://events.linuxfoundation.org/code-of-conduct/)》管辖， 该行为准则可在活动页面获得。其旨在与上述政策兼容，且包括更多关于事件回应的细节。 </del>  No newline at end of file <ins> 本行为准则改编自[贡献者契约（Contributor Covenant）](http://contributor-covenant.org) v2.0， 具体可查阅 http://contributor-covenant.org/version/2/0/code_of_conduct/ </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: /static/cncf-code-of- needs to be synced Proposed Solution: sync with en version Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh /assign
May need to wait for this PR to merge:
sure
This is merged now. You can move it forward.


Question: {{< codenew file="service/pod-with-graceful-termination.yaml" >}} <del> ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: terminationGracePeriodSeconds: 120 # extra long grace period containers: - name: nginx image: nginx:latest ports: - containerPort: 80 lifecycle: preStop: exec: # Real life termination may take any time up to terminationGracePeriodSeconds. # In this example - just hang around for at least the duration of terminationGracePeriodSeconds, # at 120 seconds container will be forcibly terminated. # Note, all this time nginx will keep processing requests. command: [ "/bin/sh", "-c", "sleep 180" ] </del> <ins> {{< codenew file="service/explore-graceful-termination-nginx.yaml" >}} </ins> <del> --- </del> <ins> Now create the Deployment Pod and Service using the above files: </ins> <del> apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 </del> <ins> ```shell kubectl apply -f pod-with-graceful-termination.yaml kubectl apply -f explore-graceful-termination-nginx.yaml </ins> ``` Once the Pod and Service are running, you can get the name of any associated EndpointSlices:

The example Deployment resource is duplicated in (code import shortcode and in-line code)
/language en
/kind bug We should keep the shortcode and drop the inline manifest.
/triage accepted /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 : /triage accepted /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
we should contain the Service resource following to the Deployment in the as well, right? (or should we create a new file for Service?)
Hey I would like to work on this issue. Do assign me this issue so I can start working on this.
/assign
BTW our convention in SIG Docs is very much that anyone is welcome to start work on an issue, and the best way to indicate that you're starting work is to open a PR (either a draft or the final thing). If anyone else wanted to work on this, please do try to liaise with first.
Thanks for your piece of advice, I will definitely keep this in mind for the next time.
The page to fix is Ah yes. The Service: should go in a new example manifest file and we'll need a second shortcode to cover that. Ideally we also explain how to use to deploy those. For example, for the Deployment, it's
Hey I have linked a PR against this issue, please do review it.
PR is submitted by another first time contributor to address the same problem before this issue was created. I will let other members decide on the best remediation of this situation.

ah sorry, that was my bad, I only searched issues before filing this issue... :bow:
I created PR after I searched both issues and PRs and there was nothing at that time... since this could be my first PR to the repo.
To make PR more likely to be my first contribution to the repo, I have in the beginning, and in addition, a missing step in the middle to get the info of the pods. To promote a bit: PR was created before this issue was created. is and uses the common YAML reference to A single YAML is used so that it can be deleted with a single . A missing step to get the info of the pods is .
Hey i have recently started my journey in open source and want to learn more looking for correct mentorship and guidance. If this issue is not resolved completely in that case can i also work on this??
Hi this issue is already resolved, I've also linked a PR to this issue. You can look for another good-first-issue to get started with.
Hey, anyone working on this, can you assign it to me. /assign
this issue is already resolved. As you can see I've also linked a PR to this issue. You can search for another good-first-issue to get started with.
This issue isn't yet resolved, but at least one reviewable PR is already open with a potential fix.
/assign
/assign
is issuse still open if yes then please assign me with issuse???


Question: * If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/). * View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers). * Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project. <del> * View [svc-cat.io](https://svc-cat.io/docs/). </del>

This is a Bug Report Problem: In the documentation page , in the last section What's next, the link to appears to be dead. Proposed Solution: Remove (or Update) the link. Page to Update:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language en /kind bug /sig service-catalog
/assign


Question: ## {{% heading "prerequisites" %}} <del> {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} </del> <ins> You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this task on a cluster with at least two nodes that are not acting as control plane nodes . If you do not already have a cluster, you can create one by using [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/). </ins> <!-- steps -->

This is a... [x] Feature Request [ ] Bug Report Study this topic and related topics: . Bring all of the etcd content into a coherent set of topics. Check for accuracy, and update as needed. Put topics into the appropriate templates. Edit topics to comply with our style guide.
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
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
/remove-lifecycle rotten /lifecycle frozen /reopen
/language en
/priority backlog Is that OK?
Actually where exactly are the deviations from the style guide?
/triage accepted I don't see any obvious style concerns.
is wrong: you can't practice operating an etcd cluster for Kubernetes within a Katacoda playground, at least not unless you get very technical.
This issue has not been updated in over 1 year, and should be re-triaged. You can: Confirm that this issue is still relevant with (org members only) Close this issue with For more details on the triage process, see /remove-triage accepted
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: Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is allowed, which is the default if not specified. For local container restarts, ReplicationControllers delegate to an agent on the node, <del> for example the [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) or Docker. </del> <ins> for example the [Kubelet](/docs/reference/command-line-tools-reference/kubelet/). </ins> ### Labels on the ReplicationController

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: <!-- {{< table caption="Local machine solutions table that lists the tools supported by the community and the ecosystem to deploy Kubernetes." >}} |Community           |Ecosystem     | <del> |社区           |生态系统     | </del> <ins> | ------------       | --------     | | [Minikube](/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| | [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)| |                     | [MicroK8s](https://microk8s.io/)| </ins> --> {{< table caption="本地机器解决方案表，其中列出了社区和生态系统支持的用于部署 Kubernetes 的工具。" >}} |社区           |生态系统     | | ------------       | --------     | <del> | [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | | [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| |                     | [Minishift](https://docs.okd.io/latest/minishift/)| </del> <ins> | [Minikube](/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| | [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)| </ins> |                     | [MicroK8s](https://microk8s.io/)| <del> |                     | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | |                     | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)| |                     | [k3s](https://k3s.io)| |                     | [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/)| </del> <!--

This is a Feature Request Chinese "Gettting started" page not updated. <!-- 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. -- page is not corresponed to English original page especially the "Learning environment" part and "Production environment" part ! ! Why is this needed Update Chinese "Gettting started" page Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --Page in English: Page in Chinese:
/language zh
/assign


Question: Here's an example of a Job with two containers, one of which is a sidecar: {{% code_sample language="yaml" file="application/job/job-sidecar.yaml" %}} <del> By default, this feature is not available in Kubernetes. To avail this feature, you need to enable the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) named `SidecarContainers`. </del> ## Differences from regular containers

This is a Bug Report Problem: text is no longer needed as sidecar containers are now entered into beta state and they are enable by default. reference link of sidecar containers present in page is wrongly redirecting to page. Proposed Solution: the text below from sidecar containers documentation. reference link present in page from page to page. Page to Update:
/sig docs /language en
/assign
Beta APIs are off by default with
is not a beta API though /triage accepted


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 file might be outdated. en: Under "Networking and Network Policy" section, the entry "Contiv" exists. ja: The entry "Contiv" does not exist. Proposed Solution: Update . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ja
/triage accepted
/assign
I'd like to create a PR for this issue. Please comment if you are working on this issue.
sorry, I have not started to work this issue. please do that.
Thanks for your reply. I'll do it. /assign


Question: letter-spacing: 0.03em; } <ins> .youtube-quote-sm { display: inline-block; width: 380px; height: 215px; } .youtube-quote-sm iframe { width: 100%; height: 100%; border: 0; } </ins> @media screen and (max-width: 910px) { h1 { font-size: 32px;

This is a clean up request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update the to use the  shortcode that is built in to Hugo. Why is this needed Using HTML and s directly is not as easy to maintain as Hugo shortcodes, which are explicitly designed to afford code reuse. Comments /kind cleanup /help /language en If you make this change, and check that the videos still render. Related 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 clean up request <!-- See for guidance on writing an actionable issue description. --Update the to use the  shortcode that is built in to Hugo. Using HTML and s directly is not as easy to maintain as Hugo shortcodes, which are explicitly designed to afford code reuse. /kind cleanup /help /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
/assign
Thanks


Question: done ``` <del> Then verify the blob by using `cosign`: </del> <ins> Then verify the blob by using `cosign verify-blob`: </ins> ```shell <del> cosign verify-blob "$BINARY" --signature "$BINARY".sig --certificate "$BINARY".cert </del> <ins> cosign verify-blob "$BINARY"  --signature "$BINARY".sig  --certificate "$BINARY".cert  --certificate-identity krel-staging@k8s-releng-prod.iam.gserviceaccount.com  --certificate-oidc-issuer https://accounts.google.com </ins> ``` <del> cosign v1.9.0 is required to be able to use the `--certificate` flag. Please use `--cert` for older versions of cosign. </del> {{< note >}} <del> To learn more about keyless signing, please refer to [Keyless Signatures](https://github.com/sigstore/cosign/blob/main/KEYLESS.md#keyless-signatures). </del> <ins> Cosign 2.0 requires the `--certificate-identity` and `--certificate-oidc-issuer` options. To learn more about keyless signing, please refer to [Keyless Signatures](https://docs.sigstore.dev/cosign/keyless). Previous versions of Cosign required that you set `COSIGN_EXPERIMENTAL=1`. For additional information, plase refer to the [sigstore Blog](https://blog.sigstore.dev/cosign-2-0-released/) </ins> {{< /note >}} ## Verifying image signatures

This is a Feature Request After release, we don't need . We should update the instructions on the task to include verification using cosign 2.0 <!-- 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 <details<summaryverification using cosign 2.0</summaryAdd a note if cosign version < 2.0 </details<!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Why is this needed There are some breaking changes in cosign 2.0 and we should update the instruction for the verification of images. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/sig release /sig security /retitle Update page Verify Signed Kubernetes Artifacts for cosign 2.0 /kind bug /remove-kind feature /language en /triage accepted Thanks
:+1:
I can work on this /assign
Hey Are you still working on this issue? If not, can I work on this?
Haven't gotten to it as I expected to. Please feel free to work on it /unassign
/assign
FYI
Apologies for not being able to review the PR. I am going through University exams which is ending tomorrow. I just rushed through the changes that you made and you really did awesome work on this. I'll look more into this after the exams. Thanks for working on this.


Question: <ins> --- title: "Migrating from dockershim" weight: 10 content_type: task --- <!-- overview --> This section presents information you need to know when migrating from dockershim to other container runtimes. Since the announcement of [dockershim deprecation](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) in Kubernetes 1.20, there were questions on how this will affect various workloads and Kubernetes installations. You can find this blog post useful to understand the problem better: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) It is recommended to migrate from dockershim to alternative container runtimes. Check out [container runtimes](/docs/setup/production-environment/container-runtimes/) section to know your options. Make sure to [report issues](https://github.com/kubernetes/kubernetes/issues) you encountered with the migration. So the issue can be fixed in a timely manner and your cluster would be ready for dockershim removal. </ins>

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


Question:
format [Required]
 string
numaNode [Required]
 int32  	   Format Flag specifies the structure of log messages. default value of format is `text`	   No description provided.

sanitization [Required]
 bool
limits [Required]
 core/v1.ResourceList  	   [Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens). Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production.`)</td> </del> <ins> <span class="text-muted">No description provided.</span> </td> </ins> </tr> </tbody> </table> <ins> ## `ResourceChangeDetectionStrategy`     {#kubelet-config-k8s-io-v1beta1-ResourceChangeDetectionStrategy} (Alias of `string`) **Appears in:** - [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) ResourceChangeDetectionStrategy denotes a mode in which internal managers (secret, configmap) are discovering object changes.

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: Visiting provides inaccurate default values for shutdownGracePeriod (30s rather than 0s) and shutdownGracePeriodCriticalPods (10s rather than 0s). Proposed Solution: Correct the documentation to match the actual default values. Page to Update:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I would like to take up this ticket.