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

The second element specifies that the value of the Pod's `annotations` field should be stored in a file named `annotations`. --> <del> 在配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器中的 `/etc` 目录。 </del> <ins> 在配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器中的 `/etc/podinfo` 目录。 </ins> 查看 `downwardAPI` 下面的 `items` 数组。 每个数组元素都是一个


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

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


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

同样，查看`annotations`文件： ```shell <del> /# cat /etc/annotations </del> <ins> /# cat /etc/podinfo/annotations </ins> ``` <!--


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

lrwxrwxrwx  ... Feb 6 21:47 annotations -> ..data/annotations lrwxrwxrwx  ... Feb 6 21:47 labels -> ..data/labels <del> /etc/..2982_06_02_21_47_53.299460680: </del> <ins> /etc/podinfo/..2982_06_02_21_47_53.299460680: </ins> total 8 -rw-r--r--  ... Feb  6 21:47 annotations -rw-r--r--  ... Feb  6 21:47 labels


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

Create the Pod: --> <del> 在这个配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器的 `/etc/podinfo` 目录。 </del> <ins> 在这个配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器的 `/etc/podinfo` 目录。 </ins> 查看 `downwardAPI` 下面的 `items` 数组。每个数组元素都是一个 DownwardAPIVolumeFile。


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

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


Question:
The Chinese version of the chapter introducing the concept of misses the explanation of the info field compared to the English version. Please check it.
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
this is fixed here

You can modify Node objects regardless of the setting of `--register-node`. For example, you can set labels on an existing Node, or mark it unschedulable. --> <del> #### 手动节点管理 </del> <ins> ### 手动节点管理 </ins> 你可以使用 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 来创建和修改 Node 对象。


Question:
The Chinese version of the chapter introducing the concept of misses the explanation of the info field compared to the English version. Please check it.
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
this is fixed here

| `MemoryPressure`    | `True` if pressure exists on the node memory - that is, if the node memory is low; otherwise `False` | | `PIDPressure`    | `True` if pressure exists on the processes - that is, if there are too many processes on the node; otherwise `False` | | `NetworkUnavailable`    | `True` if the network for the node is not correctly configured, otherwise `False` | <ins> {{< /table >}} </ins> --> {{< table caption = "节点状况及每种状况适用场景的描述" >}} | 节点状况       | 描述        |


Question:
The Chinese version of the chapter introducing the concept of misses the explanation of the info field compared to the English version. Please check it.
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
this is fixed here

| `MemoryPressure` | `True` 表示节点存在内存压力，即节点内存可用量低，否则为 `False` | | `PIDPressure` | `True` 表示节点存在进程压力，即节点上进程过多；否则为 `False` | | `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` | <ins> {{< /table >}} </ins> <!-- If you use command-line tools to print details of a cordoned Node, the Condition includes


Question:
The Chinese version of the chapter introducing the concept of misses the explanation of the info field compared to the English version. Please check it.
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
this is fixed here

Kubernetes 节点发送的心跳（Heartbeats）有助于确定节点的可用性。 心跳有两种形式：`NodeStatus` 和 [`Lease` 对象] <del> (/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io)。 </del> <ins> (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)。 </ins> 每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="名字空间">}} 中都有一个与之关联的 `Lease` 对象。 `Lease` 是一种轻量级的资源，可在集群规模扩大时提高节点心跳机制的性能。


Question:
The Chinese version of the chapter introducing the concept of misses the explanation of the info field compared to the English version. Please check it.
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
this is fixed here

参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/) 了解详细信息。 <ins> <!-- ## Graceful Node Shutdown {#graceful-node-shutdown} --> ## 节点体面关闭 {#graceful-node-shutdown} {{< feature-state state="alpha" for_k8s_version="v1.20" >}} <!-- If you have enabled the `GracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then the kubelet attempts to detect the node system shutdown and terminates pods running on the node. Kubelet ensures that pods follow the normal [pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) during the node shutdown. --> 如果你启用了 `GracefulNodeShutdown` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， 那么 kubelet 尝试检测节点的系统关闭事件并终止在节点上运行的 Pod。 在节点终止期间，kubelet 保证 Pod 遵从常规的 [Pod 终止流程](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。 <!-- When the `GracefulNodeShutdown` feature gate is enabled, kubelet uses [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration. During a shutdown kubelet terminates pods in two phases: --> 当启用了 `GracefulNodeShutdown` 特性门控时， kubelet 使用 [systemd 抑制器锁](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) 在给定的期限内延迟节点关闭。在关闭过程中，kubelet 分两个阶段终止 Pod： <!-- 1. Terminate regular pods running on the node. 2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node. --> 1. 终止在节点上运行的常规 Pod。 2. 终止在节点上运行的[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 <!-- Graceful Node Shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options: * `ShutdownGracePeriod`: * Specifies the total duration that the node should delay the shutdown by. This is the total grace period for pod termination for both regular and [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). * `ShutdownGracePeriodCriticalPods`: * Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This should be less than `ShutdownGracePeriod`. --> 节点体面关闭的特性对应两个 [`KubeletConfiguration`](/zh/docs/tasks/administer-cluster/kubelet-config-file/) 选项： * `ShutdownGracePeriod`： * 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod 还是 [关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 * `ShutdownGracePeriodCriticalPods`： * 在节点关闭期间指定用于终止 [关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) 的持续时间。该值应小于 `ShutdownGracePeriod`。 <!-- For example, if `ShutdownGracePeriod=30s`, and `ShutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by 30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved for gracefully terminating normal pods, and the last 10 seconds would be reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). --> 例如，如果设置了 `ShutdownGracePeriod=30s` 和 `ShutdownGracePeriodCriticalPods=10s`，则 kubelet 将延迟 30 秒关闭节点。 在关闭期间，将保留前 20（30 - 10）秒用于体面终止常规 Pod，而保留最后 10 秒用于终止 [关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 </ins> ## {{% heading "whatsnext" %}} <!--


Question:
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

<del> ### Exposed Persistent volumes {#Exposed Persistent volumes} </del> <ins> ### Exposed Persistent volumes {#Exposed-Persistent-volumes} </ins> - **persistentVolumeClaim** (PersistentVolumeClaimVolumeSource)


Question:
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

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)


Question:
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

Type for HostPath Volume Defaults to "" More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath <del> ### Persistent volumes {#Persistent volumes} </del> <ins> ### Persistent volumes {#Persistent-volumes} </ins> - **awsElasticBlockStore** (AWSElasticBlockStoreVolumeSource)


Question:
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

Storage Policy Based Management (SPBM) profile name. <del> ### Beta level {#Beta level} </del> <ins> ### Beta level {#Beta-level} </ins> - **csi** (CSIVolumeSource)


Question:
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

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)


Question:
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

Container's working directory. If not specified, the container runtime's default will be used, which might be configured in the container image. Cannot be updated. <del> ### Environment variables {#Environment variables} </del> <ins> ### Environment variables {#Environment-variables} </ins> - **env** ([]EnvVar)


Question:
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

Whether this container should allocate a TTY for itself, also requires 'stdin' to be true. Default is false. <del> ### Not allowed {#Not allowed} </del> <ins> ### Not allowed {#Not-allowed} </ins> - **ports** ([]ContainerPort)


Question:
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

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


Question:
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

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).


Question:
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

different when read back. * Setting originally unset fields is less likely to cause problems than overwriting fields set in the original request. Avoid doing the latter. <del> * This is a beta feature. Future versions of Kubernetes may restrict the types of mutations these webhooks can make. </del> * Future changes to control loops for built-in resources or third-party resources may break webhooks that work well today. Even when the webhook installation API is finalized, not all possible webhook behaviors will be guaranteed to be supported


Question:
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

### ValidatingAdmissionWebhook {#validatingadmissionwebhook} <del> {{< feature-state for_k8s_version="v1.13" state="beta" >}} </del> This admission controller calls any validating webhooks which match the request. Matching webhooks are called in parallel; if any of them rejects the request, the request fails. This admission controller only runs in the validation phase; the webhooks it calls may not


Question:
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

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


Question:
In the table of of there are two descriptions missing of two tolerations kyes, one is another one is , their descriptions are missing.
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

| ---------------------------------------- | ---------- | ------- | ----------- | | `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. | | `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. | <del> | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | | | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | | </del> <ins> | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | DaemonSet pods tolerate disk-pressure attributes by default scheduler. | | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | DaemonSet pods tolerate memory-pressure attributes by default scheduler. | </ins> | `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSet pods tolerate unschedulable attributes by default scheduler. | | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |


Question:
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 the pages: the part before is sometimes a plural and sometimes not. We should make this consistent. Why is this needed When we use language inconsistently, that language becomes harder for (some) localization teams to translate well. Additionally, readers might see the different pluralization and wonder (perhaps even believe) that it is significant, given the authority attached to the website where it appears. Comments /language en /kind cleanup
/triage accepted
you might want to know about this issue - I am sure you would have some tips for a person picking it up
This change needs to happen in the generator, ? The idea is to make the resource type or category singular?
That's the approach I'd take.

Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`: <ins> {% include code.html language="yaml" file="bad-nginx-deployment.yaml" ghlink="/docs/user-guide/bad-nginx-deployment.yaml" %} </ins> ```shell $ kubectl apply -f docs/user-guide/bad-nginx-deployment.yaml deployment "nginx-deployment" configured


Question:
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: "FrameworkHandle" link is broken. Proposed Solution: The link should be ( ) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en /triage accepted
/assign

{{< note >}} While any plugin can access the list of "waiting" Pods and approve them <del> (see [`FrameworkHandle`](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md#frameworkhandle)), we expect only the permit </del> <ins> (see [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)), we expect only the permit </ins> plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod is approved, it is sent to the [PreBind](#pre-bind) phase. {{< /note >}}


Question:
Link broken or pointing to a wrong link. Under section: Programmatic access to the API. The link provided in the below line seems to be broken to wrong.
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 think this report is about the page can you paste in the text (or HTML source) of the broken hyperlink /triage needs-information

} ``` <del> If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](#accessing-the-api-from-within-a-pod). </del> <ins> If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod). </ins> #### Python client


Question:
По ссылке получаю страницу "404"
/language ru /kind bug
Страница на текущий момент не вся актуальна. Используйте английскую версию.
/triage accepted

* Пробуете или начинаете работу с Kubernetes * Локально разрабатываете и тестируете кластер <del> Выбрать [решение для запуска на локальной машине](/docs/setup/pick-right-solution/#local-machine-solutions). </del> <ins> Выбрать [решение для запуска на локальной машине](/docs/setup/learning-environment/). </ins> ## Управляемые решения


Question:
Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented. May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /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

all: build ## Build site with production settings and put deliverables in ./public <del> build: module-check ## Build site with production settings and put deliverables in ./public hugo --minify </del> <ins> build: module-check ## Build site with non-production settings and put deliverables in ./public hugo --minify --environment development </ins> build-preview: module-check ## Build site with drafts and future posts enabled <del> hugo --buildDrafts --buildFuture </del> <ins> hugo --buildDrafts --buildFuture --environment preview </ins> deploy-preview: ## Deploy preview site via netlify <del> hugo --enableGitInfo --buildFuture -b $(DEPLOY_PRIME_URL) </del> <ins> hugo --enableGitInfo --buildFuture --environment preview -b $(DEPLOY_PRIME_URL) </ins> functions-build: $(NETLIFY_FUNC) build functions-src


Question:
Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented. May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /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

check-headers-file: scripts/check-headers-file.sh <del> production-build: build check-headers-file ## Build the production site and ensure that noindex headers aren't added </del> <ins> production-build: module-check ## Build the production site and ensure that noindex headers aren't added hugo --minify --environment production HUGO_ENV=production $(MAKE) check-headers-file </ins> <del> non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing hugo --enableGitInfo </del> <ins> non-production-build: module-check ## Build the non-production site, which adds noindex headers to prevent indexing hugo --enableGitInfo --environment nonprod </ins> serve: module-check ## Boot the development server. <del> hugo server --buildFuture </del> <ins> hugo server --buildFuture --environment development </ins> docker-image: @echo -e "$(CCRED)**** The use of docker-image is deprecated. Use container-image instead. ****$(CCEND)"


Question:
Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented. May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /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

--build-arg HUGO_VERSION=$(HUGO_VERSION) container-build: module-check <del> $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify" </del> <ins> $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify --environment development" </ins> container-serve: module-check ## Boot the development server using container. Run `make container-image` before this. <del> $(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir </del> <ins> $(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir </ins> test-examples: scripts/test_examples.sh install


Question:
Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented. May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /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

$(MAKE) container-internal-linkcheck container-internal-linkcheck: link-checker-image-pull <del> $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture </del> <ins> $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture --environment test </ins> $(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest clean-api-reference: ## Clean all directories in API reference directory, preserve _index.md


Question:
Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented. May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /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

<!doctype html> <html lang="{{ .Site.Language.Lang }}" class="{{.Params.class}} no-js"> <del> <head> </del> <ins> {{- if eq hugo.Environment "preview" -}} <!-- deploy preview --> {{- end -}} <head {{- if hugo.IsProduction -}}class="live-site"{{- end -}}> </ins> {{ partial "head.html" . }} </head> <body class="td-{{ .Kind }}{{- if ne (lower .Params.cid) "" -}}{{- printf " cid-%s" (lower .Params.cid) -}}{{- end -}}">


Question:
Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented. May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /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

<del> {{- if eq (getenv "HUGO_ENV") "production" }} </del> <ins> {{- if eq hugo.Environment "production" }} </ins> {{- $cssFilesFromConfig := site.Params.pushAssets.css -}} {{- $jsFilesFromConfig := site.Params.pushAssets.js -}} {{- $pages := site.RegularPages -}}


Question:
Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented. May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /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

{{- $isBlogPost := eq .Section "blog" }} {{- $ogType := cond (.IsHome) "website" "article" }} <ins> <!-- per-page robot indexing controls --> {{- if hugo.IsProduction -}} <meta name="ROBOTS" content="INDEX, FOLLOW"> {{- else -}} <meta name="ROBOTS" content="NOINDEX, NOFOLLOW"> {{- end -}} </ins> <!-- Global site tag (gtag.js) - Google Analytics --> <script async src="https://www.googletagmanager.com/gtag/js?id=UA-36037335-10"></script> <script>


Question:
Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented. May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /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

<meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> {{ hugo.Generator }} <del> {{ if eq (getenv "HUGO_ENV") "production" }} <META NAME="ROBOTS" CONTENT="INDEX, FOLLOW"> {{ else }} <META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW"> {{ end }} </del> {{ range .AlternativeOutputFormats -}} <link rel="{{ .Rel }}" type="{{ .MediaType.Type }}" href="{{ .Permalink | safeURL }}"> {{ end -}}


Question:
Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented. May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /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

{{- template "_internal/google_news.html" . -}} {{- template "_internal/schema.html" . -}} {{- template "_internal/twitter_cards.html" . -}} <del> {{ if eq (getenv "HUGO_ENV") "production" }} </del> <ins> {{- if hugo.IsProduction -}} </ins> {{ template "_internal/google_analytics_async.html" . }} {{ end }} {{ partialCached "head-css.html" . "asdf" }}


Question:
Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented. May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /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

command = "git submodule update --init --recursive --depth 1 && make deploy-preview" [context.branch-deploy] <del> command = "git submodule update --init --recursive --depth 1 && make deploy-preview" </del> <ins> command = "git submodule update --init --recursive --depth 1 && make non-production-build" </ins> <del> [context.master] # This context is triggered by the `master` branch and allows search indexing </del> <ins> [context.main] # This context is triggered by the `main` branch and allows search indexing </ins> # DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads) publish = "public" command = "git submodule update --init --recursive --depth 1 && make production-build" <del> # adding in headers to prevent clickjacking [[headers]] for = "/*" [headers.values] X-Frame-Options = "DENY" X-XSS-Protection = "1; mode=block" </del>


Question:
includes the deadlink:
/kind bug /triage accepted /language en
/sig cluster-lifecycle node i've LGTM on the pending PR.
/retitle container-runtime: migration guide points to a 404
this PR did not fix the problem: because it lacks a leading i will send a new one.
new fix is here:

### Migrating to the `systemd` driver in kubeadm managed clusters <del> Follow this [Migration guide](docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver) </del> <ins> Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver) </ins> if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters. ## Container runtimes


Question:
This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

<ins> --- title: "Kubernetesオブジェクトの管理" description: Kubernetes APIと対話するための宣言型および命令型のパラダイム。 weight: 25 --- </ins>


Question:
This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

<ins> --- title: CronJobを使用して自動化タスクを実行する min-kubernetes-server-version: v1.21 content_type: task weight: 10 --- <!-- overview --> CronJobは、Kubernetes v1.21で一般利用(GA)に昇格しました。古いバージョンのKubernetesを使用している場合、正確な情報を参照できるように、使用しているバージョンのKubernetesのドキュメントを参照してください。古いKubernetesのバージョンでは、`batch/v1` CronJob APIはサポートされていません。 {{< glossary_tooltip text="CronJob" term_id="cronjob" >}}を使用すると、{{< glossary_tooltip text="Job" term_id="job" >}}を時間ベースのスケジュールで実行できるようになります。この自動化されたJobは、LinuxまたはUNIXシステム上の[Cron](https://ja.wikipedia.org/wiki/Cron)のように実行されます。 CronJobは、バックアップやメールの送信など、定期的なタスクや繰り返しのタスクを作成する時に便利です。CronJobはそれぞれのタスクを、たとえばアクティビティが少ない期間など、特定の時間にスケジューリングすることもできます。 CronJobには制限と特性があります。たとえば、特定の状況下では、1つのCronJobが複数のJobを作成する可能性があるため、Jobは冪等性を持つようにしなければいけません。 制限に関する詳しい情報については、[CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。 ## {{% heading "prerequisites" %}} * {{< include "task-tutorial-prereqs.md" >}} <!-- steps --> ## CronJobを作成する CronJobには設定ファイルが必要です。次の例のCronJobの`.spec`は、現在の時刻とhelloというメッセージを1分ごとに表示します。 {{< codenew file="application/job/cronjob.yaml" >}} 次のコマンドで例のCronJobを実行します。 ```shell kubectl create -f https://k8s.io/examples/application/job/cronjob.yaml ``` 出力は次のようになります。 ``` cronjob.batch/hello created ``` CronJobを作成したら、次のコマンドで状態を取得します。 ```shell kubectl get cronjob hello ``` 出力は次のようになります。 ``` NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE hello   */1 * * * *   False     0        <none>          10s ``` コマンドの結果からわかるように、CronJobはまだスケジュールされておらず、まだ何のJobも実行していません。約1分以内にJobが作成されるのを見てみましょう。 ```shell kubectl get jobs --watch ``` 出力は次のようになります。 ``` NAME               COMPLETIONS   DURATION   AGE hello-4111706356   0/1                      0s hello-4111706356   0/1           0s         0s hello-4111706356   1/1           5s         5s ``` "hello"CronJobによってスケジュールされたJobが1つ実行中になっていることがわかります。Jobを見るのをやめて、再度CronJobを表示して、Jobがスケジュールされたことを確認してみます。 ```shell kubectl get cronjob hello ``` 出力は次のようになります。 ``` NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE hello   */1 * * * *   False     0        50s             75s ``` CronJob`hello`が、`LAST SCHEDULE`で指定された時間にJobを正しくスケジュールしたことが確認できるはずです。現在、activeなJobの数は0です。つまり、Jobは完了または失敗したことがわかります。 それでは、最後にスケジュールされたJobの作成と、Podの1つの標準出力を表示してみましょう。 {{< note >}} Jobの名前とPodの名前は異なります。 {{< /note >}} ```shell # "hello-4111706356" の部分は、あなたのシステム上のJobの名前に置き換えてください。 pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name}) ``` Podのログを表示します。 ```shell kubectl logs $pods ``` 出力は次のようになります。 ``` Fri Feb 22 11:02:09 UTC 2019 Hello from the Kubernetes cluster ``` ## CronJobの削除 CronJobが必要なくなったときは、`kubectl delete cronjob <cronjob name>`で削除します。 ```shell kubectl delete cronjob hello ``` CronJobを削除すると、すべてのJobと、そのJobが作成したPodが削除され、追加のJobの作成が停止されます。Jobの削除について詳しく知りたい場合は、[ガベージコレクション](/ja/docs/concepts/workloads/controllers/garbage-collection/)を読んでください。 ## CronJobのspecを書く {#writing-a-cron-job-spec} すべてのKubernetesの設定と同じように、CronJobにも`apiVersion`、`kind`、`metadata`のフィールドが必要です。設定ファイルの扱い方についての一般的な情報については、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)と[kubectlを使用してリソースを管理する](/ja/docs/concepts/overview/working-with-objects/object-management/)を読んでください。 CronJobの設定には、[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。 {{< note >}} CronJobの特に`spec`へのすべての修正は、それ以降の実行にのみ適用されます。 {{< /note >}} ### Schedule `.spec.schedule`は、`.spec`には必須のフィールドです。`0 * * * *`や`@hourly`などの[Cron](https://ja.wikipedia.org/wiki/Cron)形式の文字列を取り、Jobの作成と実行のスケジュール時間を指定します。 フォーマットにはVixie cronのステップ値(step value)も指定できます。[FreeBSDのマニュアル](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)では次のように説明されています。 > ステップ値は範囲指定と組み合わせて使用できます。範囲の後ろに`/<number>`を付けると、範囲全体で指定したnumberの値ごとにスキップすることを意味します。たとえば、`0-23/2`をhoursフィールドに指定すると、2時間毎にコマンド実行を指定することになります(V7標準では代わりに`0,2,4,6,8,10,12,14,16,18,20,22`と指定する必要があります)。ステップはアスタリスクの後ろにつけることもできます。そのため、「2時間毎に実行」したい場合は、単純に`*/2`と指定できます。 {{< note >}} スケジュール内の疑問符`?`はアスタリスク`*`と同じ意味を持ちます。つまり、与えられたフィールドには任意の値が使えるという意味になります。 {{< /note >}} ### Job Template `.spec.jobTemplate`はJobのテンプレートであり、必須です。[Job](/docs/concepts/workloads/controllers/job/)と完全に同一のスキーマを持ちますが、フィールドがネストされている点と、`apiVersion`と`kind`が存在しない点だけが異なります。Jobの`.spec`を書くための情報については、[JobのSpecを書く](/docs/concepts/workloads/controllers/job/#writing-a-job-spec)を参照してください。 ### Starting Deadline `.spec.startingDeadlineSeconds`フィールドはオプションです。何かの理由でスケジュールに間に合わなかった場合に適用される、Jobの開始のデッドライン(締め切り)を秒数で指定します。デッドラインを過ぎると、CronJobはJobを開始しません。この場合にデッドラインに間に合わなかったJobは、失敗したJobとしてカウントされます。もしこのフィールドが指定されなかった場合、Jobはデッドラインを持ちません。 `.spec.startingDeadlineSeconds`フィールドがnull以外に設定された場合、CronJobコントローラーはJobの作成が期待される時間と現在時刻との間の時間を計測します。もしその差が制限よりも大きかった場合、その実行はスキップされます。 たとえば、この値が`200`に設定された場合、実際のスケジュールの最大200秒後までに作成されるJobだけが許可されます。 ### Concurrency Policy `.spec.concurrencyPolicy`フィールドもオプションです。このフィールドは、このCronJobで作成されたJobの並列実行をどのように扱うかを指定します。specには以下のconcurrency policyのいずれかを指定します。 * `Allow` (デフォルト): CronJobがJobを並列に実行することを許可します。 * `Forbid`: CronJobの並列実行を禁止します。もし新しいJobの実行時に過去のJobがまだ完了していなかった場合、CronJobは新しいJobの実行をスキップします。 * `Replace`: もし新しいJobの実行の時間になっても過去のJobの実行が完了していなかった場合、CronJobは現在の実行中のJobを新しいJobで置換します。 concurrency policyは、同じCronJobが作成したJobにのみ適用されます。もし複数のCronJobがある場合、それぞれのJobの並列実行は常に許可されます。 ### Suspend `.spec.suspend`フィールドもオプションです。このフィールドを`true`に設定すると、すべての後続の実行がサスペンド(一時停止)されます。この設定はすでに実行開始したJobには適用されません。デフォルトはfalseです。 {{< caution >}} スケジュールされた時間中にサスペンドされた実行は、見逃されたJob(missed job)としてカウントされます。[starting deadline](#starting-deadline)が設定されていない既存のCronJob`.spec.suspend`が`true`から`false`に変更されると、見逃されたJobは即座にスケジュールされます。 {{< /caution >}} ### Job History Limit `.spec.successfulJobsHistoryLimit`と`.spec.failedJobsHistoryLimit`フィールドはオプションです。これらのフィールドには、完了したJobと失敗したJobをいくつ保持するかを指定します。デフォルトでは、それぞれ3と1に設定されます。リミットを`0`に設定すると、対応する種類のJobを実行完了後に何も保持しなくなります。 </ins>


Question:
This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/triage accepted

<ins> --- title: approverとreviewer向けのレビュー linktitle: approverとreviewer向け slug: for-approvers content_type: concept weight: 20 --- <!-- overview --> SIG Docsの[Reviewer(レビュアー)](/docs/contribute/participate/#reviewers)と[Approver(承認者)](/docs/contribute/participate/#approvers)は、変更をレビューする時にいくつか追加の作業を行います。 毎週、docsのメンバーの特定のapproverのボランティアは、pull requestのトリアージとレビューを担当します。この担当者は、その週の「PR Wrangler(PRの世話人)」と呼ばれます。詳しい情報は、[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)を参照してください。PR Wranglerになるには、週次のSIG Docsミーティングに参加し、ボランティアをします。もしその週にスケジュールされていなくても、活発なレビューが行われていないpull request(PR)をレビューすることは問題ありません。 このローテーションに加えて、変更されたファイルのオーナーに基づいて、botがPRにreviewerとapproverを割り当てます。 <!-- body --> ## PRをレビューする Kubernetesのドキュメントは[Kubernetesコードレビュープロセス](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)に従います。 [pull requestのレビュー](/ja/docs/contribute/review/reviewing-prs/)に書かれているすべてのことが適用されますが、ReviewerとApproverはそれに加えて次のことも行います。 - 必要に応じて、`/assign`Prowコマンドを使用して、特定のreviewerにPRを割り当てる。これは、コードのコントリビューターからの技術的なレビューが必要な場合には特に重要です。 {{< note >}} 技術的なレビューを行える人物を知るには、Markdownファイル上部にあるfront-matterの`reviewers`フィールドを確認してください。 {{< /note >}} - PRが[コンテンツ](/ja/docs/contribute/style/content-guide/)および[スタイル](/docs/contribute/style/style-guide/)のガイドに従っていることを確認してください。ガイドに従っていない場合は、ガイドの関連する部分にリンクを作者に示してください。 - PRの作者に変更を提案できるときは、GitHubの**Request Changes**(変更をリクエスト)オプションを利用してください。 - 提案したことが反映されたら、`/approve`や`/lgtm`コマンドを使用して、GitHubのレビューステータスを変更してください。 ## 他の作者のPRにコミットを追加する PRにコメントを残すのは助けになりますが、まれに他の作者のPRに代わりにコミットを追加する必要がある場合があります。 あなたが明示的に作者から頼まれたり、長い間放置されたPRを蘇らせるような場合でない限り、他の作者のPRを「乗っ取る」ようなことはしないでください。短期的に見ればそのほうが短時間で終わるかもしれませんが、そのようなことをするとその人が貢献するチャンスを奪ってしまうことになります。 あなたが取る方法は、編集する必要のあるファイルがすでにPRのスコープに入っているか、あるいはPRがまだ触れていないファイルであるかによって変わります。 以下のいずれかが当てはまる場合、他の作者のPRにあなたがコミットを追加することはできません。 - PRの作者が自分のブランチを直接[https://github.com/kubernetes/website/](https://github.com/kubernetes/website/)リポジトリにpushした場合。この場合、pushアクセス権限を持つreviewerしか他のユーザーのPRにコミットを追加することはできません。 {{< note >}} 次回PRを作成するとき、自分のブランチを自分のforkに対してpushするように作者に促してください。 {{< /note >}} - PRの作者が明示的にapproverからの編集を禁止している場合。 ## レビュー向けのProwコマンド [Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md)は、pull request(PR)に対してジョブを実行するKubernetesベースのCI/CDシステムです。Prowは、Kubernetes organization全体でchatbotスタイルのコマンドを利用してGitHub actionsを扱えるようにします。たとえば、[ラベルの追加と削除](#adding-and-removing-issue-labels)、issueのclose、approverの割り当てなどが行なえます。Prowコマンドは、GitHubのコメントに`/<command-name>`という形式で入力します。 reviewerとapproverが最もよく使うprowコマンドには、以下のようなものがあります。 {{< table caption="Prow commands for reviewing" >}} Prowコマンド | Roleの制限 | 説明 :------------|:------------------|:----------- `/lgtm` | 誰でも。ただし、オートメーションがトリガされるのはReviewerまたはApproverが使用したときのみ。 | PRのレビューが完了し、変更に納得したことを知らせる。 `/approve` | Approver | PRをマージすることを承認する。 `/assign` | ReviewerまたはApprover | PRのレビューまたは承認するひとを割り当てる。 `/close` | ReviewerまたはApprover | issueまたはPRをクローンする。 `/hold` | 誰でも | `do-not-merge/hold`ラベルを追加して、自動的にマージできないPRであることを示す。 `/hold cancel` | 誰でも | `do-not-merge/hold`ラベルを削除する。 {{< /table >}} PRで利用できるすべてのコマンド一覧を確認するには、[Prowコマンドリファレンス](https://prow.k8s.io/command-help)を参照してください。 ## issueのトリアージとカテゴリー分類 一般に、SIG Docsは[Kubernetes issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md)のプロセスに従い、同じラベルを使用しています。 このGitHub issueの[フィルター](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc)は、トリアージが必要な可能性があるissueを表示します。 ### issueをトリアージする 1. issueを検証する - issueがドキュメントのウェブサイトに関係するものであることを確かめる。質問に答えたりリソースの場所を報告者に教えることですぐに閉じられるissueもあります。詳しくは、[サポートリクエストまたはコードのバグレポート](#support-requests-or-code-bug-reports)のセクションを読んでください。 - issueにメリットがあるかどうか評価する。 - issueに行動を取るのに十分な詳細情報がない場合や、テンプレートが十分埋められていない場合は、`triage/needs-information`ラベルを追加する。 - `lifecycle/stale`と`triage/needs-information`の両方のラベルがあるときは、issueをcloseする。 2. 優先度(priority)ラベルを追加する([issueトリアージガイドライン](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)は、priorityラベルについて詳しく定義しています。) {{< table caption="issueのラベル" >}} ラベル | 説明 :------------|:------------------ `priority/critical-urgent` | 今すぐに作業する。 `priority/important-soon` | 3ヶ月以内に取り組む。 `priority/important-longterm` | 6ヶ月以内に取り組む。 `priority/backlog` | 無期限に延期可能。リソースに余裕がある時に取り組む。 `priority/awaiting-more-evidence` | よいissueの可能性があるissueを見失わないようにするためのプレースホルダー。 `help`または`good first issue` | KubernetesまたはSIG Docsでほとんど経験がない人に適したissue。より詳しい情報は、[Help WantedとGood First Issueラベル](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)を読んでください。 {{< /table >}} あなたの裁量で、issueのオーナーシップを取り、issueに対するPRを提出してください(簡単なissueや、自分がすでに行った作業に関連するissueである場合は特に)。 issueのトリアージについて質問があるときは、Slackの`#sig-docs`か[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)で質問してください。 ## issueラベルの追加と削除 {#adding-and-removing-issue-labels} ラベルを追加するには、以下のいずれかの形式でコメントします。 - `/<label-to-add>`(たとえば、`/good-first-issue`) - `/<label-category> <label-to-add>`(たとえば、`/triage needs-information`や`/language ja`) ラベルを削除するには、以下のいずれかの形式でコメントします。 - `/remove-<label-to-remove>`(たとえば、`/remove-help`) - `/remove-<label-category> <label-to-remove>`(たとえば、`/remove-triage needs-information`) いずれの場合でも、ラベルは既存のものでなければなりません。存在しないラベルを追加しようとした場合、コマンドは無視されます。 すべてのラベル一覧は、[websiteリポジトリーのラベルセクション](https://github.com/kubernetes/website/labels)で確認できます。SIG Docsですべてのラベルが使われているわけではありません。 ### issueのライフサイクルに関するラベル issueは一般にopen後に短期間でcloseされます。しかし、issueがopenされた後にアクティブでなくなったり、issueが90日以上openのままである場合もあります。 {{< table caption="issueのライブラリに関するラベル" >}} ラベル | 説明 :------------|:------------------ `lifecycle/stale` | 90日間活動がない場合、issueは自動的にstaleとラベル付けされます。`/remove-lifecycle stale`コマンドを使って手動でlifecycleをリバートしない限り、issueは自動的にcloseされます。 `lifecycle/frozen` | このラベルが付けられたissueは、90日間活動がなくてもstaleになりません。`priority/important-longterm`ラベルを付けたissueなど、90日以上openにしておく必要があるissueには、このラベルを手動で追加します。 {{< /table >}} ## 特別な種類のissueに対処する SIG Docsでは、対処方法をドキュメントに書いても良いくらい頻繁に、以下のような種類のissueに出会います。 ### 重服したissue 1つの問題に対して1つ以上のissueがopenしている場合、1つのissueに統合します。あなたはどちらのissueをopenにしておくか(あるいは新しいissueを作成するか)を決断して、すべての関連する情報を移動し、関連するすべてのissueにリンクしなければなりません。最後に、同じ問題について書かれたすべての他のissueに`triage/duplicate`ラベルを付けて、それらをcloseします。作業対象のissueを1つだけにすることで、混乱を晒し、同じ問題に対して作業が重複することを避けられます。 ### リンク切れに関するissue リンク切れのissueがAPIまたは`kubectl`のドキュメントにあるものは、問題が完全に理解されるまでは`/priority critical-urgent`を割り当ててください。その他のすべてのリンク切れに関するissueには、手動で修正が必要であるため、`/priority important-longterm`を付けます。 ### Blogに関するissue [Kubernetes Blog](https://kubernetes.io/blog/)のエントリーは時間が経つと情報が古くなるものだと考えています。そのため、ブログのエントリーは1年以内のものだけをメンテナンスします。1年以上前のブログエントリーに関するissueは修正せずにcloseします。 ### サポートリクエストまたはコードのバグレポート {#support-requests-or-code-bug-reports} 一部のドキュメントのissueは、実際には元になっているコードの問題や、何か(たとえば、チュートリアル)がうまく動かないときにサポートをリクエストするものです。ドキュメントに関係のない問題は、`kind/support`ラベルを付け、サポートチャンネル(SlackやStack Overflowなど)へ報告者を導くコメントをして、もし関連があれば機能のバグに対するissueを報告するリポジトリ(`kubernetes/kubernetes`は始めるのに最適な場所です)を教えて、closeします。 サポートリクエストに対する返答の例を示します。(リクエストを行う際は英語で行うことが想定されるため、英文とその日本語訳を記載しています) ```none This issue sounds more like a request for support and less like an issue specifically for docs. I encourage you to bring your question to the `#kubernetes-users` channel in [Kubernetes slack](https://slack.k8s.io/). You can also search resources like [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) for answers to similar questions. You can also open issues for Kubernetes functionality in https://github.com/kubernetes/kubernetes. If this is a documentation issue, please re-open this issue. ``` ```none このissueは特定のドキュメントに関するissueではなく、サポートリクエストのようです。 Kubernetesに関する質問については、[Kubernetes slack](https://slack.k8s.io/)の `#kubernetes-users`チャンネルに投稿することをおすすめします。同様の質問に対する回答を [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)などの リソースで検索することもできます。 Kubernetesの機能に関するissueについては、https://github.com/kubernetes/kubernetes でissueを作成できます。 もしこれがドキュメントに関するissueの場合、このissueを再びopenしてください。 ``` コードのバグに対する返答の例を示します。 ```none This sounds more like an issue with the code than an issue with the documentation. Please open an issue at https://github.com/kubernetes/kubernetes/issues. If this is a documentation issue, please re-open this issue. ``` ```none こちらのissueは、ドキュメントではなくコードに関係するissueのようです。 https://github.com/kubernetes/kubernetes/issues でissueを作成してください。 もしこれがドキュメントに関するissueの場合、このissueを再びopenしてください。 ``` </ins>


Question:
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 example at shows in the being used without . Because (by default?) sets up the scheduler to run inside a pod, it is necessary to use to mount the config file into the pod. Using the example as given will cause the scheduler to fail to start, even if the referenced config file exists on the host. It is also not mentioned here that providing a config file (now?) causes the scheduler to ignore several of the flags (like and ) that kubeadm sets the scheduler up with, so any config file passed needs to duplicate those settings if the scheduler is to work as kubeadm intends. In particular, without setting a , the scheduler will not come up. This documentation is especially important because doesn't necessarily work before the scheduler can schedule enough Kubernetes components to start up TLS, so it can be nearly impossible to debug what is wrong with a non-working scheduler pod without a lot of documentation. Proposed Solution: A working example that lets the scheduler come up with a nontrivial configuration change seems to be: Scheduler config file on host in e.g. : Config file for to point to and mount it: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 1.19.3 <!--Additional Information:--
no other ways are supported, by kubeadm. i can see how the kubeadm example may be bogus in that regard. if scheduler config overrides flags that is an artifact of the kube-scheduler. normally flags should override config, or the mixture should just error out. if some kube-scheduler specifics are not documented they should go here: or here: kubeadm just allows you to configure it and i don't think we should special case the component a lot here: having the following minimal example makes sense to me: ^ this sentence can also be extended to link to /sig cluster-lifecycle scheduling /triage accepted PRs are welcome.
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
perhaps pages like: should start linking to the respective component config pages too:
/assign

kubernetesVersion: v1.16.0 scheduler: extraArgs: <del> bind-address: 0.0.0.0 config: /home/johndoe/schedconfig.yaml kubeconfig: /home/johndoe/kubeconfig.yaml </del> <ins> config: /etc/kubernetes/scheduler-config.yaml extraVolumes: - name: schedulerconfig hostPath: /home/johndoe/schedconfig.yaml mountPath: /etc/kubernetes/scheduler-config.yaml readOnly: true pathType: "File" </ins> ```


Question:
This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/triage accepted

<ins> --- title: システムログ content_type: concept weight: 60 --- <!-- overview --> システムコンポーネントのログは、クラスター内で起こったイベントを記録します。このログはデバッグのために非常に役立ちます。ログのverbosityを設定すると、ログをどの程度詳細に見るのかを変更できます。ログはコンポーネント内のエラーを表示する程度の荒い粒度にすることも、イベントのステップバイステップのトレース(HTTPのアクセスログ、Podの状態の変更、コントローラーの動作、スケジューラーの決定など)を表示するような細かい粒度に設定することもできます。 <!-- body --> ## klog klogは、Kubernetesのログライブラリです。[klog](https://github.com/kubernetes/klog)は、Kubernetesのシステムコンポーネント向けのログメッセージを生成します。 klogの設定に関する詳しい情報については、[コマンドラインツールのリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。 klogネイティブ形式の例: ``` I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] ``` ### 構造化ログ {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< warning >}} 構造化ログへのマイグレーションは現在進行中の作業です。このバージョンでは、すべてのログメッセージが構造化されているわけではありません。ログファイルをパースする場合、JSONではないログの行にも対処しなければなりません。 ログの形式と値のシリアライズは変更される可能性があります。 {{< /warning>}} 構造化ログは、ログメッセージに単一の構造を導入し、プログラムで情報の抽出ができるようにするものです。構造化ログは、僅かな労力とコストで保存・処理できます。新しいメッセージ形式は後方互換性があり、デフォルトで有効化されます。 構造化ログの形式: ```ini <klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ... ``` 例: ```ini I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready" ``` ### JSONログ形式 {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{<warning >}} JSONの出力は多数の標準のklogフラグをサポートしていません。非対応のklogフラグの一覧については、[コマンドラインツールリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。 すべてのログがJSON形式で書き込むことに対応しているわけではありません(たとえば、プロセスの開始時など)。ログのパースを行おうとしている場合、JSONではないログの行に対処できるようにしてください。 フィールド名とJSONのシリアライズは変更される可能性があります。 {{< /warning >}} `--logging-format=json`フラグは、ログの形式をネイティブ形式klogからJSON形式に変更します。以下は、JSONログ形式の例(pretty printしたもの)です。 ```json { "ts": 1580306777.04728, "v": 4, "msg": "Pod status updated", "pod":{ "name": "nginx-1", "namespace": "default" }, "status": "ready" } ``` 特別な意味を持つキー: * `ts` - Unix時間のタイムスタンプ(必須、float) * `v` - verbosity (必須、int、デフォルトは0) * `err` - エラー文字列 (オプション、string) * `msg` - メッセージ (必須、string) 現在サポートされているJSONフォーマットの一覧: * {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} * {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} * {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} * {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} ### ログのサニタイズ {{< feature-state for_k8s_version="v1.20" state="alpha" >}} {{<warning >}} ログのサニタイズ大きな計算のオーバーヘッドを引き起こす可能性があるため、本番環境では有効にするべきではありません。 {{< /warning >}} `--experimental-logging-sanitization`フラグはklogのサニタイズフィルタを有効にします。有効にすると、すべてのログの引数が機密データ(パスワード、キー、トークンなど)としてタグ付けされたフィールドについて検査され、これらのフィールドのログの記録は防止されます。 現在ログのサニタイズをサポートしているコンポーネント一覧: * kube-controller-manager * kube-apiserver * kube-scheduler * kubelet {{< note >}} ログのサニタイズフィルターは、ユーザーのワークロードのログが機密データを漏洩するのを防げるわけではありません。 {{< /note >}} ### ログのverbosityレベル `-v`フラグはログのverbosityを制御します。値を増やすとログに記録されるイベントの数が増えます。値を減らすとログに記録されるイベントの数が減ります。verbosityの設定を増やすと、ますます多くの深刻度の低いイベントをログに記録するようになります。verbosityの設定を0にすると、クリティカルなイベントだけをログに記録します。 ### ログの場所 システムコンポーネントには2種類あります。コンテナ内で実行されるコンポーネントと、コンテナ内で実行されないコンポーネントです。たとえば、次のようなコンポーネントがあります。 * Kubernetesのスケジューラーやkube-proxyはコンテナ内で実行されます。 * kubeletやDockerのようなコンテナランタイムはコンテナ内で実行されません。 systemdを使用しているマシンでは、kubeletとコンテナランタイムはjournaldに書き込みを行います。それ以外のマシンでは、`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナ内部のシステムコンポーネントは、デフォルトのログ機構をバイパスするため、常に`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナのログと同様に、`/var/log`ディレクトリ内のシステムコンポーネントのログはローテートする必要があります。`kube-up.sh`スクリプトによって作成されたKubernetesクラスターでは、ログローテーションは`logrotate`ツールで設定されます。`logrotate`ツールはログを1日ごとまたはログのサイズが100MBを超えたときにローテートします。 ## {{% heading "whatsnext" %}} * [Kubernetesのログのアーキテクチャ](/docs/concepts/cluster-administration/logging/)について読む。 * [構造化ログ](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)について読む。 * [ログの深刻度の慣習](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)について読む。 </ins>


Question:
No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
…until now:
I reckon will close this issue.

--- title: Service Accounts description: > <del> Learn about the Kubernetes ServiceAccount object. </del> <ins> Learn about ServiceAccount objects in Kubernetes. </ins> content_type: concept weight: 10 ---


Question:
No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
…until now:
I reckon will close this issue.

the configurations portable. Service accounts are different from user accounts, which are authenticated <del> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </del> <ins> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </ins> data. You can authenticate as a user account using multiple methods. Some Kubernetes distributions might add custom extension APIs to represent user accounts in the API server.


Question:
No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
…until now:
I reckon will close this issue.

object named `default` for every namespace in your cluster. The `default` service accounts in each namespace get no permissions by default other than the [default API discovery permissions](/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) <del> that Kubernetes grants to all authenticated principals if role-based access control (RBAC) is enabled. If you delete the `default` ServiceAccount object in a namespace, the {{<glossary_tooltip text="control plane" term_id="control-plane">}} </del> <ins> that Kubernetes grants to all authenticated principals if role-based access control (RBAC) is enabled. If you delete the `default` ServiceAccount object in a namespace, the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} </ins> replaces it with a new one. If you deploy a Pod in a namespace, and you don't


Question:
No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
…until now:
I reckon will close this issue.

following methods: * [TokenRequest API](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) <del> (recommended): Request a short-lived service account token using your *application code*. The token expires automatically and can rotate upon expiration. </del> <ins> (recommended): Request a short-lived service account token from within your own *application code*. The token expires automatically and can rotate upon expiration. If you have a legacy application that is not aware of Kubernetes, you could use a sidecar container within the same pod to fetch these tokens and make them available to the application workload. </ins> * [Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) <del> (recommended): In Kubernetes v1.20 and later, use the Pod specification to </del> <ins> (also recommended): In Kubernetes v1.20 and later, use the Pod specification to </ins> tell the kubelet to add the service account token to the Pod as a *projected volume*. Projected tokens expire automatically, and the kubelet rotates the token before it expires.


Question:
No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
…until now:
I reckon will close this issue.

with static, long-lived credentials. In Kubernetes v1.24 and later, the [LegacyServiceAccountTokenNoAutoGeneration feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features) prevents Kubernetes from automatically creating these tokens for <del> ServiceAccounts. </del> <ins> ServiceAccounts. `LegacyServiceAccountTokenNoAutoGeneration` is enabled by default; in other words, Kubernetes does not create these tokens. </ins> ## Authenticating service account credentials {#authenticating-credentials}


Question:
No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
…until now:
I reckon will close this issue.

trust relationship exists. Depending on how the token was issued (either time-limited using a `TokenRequest` or using a legacy mechanism with a Secret), a ServiceAccount token might also have an expiry time, an audience, <del> and a time after which the token *starts* being valid. When a process running in a Pod attempts to communicate with the Kubernetes API server, it adds an `Authorization: Bearer <token>` header to the HTTP request. The API server checks the validity of the bearer token as follows: </del> <ins> and a time after which the token *starts* being valid. When a client that is acting as a ServiceAccount tries to communicate with the Kubernetes API server, the client includes an `Authorization: Bearer <token>` header with the HTTP request. The API server checks the validity of that bearer token as follows: </ins> 1. Check the token signature. 1. Check whether the token has expired. <del> 1. Checks whether object references in the token claims are currently valid </del> <ins> 1. Check whether object references in the token claims are currently valid. </ins> 1. Check whether the token is currently valid. 1. Check the audience claims. <ins> The TokenRequest API produces _bound tokens_ for a ServiceAccount. This binding is linked to the lifetime of the client, such as a Pod, that is acting as that ServiceAccount. </ins> For tokens issued using the `TokenRequest` API, the API server also checks that the specific object reference that is using the ServiceAccount still exists, matching by the {{< glossary_tooltip term_id="uid" text="unique ID" >}} of that