Question: - If there are pods in one of these states _right after_ `kubeadm init`, please open an issue in the kubeadm repo. `coredns` (or `kube-dns`) should be in the `Pending` state <del> until you have deployed the network solution. </del> <ins> until you have deployed the network add-on. </ins> - If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state <del> after deploying the network solution and nothing happens to `coredns` (or `kube-dns`), it's very likely that the Pod Network solution that you installed is somehow broken. </del> <ins> after deploying the network add-on and nothing happens to `coredns` (or `kube-dns`), it's very likely that the Pod Network add-on that you installed is somehow broken. </ins> You might have to grant it more RBAC privileges or use a newer version. Please file an issue in the Pod Network providers' issue tracker and get the issue triaged there. - If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: There are words should be unified in and . For the sake of clarity, the same words should be used for things that have the same meaning. Proposed Solution: We should use either the terms "network solution" or "network add-on". Page to Update: Troubleshooting kubeadm: Installing Addons: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
modifying the kubeadm troubleshooting page to use "addon" instead of "solution" seems fine to me. PRs welcome! /help /sig cluster-lifecycle /kind cleanup /priority backlog
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 : modifying the kubeadm troubleshooting page to use "addon" instead of "solution" seems fine to me. PRs welcome! /sig cluster-lifecycle /kind cleanup /priority backlog </details
/assign
/assign


Question: [languages.de] title = "Kubernetes" description = "Produktionsreife Container-Verwaltung" <del> languageName = "Deutsch" </del> <ins> languageName = "Deutsch (German)" languageNameLatinScript = "German" </ins> contentDir = "content/de" <del> weight = 3 </del> <ins> weight = 8 </ins> ``` <ins> The value for `languageName` will be listed in language selection bar. Assign "language name in native script (language name in latin script)" to `languageName`, for example, `languageName = "한국어 (Korean)"`. `languageNameLatinScript` can be used to access the language name in latin script and use it in the theme. Assign "language name in latin script" to `languageNameLatinScript`, for example, `languageNameLatinScript ="Korean"`. </ins> When assigning a `weight` parameter for your block, find the language block with the highest weight and add 1 to that value. For more information about Hugo's multilingual support, see "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)".

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 updated Update languageName in to use both native and English alphabets (letter) for each language (except English). [ ] modify the localization guide document. (to mention a new recommended best practice for in each language block. in : using both their own alphabets and English alphabets (ex: ) if it is applicable. I'd like to suggest a format for consistency: languageName = " (Chinese)" languageName = " (Korean)" languageName ="Français (French)" languageName = "हिन्दी (Hindi)" ... Why is this needed The block for in configures multiple languages to the site. And parameter in each language block is used to show language menu on the website. ! Some languages (Chinese, Korean and Japanese) are using both their own alphabets and English alphabets in languageName (ex: ), but the others are using own alphabet only. This inconsistency issue was discussed in Kube SIG Docs localization meeting Monday 2/7, 2022. And we decided a new recommended best practice using both native alphabets and English (ex: " Korean") as it help folks who can't read native alphabet to know which language it is. Comments Related discussions: Kube SIG Docs localization meeting Monday 2/7:
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
PTAL :)
Let me open a PR to modify the localization guide document. :) /assign
Looks good to me. Thank you <3
/area localization
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area localization 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
Hmm, we should add that label!

My suggestion: two fields. plus an optional second one . That will let us retain access to the actual localized if we need it.
thanks for writing this up I like Tim's suggestion of making this into 2 variables as well
/area localization
Thanks for the suggestion :) I hope to check your suggestion is about adding additional parameter () in the block for of For instance, If it is what you meant, I am not sure how works in Hugo. (I cannot find this parameter) Could you give me more context ?
I think would be a Kubernetes thing, not a Hugo thing. So long as Hugo lets us set it, we can then access that data in the theme and use it somewhere sensible.


Question: ``` deployment.apps/nginx-deployment resumed ``` <del> * Watch the status of the rollout until it's done. </del> <ins> * {{< glossary_tooltip text="Watch" term_id="watch" >}} the status of the rollout until it's done. </ins> ```shell <del> kubectl get rs -w </del> <ins> kubectl get rs --watch </ins> ``` The output is similar to this:

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update the to include an explanation of “watch”. Why is this needed The watch verb (and actually watchcollection as well) is K8s-specific jargon. We should help readers understand it. Comments Extra credit for also using the new term in existing pages, using a . /kind feature /wg api-expression
/assign
/priority backlog /triage accepted
Hi PR: for this issue. PTAL
I'm happy for any reviewer (for English) to take a look there.


Question: Bring the node back online by marking it schedulable: ```shell <ins> # execute this command on a control plane node </ins> # replace <node-to-uncordon> with the name of your node kubectl uncordon <node-to-uncordon> ```

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: This is related to the page . The and commands should be executed on the controlplane node. This is not obvious from the documentation. A new user unfamiliar with the process of upgrade will invariably execute these commands on the worker node and will fail. Proposed Solution: Add instruction to execute the and commands from the controlplane node. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
/sig docs /language en
/sig cluster-lifecycle /triage accepted


Question: peerCertSANs: - "${HOST}" extraArgs: <del> initial-cluster: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380 initial-cluster-state: new name: ${NAME} listen-peer-urls: https://${HOST}:2380 listen-client-urls: https://${HOST}:2379 advertise-client-urls: https://${HOST}:2379 initial-advertise-peer-urls: https://${HOST}:2380 </del> <ins> - name: initial-cluster value: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380 - name: initial-cluster-state value: new - name: name value: ${NAME} - name: listen-peer-urls value: https://${HOST}:2380 - name: listen-client-urls value: https://${HOST}:2379 - name: advertise-client-urls value: https://${HOST}:2379 - name: initial-advertise-peer-urls value: https://${HOST}:2380 </ins> EOF done ```

The kubeadm config snippet uses the v1beta3 that is a , in this seems to be a .
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
Actually, that is how the API changed. See for source code, and for an example. /close
Closing this issue. <detailsIn response to : Actually, that is how the API changed. See for source code, and for an example. /close </details
Yes, the API has been updated and the docs need to be updated to reflect that. I apologize, my initial report was lazy. Let me try again. When using the configuration in to create a HA etcd cluster, it fails due to being unable to marshal into . This is because the API has been updated in v1beta4 and is no longer a . You'll notice in the sample, the is , however the structure of is still a map. This was correct for , but is no longer correct for . I've opened a PR to rectify this.
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
Got it. Let's reopen this issue and let it be fixed by your PR.


Question: You can specify scheduling profiles by running `kube-scheduler --config <filename>`, using the component config APIs <del> ([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration) or [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration)). The `v1alpha2` API allows you to configure kube-scheduler to run [multiple profiles](#multiple-profiles). </del> <ins> ([`v1beta1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.19.0/config/v1beta1?tab=doc#KubeSchedulerConfiguration)). </ins> A minimal configuration looks as follows:

I found the references to and v1alpha2 to be confusing since the configuration that follow were v1beta1. Perhaps it would make sense to remove the alpha1/2 references entirely? !


Question: Adding these tolerations ensures backward compatibility. You can also add arbitrary tolerations to DaemonSets. ## {{% heading "whatsnext" %}} * Read about [out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) and how you can configure it

Page to update: Blocked by Based on in PR , we should add the following information about node conditions to the Taint Nodes by Condition section of this page. The API server also respects when making scheduling decisions. For example, If the node condition is active, the system doesn't allow any new Pods to schedule on the node. If the node condition is active on a node, the system doesn't allow new pods on the node. What is "the system"? The API server? /cc /assign /sig docs /language en
"The system" is a mix of components: the kube-controller-manager sets the taints via the node controller. apiserver sets the toleration for DiskPressure for non-BestEffort pods. scheduler checks if pods have tolerations for the taint But that's too much implementation detail. "The system" or "the control plane" should be enough. WDYT ?
Ah, if it's the control plane then we can say that haha I thought it was something else :P
/triage accepted


Question: Kubernetes 1.20で[dockershim deprecation](blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)が発表されてから、様々なワークロードやKubernetesインストールにどう影響するのかという質問が寄せられています。 <del> この問題をよりよく理解するために、[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)ブログが役に立つでしょう。 </del> <ins> この問題をよりよく理解するために、[dockershimの削除に関するFAQ](/ja/dockershim)ブログが役に立つでしょう。 </ins> dockershimから代替のコンテナランタイムに移行することが推奨されます。 [コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)のセクションをチェックして、どのような選択肢があるかを確認してください。

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. --Add japanese translations of the contents listed below: {{% dockershim-removal %}} block Why is this needed Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --ref.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/language ja


Question: {{< tabs name="kubectl_retainkeys_example" >}} {{{< tab name="Bash" codelang="bash" >}} <del> kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-no-retainkeys.yaml)" </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-no-retainkeys.yaml)" </ins> {{< /tab >}} {{< tab name="PowerShell" codelang="posh" >}} <del> kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) </ins> {{< /tab >}}} {{< /tabs >}}

example commands are missing Resulting in: I will prepare a patch for this.
/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 : /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


Question: {{< tabs name="kubectl_retainkeys_example" >}} {{{< tab name="Bash" codelang="bash" >}} <del> kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-no-retainkeys.yaml)" </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-no-retainkeys.yaml)" </ins> {{< /tab >}} {{< tab name="PowerShell" codelang="posh" >}} <del> kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) </ins> {{< /tab >}}} {{< /tabs >}}

example commands are missing Resulting in: I will prepare a patch for this.
/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 : /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


Question: 個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。Podが作成されると、一意のID([UID](/ja/docs/concepts/overview/working-with-objects/names/#uids))が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。 {{< glossary_tooltip term_id="node" >}}が停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に[削除](#pod-garbage-collection)されます。 <del> Pod自体は、自己修復しません。Podが{{< glossary_tooltip text="node" term_id="node" >}}にスケジュールされ、その後に失敗、またはスケジュール操作自体が失敗した場合、Podは削除されます。同様に、リソースの不足またはNodeのメンテナンスによりPodはNodeから立ち退きます。Kubernetesは、比較的使い捨てのPodインスタンスの管理作業を処理する、{{< glossary_tooltip term_id="controller" text="controller" >}}と呼ばれる上位レベルの抽象化を使用します。 </del> <ins> Pod自体は、自己修復しません。Podが{{< glossary_tooltip text="node" term_id="node" >}}にスケジュールされ、その後に失敗した場合、Podは削除されます。同様に、リソースの不足またはNodeのメンテナンスによりPodはNodeから立ち退きます。Kubernetesは、比較的使い捨てのPodインスタンスの管理作業を処理する、{{< glossary_tooltip term_id="controller" text="controller" >}}と呼ばれる上位レベルの抽象化を使用します。 </ins> 特定のPod(UIDで定義)は新しいNodeに"再スケジュール"されません。代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます。 {{< glossary_tooltip term_id="volume" text="volume" >}}など、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。 <del> {{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}} </del> <ins> {{< figure src="/images/docs/pod.svg" title="Podの図" class="diagram-medium" >}} </ins> *file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用しています。*

This is a Feature Request What would you like to be We need to update content/ja/docs/concepts/workloads/pods/pod- according to the English text, because it is outdated. Why is this needed content/ja/docs/concepts/workloads/pods/pod- is outdated. For example, there is no description of PodHasNetwork(alpha feature). Comments /language ja /assign
/triage accepted


Question: {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} <del> Each node in your cluster must have at least 1 CPU. </del> <ins> Your cluster must have at least 1 CPU available for use to run the task examples. </ins> A few of the steps on this page require you to run the [metrics-server](https://github.com/kubernetes-incubator/metrics-server)

A couple of pages: state that Based on what I know about nodes, this seems like something you could take for granted. Consider ~dropping~ revising that text.
/kind cleanup /priority backlog
Just realized this is talking about Kubernetes' count of CPUs, rather than what (say) the Linux kernel would see. That might not be obvious to every reader—I missed it, for example.
/language en
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
/remove-lifecycle stale
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
/remove-lifecycle stale
/help
Happy to help with explanations for anyone who is picking this up.
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
/remove-lifecycle stale
/assign /remove-help
I was reviewing the docs and I think the statement is referring to the minimal requirements to execute the proposed tasks (and I think this is wrong, because some exercises goes up to 2 cores). Not sure if my understanding is the same as yours.
The “1 CPU” means 1.0 of Kubernetes CPU units. That's different from saying “there needs to be at least one physical CPU core available”. Readers new to Kubernetes might not grasp that Kubernetes has its own idea of CPU number and assume that a Node that runs the kubelet OK must have at least one installed core available to make code execution possible. For example: a node with 0.5 CPU doesn't meet the 1.0 CPU requirement.

If some exercises require more than 1.0 CPU then those pages should explain that. I think addressing that might be a different issue though.
Honestly, I still don't get it. I thought the Kubernetes CPU reflects what the operating system reports (ex.: ). I wasn't considering possible to have a Kubelet running on a node and reporting only 0.5 CPU (how do we do that? flags? cgroup via systemd?). Since the docs are not using term physical, I still think the original author was referring to minimum required resource for the task examples.
To be honest, I might have this wrong too. I do know that the existing text is not clear.
An example of an instance type with < 1.0 CPU:
Even those shared core instances will reports 1 vCPU, but I got your point. I'll try something here!


Question: <ins> --- layout: blog title: "Kubernetes 验证准入策略：一个真实示例" date: 2023-03-30T00:00:00+0000 slug: kubescape-validating-admission-policy-library --- <!-- layout: blog title: "Kubernetes Validating Admission Policies: A Practical Example" date: 2023-03-30T00:00:00+0000 slug: kubescape-validating-admission-policy-library --> <!-- **Authors**: Craig Box (ARMO), Ben Hirschberg (ARMO) --> **作者**：Craig Box (ARMO), Ben Hirschberg (ARMO) **译者**：Xiaoyang Zhang (Huawei) <!-- Admission control is an important part of the Kubernetes control plane, with several internal features depending on the ability to approve or change an API object as it is submitted to the server. It is also useful for an administrator to be able to define business logic, or policies, regarding what objects can be admitted into a cluster. To better support that use case, [Kubernetes introduced external admission control in v1.7](/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates/). --> 准入控制是 Kubernetes 控制平面的重要组成部分，在向服务器提交请求时，可根据批准或更改 API 对象的能力来实现多项内部功能。 对于管理员来说，定义有关哪些对象可以进入集群的业务逻辑或策略是很有用的。为了更好地支持该场景， [Kubernetes 在 v1.7 中引入了外部准入控制](/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates/)。 <!-- In addition to countless custom, internal implementations, many open source projects and commercial solutions implement admission controllers with user-specified policy, including [Kyverno](https://github.com/kyverno/kyverno) and Open Policy Agent’s [Gatekeeper](https://github.com/open-policy-agent/gatekeeper). --> 除了众多的自定义内部实现外，许多开源项目和商业解决方案还使用用户指定的策略实现准入控制器，包括 [Kyverno](https://github.com/kyverno/kyverno) 和 Open Policy Agent 的 [Gatekeep](https://github.com/open-policy-agent/gatekeeper)。 <!-- While admission controllers for policy have seen adoption, there are blockers for their widespread use. Webhook infrastructure must be maintained as a production service, with all that entails. The failure case of an admission control webhook must either be closed, reducing the availability of the cluster; or open, negating the use of the feature for policy enforcement. The network hop and evaluation time makes admission control a notable component of latency when dealing with, for example, pods being spun up to respond to a network request in a "serverless" environment. --> 虽然针对策略的准入控制器已经被人采用，但其广泛使用仍存在障碍。 Webhook 基础设施必须作为生产服务进行维护，且包含所有相关内容。 如果准入控制 Webhook 失败，则要么必须关闭，从而降低集群的可用性；要么打开，使该功能在策略执行中的使用失效。 例如，在 “serverless” 环境中，当 Pod 启动以响应网络请求时，网络跳跃和评估时间使准入控制成为处理延迟的重要组成部分。 <!-- ## Validating admission policies and the Common Expression Language Version 1.26 of Kubernetes introduced, in alpha, a compromise solution. [Validating admission policies](/docs/reference/access-authn-authz/validating-admission-policy/) are a declarative, in-process alternative to admission webhooks. They use the [Common Expression Language](https://github.com/google/cel-spec) (CEL) to declare validation rules. --> ## 验证准入策略和通用表达语言 {#validating-admission-policies-and-the-common-expression-language} Kubernetes 1.26 版本引入了一个折中的、Alpha 状态的解决方案。 [验证准入策略](/zh-cn/docs/reference/access-authn-authz/validating-admission-policy/)是一种声明式的、 进程内的方案，用来替代验证准入 Webhook。使用[通用表达语言](https://github.com/google/cel-spec) (Common Expression Language，CEL) 来声明策略的验证规则。 <!-- CEL was developed by Google for security and policy use cases, based on learnings from the Firebase real-time database. Its design allows it to be safely embedded into applications and executed in microseconds, with limited compute and memory impact. [Validation rules for CRDs](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules) introduced CEL to the Kubernetes ecosystem in v1.23, and at the time it was noted that the language would suit a more generic implementation of validation by admission control. --> CEL 是由 Google 根据 Firebase 实时数据库的经验，针对安全和策略用例而开发的。 它的设计使得它可以安全地嵌入到应用程序中，执行时间在微秒量级，对计算和内存的影响很小。 v1.23 版本中，[针对 CRD 的验证规则](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules)将 CEL 引入了 Kubernetes 生态系统，当时人们注意到该语言将适合实现通过准入控制进行更通用的验证。 <!-- ## Giving CEL a roll - a practical example [Kubescape](https://github.com/kubescape/kubescape) is a CNCF project which has become one of the most popular ways for users to improve the security posture of a Kubernetes cluster and validate its compliance. Its [controls](https://github.com/kubescape/regolibrary) — groups of tests against API objects — are built in [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/), the policy language of Open Policy Agent. --> ## 让 CEL 发挥作用——一个实际例子 {#giving-cel-a-roll-a-practical-example} [Kubescape](https://github.com/kubescape/kubescape) 是一个 CNCF 项目， 已成为用户改善 Kubernetes 集群安全状况并验证其合规性的最流行方法之一。 它的[控件](https://github.com/kubescape/regolibrary)——针对 API 对象的多组测试——是用 Open Policy Agent 的策略语言 [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) 构建的。 <!-- Rego has a reputation for complexity, based largely on the fact that it is a declarative query language (like SQL). It [was considered](https://github.com/kubernetes/enhancements/blob/499e28/keps/sig-api-machinery/2876-crd-validation-expression-language/README.md#alternatives) for use in Kubernetes, but it does not offer the same sandbox constraints as CEL. --> Rego 以复杂性著称，这主要是因为它是一种声明式查询语言（如 SQL）。 它[被考虑](https://github.com/kubernetes/enhancements/blob/499e28/keps/sig-api-machinery/2876-crd-validation-expression-language/README.md#alternatives)在 Kubernetes 中使用，但它没有提供与 CEL 相同的沙箱约束。 <!-- A common feature request for the project is to be able to implement policies based on Kubescape’s findings and output. For example, after scanning pods for [known paths to cloud credential files](https://hub.armosec.io/docs/c-0020), users would like the ability to enforce policy that these pods should not be admitted at all. The Kubescape team thought this would be the perfect opportunity to try and port our existing controls to CEL and apply them as admission policies. --> 该项目的一个常见功能要求是能够根据 Kubescape 的发现和输出来实现策略。例如，在扫描 Pod 是否存在[云凭据文件的已知路径](https://hub.armosec.io/docs/c-0020)后， 用户希望能够执行完全不允许这些 Pod 进入的策略。 Kubescape 团队认为这是一个绝佳的机会，可以尝试将现有的控制措施移植到 CEL，并将其应用为准入策略。 <!-- ### Show me the policy It did not take us long to convert many of our controls and build a [library of validating admission policies](https://github.com/kubescape/cel-admission-library). Let’s look at one as an example. --> ### 策略展示 {#show-me-the-policy} 我们很快就转换了许多控件并建立了一个验证准入策略的库。让我们看一个例子。 <!-- Kubescape’s [control C-0017](https://hub.armosec.io/docs/c-0017) covers the requirement for containers to have an immutable (read-only) root filesystem. This is a best practice according to the [NSA Kubernetes hardening guidelines](/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/#immutable-container-filesystems), but is not currently required as a part of any of the [pod security standards](/docs/concepts/security/pod-security-standards/). --> Kubescape 的 [control C-0017](https://hub.armosec.io/docs/c-0017) 涵盖了容器具有不可变（只读）根文件系统的要求。 根据 [NSA Kubernetes 强化指南](/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/#immutable-container-filesystems)， 这是最佳实践，但目前不要求将其作为任何 [Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)的一部分。 <!-- Here's how we implemented it in CEL: --> 以下是我们用 CEL 的实现方式： ```yaml apiVersion: admissionregistration.k8s.io/v1alpha1 kind: ValidatingAdmissionPolicy metadata: name: "kubescape-c-0017-deny-resources-with-mutable-container-filesystem" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups:   [""] apiVersions: ["v1"] operations:  ["CREATE", "UPDATE"] resources:   ["pods"] - apiGroups:   ["apps"] apiVersions: ["v1"] operations:  ["CREATE", "UPDATE"] resources:   ["deployments","replicasets","daemonsets","statefulsets"] - apiGroups:   ["batch"] apiVersions: ["v1"] operations:  ["CREATE", "UPDATE"] resources:   ["jobs","cronjobs"] validations: - expression: "object.kind != 'Pod' || object.spec.containers.all(container, has(container.securityContext) && has(container.securityContext.readOnlyRootFilesystem) &&  container.securityContext.readOnlyRootFilesystem == true)" message: "Pods having containers with mutable filesystem not allowed! (see more at https://hub.armosec.io/docs/c-0017)" - expression: "['Deployment','ReplicaSet','DaemonSet','StatefulSet','Job'].all(kind, object.kind != kind) || object.spec.template.spec.containers.all(container, has(container.securityContext) && has(container.securityContext.readOnlyRootFilesystem) &&  container.securityContext.readOnlyRootFilesystem == true)" message: "Workloads having containers with mutable filesystem not allowed! (see more at https://hub.armosec.io/docs/c-0017)" - expression: "object.kind != 'CronJob' || object.spec.jobTemplate.spec.template.spec.containers.all(container, has(container.securityContext) && has(container.securityContext.readOnlyRootFilesystem) &&  container.securityContext.readOnlyRootFilesystem == true)" message: "CronJob having containers with mutable filesystem not allowed! (see more at https://hub.armosec.io/docs/c-0017)" ``` <!-- Match constraints are provided for three possible API groups: the `core/v1` group for Pods, the `apps/v1` workload controllers, and the `batch/v1` job controllers. --> 此策略为三个可能的 API 组提供匹配约束：Pod 的 `core/v1` 组、负载控制器的 `apps/v1` 和作业控制器的 `batch/v1`。 {{< note >}} <!-- `matchConstraints` will convert the API object to the matched version for you. If, for example, an API request was for `apps/v1beta1` and you match `apps/v1` in matchConstraints, the API request will be converted from `apps/v1beta1` to `apps/v1` and then validated. This has the useful property of making validation rules secure against the introduction of new versions of APIs, which would otherwise allow API requests to sneak past the validation rule by using the newly introduced version. --> `matchConstraints` 会为你将 API 对象转换为匹配的版本。例如，如果 API 请求的对象是 `apps/v1beta1`， 而你在 matchConstraints 中要匹配 `apps/v1`，那么 API 请求就会从 `apps/v1beta1` 转换为 `apps/v1` 然后进行验证。 这样做的好处是可以确保验证规则不会被引入新版本的 API 所破坏，否则 API 请求就会通过使用新引入的版本而躲过验证规则的检查。 {{< /note >}} <!-- The `validations` include the CEL rules for the objects. There are three different expressions, catering for the fact that a Pod `spec` can be at the root of the object (a [naked pod](/docs/concepts/configuration/overview/#naked-pods-vs-replicasets-deployments-and-jobs)), under `template` (a workload controller or a Job), or under `jobTemplate` (a CronJob). --> 其中 `validations` 包括对象的 CEL 规则。有三种不同的表达方式，以满足 Pod `spec` 可以位于对象的根部（[独立的 Pod](/zh-cn/docs/concepts/configuration/overview/#naked-pods-vs-replicasets-deployments-and-jobs)）、 在 `template` 下（负载控制器或作业）或位于 `jobTemplate`（CronJob）下的情况。 <!-- In the event that any `spec` does not have `readOnlyRootFilesystem` set to true, the object will not be admitted. --> 如果任何一个 `spec` 没有将 `readOnlyRootFilesystem` 设为 true，则该对象将不会被接受。 {{< note >}} <!-- In our initial release, we have grouped the three expressions into the same policy object. This means they can be enabled and disabled atomically, and thus there is no chance that a user will accidentally leave a compliance gap by enabling policy for one API group and not the others. Breaking them into separate policies would allow us access to improvements targeted for the 1.27 release, including type checking. We are talking to SIG API Machinery about how to best address this before the APIs reach `v1`. --> 在最初的版本中，我们将这三个表达式分组到同一个策略对象中。这意味着可以原子性地启用和禁用它们， 因此不会出现以下情况：用户启用一个 API 组的策略而未启用其他组的策略，从而不小心留下合规性漏洞。 将它们分成单独的策略将使我们能够使用针对 1.27 版本所作的改进，包括类型检查。 我们正在与 SIG API Machinery 讨论如何在 API 达到 `v1` 之前最好地解决这个问题。 {{< /note >}} <!-- ### Using the CEL library in your cluster Policies are provided as Kubernetes objects, which are then bound to certain resources by a [selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors). --> ### 在集群中使用 CEL 库 {#using-the-cel-library-in-your-cluster} 策略以 Kubernetes 对象的形式提供，并通过[选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)绑定到某些资源。 <!-- [Minikube](https://minikube.sigs.k8s.io/docs/) is a quick and easy way to install and configure a Kubernetes cluster for testing. To install Kubernetes v1.26 with the `ValidatingAdmissionPolicy` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled: --> [Minikube](https://minikube.sigs.k8s.io/docs/) 是一种安装和配置 Kubernetes 集群以进行测试的快速简便的方法。 安装 Kubernetes v1.26 并启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) `ValidatingAdmissionPolicy`： ```shell minikube start --kubernetes-version=1.26.1 --extra-config=apiserver.runtime-config=admissionregistration.k8s.io/v1alpha1  --feature-gates='ValidatingAdmissionPolicy=true' ``` <!-- To install the policies in your cluster: ```shell # Install configuration CRD kubectl apply -f https://github.com/kubescape/cel-admission-library/releases/latest/download/policy-configuration-definition.yaml # Install basic configuration kubectl apply -f https://github.com/kubescape/cel-admission-library/releases/latest/download/basic-control-configuration.yaml # Install policies kubectl apply -f https://github.com/kubescape/cel-admission-library/releases/latest/download/kubescape-validating-admission-policies.yaml ``` --> 要在集群中安装策略： ```shell # 安装配置 CRD kubectl apply -f https://github.com/kubescape/cel-admission-library/releases/latest/download/policy-configuration-definition.yaml # 安装基础配置 kubectl apply -f https://github.com/kubescape/cel-admission-library/releases/latest/download/basic-control-configuration.yaml # 安装策略 kubectl apply -f https://github.com/kubescape/cel-admission-library/releases/latest/download/kubescape-validating-admission-policies.yaml ``` <!-- To apply policies to objects, create a `ValidatingAdmissionPolicyBinding` resource. Let’s apply the above Kubescape C-0017 control to any namespace with the label `policy=enforced`: --> 要将策略应用到对象，请创建一个 `ValidatingAdmissionPolicyBinding` 资源。 让我们把上述 Kubescape C-0017 控件应用到所有带有标签 `policy=enforced` 的命名空间： <!-- ```shell # Create a binding kubectl apply -f - <<EOT apiVersion: admissionregistration.k8s.io/v1alpha1 kind: ValidatingAdmissionPolicyBinding metadata: name: c0017-binding spec: policyName: kubescape-c-0017-deny-mutable-container-filesystem matchResources: namespaceSelector: matchLabels: policy: enforced EOT # Create a namespace for running the example kubectl create namespace policy-example kubectl label namespace policy-example 'policy=enforced' ``` --> ```shell # 创建绑定 kubectl apply -f - <<EOT apiVersion: admissionregistration.k8s.io/v1alpha1 kind: ValidatingAdmissionPolicyBinding metadata: name: c0017-binding spec: policyName: kubescape-c-0017-deny-mutable-container-filesystem matchResources: namespaceSelector: matchLabels: policy: enforced EOT # 创建用于运行示例的命名空间 kubectl create namespace policy-example kubectl label namespace policy-example 'policy=enforced' ``` <!-- Now, if you attempt to create an object without specifying a `readOnlyRootFilesystem`, it will not be created. ```shell # The next line should fail kubectl -n policy-example run nginx --image=nginx --restart=Never ``` --> 现在，如果尝试创建一个对象但不指定 `readOnlyRootFilesystem`，该对象将不会被创建。 ```shell # 如下命令会失败 kubectl -n policy-example run nginx --image=nginx --restart=Never ``` <!-- The output shows our error: --> 输出错误信息： ``` The pods "nginx" is invalid: : ValidatingAdmissionPolicy 'kubescape-c-0017-deny-mutable-container-filesystem' with binding 'c0017-binding' denied request: Pods having containers with mutable filesystem not allowed! (see more at https://hub.armosec.io/docs/c-0017) ``` <!-- ### Configuration Policy objects can include configuration, which is provided in a different object. Many of the Kubescape controls require a configuration: which labels to require, which capabilities to allow or deny, which registries to allow containers to be deployed from, etc. Default values for those controls are defined in [the ControlConfiguration object](https://github.com/kubescape/cel-admission-library/blob/main/configuration/basic-control-configuration.yaml). --> ### 配置 策略对象可以包括在不同对象中提供的配置。许多 Kubescape 控件需要配置： 需要哪些标签、允许或拒绝哪些权能、允许从哪些镜像库部署容器等。 这些控件的默认值在 [ControlConfiguration 对象](https://github.com/kubescape/cel-admission-library/blob/main/configuration/basic-control-configuration.yaml)中定义。 <!-- To use this configuration object, or your own object in the same format, add a `paramRef.name` value to your binding object: --> 要使用这个配置对象，或者以相同的格式使用你自己的对象，在你绑定对象中添加一个 `paramRef.name` 值: ```yaml apiVersion: admissionregistration.k8s.io/v1alpha1 kind: ValidatingAdmissionPolicyBinding metadata: name: c0001-binding spec: policyName: kubescape-c-0001-deny-forbidden-container-registries paramRef: name: basic-control-configuration matchResources: namespaceSelector: matchLabels: policy: enforced ``` <!-- ## Summary Converting our controls to CEL was simple, in most cases. We cannot port the whole Kubescape library, as some controls check for things outside a Kubernetes cluster, and some require data that is not available in the admission request object. Overall, we are happy to contribute this library to the Kubernetes community and will continue to develop it for Kubescape and Kubernetes users alike. We hope it becomes useful, either as something you use yourself, or as examples for you to write your own policies. --> ## 总结 {#summary} 在大多数情况下，将我们的控件转换为 CEL 很简单。我们无法移植整个 Kubescape 库，因为有些控件会检查 Kubernetes 集群外部的事物，有些控件需要访问准入请求对象中不可用的数据。 总的来说，我们很高兴将这个库贡献给 Kubernetes 社区，并将继续为 Kubescape 和 Kubernetes 用户开发它。 我们希望它能成为有用的工具，既可以作为你自己使用的工具，也可以作为你编写自己的策略的范例。 <!-- As for the validating admission policy feature itself, we are very excited to see this native functionality introduced to Kubernetes. We look forward to watching it move to Beta and then GA, hopefully by the end of the year. It is important to note this feature is currently in Alpha, which means this is the perfect opportunity to play around with it in environments like Minikube and give a test drive. However, it is not yet considered production-ready and stable, and will not be enabled on most managed Kubernetes environments. We will not recommend Kubescape users use these policies in production until the underlying functionality becomes stable. Keep an eye on [the KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/3488-cel-admission-control/README.md), and of course this blog, for an eventual release announcement. --> 至于验证准入策略功能本身，我们很高兴看到 Kubernetes 引入这一原生功能。 我们期待看到它进入 Beta 版，然后进入 GA 版，希望能在今年年底前完成。 值得注意的是，该功能目前还处于 Alpha 阶段，这意味着这是在 Minikube 等环境中试用该功能的绝佳机会。 然而，它尚未被视为生产就绪且稳定，且不会在大多数托管的 Kubernetes 环境中启用。 底层功能变得稳定之前，我们不会建议 Kubescape 用户在生产环境中使用这些策略。 请密切关注 [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/3488-cel-admission-control/README.md)， 当然还有此博客，以获取最终的发布公告。 </ins>  No newline at end of file

This is a Feature Request This page has no Chinese version What would you like to be Translate Chinese version for blogkubescape-validating-admission-policy- Comments /language zh /assign
/triage accepted


Question: <ins> --- title: エフェメラルコンテナ content_type: concept weight: 80 --- <!-- overview --> {{< feature-state state="alpha" for_k8s_version="v1.16" >}} このページでは、特別な種類のコンテナであるエフェメラルコンテナの概要を説明します。エフェメラルコンテナは、トラブルシューティングなどのユーザーが開始するアクションを実行するために、すでに存在する{{< glossary_tooltip term_id="pod" >}}内で一時的に実行するコンテナです。エフェメラルコンテナは、アプリケーションの構築ではなく、serviceの調査のために利用します。 {{< warning >}} エフェメラルコンテナは初期のアルファ状態であり、本番クラスタには適しません。[Kubernetesの非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従って、このアルファ機能は、将来大きく変更されたり、完全に削除される可能性があります。 {{< /warning >}} <!-- body --> ## エフェメラルコンテナを理解する {{< glossary_tooltip text="Pod" term_id="pod" >}}は、Kubernetesのアプリケーションの基本的なビルディングブロックです。Podは破棄可能かつ置き換え可能であることが想定されているため、一度Podが作成されると新しいコンテナを追加することはできません。その代わりに、通常は{{< glossary_tooltip text="Deployment" term_id="deployment" >}}を使用してPodを削除して置き換えます。 たとえば、再現困難なバグのトラブルシューティングなどのために、すでに存在するPodの状態を調査する必要が出てくることがあります。このような場合、既存のPod内でエフェメラルコンテナを実行することで、Podの状態を調査したり、任意のコマンドを実行したりできます。 ### エフェメラルコンテナとは何か？ エフェメラルコンテナは、他のコンテナと異なり、リソースや実行が保証されず、自動的に再起動されることも決してないため、アプリケーションを構築する目的には適しません。エフェメラルコンテナは、通常のコンテナと同じ`ContainerSpec`で記述されますが、多くのフィールドに互換性がなかったり、使用できなくなっています。 - エフェメラルコンテナはポートを持つことができないため、`ports`、`livenessProbe`、`readinessProbe`などは使えなくなっています。 - Podリソースの割り当てはイミュータブルであるため、`resources`の設定が禁止されています。 - 利用が許可されているフィールドの一覧については、[EphemeralContainerのリファレンスドキュメント](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core)を参照してください。 エフェメラルコンテナは、直接`pod.spec`に追加するのではなく、API内の特別な`ephemeralcontainers`ハンドラを使用して作成します。そのため、エフェメラルコンテナを`kubectl edit`を使用して追加することはできません。 エフェメラルコンテナをPodに追加した後は、通常のコンテナのようにエフェメラルコンテナを変更または削除することはできません。 ## エフェメラルコンテナの用途 エフェメラルコンテナは、コンテナがクラッシュしてしまったり、コンテナイメージにデバッグ用ユーティリティが同梱されていない場合など、`kubectl exec`では不十分なときにインタラクティブなトラブルシューティングを行うために役立ちます。 特に、[distrolessイメージ](https://github.com/GoogleContainerTools/distroless)を利用すると、攻撃対象領域を減らし、バグや脆弱性を露出する可能性を減らせる最小のコンテナイメージをデプロイできるようになります。distrolessイメージにはシェルもデバッグ用のユーティリティも含まれないため、`kubectl exec`のみを使用してdistrolessイメージのトラブルシューティングを行うのは困難です。 エフェメラルコンテナを利用する場合には、他のコンテナ内のプロセスにアクセスできるように、[プロセス名前空間の共有](/ja/docs/tasks/configure-pod-container/share-process-namespace/)を有効にすると便利です。 エフェメラルコンテナを利用してトラブルシューティングを行う例については、[デバッグ用のエフェメラルコンテナを使用してデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)を参照してください。 ## Ephemeral containers API {{< note >}} このセクションの例を実行するには、`EphemeralContainers`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、Kubernetesクライアントとサーバーのバージョンをv1.16以上にする必要があります。 {{< /note >}} このセクションの例では、API内でエフェメラルコンテナを表示する方法を示します。通常は、APIを直接呼び出すのではなく、`kubectl alpha debug`やその他の`kubectl`[プラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)を使用して、これらのステップを自動化します。 エフェメラルコンテナは、Podの`ephemeralcontainers`サブリソースを使用して作成されます。このサブリソースは、`kubectl --raw`を使用して確認できます。まずはじめに、以下に`EphemeralContainers`リストとして追加するためのエフェメラルコンテナを示します。 ```json { "apiVersion": "v1", "kind": "EphemeralContainers", "metadata": { "name": "example-pod" }, "ephemeralContainers": [{ "command": [ "sh" ], "image": "busybox", "imagePullPolicy": "IfNotPresent", "name": "debugger", "stdin": true, "tty": true, "terminationMessagePolicy": "File" }] } ``` すでに実行中の`example-pod`のエフェメラルコンテナを更新するには、次のコマンドを実行します。 ```shell kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json ``` このコマンドを実行すると、新しいエフェメラルコンテナのリストが返されます。 ```json { "kind":"EphemeralContainers", "apiVersion":"v1", "metadata":{ "name":"example-pod", "namespace":"default", "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers", "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c", "resourceVersion":"15886", "creationTimestamp":"2019-08-29T06:41:42Z" }, "ephemeralContainers":[ { "name":"debugger", "image":"busybox", "command":[ "sh" ], "resources":{ }, "terminationMessagePolicy":"File", "imagePullPolicy":"IfNotPresent", "stdin":true, "tty":true } ] } ``` 新しく作成されたエフェメラルコンテナの状態を確認するには、`kubectl describe`を使用します。 ```shell kubectl describe pod example-pod ``` ``` ... Ephemeral Containers: debugger: Container ID:  docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f Image:         busybox Image ID:      docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70 Port:          <none> Host Port:     <none> Command: sh State:          Running Started:      Thu, 29 Aug 2019 06:42:21 +0000 Ready:          False Restart Count:  0 Environment:    <none> Mounts:         <none> ... ``` 新しいエフェメラルコンテナとやりとりをするには、他のコンテナと同じように、`kubectl attach`、`kubectl exec`、`kubectl logs`などのコマンドが利用できます。例えば、次のようなコマンドが実行できます。 ```shell kubectl attach -it example-pod -c debugger ``` </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


Question: } } <del> body > footer { width: 100vw; } </del> /* FOOTER */ footer { background-color: #303030;

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


Question: Some cloud providers require a config file. If so, you need to put config file into apiserver image or mount through hostPath. - `--cloud-config=` set if cloud provider requires a config file. <del> - Used by `aws`, `gce`, `mesos`, `openshift`, `ovirt` and `rackspace`. </del> <ins> - Used by `aws`, `gce`, `mesos`, `openstack`, `ovirt` and `rackspace`. </ins> - You must put config file into apiserver image or mount through hostPath. - Cloud config file syntax is [Gcfg](https://code.google.com/p/gcfg/). - AWS format defined by type [AWSCloudConfig](https://releases.k8s.io/{{page.githubbranch}}/pkg/cloudprovider/providers/aws/aws.go)

<!-- 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: At "Cloud Providers" paragraph, There is a sentence following. In this sentence, is "openshift" correct? It should be "openstack", I think. Because following sentence is described at same paragraph. Here, "openshift" isn't present, but "openstack" is present. Proposed Solution: Replace "openshift" with "openstack" in sentence at "Cloud Providers" paragraph following. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
thanks - I suspect you're correct and made a quick patch () to resolve. When I looked in the cloud-provider releases for 1.8, there was one for openstack, but not openshift - so I think this was just a missed typo/reference mistake


Question: `name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/) section. <del> ## Privileged mode for containers {{< note >}} Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant. {{< /note >}} Any container in a pod can run in privileged mode to use operating system administrative capabilities that would otherwise be inaccessible. This is available for both Windows and Linux. ### Linux privileged containers In Linux, any container in a Pod can enable privileged mode using the `privileged` (Linux) flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices. ### Windows privileged containers {{< feature-state for_k8s_version="v1.26" state="stable" >}} In Windows, you can create a [Windows HostProcess pod](/docs/tasks/configure-pod-container/create-hostprocess-pod) by setting the `windowsOptions.hostProcess` flag on the security context of the pod spec. All containers in these pods must run as Windows HostProcess containers. HostProcess pods run directly on the host and can also be used to perform administrative tasks as is done with Linux privileged containers. </del> <ins> ## Pod security settings {#pod-security} To set security constraints on Pods and containers, you use the `securityContext` field in the Pod specification. This field gives you granular control over what a Pod or individual containers can do. For example: * Drop specific Linux capabilities to avoid the impact of a CVE. * Force all processes in the Pod to run as a non-root user or as a specific user or group ID. * Set a specific seccomp profile. * Set Windows security options, such as whether containers run as HostProcess. {{< caution >}} You can also use the Pod securityContext to enable [_privileged mode_](/docs/concepts/security/linux-kernel-security-constraints/#privileged-containers) in Linux containers. Privileged mode overrides many of the other security settings in the securityContext. Avoid using this setting unless you can't grant the equivalent permissions by using other fields in the securityContext. In Kubernetes 1.26 and later, you can run Windows containers in a similarly privileged mode by setting the `windowsOptions.hostProcess` flag on the security context of the Pod spec. For details and instructions, see [Create a Windows HostProcess Pod](/docs/tasks/configure-pod-container/create-hostprocess-pod/). {{< /caution >}} * To learn about kernel-level security constraints that you can use, see [Linux kernel security constraints for Pods and containers](/docs/concepts/security/linux-kernel-security-constraints). * To learn more about the Pod security context, see [Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/). </ins> ## Static Pods

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 doesn't mention that you can run Pods with AppArmor / seccomp / whatever to constrain the container. Why is this needed Although we have tutorials that explain the concepts in the manner of a walkthough, having a concept guide is important too. It's OK if the mention within is more like a signpost: a hyperlink to another page such as (which doesn't exist). Comments /sig security Relevant to Relevant to
This should be a fun time Since we already talk about privileged mode on the Pods page I agree that it's important to talk about the security constraints that you can place on containers. I also agree that a standalone page that discusses container isolation strategies and kernel-level security measures would be a good addition to our docs. /triage accepted /assign
As a first step, I'll find out if this information exists across our current docs (it definitely does) and draft up a plan for changes.
The framing here should be: small simple soon
Thanks If you're willing to focus first on the minimum viable change that can allow seccomp and AppArmor to graduate with docs in place, that'll help. It does mean more overall work if you then revisit things to make a larger improvement. Sorry about that.
Going through the current content it feels disconnected talking about Privileged mode, without not mentioning isolation levels. For someone starting their learning journey it may be hard to understand what that really means. In my opinion, the existing section could become a higher level section about Security Context (or a brief point on isolation levels), and within there we could talk about the ways of constraining (or enforcing isolation of) the container execution via AppArmor, Seccomp, SELinux and Privileged containers. We probably should use this opportunity to highlight the impact of privileged mode on those constraints. wdyt?
Agreed that it's a bit out of place there.

We already have so I wonder how that fits... Regardless for the mvp for this issue I'll focus on a smaller scope to meet the requirements here and then we can fiddle and improve
Planned here: I'd appreciate reviews on the scope so that I can do a draft and get that reviewed
I drafted the MVP of that page: It's missing some info that I am not sure about
I'd be happy to see a PR anyway.
Still working on this, will send a PR soon
would you like any help here?
I'll open a draft PR in the coming days. One final ish question: The content in (the seccomp and Apparmor/SELinux sections) are a summary basically of the content in this new page. Think it's a good idea to remove that bulk from the checklist page and link to the new page to learn more?
I'd really like to hear your thoughts on Shannon's question in
Security has been one of the top concerns for a few years when people start evaluating k8s. What I'd like to see is a single concept page clearly outlining all relevant topics as links to more detailed references. In this concept page, we may want to articulate the shared-responsibility model where security topics are organized based on users' persona. In other words, as an application developer, what are the things I need to pay attention to? As a cluster operator, what are the best practices I need to check. As someone who prepares the underlying infrastructure, is there a checklist for me?
If merges first, we could build on that. Thoughts there?
I agree - we can expand that page or work it into a more use case based signposting topic. Some considerations though: We should think about how to organize it. There's the CNCF white paper phases, yes, but there's also the opportunity to organize by pillar, like authn/z, encryption, monitoring and logging, etc. Maybe a sensible combination of the two? The links we provide should be associated with specific jobs to be done. For example, in the Authorization pillar, we could have "Authorize actions in clusters" and list the learning journey (About authorization RBAC RBAC good practices RBAC how-to) Maybe we can create a follow-up issue for this and discuss the actual presentation of that information there?
Maybe we can draft a toc for this on google docs for discussion?

sounds good to me, we should probably also create a backlog issue for tracking purposes (I can do it later today I'm away from my computer still waking up )
Relevant to
We can now link from the Pod concept to


Question:
 --- reviewers: - jszczepkowski title: Set up a High-Availability Control Plane content_type: task aliases: [ '/docs/tasks/administer-cluster/highly-available-master/' ] ---  {{< feature-state for_k8s_version="v1.5" state="alpha" >}} You can replicate Kubernetes control plane nodes in `kube-up` or `kube-down` scripts for Google Compute Engine. However this scripts are not suitable for any sort of production use, it's widely used in the project's CI. This document describes how to use kube-up/down scripts to manage a highly available (HA) control plane and how HA control planes are implemented for use with GCE. ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}  ## Starting an HA-compatible cluster To create a new HA-compatible cluster, you must set the following flags in your `kube-up` script: * `MULTIZONE=true` - to prevent removal of control plane kubelets from zones different than server's default zone. Required if you want to run control plane nodes in different zones, which is recommended. * `ENABLE_ETCD_QUORUM_READ=true` - to ensure that reads from all API servers will return most up-to-date data. If true, reads will be directed to leader etcd replica. Setting this value to true is optional: reads will be more reliable but will also be slower. Optionally, you can specify a GCE zone where the first control plane node is to be created. Set the following flag: * `KUBE_GCE_ZONE=zone` - zone where the first control plane node will run. The following sample command sets up a HA-compatible cluster in the GCE zone europe-west1-b: ```shell MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b  ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh ``` Note that the commands above create a cluster with one control plane node; however, you can add new control plane nodes to the cluster with subsequent commands. ## Adding a new control plane node After you have created an HA-compatible cluster, you can add control plane nodes to it. You add control plane nodes by using a `kube-up` script with the following flags: * `KUBE_REPLICATE_EXISTING_MASTER=true` - to create a replica of an existing control plane node. * `KUBE_GCE_ZONE=zone` - zone where the control plane node will run. Must be in the same region as other control plane nodes' zones. You don't need to set the `MULTIZONE` or `ENABLE_ETCD_QUORUM_READS` flags, as those are inherited from when you started your HA-compatible cluster. The following sample command replicates the control plane node on an existing HA-compatible cluster: ```shell KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh ``` ## Removing a control plane node You can remove a control plane node from an HA cluster by using a `kube-down` script with the following flags: * `KUBE_DELETE_NODES=false` - to restrain deletion of kubelets. * `KUBE_GCE_ZONE=zone` - the zone from where the control plane node will be removed. * `KUBE_REPLICA_NAME=replica_name` - (optional) the name of control plane node to remove. If empty: any replica from the given zone will be removed. The following sample command removes a control plane node from an existing HA cluster: ```shell KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh ``` ## Handling control plane node failures If one of the control plane nodes in your HA cluster fails, the best practice is to remove the node from your cluster and add a new control plane node in the same zone. The following sample commands demonstrate this process: 1. Remove the broken replica: ```shell KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh ```

Add a new node in place of the old one:

 ```shell KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh ``` ## Best practices for replicating control plane nodes for HA clusters * Try to place control plane nodes in different zones. During a zone failure, all control plane nodes placed inside the zone will fail. To survive zone failure, also place nodes in multiple zones (see [multiple-zones](/docs/setup/best-practices/multiple-zones/) for details). * Do not use a cluster with two control plane nodes. Consensus on a two-node control plane requires both nodes running when changing persistent state. As a result, both nodes are needed and a failure of any node turns the cluster into majority failure state. A two-node control plane is thus inferior, in terms of HA, to a cluster with one control plane node. * When you add a control plane node, cluster state (etcd) is copied to a new instance. If the cluster is large, it may take a long time to duplicate its state. This operation may be sped up by migrating the etcd data directory, as described in the [etcd administration guide](https://etcd.io/docs/v2.3/admin_guide/#member-migration) (we are considering adding support for etcd data dir migration in the future).  ## Implementation notes ![ha-control-plane](/docs/images/ha-control-plane.svg) ### Overview The figure above illustrates three control plane nodes and their components in a highly available cluster. The control plane node’s components employ the following methods: - etcd: instances are clustered together using consensus. - Controllers, scheduler and cluster auto-scaler: only one instance of each will be active in a cluster using a lease mechanism. - Add-on manager: each works independently to keep add-ons in sync. In addition, a load balancer operating in front of the API servers routes external and internal traffic to the control plane nodes. Each of the control plane nodes will run the following components in the following mode: * etcd instance: all instances will be clustered together using consensus; * API server: each server will talk to local etcd - all API servers in the cluster will be available; * controllers, scheduler, and cluster auto-scaler: will use lease mechanism - only one instance of each of them will be active in the cluster; * add-on manager: each manager will work independently trying to keep add-ons in sync. In addition, there will be a load balancer in front of API servers that will route external and internal traffic to them. ### Load balancing When starting the second control plane node, a load balancer containing the two replicas will be created and the IP address of the first replica will be promoted to IP address of load balancer. Similarly, after removal of the penultimate control plane node, the load balancer will be removed and its IP address will be assigned to the last remaining replica. Please note that creation and removal of load balancer are complex operations and it may take some time (~20 minutes) for them to propagate. ### Control plane service & kubelets Instead of trying to keep an up-to-date list of Kubernetes apiserver in the Kubernetes service, the system directs all traffic to the external IP: * in case of a single node control plane, the IP points to the control plane node, * in case of an HA control plane, the IP points to the load balancer in-front of the control plane nodes. Similarly, the external IP will be used by kubelets to communicate with the control plane. ### Control plane node certificates Kubernetes generates TLS certificates for the external public IP and local IP for each control plane node. There are no certificates for the ephemeral public IP for control plane nodes; to access a control plane node via its ephemeral public IP, you must skip TLS verification. ### Clustering etcd To allow etcd clustering, ports needed to communicate between etcd instances will be opened (for inside cluster communication). To make such deployment secure, communication between etcd instances is authorized using SSL. ### API server identity {{< feature-state state="alpha" for_k8s_version="v1.20" >}} The API Server Identity feature is controlled by a [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and is not enabled by default. You can activate API Server Identity by enabling the feature gate named `APIServerIdentity` when you start the {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}: ```shell kube-apiserver  --feature-gates=APIServerIdentity=true  # …and other flags as usual ``` During bootstrap, each kube-apiserver assigns a unique ID to itself. The ID is in the format of `kube-apiserver-{UUID}`. Each kube-apiserver creates a [Lease](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io) in the _kube-system_ {{< glossary_tooltip text="namespaces" term_id="namespace">}}. The Lease name is the unique ID for the kube-apiserver. The Lease contains a label `k8s.io/component=kube-apiserver`. Each kube-apiserver refreshes its Lease every `IdentityLeaseRenewIntervalSeconds` (defaults to 10s). Each kube-apiserver also checks all the kube-apiserver identity Leases every `IdentityLeaseDurationSeconds` (defaults to 3600s), and deletes Leases that hasn't got refreshed for more than `IdentityLeaseDurationSeconds`. `IdentityLeaseRenewIntervalSeconds` and `IdentityLeaseDurationSeconds` can be configured by kube-apiserver flags `identity-lease-renew-interval-seconds` and `identity-lease-duration-seconds`. Enabling this feature is a prerequisite for using features that involve HA API server coordination (for example, the `StorageVersionAPI` feature gate). ## Additional reading [Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In , and scripts are mentioned. But according to 's , And the in (where the and scripts exist) says that Proposed Solution: ~Update to not mention and scripts.~ Delete and redirect it to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/kind cleanup /triage accepted
/sig cluster-lifecycle (ish)
/reopen The page still mentions those scripts.
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
I think it would probably be best to instead drop all reference to them, we have if we need to document details to upstream contributors, previously we did not and sort of did double-duty IMHO
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]:
Let's delete and redirect it to /lifecycle frozen do you agree with that approach? If so, please update the issue description to highlight it as a plan.
→ Yes! → Done!
/assign
Thanks all.


Question: curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f - ``` {{< /note >}} ### Windowsワーカーノードの参加

Problem: Based on , I have created this issue/task to help update the [ja] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website/content/ja" /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/containers/container- 46: IPDNS /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services-networking/connect-applications- 146: /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services- 283: )Service /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/setup/learning- 220: {{< param "fullversion" }}: 223: minikube start --kubernetes-version {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/tools/install- 34: Linux{{< param "fullversion" }}: 37: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 116: macOS{{< param "fullversion" }}: 119: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 181: {{< 181: "fullversion" }}){{< param "fullversion" }} 186: curl -LO {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows- 107: Kubernetes{{< param "fullversion" }} 111: releases/latest/download/kube- kubectl apply -f - 150: .PrepareNode.

ps1 -KubernetesVersion {{% param "fullversion" %}} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows- 35: # {{% param "fullversion" %}} 36: -Lo C:k {{% param "fullversion" %}} 70: -Lo C:k {{% param "fullversion" %}} 86: {{< param "fullversion" }}: 89: releases/latest/download/kube- kubectl apply -f - /sig docs /sig localization /language ja cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: All the other documents need to change into or appropriatly. Since several languages are involved, I'd like to share this issue to check all localizations complete the task. Proposed Solution: Page to Update: /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services-networking/connect-applications- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/setup/learning- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/tools/install- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows- /sig localization /language ja cc: 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
cc:
/triage accepted /area localization /priority backlog


Question: nodeName: kube-01 ``` <del> The above pod will run on the node kube-01. </del> <ins> The above Pod will only run on the node `kube-01`. </ins> ## {{% heading "whatsnext" %}} <del> [Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods. The design documents for [node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md) and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) contain extra background information about these features. Once a Pod is assigned to a Node, the kubelet runs the Pod and allocates node-local resources. The [topology manager](/docs/tasks/administer-cluster/topology-manager/) can take part in node-level resource allocation decisions. </del> <ins> * Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) . * Read the design docs for [node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md) and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md). * Learn about how the [topology manager](/docs/tasks/administer-cluster/topology-manager/) takes part in node-level resource allocation decisions. * Learn how to use [nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/). * Learn how to use [affinity and anti-affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/). </ins>

Page: This page could use a review and update for consistency, clarity, and style. Some sections read like tasks instead of conceptual information, and there's a few areas where the headings and readability are not in line with our style guidelines. /assign /sig docs /triage accepted /language en /kind cleanup
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]:
/lifecycle frozen

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 description provide in the following section is somewhat missing out the details. It is not justifying the value of weight one should configure in the affinity section of a deployment. Proposed Solution: It would be best if this page can contain a legitimate example around the weight in Node affinity. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--v1.18 <!--Additional Information:--What is the significance of weight: 1 as compared to weight: 100 ? Creating first issue in GIT, apologies if I have missed out something. Would be happy to hear from you.
/language en /sig scheduling
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at .

/lifecycle rotten
/remove-lifecycle rotten
/priority backlog
From what I understand, the scheduler iterates through each field for each matched affinity term and computes a sum, then places pods in nodes that meet the scheduling requirements by order of highest weight sum. Is this correct?
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
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
fixes this.
/remove-lifecycle rotten
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
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 .


Question: ```sh root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml <del> root@HOST1 $ kubeadm init phase etcd local --config=/tmp/${HOST1}/kubeadmcfg.yaml root@HOST2 $ kubeadm init phase etcd local --config=/tmp/${HOST2}/kubeadmcfg.yaml </del> <ins> root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml </ins> ``` 1. Optional: Check the cluster health

I don't have any issue .but i have suggestion . when i follow the official guide i noticed a document incorrect path issue. In the steps 7 they mention in /tmp folder all the etcd instance. but steps 6 showing in the only $HOST0 having tmp other etcd instance having document root. Document should update the correct path !
/language en /sig cluster-lifecycle I don't think I've understood the report you've filed In the existing page, which specific part of that text contains the details that you think we should change?
Hi In the step 7 path should be correct as below root {HOST0} root root
if you look at step 4: all files are under ~so it seems step 6 is the one that is wrong.~ EDIT: never mind the copied files end up in HOME with scp.
/assign
/kind bug /triage accepted
fix here: