Question: - [Pods](/docs/concepts/workloads/pods/) - [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/) - [Headless Services](/docs/concepts/services-networking/service/#headless-services) <del> - [PersistentVolumes](/docs/concepts/storage/volumes/) </del> <ins> - [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) </ins> - [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/) - [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) - [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)

This is a Bug Report Problem: page contains the following broken links: If we go through the Running ZooKeeper, A Distributed System Coordinator Introduction. If we go to click PersistentVolumes it should redirect us to PersistentVolumes Page but it shows us Volumes Page which we have to rectify here! ! Proposed Solution: Fix the broken links by Updating it to: Page to Update:
/sig docs /language en /assign
hey Can you look into this issue!!!!
/retitle Incorrect link redirection on "Running ZooKeeper" tutorial for "PersistentVolumes" /kind bug
/priority backlog (or lower) /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /priority backlog (or lower) /triage accepted /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Incorrect link redirection in "Running ZooKeeper" tutorial page for "PersistentVolumes"
Thanks
But I have to work on this issue!!! I have self-assigned this issue to myself, Why someone else has raised a PR For this ??????


Question: {{< note >}} <!-- <del> `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above. </del> <ins> `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above. </ins> --> 对于运行 Linux 内核版本 4.0 或更高版本，或使用 3.10.0-51 及更高版本的 RHEL 或 CentOS 的系统，`overlay2`是首选的存储驱动程序。

! w sudo systemctl enable crio --now
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This 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: Typo in zh/docs/setup/production-environment/container-runtimes Proposed Solution: -Page to Update: zh: (en: ) <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/retitle [zh] Typo in docs/setup/production-environment/container-runtimes /kind bug /language zh
Page is a little bit lagging behind. Will fix. /assign


Question: This section outlines the necessary steps to use containerd as CRI runtime. <del> To install containerd on your system, follow the instructions on [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md).Return to this step once you've created a valid `config.toml` configuration file. </del> <ins> To install containerd on your system, follow the instructions on [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md). Return to this step once you've created a valid `config.toml` configuration file. </ins> {{< tabs name="Finding your config.toml file" >}} {{% tab name="Linux" %}}

This section: I would add information like here: Note: In v1.22, if the user is not setting the cgroupDriver field under KubeletConfiguration, kubeadm will default it to systemd.
this section: already links to: PRs welcome with proposed improvements. /help /sig cluster-lifecycle
If someone wants to help here, I'm not sure what steps they should follow to assist. Because of that: /remove-help
/language en
I think the suggestion is to add something about to container-runtimes pages but I don't think that fits well on that page because it only covers the container runtime side. What could be though is that there's a note/reminder to ensure they are always the same. I can work on that if we agree what's what we want here.
hmm, looks like this is already covered too.
some additional feedback in
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/assign


Question: ## Using the built-in Pod Security Admission Controller <del> {{< feature-state for_k8s_version="v1.22" state="alpha" >}} </del> <ins> {{< feature-state for_k8s_version="v1.23" state="beta" >}} </ins> The [Pod Security Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) intends to replace the deprecated PodSecurityPolicies.

This is a Bug Report Problem: The of PodSecurityAdmission is mentioned under . Which is wrong, the correct one is . Proposed Solution: Change the from to . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/sig auth /assign
Fixed it here:
/triage accepted


Question: <ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-ingress spec: podSelector: {} ingress: - {} policyTypes: - Ingress </ins>

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
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale


Question:
</form>
{{ T "main_kubeweekly_past_link" }}

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 enhanced? I think "Subscribe to KubeWeekly Newsletter" section at bottom of Home page is:- too much white/grey space that can be shortend. input area where user will enter his/her email id is a little small and maybe it will be better if that gets a little enlarged. <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --!
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
/area web-development
/priority backlog
Page:
/good-first-issue The files to edit can be found in assets/scss
/remove-help /remove-good-first-issue Don't label issues as good first issues unless they are also triaged as Accepted
/assign
when we shorten this white space I feel there is no need to enlarge the input area as it aligns perfectly once shorten. !
/close
Closing this issue. <detailsIn response to : /close </details


Question: ``` <del> For initial troubleshooting, you can use the following flags in [nssm.exe](https://nssm.cc/) to redirect stdout and stderr to a output file: </del> <ins> 最初のトラブルシューティングでは、[nssm.exe](https://nssm.cc/)で次のフラグを使用して、stdoutおよびstderrを出力ファイルにリダイレクトできます。: </ins> ```powershell nssm set <Service Name> AppStdout C:kmysvc.log nssm set <Service Name> AppStderr C:kmysvc.log ``` <del> For additional details, see official [nssm usage](https://nssm.cc/usage) docs. </del> <ins> 詳細については、公式の[nssmの使用法](https://nssm.cc/usage)のドキュメントを参照してください。 </ins> <del> 1. My Windows Pods do not have network connectivity </del> <ins> 1. Windows Podにネットワーク接続がありません </ins> <del> If you are using virtual machines, ensure that MAC spoofing is enabled on all the VM network adapter(s). </del> <ins> 仮想マシンを使用している場合は、すべてのVMネットワークアダプターでMACスプーフィングが有効になっていることを確認してください。 </ins> <del> 1. My Windows Pods cannot ping external resources </del> <ins> 1. Windows Podが外部リソースにpingできません </ins> <del> Windows Pods do not have outbound rules programmed for the ICMP protocol today. However, TCP/UDP is supported. When trying to demonstrate connectivity to resources outside of the cluster, please substitute `ping <IP>` with corresponding `curl <IP>` commands. </del> <ins> 現在、Windows Podには、ICMPプロトコル用にプログラムされた送信ルールはありません。ただし、TCP/UDPはサポートされています。クラスター外のリソースへの接続を実証する場合は、`ping <IP>`に対応する`curl <IP>`コマンドに置き換えてください。 </ins> <del> If you are still facing problems, most likely your network configuration in [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf) deserves some extra attention. You can always edit this static file. The configuration update will apply to any newly created Kubernetes resources. </del> <ins> それでも問題が解決しない場合は、[cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)のネットワーク構成に値する可能性があるので、いくつかの特別な注意が必要です。この静的ファイルはいつでも編集できます。構成の更新は、新しく作成されたすべてのKubernetesリソースに適用されます。 </ins> <del> One of the Kubernetes networking requirements (see [Kubernetes model](/ja/docs/concepts/cluster-administration/networking/)) is for cluster communication to occur without NAT internally. To honor this requirement, there is an [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) for all the communication where we do not want outbound NAT to occur. However, this also means that you need to exclude the external IP you are trying to query from the ExceptionList. Only then will the traffic originating from your Windows pods be SNAT'ed correctly to receive a response from the outside world. In this regard, your ExceptionList in `cni.conf` should look as follows: </del> <ins> Kubernetesのネットワーキング要件の1つ(参照[Kubernetesモデル](/ja/docs/concepts/cluster-administration/networking/))は、内部でNATを使用せずにクラスター通信を行うためのものです。この要件を遵守するために、すべての通信に[ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)があり、アウトバウンドNATが発生しないようにします。ただし、これは、クエリしようとしている外部IPをExceptionListから除外する必要があることも意味します。そうして初めて、Windows PodからのトラフィックがSNAT処理され、外部からの応答を受信できるようになります。この点で、`cni.conf`のExceptionListは次のようになります。: </ins> ```conf "ExceptionList": [ <del> "10.244.0.0/16",  # Cluster subnet "10.96.0.0/12",   # Service subnet "10.127.130.0/24" # Management (host) subnet </del> <ins> "10.244.0.0/16",  # クラスターのサブネット "10.96.0.0/12",   # Serviceのサブネット "10.127.130.0/24" # 管理 (ホスト) のサブネット </ins> ] ``` <del> 1. My Windows node cannot access NodePort service </del> <ins> 1. WindowsノードがNodePort Serviceにアクセスできません </ins> <del> Local NodePort access from the node itself fails. This is a known limitation. NodePort access works from other nodes or external clients. </del> <ins> ノード自体からのローカルNodePortアクセスは失敗します。これは既知の制限です。NodePortアクセスは、他のノードまたは外部クライアントから行えます。 </ins> <del> 1. vNICs and HNS endpoints of containers are being deleted </del> <ins> 1. コンテナのvNICとHNSエンドポイントが削除されています </ins> <del> This issue can be caused when the `hostname-override` parameter is not passed to [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/). To resolve it, users need to pass the hostname to kube-proxy as follows: </del> <ins> この問題は、`hostname-override`パラメータが[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)に渡されない場合に発生する可能性があります。これを解決するには、ユーザーは次のようにホスト名をkube-proxyに渡す必要があります。: </ins> ```powershell C:kkube-proxy.exe --hostname-override=$(hostname) ``` <del> 1. With flannel my nodes are having issues after rejoining a cluster </del> <ins> 1. flannelを使用すると、クラスターに再参加した後、ノードに問題が発生します </ins> <del> Whenever a previously deleted node is being re-joined to the cluster, flannelD tries to assign a new pod subnet to the node. Users should remove the old pod subnet configuration files in the following paths: </del> <ins> 以前に削除されたノードがクラスターに再参加するときはいつも、flannelDは新しいPodサブネットをノードに割り当てようとします。ユーザーは、次のパスにある古いPodサブネット構成ファイルを削除する必要があります。: </ins> ```powershell Remove-Item C:kSourceVip.json Remove-Item C:kSourceVipRequest.json ``` <del> 1. After launching `start.ps1`, flanneld is stuck in "Waiting for the Network to be created" </del> <ins> 1. `start.ps1`を起動した後、flanneldが「ネットワークが作成されるのを待っています」と表示されたままになります </ins> <del> There are numerous reports of this [issue which are being investigated](https://github.com/coreos/flannel/issues/1066); most likely it is a timing issue for when the management IP of the flannel network is set. A workaround is to simply relaunch start.ps1 or relaunch it manually as follows: </del> <ins> この[調査中の問題](https://github.com/coreos/flannel/issues/1066)に関する多数の報告があります。最も可能性が高いのは、flannelネットワークの管理IPが設定されるタイミングの問題です。回避策は、単純にstart.ps1を再起動するか、次のように手動で再起動することです。: </ins> ```powershell PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>") PS C:> C:flannelflanneld.exe --kubeconfig-file=c:kconfig --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1 ``` <del> 1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env` </del> <ins> 1. `/run/flannel/subnet.env`がないため、Windows Podを起動できません </ins> <del> This indicates that Flannel didn't launch correctly. You can either try to restart flanneld.exe or you can copy the files over manually from `/run/flannel/subnet.env` on the Kubernetes master to` C:runflannelsubnet.env` on the Windows worker node and modify the `FLANNEL_SUBNET` row to a different number. For example, if node subnet 10.244.4.1/24 is desired: </del> <ins> これは、Flannelが正しく起動しなかったことを示しています。 flanneld.exeの再起動を試みるか、Kubernetesマスターの`/run/flannel/subnet.env`からWindowsワーカーノードの`C:runflannelsubnet.env`に手動でファイルをコピーすることができます。「FLANNEL_SUBNET」行を別の番号に変更します。たとえば、ノードサブネット10.244.4.1/24が必要な場合は以下となります。: </ins> ```env FLANNEL_NETWORK=10.244.0.0/16

This is a Feature Request What would you like to be Translate docs/setup/production-environment/windows/intro-windows-in-kubernetes/ into Japanese Why is this needed This page has not been translated. Comments /language ja /assign
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: See [Traffic Policies](/docs/reference/networking/virtual-ips/#traffic-policies) for more details. <del> ### Trafic distribution </del> <ins> ### Traffic distribution </ins> {{< feature-state feature_gate_name="ServiceTrafficDistribution" >}}

This seems to be a typo, shouldn't it be traffic-distribution and not trafic-distribution ?
/triage accepted /good-first-issue Yep, looks like that was a typo in the recent updates.
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language en
/retitle Typo in "Service" concept page /kind bug


Question: これで、Hugoのサーバーが1313番ポートを使って開始します。お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 <ins> ## API reference pagesをビルドする `content/en/docs/reference/kubernetes-api`に配置されているAPIリファレンスページは<https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>を使ってSwagger仕様書からビルドされています。 新しいKubernetesリリースのためにリファレンスページをアップデートするには、次の手順を実行します: 1. `api-ref-generator`サブモジュールをプルする: ```bash git submodule update --init --recursive --depth 1 ``` 2. Swagger仕様書を更新する: ```bash curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json ``` 3. 新しいリリースの変更を反映するため、`api-ref-assets/config/`で`toc.yaml`と`fields.yaml`を適用する。 4. 次に、ページをビルドする: ```bash make api-reference ``` コンテナイメージからサイトを作成・サーブする事でローカルで結果をテストすることができます: ```bash make container-image make container-serve ``` APIリファレンスを見るために、ブラウザで<http://localhost:1313/docs/reference/kubernetes-api/>を開いてください。 5. 新しいコントラクトのすべての変更が設定ファイル`toc.yaml`と`fields.yaml`に反映されたら、新しく生成されたAPIリファレンスページとともにPull Requestを作成します。 </ins> ## トラブルシューティング ### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version

This is a Feature Request What would you like to be Update README- Why is this needed has been updated after translated Comments /language ja
/triage accepted


Question: * `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector hoding the computed concurrency limit (based on the API server's total concurrency limit and PriorityLevelConfigurations' concurrency <del> shares), broken down by the label `priorityLevel`. </del> <ins> shares), broken down by the label `priority_level`. </ins> * `apiserver_flowcontrol_request_wait_duration_seconds` is a histogram vector of how long requests spent queued, broken down by the labels <del> `flowSchema` (indicating which one matched the request), `priorityLevel` (indicating the one to which the request was </del> <ins> `flow_schema` (indicating which one matched the request), `priority_level` (indicating the one to which the request was </ins> assigned), and `execute` (indicating whether the request started executing). {{< note >}}

Keep the doc consistent with
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: ## Securing etcd clusters <del> Access to etcd is equivalent to root permission in the cluster so ideally only the API server should have access to it. Considering the sensitivity of the data, it is recommended to grant permission to only those nodes that require access to etcd clusters. To secure etcd, either set up firewall rules or use the security features provided by etcd. etcd security features depend on x509 Public Key Infrastructure (PKI). To begin, establish secure communication channels by generating a key and certificate pair. For example, use key pairs `peer.key` and `peer.cert` for securing communication between etcd members, and `client.key` and `client.cert` for securing communication between etcd and its clients. See the [example scripts](https://github.com/coreos/etcd/tree/master/hack/tls-setup) provided by the etcd project to generate key pairs and CA files for client authentication. </del> <ins> Access to etcd is equivalent to root permission in the cluster so ideally only the API server should have access to it. Considering the sensitivity of the data, it is recommended to grant permission to only those nodes that require access to etcd clusters. To secure etcd, either set up firewall rules or use the security features provided by etcd. etcd security features depend on x509 Public Key Infrastructure (PKI). To begin, establish secure communication channels by generating a key and certificate pair. For example, use key pairs `peer.key` and `peer.cert` for securing communication between etcd members, and `client.key` and `client.cert` for securing communication between etcd and its clients. See the [example scripts](https://github.com/coreos/etcd/tree/master/hack/tls-setup) provided by the etcd project to generate key pairs and CA files for client authentication. </ins> ### Securing communication <del> To configure etcd with secure peer communication, specify flags `--peer-key-file=peer.key` and `--peer-cert-file=peer.cert`, and use https as URL schema. </del> <ins> To configure etcd with secure peer communication, specify flags `--peer-key-file=peer.key` and `--peer-cert-file=peer.cert`, and use HTTPS as the URL schema. </ins> <del> Similarly, to configure etcd with secure client communication, specify flags `--key-file=k8sclient.key` and `--cert-file=k8sclient.cert`, and use https as URL schema. </del> <ins> Similarly, to configure etcd with secure client communication, specify flags `--key-file=k8sclient.key` and `--cert-file=k8sclient.cert`, and use HTTPS as the URL schema. </ins> ### Limiting access of etcd clusters <del> After configuring secure communication, restrict the access of etcd cluster to only the Kubernetes API server. Use TLS authentication to do so. </del> <ins> After configuring secure communication, restrict the access of etcd cluster to only the Kubernetes API servers. Use TLS authentication to do so. </ins> <del> For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are trusted by the CA `etcd.ca`. When etcd is configured with `--client-cert-auth` along with TLS, it verifies the certificates from clients by using system CAs or the CA passed in by `--trusted-ca-file` flag. Specifying flags `--client-cert-auth=true` and `--trusted-ca-file=etcd.ca` will restrict the access to clients with the certificate `k8sclient.cert`. </del> <ins> For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are trusted by the CA `etcd.ca`. When etcd is configured with `--client-cert-auth` along with TLS, it verifies the certificates from clients by using system CAs or the CA passed in by `--trusted-ca-file` flag. Specifying flags `--client-cert-auth=true` and `--trusted-ca-file=etcd.ca` will restrict the access to clients with the certificate `k8sclient.cert`. </ins> <del> Once etcd is configured correctly, only clients with valid certificates can access it. To give Kubernetes API server the access, configure it with the flags `--etcd-certfile=k8sclient.cert`,`--etcd-keyfile=k8sclient.key` and `--etcd-cafile=ca.cert`. </del> <ins> Once etcd is configured correctly, only clients with valid certificates can access it. To give Kubernetes API servers the access, configure them with the flags `--etcd-certfile=k8sclient.cert`,`--etcd-keyfile=k8sclient.key` and `--etcd-cafile=ca.cert`. </ins> {{< note >}} <del> etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398). </del> <ins> etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398). </ins> {{< /note >}} ## Replacing a failed etcd member <del> etcd cluster achieves high availability by tolerating minor member failures. However, to improve the overall health of the cluster, replace failed members immediately. When multiple members fail, replace them one by one. Replacing a failed member involves two steps: removing the failed member and adding a new member. </del> <ins> etcd cluster achieves high availability by tolerating minor member failures. However, to improve the overall health of the cluster, replace failed members immediately. When multiple members fail, replace them one by one. Replacing a failed member involves two steps: removing the failed member and adding a new member. </ins> <del> Though etcd keeps unique member IDs internally, it is recommended to use a unique name for each member to avoid human errors. For example, consider a three-member etcd cluster. Let the URLs be, member1=http://10.0.0.1, member2=http://10.0.0.2, and member3=http://10.0.0.3. When member1 fails, replace it with member4=http://10.0.0.4. </del> <ins> Though etcd keeps unique member IDs internally, it is recommended to use a unique name for each member to avoid human errors. For example, consider a three-member etcd cluster. Let the URLs be, `member1=http://10.0.0.1`, `member2=http://10.0.0.2`, and `member3=http://10.0.0.3`. When `member1` fails, replace it with `member4=http://10.0.0.4`. </ins> <del> 1. Get the member ID of the failed member1: </del> <ins> 1. Get the member ID of the failed `member1`: </ins> <del> `etcdctl --endpoints=http://10.0.0.2,http://10.0.0.3 member list` </del> <ins> ```shell etcdctl --endpoints=http://10.0.0.2,http://10.0.0.3 member list ``` </ins> <del> The following message is displayed: </del> <ins> The following message is displayed: </ins> <del> 8211f1d0f64f3269, started, member1, http://10.0.0.1:2380, http://10.0.0.1:2379 91bc3c398fb3c146, started, member2, http://10.0.0.2:2380, http://10.0.0.2:2379 fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379 </del> <ins> ```console 8211f1d0f64f3269, started, member1, http://10.0.0.1:2380, http://10.0.0.1:2379 91bc3c398fb3c146, started, member2, http://10.0.0.2:2380, http://10.0.0.2:2379 fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379 ``` </ins> 2. Remove the failed member: <del> `etcdctl member remove 8211f1d0f64f3269` </del> <ins> ```shell etcdctl member remove 8211f1d0f64f3269 ``` </ins> <del> The following message is displayed: </del> <ins> The following message is displayed: </ins> <del> Removed member 8211f1d0f64f3269 from cluster </del> <ins> ```console Removed member 8211f1d0f64f3269 from cluster ``` </ins> 3. Add the new member: <del> `./etcdctl member add member4 --peer-urls=http://10.0.0.4:2380` </del> <ins> ```shell etcdctl member add member4 --peer-urls=http://10.0.0.4:2380 ``` </ins> <del> The following message is displayed: </del> <ins> The following message is displayed: </ins> <del> Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4 </del> <ins> ```console Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4 ``` </ins> 4. Start the newly added member on a machine with the IP `10.0.0.4`: <del> export ETCD_NAME="member4" export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380" export ETCD_INITIAL_CLUSTER_STATE=existing etcd [flags] </del> <ins> ```shell export ETCD_NAME="member4" export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380" export ETCD_INITIAL_CLUSTER_STATE=existing etcd [flags] ``` </ins> 5. Do either of the following: <del> 1. Update its `--etcd-servers` flag to make Kubernetes aware of the configuration changes, then restart the Kubernetes API server. 2. Update the load balancer configuration if a load balancer is used in the deployment. </del> <ins> 1. Update the `--etcd-servers` flag for the Kubernetes API servers to make Kubernetes aware of the configuration changes, then restart the Kubernetes API servers. 2. Update the load balancer configuration if a load balancer is used in the deployment. </ins> <del> For more information on cluster reconfiguration, see [etcd Reconfiguration Documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/runtime-configuration.md#remove-a-member). </del> <ins> For more information on cluster reconfiguration, see [etcd reconfiguration documentation](https://etcd.io/docs/current/op-guide/runtime-configuration/#remove-a-member). </ins> ## Backing up an etcd cluster <del> All Kubernetes objects are stored on etcd. Periodically backing up the etcd cluster data is important to recover Kubernetes clusters under disaster scenarios, such as losing all master nodes. The snapshot file contains all the Kubernetes states and critical information. In order to keep the sensitive Kubernetes data safe, encrypt the snapshot files. </del> <ins> All Kubernetes objects are stored on etcd. Periodically backing up the etcd cluster data is important to recover Kubernetes clusters under disaster scenarios, such as losing all control plane nodes. The snapshot file contains all the Kubernetes states and critical information. In order to keep the sensitive Kubernetes data safe, encrypt the snapshot files. </ins> <del> Backing up an etcd cluster can be accomplished in two ways: etcd built-in snapshot and volume snapshot. </del> <ins> Backing up an etcd cluster can be accomplished in two ways: etcd built-in snapshot and volume snapshot. </ins> ### Built-in snapshot <del> etcd supports built-in snapshot. A snapshot may either be taken from a live member with the `etcdctl snapshot save` command or by copying the `member/snap/db` file from an etcd [data directory](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/configuration.md#--data-dir) that is not currently used by an etcd process. Taking the snapshot will normally not affect the performance of the member. </del> <ins> etcd supports built-in snapshot. A snapshot may either be taken from a live member with the `etcdctl snapshot save` command or by copying the `member/snap/db` file from an etcd [data directory](https://etcd.io/docs/current/op-guide/configuration/#--data-dir) that is not currently used by an etcd process. Taking the snapshot will not affect the performance of the member. </ins> <del> Below is an example for taking a snapshot of the keyspace served by `$ENDPOINT` to the file `snapshotdb`: </del> <ins> Below is an example for taking a snapshot of the keyspace served by `$ENDPOINT` to the file `snapshotdb`: </ins> <del> ```sh </del> <ins> ```shell </ins> ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshotdb <del> # exit 0 </del> <ins> ``` Verify the snapshot: </ins> <del> # verify the snapshot </del> <ins> ```shell </ins> ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshotdb <ins> ``` ```console </ins> +----------+----------+------------+------------+ |   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE | +----------+----------+------------+------------+

Links to github on this page seems to be broken
/triage accepted /assign
Also see issue


Question: API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource. <del> The name of a CRD object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). </del> <ins> The name of the CRD object itself must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) derived from the defined resource name and its API group; see [how to create a CRD](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions#create-a-customresourcedefinition) for more details. Further, the name of an object whose kind/resource is defined by a CRD must also be a valid DNS subdomain name. </ins> This frees you from writing your own API server to handle the custom resource, but the generic nature of the implementation means you have less flexibility than with

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: I wondered what are the restrictions (if any) that Kubernetes imposes on the names of objects of a kind that gets defined by a CustomResourceDefinition. I am not talking about the name of the CRD itself. I tried to find this in the documentation, and couldn't. I asked on the channel on the Kubernetes Slack, and was referred to . The text there says Since a CRD is itself an object, I thought this was clearly talking about the name of the CRD itself (I temporarily forgot that I know that the name of the CRD itself is constrained to be ). But I was assured that this text is trying to talk about the objects whose kind is defined by the CRD. Proposed Solution: Update the cited doc to be clearer. Page to Update:
/sig docs /language en
/triage accepted /wg api-expression Since a CRD is itself an object, I thought this was clearly talking about the name of the CRD itself Yes, that's right. Both I and confirm this; I'm an emeritus tech lead for SIG Docs, and is a current tech lead. (sic) Would be good to add that detail to the page.


Question: The latter selects all resources with key equal to `tier` and value distinct from `frontend`, and all resources with no labels with the `tier` key. One could filter for resources in `production` excluding `frontend` using the comma operator: `environment=production,tier!=frontend` <ins> One usage scenario for equality-based label requirement is for Pods to specify node selection criteria. For example, the sample Pod below selects nodes with the label "`accelerator=nvidia-tesla-p100`". ```yaml apiVersion: v1 kind: Pod metadata: name: cuda-test spec: containers: - name: cuda-test image: "k8s.gcr.io/cuda-vector-add:v0.1" resources: limits: nvidia.com/gpu: 1 nodeSelector: accelerator: nvidia-tesla-p100 ``` </ins> ### _Set-based_ requirement

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [ ] Bug Report [x] Documentation request Problem: Can we use equality-based requirement selectors like this in yaml/json files: Proposed Solution: Clearly mention if this is possible and if so include a small example. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /assign


Question: You can specify init containers in the Pod specification alongside the `containers` array (which describes app containers). <ins> In Kubernetes, a [sidecar container](/docs/concepts/workloads/pods/sidecar-containers/) is a container that starts before the main application container and _continues to run_. This document is about init containers: containers that run to completion during Pod initialization. </ins> <!-- body -->

restartPolicy under initContainers is not allowing to create Jobs specified into the below documents Error Message: Job in version "v1" cannot be handled as a Job: strict decoding error: unknown field "[0].restartPolicy" Document Link:
Hi I believe the error message you are getting is because you might have used feild under the section. But it is not allowed under the . /language en
Page related to the issue: /sig docs /sig node
Hi , Below is the Job configuration:
Could you please provide the code block with proper indentation?
updated above section
The indentation should be corrected as below
/kind bug
mentions a feature gate, but doesn't make it explicitly clear that you need to enable it. The feature gate is named . The fix I recommend: add a brand new page edit to direct readers to that new page /remove-kind bug I don't think there is anything actually incorrect. /triage accepted /retitle Unclear documentation about sidecar containers
Is anybody working to fix this issue? If no, i can take it.
/assign
Feel free to involve me, if you need any help.
Sure, Thank you.
PR raised to fix the issue .
Also see
To learn more, you can read (but not plagiarize)
Hi, I also having this problem I tried to add restartPolicy as to under containers and init containers, but I get the same error. I do not got any errors for the restartPolicy, but and are gave the error mentioned at the top. Im using Minikube, and my CC: Your suggestions highly appriciatable
Looks like you are using 1.27, but this feature was in 1.28.
Thanks I updated my k8s Even though I can not use and in both places. ( and I put this marker in the above comment). It says,


Question: {{< /note >}} Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working. <del> To enable bash autocompletion in current session of shell, source the ~/.bashrc file: </del> <ins> To enable bash autocompletion in current session of shell, run `exec bash`: </ins> ```bash <del> source ~/.bashrc </del> <ins> exec bash </ins> ```

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: When somebody configures shell completion for , the instructions explain how to turn that on for your current session. However, that advice only works if the reader picked the approach in the “User” tab. If someone picked the “System” tab, the advice does not help them update their current session. Proposed Solution: Change that page to advise the user to run Some other change that also helps the user, regardless of which approach they took. Page to Update: Additional Information: Prompted by /language en /priority backlog
/triage accepted
/assign


Question: { type: 0, name: 'ASM Technologies Limited', <del> logo: 'asmtech', </del> <ins> logo: 'asm', </ins> link: 'http://www.asmtech.com/', <del> blurb: 'http://www.asmtech.com/audience-channels/software_publisher/' </del> <ins> blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' </ins> }, { type: 1,

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [X] Bug Report Problem: The link "build-tools/" doesn't work anymore and returns 404. Proposed Solution: Fix the link Page to Update:
Fixed. Thanks!


Question: { type: 0, name: 'ASM Technologies Limited', <del> logo: 'asmtech', </del> <ins> logo: 'asm', </ins> link: 'http://www.asmtech.com/', <del> blurb: 'http://www.asmtech.com/audience-channels/software_publisher/' </del> <ins> blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' </ins> }, { type: 1,

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: Page url: in line 83, click PetSets guide occur 404 error. Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Fixed.


Question: { type: 0, name: 'ASM Technologies Limited', <del> logo: 'asmtech', </del> <ins> logo: 'asm', </ins> link: 'http://www.asmtech.com/', <del> blurb: 'http://www.asmtech.com/audience-channels/software_publisher/' </del> <ins> blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' </ins> }, { type: 1,

This is a... [ ] Feature Request [X] Bug Report Problem: link "Minikube installation guide" points to which is 404 Proposed Solution: fix the link by making it absolute: Page to Update:
Fixed.


Question: { type: 0, name: 'ASM Technologies Limited', <del> logo: 'asmtech', </del> <ins> logo: 'asm', </ins> link: 'http://www.asmtech.com/', <del> blurb: 'http://www.asmtech.com/audience-channels/software_publisher/' </del> <ins> blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' </ins> }, { type: 1,

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [X] Bug Report Problem: Multiple links on the page generate 404 Not Found Examples: (redirected from ) (redirected from ) Proposed Solution: fix the links Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Here is the full list of broken links on xhyve driver kvm (driver installation) xhyve (driver installation) See DRIVERS docker-env command minikube start minikube stop minikube delete full CLI docs


Question: { type: 0, name: 'ASM Technologies Limited', <del> logo: 'asmtech', </del> <ins> logo: 'asm', </ins> link: 'http://www.asmtech.com/', <del> blurb: 'http://www.asmtech.com/audience-channels/software_publisher/' </del> <ins> blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' </ins> }, { type: 1,

I wish /docs/user-guide/horizontal-pod-autoscaling/walkthrough/ actually contained the information, or at least a link to autoscaling by custom application logic (as referred to by the first sentence in the article - . The second half of this article seems like the correct target link -
Fixed. Thanks.


Question: 例如：要禁用batch/v1，请设置 `--runtime-config=batch/v1=false`，以启用batch/v2alpha1，请设置`--runtime-config=batch/v2alpha1`。 该标志接受描述apiserver的运行时配置的逗号分隔的一组键值对。 <del> 重要：启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 `--runtime-config` 更改生效。 </del> <ins> {{< note >}} 启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 `--runtime-config` 更改生效。 {{< /note >}} </ins> <!-- <del> ## Enabling resources in the groups </del> <ins> ## Enabling specific resources in the extensions/v1beta1 group DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default. For example: to enable deployments and daemonsets, set `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. </ins> <del> DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs and ReplicaSets are enabled by default. Other extensions resources can be enabled by setting `--runtime-config` on apiserver. `--runtime-config` accepts comma separated values. For example: to disable deployments and ingress, set `--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false` </del> <ins> Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons. </ins> --> <del> ## 启用组中资源 </del> <ins> ## 启用 extensions/v1beta1 组中资源 在 `extensions/v1beta1` API 组中，DaemonSets，Deployments，StatefulSet, NetworkPolicies, PodSecurityPolicies 和 ReplicaSets 是默认禁用的。 例如：要启用 deployments 和 daemonsets，请设置 `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`。 {{< note >}} 出于遗留原因，仅在 `extensions / v1beta1` API 组中支持各个资源的启用/禁用。 </ins> <del> DaemonSets，Deployments，HorizontalPodAutoscalers，Ingress，Jobs 和 ReplicaSets是默认启用的。 其他扩展资源可以通过在apiserver上设置 `--runtime-config` 来启用。 `--runtime-config` 接受逗号分隔的值。 例如：要禁用 Deployment 和 Ingress， 请设置 `--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false` </del> <ins> {{< /note >}} </ins> {{% /capture %}}

This is a Feature Request Since v1.16, extensions/v1beta1 has been deleted and it should not be used in docs What would you like to be The following pages should be edited due to this deletion. [ ] [ ] [x] [ ] [ ] [ ] [ ] [ ] [x] [x] Why is this needed extensions/v1beta1 is deleted in 1.16 Comments
/kind cleanup /priority important-soon (I think)
If you are looking at this as potentially something to contribute to, it's OK to suggest a PR that fixes only one page, or only some pages. If you do that please mention “Partial fix for issue ” in the description of your PR.
thanks for contribution here. Could you please share which pages would you take? Let us make the assignment more clear and help other contributors easily start their work.
Thank you for your comments. I wrote the target file into PR titles. And I will write to the comment about netlify demo pages and original pages to enable checking the diff easily.


Question: ### Calico <del> [Calico](https://docs.projectcalico.org/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement. </del> <ins> [Calico](https://projectcalico.docs.tigera.io/about/about-calico/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement. </ins> ### Cilium

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --In , update the link URL from to update the link URL from to update the link URL from to update the link URL from to update the link URL from to update the link URL from to Why is this needed redirects to , which is a fork of and currently 62 commits behind . The latest commit of : on 29 Oct 2021 The latest commit of : on 12 Feb 2019 and for other CNIs, it would be better to use the final URLs than using redirecting URLs. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --Page to update:
/assign
/triage accepted /kind cleanup
/retitle Fix incorrect / outdated URIs in list of network plugins /language en /priority backlog


Question: --- <del> title: Control Plane </del> <ins> title: Ambiente de gerenciamento </ins> id: control-plane date: 2020-04-19 full_link:

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: is giving 404 Proposed Solution: if doesn't have the pt version Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign


Question: The name of each app and init container in a Pod must be unique; a validation error is thrown for any container sharing a name with another. <del> #### API for sidecar containers {{< feature-state for_k8s_version="v1.28" state="alpha" >}} Starting with Kubernetes 1.28 in alpha, a feature gate named `SidecarContainers` allows you to specify a `restartPolicy` for init containers which is independent of the Pod and other init containers. Container [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe) can also be added to control their lifecycle. If an init container is created with its `restartPolicy` set to `Always`, it will start and remain running during the entire life of the Pod, which is useful for running supporting services separated from the main application containers. If a `readinessProbe` is specified for this init container, its result will be used to determine the `ready` state of the Pod. Since these containers are defined as init containers, they benefit from the same ordering and sequential guarantees as other init containers, allowing them to be mixed with other init containers into complex Pod initialization flows. Compared to regular init containers, sidecar-style init containers continue to run and the next init container can begin starting once the kubelet has set the `started` container status for the sidecar-style init container to true. That status either becomes true because there is a process running in the container and no startup probe defined, or as a result of its `startupProbe` succeeding. This feature can be used to implement the sidecar container pattern in a more robust way, as the kubelet always restarts a sidecar container if it fails. Here's an example of a Deployment with two containers, one of which is a sidecar: {{% code_sample language="yaml" file="application/deployment-sidecar.yaml" %}} This feature is also useful for running Jobs with sidecars, as the sidecar container will not prevent the Job from completing after the main container has finished. Here's an example of a Job with two containers, one of which is a sidecar: {{% code_sample language="yaml" file="application/job/job-sidecar.yaml" %}} #### Resource sharing within containers </del> <ins> ### Resource sharing within containers </ins> <del> Given the ordering and execution for init containers, the following rules </del> <ins> Given the order of execution for init, sidecar and app containers, the following rules </ins> for resource usage apply: * The highest of any particular resource request or limit defined on all init


Question: is an [Istio](https://istio.io/) based ingress controller. * The [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme) is an ingress controller driving [Kong Gateway](https://konghq.com/kong/). <del> * The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller) </del> <ins> * The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/) </ins> works with the [NGINX](https://www.nginx.com/resources/glossary/nginx/) webserver (as a proxy). * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy. * The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an

"The works with the NGINX webserver (as a proxy)." The URL given against the text "NGINX Ingress Controller for Kubernetes" is not working. It returned 404 error(Page not found) in my case.
/triage accepted /kind cleanup


Question: The Kubernetes project recommends that you use the TokenReview API, because this method invalidates tokens that are bound to API objects such as Secrets, ServiceAccounts, and Pods when those objects are deleted. For example, if you <del> delete the Pod that contains a projected ServiceAccount token, the TokenReview API invalidates that token immediately. If you use OIDC validation instead, your clients continue to treat the token as valid until the token reaches its expiration timestamp. </del> <ins> delete the Pod that contains a projected ServiceAccount token, the cluster invalidates that token immediately and a TokenReview immediately fails. If you use OIDC validation instead, your clients continue to treat the token as valid until the token reaches its expiration timestamp. </ins> Your application should always define the audience that it accepts, and should check that the token's audiences match the audiences that the application expects. This helps to minimize the scope of the token so that it can only be <del> used in your appplication and nowhere else. </del> <ins> used in your application and nowhere else. </ins> ## Alternatives

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.


Question: ```shell sudo systemctl daemon-reload <del> sudo systemctl enable crio --no </del> <ins> sudo systemctl enable crio --now </ins> ``` <!--

! w sudo systemctl enable crio --now
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This 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: Typo in zh/docs/setup/production-environment/container-runtimes Proposed Solution: -Page to Update: zh: (en: ) <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/retitle [zh] Typo in docs/setup/production-environment/container-runtimes /kind bug /language zh
Page is a little bit lagging behind. Will fix. /assign


Question: ### Preparing the hosts <ins> #### Component installation </ins> Install a {{< glossary_tooltip term_id="container-runtime" text="container runtime" >}} and kubeadm on all the hosts. For detailed instructions and other prerequisites, see [Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).

I have a catastrophic problem with my production control-plane just because I naive believe in the instruction of the output of . My control-plane was gone and I couldn't recover from the failure because could not restart. After some tests, I found that need to be so that it tell the to use the correct internal IP that allow both new control plane and the current plane to talk to each other. Specifically, those IPs should allow etcd to communicate throw both servers. Without the default IP interface was used, but the firewall that I set on the default IP did not allow etcd to connect through. At this point, I would like to make a change to the document in a way that it emphasize the importance of in the command.
/language en /sig docs /kind feature
Page reported in issue: /sig cluster-lifecycle
/retitle Highlight the significance of in kubeadm join for HA cluster setup
all k8s components work like that. not only kubeadm. if you want custom IP from a different interface you need to pass it to the advertise address flag, but also as --node-ip to the kubelet. overall this setup with private IPs is not recommended and is difficult to manage. instead you should make the setup so that the public IP is the default route. then firewall the cluster properly. PRs for the above "create cluster" page with a note fix are welcome. the note can talk about "init" and "join", public IPs and firewall. /help /sig network
/triage accepted
actually, let me try to send the note. /remove-help
/assign


Question: {{% /tab %}} {{< /tabs >}} <del> #### systemd {#containerd-systemd} </del> <ins> #### Using the `systemd` cgroup driver {#containerd-systemd} </ins> To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set

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 The documentation for container runtimes at: needs to have a clear warning that by adding the suggested change in , this will actually PREVENT from successfully initializing a cluster (this is my experience multiple times with K8s 1.20.4 on Ubuntu 20.04 with containerd - not Docker). Why is this needed The current wording does not indicate that the suggested change for containerd's will actually break things. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --It is not clear even why that suggestion is there given that it stops from working.
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
The current text reads: How would you reword this How about: When using kubeadm, you must manually configure the cgroup driver for kubelet. /language en /priority awaiting-more-evidence /sig cluster-lifecycle
Thank you for all the work that you do, related to Kubernetes and all other open source projects you contribute to. Your efforts are really appreciated. My own experience is that the configuration snippet there is actually harmful in the scope of using kubeadm. I realize now that the page is discussing how to use containerd with the systemd cgroup driver in general... but the typical person coming to the "" documentation is there to learn how to use containerd in the context of kubernetes. That makes that configuration snippet a bit out of place since it will actually prevent the usage of kubeadm. For this reason, I believe it is better to be crystal clear and explicitly mention all of that. "To use the systemd cgroup driver... [plugins... ... SystemdCgroup = true However, when using kubeadm to initialize the cluster, the above configuration should NOT be done (it will actually prevent kubelet from bringing up static pods).


Question: {{% /tab %}} {{< /tabs >}} <del> #### systemd {#containerd-systemd} </del> <ins> #### Using the `systemd` cgroup driver {#containerd-systemd} </ins> To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set

Instead, manually configure the cgroup driver for kubelet."
i don't see anything invalid on the page, but ideas for clarification are welcome. When systemd is chosen as the init system for a Linux distribution, the init process generates and consumes a root control group (cgroup) and acts as a cgroup manager ... ^ the above already explains when the systemd driver is needed. it is the opposite. if you are using kubeadm, you must configure containerd with . and then pass the same driver to the kubelet as explained here: cgroup drivers have been confusing users for a long time and this is really a problem in the CRI spec. there is a plan to automatically handle them but this might take a while to complete.
this area of the docs is seeing some refactor, so you can add comments here too:
This is the source of our difference:. I have tried that setting multiple times (at least 4 times). It does NOT work for me on Ubuntu 20.04. When I do NOT specify that setting in containerd's , then and ONLY THEN does it work... for me.
i just tried following our documentation for installing containerd / installing kubeadm / creating kubeadm cluster. everything works fine for me: also a number of different CI setups are running kubeadm like so, you must be failing something in your setup. i doubt this is a containerd / OS bug of sorts, but it could be. /kind support
did you restart containerd after you : the step here should be after the driver is changed, so that's a documentation problem:
opened PR for this: (it also closes this issue)


Question: ```shell kubectl apply -f myapp.yaml ``` <ins> 実行結果は下記のようになります。 </ins> ``` pod/myapp-pod created ```

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/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


Question: A `csi` volume can be used in a Pod in three different ways: * through a reference to a [PersistentVolumeClaim](#persistentvolumeclaim) <del> * with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) * with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) </del> <ins> * with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes) * with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes) </ins> if the driver supports that (beta feature) The following fields are available to storage administrators to configure a CSI

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: Links to some ephemeral volume types are wrong. Proposed Solution: In , update links as follows: → → Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: <del> --- title: Podの優先度とプリエンプション content_type: concept weight: 70 --- <!-- overview --> {{< feature-state for_k8s_version="v1.14" state="stable" >}} [Pod](/ja/docs/concepts/workloads/pods/)は _priority_（優先度）を持つことができます。 優先度は他のPodに対する相対的なPodの重要度を示します。 もしPodをスケジューリングできないときには、スケジューラーはそのPodをスケジューリングできるようにするため、優先度の低いPodをプリエンプトする（追い出す）ことを試みます。 <!-- body --> {{< warning >}} クラスターの全てのユーザーが信用されていない場合、悪意のあるユーザーが可能な範囲で最も高い優先度のPodを作成することが可能です。これは他のPodが追い出されたりスケジューリングできない状態を招きます。 管理者はResourceQuotaを使用して、ユーザーがPodを高い優先度で作成することを防ぐことができます。 詳細は[デフォルトで優先度クラスの消費を制限する](/ja/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) を参照してください。 {{< /warning >}} ## 優先度とプリエンプションを使う方法 優先度とプリエンプションを使うには、 1.  1つまたは複数の[PriorityClass](#priorityclass)を追加します 1.  追加したPriorityClassを[`priorityClassName`](#pod-priority)に設定したPodを作成します。 もちろんPodを直接作る必要はありません。 一般的には`priorityClassName`をDeploymentのようなコレクションオブジェクトのPodテンプレートに追加します。 これらの手順のより詳しい情報については、この先を読み進めてください。 {{< note >}} Kubernetesには最初から既に2つのPriorityClassが設定された状態になっています。 `system-cluster-critical`と`system-node-critical`です。 これらは汎用のクラスであり、[重要なコンポーネントが常に最初にスケジュールされることを保証する](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)ために使われます。 {{< /note >}} ## PriorityClass PriorityClassはnamespaceによらないオブジェクトで、優先度クラスの名称から優先度を表す整数値への対応を定義します。 PriorityClassオブジェクトのメタデータの`name`フィールドにて名称を指定します。 値は`value`フィールドで指定し、必須です。 値が大きいほど、高い優先度を示します。 PriorityClassオブジェクトの名称は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)として適切であり、かつ`system-`から始まってはいけません。 PriorityClassオブジェクトは10億以下の任意の32ビットの整数値を持つことができます。 それよりも大きな値は通常はプリエンプトや追い出すべきではない重要なシステム用のPodのために予約されています。 クラスターの管理者は割り当てたい優先度に対して、PriorityClassオブジェクトを1つずつ作成すべきです。 PriorityClassは任意でフィールド`globalDefault`と`description`を設定可能です。 `globalDefault`フィールドは`priorityClassName`が指定されないPodはこのPriorityClassを使うべきであることを示します。`globalDefault`がtrueに設定されたPriorityClassはシステムで一つのみ存在可能です。`globalDefault`が設定されたPriorityClassが存在しない場合は、`priorityClassName`が設定されていないPodの優先度は0に設定されます。 `description`フィールドは任意の文字列です。クラスターの利用者に対して、PriorityClassをどのような時に使うべきか示すことを意図しています。 ### PodPriorityと既存のクラスターに関する注意 -   もし既存のクラスターをこの機能がない状態でアップグレードすると、既存のPodの優先度は実質的に0になります。 -   `globalDefault`が`true`に設定されたPriorityClassを追加しても、既存のPodの優先度は変わりません。PriorityClassのそのような値は、PriorityClassが追加された以後に作成されたPodのみに適用されます。 -   PriorityClassを削除した場合、削除されたPriorityClassの名前を使用する既存のPodは変更されませんが、削除されたPriorityClassの名前を使うPodをそれ以上作成することはできなくなります。 ### PriorityClassの例 ```yaml apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000 globalDefault: false description: "この優先度クラスはXYZサービスのPodに対してのみ使用すべきです。" ``` ## 非プリエンプトのPriorityClass {#non-preempting-priority-class} {{< feature-state for_k8s_version="v1.19" state="beta" >}} `PreemptionPolicy: Never`と設定されたPodは、スケジューリングのキューにおいて他の優先度の低いPodよりも優先されますが、他のPodをプリエンプトすることはありません。 スケジューリングされるのを待つ非プリエンプトのPodは、リソースが十分に利用可能になるまでスケジューリングキューに残ります。 非プリエンプトのPodは、他のPodと同様に、スケジューラーのバックオフの対象になります。これは、スケジューラーがPodをスケジューリングしようと試みたものの失敗した場合、低い頻度で再試行するようにして、より優先度の低いPodが先にスケジューリングされることを許します。 非プリエンプトのPodは、他の優先度の高いPodにプリエンプトされる可能性はあります。 `PreemptionPolicy`はデフォルトでは`PreemptLowerPriority`に設定されており、これが設定されているPodは優先度の低いPodをプリエンプトすることを許容します。これは既存のデフォルトの挙動です。 `PreemptionPolicy`を`Never`に設定すると、これが設定されたPodはプリエンプトを行わないようになります。 ユースケースの例として、データサイエンスの処理を挙げます。 ユーザーは他の処理よりも優先度を高くしたいジョブを追加できますが、そのとき既存の実行中のPodの処理結果をプリエンプトによって破棄させたくはありません。 `PreemptionPolicy: Never`が設定された優先度の高いジョブは、他の既にキューイングされたPodよりも先に、クラスターのリソースが「自然に」開放されたときにスケジューリングされます。 ### 非プリエンプトのPriorityClassの例 ```yaml apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority-nonpreempting value: 1000000 preemptionPolicy: Never globalDefault: false description: "この優先度クラスは他のPodをプリエンプトさせません。" ``` ## Podの優先度 {#pod-priority} 一つ以上のPriorityClassがあれば、仕様にPriorityClassを指定したPodを作成することができるようになります。優先度のアドミッションコントローラーは`priorityClassName`フィールドを使用し、優先度の整数値を設定します。PriorityClassが見つからない場合、そのPodの作成は拒否されます。 下記のYAMLは上記の例で作成したPriorityClassを使用するPodの設定の例を示します。優先度のアドミッションコントローラーは仕様を確認し、このPodの優先度は1000000であると設定します。 ```yaml apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent priorityClassName: high-priority ``` ### スケジューリング順序におけるPodの優先度の効果 Podの優先度が有効な場合、スケジューラーは待機状態のPodをそれらの優先度順に並べ、スケジューリングキューにおいてより優先度の低いPodよりも前に来るようにします。その結果、その条件を満たしたときには優先度の高いPodは優先度の低いPodより早くスケジューリングされます。優先度の高いPodがスケジューリングできない場合は、スケジューラーは他の優先度の低いPodのスケジューリングも試みます。 ## プリエンプション Podが作成されると、スケジューリング待ちのキューに入り待機状態になります。スケジューラーはキューからPodを取り出し、ノードへのスケジューリングを試みます。Podに指定された条件を全て満たすノードが見つからない場合は、待機状態のPodのためにプリエンプションロジックが発動します。待機状態のPodをPと呼ぶことにしましょう。プリエンプションロジックはPよりも優先度の低いPodを一つ以上追い出せばPをスケジューリングできるようになるノードを探します。そのようなノードがあれば、優先度の低いPodはノードから追い出されます。Podが追い出された後に、Pはノードへスケジューリング可能になります。 ### ユーザーへ開示される情報 Pod PがノードNのPodをプリエンプトした場合、ノードNの名称がPのステータスの`nominatedNodeName`フィールドに設定されます。このフィールドはスケジューラーがPod Pのために予約しているリソースの追跡を助け、ユーザーにクラスターにおけるプリエンプトに関する情報を与えます。 Pod Pは必ずしも「指名したノード」へスケジューリングされないことに注意してください。Podがプリエンプトされると、そのPodは終了までの猶予期間を得ます。スケジューラーがPodの終了を待つ間に他のノードが利用可能になると、スケジューラーは他のノードをPod Pのスケジューリング先にします。この結果、Podの`nominatedNodeName`と`nodeName`は必ずしも一致しません。また、スケジューラーがノードNのPodをプリエンプトさせた後に、Pod Pよりも優先度の高いPodが来た場合、スケジューラーはノードNをその新しい優先度の高いPodへ与えます。このような場合は、スケジューラーはPod Pの`nominatedNodeName`を消去します。これによって、スケジューラーはPod Pが他のノードのPodをプリエンプトさせられるようにします。 ### プリエンプトの制限 #### プリエンプトされるPodの正常終了 Podがプリエンプトされると、[猶予期間](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)が与えられます。 Podは作業を完了し、終了するために十分な時間が与えられます。仮にそうでない場合、強制終了されます。この猶予期間によって、スケジューラーがPodをプリエンプトした時刻と、待機状態のPod Pがノード Nにスケジュール可能になるまでの時刻の間に間が開きます。この間、スケジューラーは他の待機状態のPodをスケジュールしようと試みます。プリエンプトされたPodが終了したら、スケジューラーは待ち行列にあるPodをスケジューリングしようと試みます。そのため、Podがプリエンプトされる時刻と、Pがスケジュールされた時刻には間が開くことが一般的です。この間を最小にするには、優先度の低いPodの猶予期間を0または小さい値にする方法があります。 #### PodDisruptionBudgetは対応するが、保証されない [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB)は、アプリケーションのオーナーが冗長化されたアプリケーションのPodが意図的に中断される数の上限を設定できるようにするものです。KubernetesはPodをプリエンプトする際にPDBに対応しますが、PDBはベストエフォートで考慮します。スケジューラーはプリエンプトさせたとしてもPDBに違反しないPodを探します。そのようなPodが見つからない場合でもプリエンプションは実行され、PDBに反しますが優先度の低いPodが追い出されます。 #### 優先度の低いPodにおけるPod間のアフィニティ 次の条件が真の場合のみ、ノードはプリエンプションの候補に入ります。 「待機状態のPodよりも優先度の低いPodをノードから全て追い出したら、待機状態のPodをノードへスケジュールできるか」 {{< note >}} プリエンプションは必ずしも優先度の低いPodを全て追い出しません。 優先度の低いPodを全て追い出さなくても待機状態のPodがスケジューリングできる場合、一部のPodのみ追い出されます。 このような場合であったとしても、上記の条件は真である必要があります。偽であれば、そのノードはプリエンプションの対象とはされません。 {{< /note >}} 待機状態のPodが、優先度の低いPodとの間でPod間のアフィニティを持つ場合、Pod間のアフィニティはそれらの優先度の低いPodがなければ満たされません。この場合、スケジューラーはノードのどのPodもプリエンプトしようとはせず、代わりに他のノードを探します。スケジューラーは適切なノードを探せる場合と探せない場合があります。この場合、待機状態のPodがスケジューリングされる保証はありません。 この問題に対して推奨される解決策は、優先度が同一または高いPodに対してのみPod間のアフィニティを作成することです。 #### 複数ノードに対するプリエンプション Pod PがノードNにスケジューリングできるよう、ノードNがプリエンプションの対象となったとします。 他のノードのPodがプリエンプトされた場合のみPが実行可能になることもあります。下記に例を示します。 *   Pod PをノードNに配置することを検討します。 *   Pod QはノードNと同じゾーンにある別のノードで実行中です。 *   Pod Pはゾーンに対するQへのアンチアフィニティを持ちます (`topologyKey: topology.kubernetes.io/zone`)。 *   Pod Pと、ゾーン内の他のPodに対しては他のアンチアフィニティはない状態です。 *   Pod PをノードNへスケジューリングするには、Pod Qをプリエンプトすることが考えられますが、スケジューラーは複数ノードにわたるプリエンプションは行いません。そのため、Pod PはノードNへはスケジューリングできないとみなされます。 Pod Qがそのノードから追い出されると、Podアンチアフィニティに違反しなくなるので、Pod PはノードNへスケジューリング可能になります。 複数ノードに対するプリエンプションに関しては、十分な需要があり、合理的な性能を持つアルゴリズムを見つけられた場合に、追加することを検討する可能性があります。 ## トラブルシューティング Podの優先度とプリエンプションは望まない副作用をもたらす可能性があります。 いくつかの起こりうる問題と、その対策について示します。 ### Podが不必要にプリエンプトされる プリエンプションは、リソースが不足している場合に優先度の高い待機状態のPodのためにクラスターの既存のPodを追い出します。 誤って高い優先度をPodに割り当てると、意図しない高い優先度のPodはクラスター内でプリエンプションを引き起こす可能性があります。Podの優先度はPodの仕様の`priorityClassName`フィールドにて指定されます。優先度を示す整数値へと変換された後、`podSpec`の`priority`へ設定されます。 この問題に対処するには、Podの`priorityClassName`をより低い優先度に変更するか、このフィールドを未設定にすることができます。`priorityClassName`が未設定の場合、デフォルトでは優先度は0とされます。 Podがプリエンプトされたとき、プリエンプトされたPodのイベントが記録されます。 プリエンプションはPodに必要なリソースがクラスターにない場合のみ起こるべきです。 このような場合、プリエンプションはプリエンプトされるPodよりも待機状態のPodの優先度が高い場合のみ発生します。 プリエンプションは待機状態のPodがない場合や待機状態のPodがプリエンプト対象のPod以下の優先度を持つ場合には決して発生しません。そのような状況でプリエンプションが発生した場合、問題を報告してください。 ### Podはプリエンプトされたが、プリエンプトさせたPodがスケジューリングされない Podがプリエンプトされると、それらのPodが要求した猶予期間が与えられます。そのデフォルトは30秒です。 Podがその期間内に終了しない場合、強制終了されます。プリエンプトされたPodがなくなれば、プリエンプトさせたPodはスケジューリング可能です。 プリエンプトさせたPodがプリエンプトされたPodの終了を待っている間に、より優先度の高いPodが同じノードに対して作成されることもあります。この場合、スケジューラーはプリエンプトさせたPodの代わりに優先度の高いPodをスケジューリングします。 これは予期された挙動です。優先度の高いPodは優先度の低いPodに取って代わります。 ### 優先度の高いPodが優先度の低いPodより先にプリエンプトされる スケジューラーは待機状態のPodが実行可能なノードを探します。ノードが見つからない場合、スケジューラーは任意のノードから優先度の低いPodを追い出し、待機状態のPodのためのリソースを確保しようとします。 仮に優先度の低いPodが動いているノードが待機状態のPodを動かすために適切ではない場合、スケジューラーは他のノードで動いているPodと比べると、優先度の高いPodが動いているノードをプリエンプションの対象に選ぶことがあります。この場合もプリエンプトされるPodはプリエンプトを起こしたPodよりも優先度が低い必要があります。 複数のノードがプリエンプションの対象にできる場合、スケジューラーは優先度が最も低いPodのあるノードを選ぼうとします。しかし、そのようなPodがPodDisruptionBudgetを持っており、プリエンプトするとPDBに反する場合はスケジューラーは優先度の高いPodのあるノードを選ぶこともあります。 複数のノードがプリエンプションの対象として利用可能で、上記の状況に当てはまらない場合、スケジューラーは優先度の最も低いノードを選択します。 ## Podの優先度とQoSの相互作用 {#interactions-of-pod-priority-and-qos} Podの優先度と{{< glossary_tooltip text="QoSクラス" term_id="qos-class" >}}は直交する機能で、わずかに相互作用がありますが、デフォルトではQoSクラスによる優先度の設定の制約はありません。スケジューラーのプリエンプションのロジックはプリエンプションの対象を決めるときにQoSクラスは考慮しません。 プリエンプションはPodの優先度を考慮し、優先度が最も低いものを候補とします。より優先度の高いPodは優先度の低いPodを追い出すだけではプリエンプトを起こしたPodのスケジューリングに不十分な場合と、`PodDisruptionBudget`により優先度の低いPodが保護されている場合のみ対象になります。 QoSとPodの優先度の両方を考慮するコンポーネントは[リソース不足によりkubeletがPodを追い出す](/docs/tasks/administer-cluster/out-of-resource/)のみです。 kubeletは追い出すPodの順位付けを次の順で行います。枯渇したリソースを要求以上に使用しているか、優先度、枯渇したリソースの消費量の複数のPodの要求に対する相対値。 詳細は[エンドユーザーのPodの追い出し](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)を参照してください。 kubeletによるリソース不足時のPodの追い出しでは、リソースの消費が要求を超えないPodは追い出されません。優先度の低いPodのリソースの利用量がその要求を超えていなければ、追い出されることはありません。より優先度が高く、要求を超えてリソースを使用しているPodが追い出されます。 ## {{% heading "whatsnext" %}} * PriorityClassと関連付けてResourceQuotaを使用することに関して [デフォルトで優先度クラスの消費を制限する](/ja/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) </del>

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


Question: Talking to the control-plane node with the appropriate credentials, run: ```bash <del> kubectl drain <node name> --delete-local-data --force --ignore-daemonsets </del> <ins> kubectl drain <node name> --delete-emptydir-data --force --ignore-daemonsets </ins> ``` Before removing the node, reset the state installed by `kubeadm`:

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: Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data. I don’t know if it’s a good time to update this flag . If so, I can help update it. Proposed Solution: Update to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/sig cluster-lifecycle
cc
i see the discussion / PR here: using in the kubeadm docs makes sense. /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data. I don’t know if it’s a good time to update this flag . If so, I can help update it. /help </details
/assign


Question: <ins> --- title: Node Shutdowns content_type: concept weight: 10 --- <!-- overview --> In a Kubernetes cluster, a {{< glossary_tooltip text="node" term_id="node" >}} can be shutdown in a planned graceful way or unexpectedly because of reasons such as a power outage or something else external. A node shutdown could lead to workload failure if the node is not drained before the shutdown. A node shutdown can be either **graceful** or **non-graceful**. <!-- body --> ## Graceful node shutdown {#graceful-node-shutdown} {{< feature-state feature_gate_name="GracefulNodeShutdown" >}} The kubelet attempts to detect 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. During node shutdown, the kubelet does not accept new Pods (even if those Pods are already bound to the node). The Graceful node shutdown feature depends on systemd since it takes advantage of [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration. Graceful node shutdown is controlled with the `GracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) which is enabled by default in 1.21. Note that by default, both configuration options described below, `shutdownGracePeriod` and `shutdownGracePeriodCriticalPods` are set to zero, thus not activating the graceful node shutdown functionality. To activate the feature, the two kubelet config settings should be configured appropriately and set to non-zero values. Once systemd detects or notifies node shutdown, the kubelet sets a `NotReady` condition on the Node, with the `reason` set to `"node is shutting down"`. The kube-scheduler honors this condition and does not schedule any Pods onto the affected node; other third-party schedulers are expected to follow the same logic. This means that new Pods won't be scheduled onto that node and therefore none will start. The kubelet **also** rejects Pods during the `PodAdmission` phase if an ongoing node shutdown has been detected, so that even Pods with a {{< glossary_tooltip text="toleration" term_id="toleration" >}} for `node.kubernetes.io/not-ready:NoSchedule` do not start there. At the same time when kubelet is setting that condition on its Node via the API, the kubelet also begins terminating any Pods that are running locally. During a graceful shutdown, kubelet terminates pods in two phases: 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. 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 value should be less than `shutdownGracePeriod`. {{< note >}} There are cases when Node termination was cancelled by the system (or perhaps manually by an administrator). In either of those situations the Node will return to the `Ready` state. However, Pods which already started the process of termination will not be restored by kubelet and will need to be re-scheduled. {{< /note >}} 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). {{< note >}} When pods were evicted during the graceful node shutdown, they are marked as shutdown. Running `kubectl get pods` shows the status of the evicted pods as `Terminated`. And `kubectl describe pod` indicates that the pod was evicted because of node shutdown: ``` Reason:         Terminated Message:        Pod was terminated in response to imminent node shutdown. ``` {{< /note >}} ### Pod Priority based graceful node shutdown {#pod-priority-graceful-node-shutdown} {{< feature-state feature_gate_name="GracefulNodeShutdownBasedOnPodPriority" >}} To provide more flexibility during graceful node shutdown around the ordering of pods during shutdown, graceful node shutdown honors the PriorityClass for Pods, provided that you enabled this feature in your cluster. The feature allows cluster administers to explicitly define the ordering of pods during graceful node shutdown based on [priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass). The [Graceful Node Shutdown](#graceful-node-shutdown) feature, as described above, shuts down pods in two phases, non-critical pods, followed by critical pods. If additional flexibility is needed to explicitly define the ordering of pods during shutdown in a more granular way, pod priority based graceful shutdown can be used. When graceful node shutdown honors pod priorities, this makes it possible to do graceful node shutdown in multiple phases, each phase shutting down a particular priority class of pods. The kubelet can be configured with the exact phases and shutdown time per phase. Assuming the following custom pod [priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass) in a cluster, |Pod priority class name|Pod priority class value| |-------------------------|------------------------| |`custom-class-a`         | 100000                 | |`custom-class-b`         | 10000                  | |`custom-class-c`         | 1000                   | |`regular/unset`          | 0                      | Within the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) the settings for `shutdownGracePeriodByPodPriority` could look like: |Pod priority class value|Shutdown period| |------------------------|---------------| | 100000                 |10 seconds     | | 10000                  |180 seconds    | | 1000                   |120 seconds    | | 0                      |60 seconds     | The corresponding kubelet config YAML configuration would be: ```yaml shutdownGracePeriodByPodPriority: - priority: 100000 shutdownGracePeriodSeconds: 10 - priority: 10000 shutdownGracePeriodSeconds: 180 - priority: 1000 shutdownGracePeriodSeconds: 120 - priority: 0 shutdownGracePeriodSeconds: 60 ``` The above table implies that any pod with `priority` value >= 100000 will get just 10 seconds to stop, any pod with value >= 10000 and < 100000 will get 180 seconds to stop, any pod with value >= 1000 and < 10000 will get 120 seconds to stop. Finally, all other pods will get 60 seconds to stop. One doesn't have to specify values corresponding to all of the classes. For example, you could instead use these settings: |Pod priority class value|Shutdown period| |------------------------|---------------| | 100000                 |300 seconds    | | 1000                   |120 seconds    | | 0                      |60 seconds     | In the above case, the pods with `custom-class-b` will go into the same bucket as `custom-class-c` for shutdown. If there are no pods in a particular range, then the kubelet does not wait for pods in that priority range. Instead, the kubelet immediately skips to the next priority class value range. If this feature is enabled and no configuration is provided, then no ordering action will be taken. Using this feature requires enabling the `GracefulNodeShutdownBasedOnPodPriority` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), and setting `ShutdownGracePeriodByPodPriority` in the [kubelet config](/docs/reference/config-api/kubelet-config.v1beta1/) to the desired configuration containing the pod priority class values and their respective shutdown periods. {{< note >}} The ability to take Pod priority into account during graceful node shutdown was introduced as an Alpha feature in Kubernetes v1.23. In Kubernetes {{< skew currentVersion >}} the feature is Beta and is enabled by default. {{< /note >}} Metrics `graceful_shutdown_start_time_seconds` and `graceful_shutdown_end_time_seconds` are emitted under the kubelet subsystem to monitor node shutdowns. ## Non-graceful node shutdown handling {#non-graceful-node-shutdown} {{< feature-state feature_gate_name="NodeOutOfServiceVolumeDetach" >}} A node shutdown action may not be detected by kubelet's Node Shutdown Manager, either because the command does not trigger the inhibitor locks mechanism used by kubelet or because of a user error, i.e., the ShutdownGracePeriod and ShutdownGracePeriodCriticalPods are not configured properly. Please refer to above section [Graceful Node Shutdown](#graceful-node-shutdown) for more details. When a node is shutdown but not detected by kubelet's Node Shutdown Manager, the pods that are part of a {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} will be stuck in terminating status on the shutdown node and cannot move to a new running node. This is because kubelet on the shutdown node is not available to delete the pods so the StatefulSet cannot create a new pod with the same name. If there are volumes used by the pods, the VolumeAttachments will not be deleted from the original shutdown node so the volumes used by these pods cannot be attached to a new running node. As a result, the application running on the StatefulSet cannot function properly. If the original shutdown node comes up, the pods will be deleted by kubelet and new pods will be created on a different running node. If the original shutdown node does not come up, these pods will be stuck in terminating status on the shutdown node forever. To mitigate the above situation, a user can manually add the taint `node.kubernetes.io/out-of-service` with either `NoExecute` or `NoSchedule` effect to a Node marking it out-of-service. If the `NodeOutOfServiceVolumeDetach`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled on {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}, and a Node is marked out-of-service with this taint, the pods on the node will be forcefully deleted if there are no matching tolerations on it and volume detach operations for the pods terminating on the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly on a different node. During a non-graceful shutdown, Pods are terminated in the two phases: 1. Force delete the Pods that do not have matching `out-of-service` tolerations. 2. Immediately perform detach volume operation for such pods. {{< note >}} - Before adding the taint `node.kubernetes.io/out-of-service`, it should be verified that the node is already in shutdown or power off state (not in the middle of restarting). - The user is required to manually remove the out-of-service taint after the pods are moved to a new node and the user has checked that the shutdown node has been recovered since the user was the one who originally added the taint. {{< /note >}} ### Forced storage detach on timeout {#storage-force-detach-on-timeout} In any situation where a pod deletion has not succeeded for 6 minutes, kubernetes will force detach volumes being unmounted if the node is unhealthy at that instant. Any workload still running on the node that uses a force-detached volume will cause a violation of the [CSI specification](https://github.com/container-storage-interface/spec/blob/master/spec.md#controllerunpublishvolume), which states that `ControllerUnpublishVolume` "**must** be called after all `NodeUnstageVolume` and `NodeUnpublishVolume` on the volume are called and succeed". In such circumstances, volumes on the node in question might encounter data corruption. The forced storage detach behaviour is optional; users might opt to use the "Non-graceful node shutdown" feature instead. Force storage detach on timeout can be disabled by setting the `disable-force-detach-on-timeout` config field in `kube-controller-manager`. Disabling the force detach on timeout feature means that a volume that is hosted on a node that is unhealthy for more than 6 minutes will not have its associated [VolumeAttachment](/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1/) deleted. After this setting has been applied, unhealthy pods still attached to a volumes must be recovered via the [Non-Graceful Node Shutdown](#non-graceful-node-shutdown) procedure mentioned above. {{< note >}} - Caution must be taken while using the [Non-Graceful Node Shutdown](#non-graceful-node-shutdown) procedure. - Deviation from the steps documented above can result in data corruption. {{< /note >}} ## {{% heading "whatsnext" %}} Learn more about the following: * Blog: [Non-Graceful Node Shutdown](/blog/2023/08/16/kubernetes-1-28-non-graceful-node-shutdown-ga/). * Cluster Architecture: [Nodes](/docs/concepts/architecture/nodes/). </ins>

Since is a page better suited for those learning Kubernetes, the , and forced storage detach on timeout section is better suited to be on the See comment thread:
/language en /sig docs
do you feel like there is any restructuring of content that needs to happen with this move? Or is it a request to straight move those sections from one page to another?
/triage accepted I think a straightforward move is the right change to prioritize. Extra help is welcome but not at the expense of delivering the fix later.
/priority important-longterm see
/assign
see if this PR does what you're looking for. Thanks