Question: --- 本ウェブサイトには、現行版とその直前4バージョンのKubernetesドキュメントがあります。 <ins> Kubernetesバージョンのドキュメントの入手性は、そのリリースが現在サポートされているかどうかで分かれます。 どのKubernetesバージョンが公式にどのくらいの期間サポートされるかについて知るには、[サポート期間](/releases/patch-releases/#support-period)を参照してください。 </ins>

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. --Update translation /ja/docs/home/supported-doc-versions to current English version Tue May 31 06:54:51 2022 +0600 Why is this needed fix outdated doc 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: Details of the metric data that Kubernetes components export. --- <del> ## Metrics (v1.29) </del> <ins> ## Metrics (v1.28) </ins> <del> <!-- (auto-generated 2023 Sep 06) --> <!-- (auto-generated v1.29) --> </del> <ins> <!-- (auto-generated 2023 Jul 20) --> <!-- (auto-generated v1.28) --> </ins> This page details the metrics that different Kubernetes components export. You can query the metrics endpoint for these components using an HTTP scrape, and fetch the current metrics data in Prometheus format.

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: says that it is for Kubernetes v1.29, which has yet to be released. Proposed Solution: Revise to cover v1.28 metrics Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: We should fix this before the v1.29 release. /priority important-soon /sig instrumentation /language en /triage accepted
Upon some investigation, I can see the generation of 1.29 metrics on one of my old PRs; Please refer If reverting to an older version of this file helps, Let's do that. I'll make amendments for the formatting once again Alternatively, We can try some experimenting with git history and make a PR which generates 1.28 metrics, With the formatting in place. That should work too (I'd prefer doing this)
I can take this.
/assign
Given the timeline, please mention in the PR and also request a review specifically from me. Whoever gets to it first can pick up the review work.
any advice for about how to approach this?
Sure, Here's my advice These metrics are generated over at Part of the work here includes figuring out where the generation went from 1.28 to 1.29 If you're able to do that, We can revert to the point where 1.28 metrics were generated Given the timeline of docs 1.29 release, If that's not possible in this timeframe, We should revert would you like to add anything else?
Thanks, I will see that, btw can i know what's the timeline?
I believe the release is on 5th December
I found that due to commit which was made by bot on 6-9-23, changed the version from 1.28 to 1.29. If we revert this than the issue will be resolved. //
That's the code we adopted in can we revert this PR for the docs at the time of 1.29 release while keeping the generator at k8s/k8s, the same? After the release we can sync back from k8s/k8s
Yeah, this can work too
I think that's reasonable.

I believe now is a good time to revert that PR (only reverting the markdown changes would be fine)
Sure
you mean reverting completely this PR -
Yes that's correct


Question: 所生成的 ConfigMap 和 Secret 都会包含内容哈希值后缀。 这是为了确保内容发生变化时，所生成的是新的 ConfigMap 或 Secret。 要禁止自动添加后缀的行为，用户可以使用 `generatorOptions`。 <del> 除此以外，为生成的 ConfigMap 和 Secret 指定贯穿性选项也是可能的。 </del> <ins> 除此以外，为生成的 ConfigMap 和 Secret 指定贯穿性选项也是可以的。 </ins> ```shell cat <<EOF >./kustomization.yaml

There are some Chinese typo issues in , which should be corrected. For example: <img width="705" alt="image" src="https://user-"The "" should be "“. And, <img width="572" alt="image" src="https://user-"The "“ is wrong and should be "". As I have read the full article, I am planing to submit a PR.
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


In new (k8s 1.28 updated) documentation page: the link given in the third paragraph does not work. (the bug is really about that link not working; the URL looks ok but it is some days I am getting a 404)
/triage accepted /kind bug
The link to "NetworkPolicy" on suffers the same fate.

on page gives 404 error in section:
/kind bug /language en
/triage accepted We have a PR ready for a fix; now, that PR needs a review. /priority backlog
/retitle Broken link to API reference in Pod Lifecycle concept
It is really a broken link to the whole k8s 1.28 API reference (not only to the Pod-Lifecycle part); note the URL does not work (but it still works for , , ...)
For an issue about the API reference missing overall, see


Question: <ins> --- title: Podのセキュリティアドミッション content_type: concept weight: 20 min-kubernetes-server-version: v1.22 --- <!-- overview --> {{< feature-state for_k8s_version="v1.23" state="beta" >}} Kubernetesの[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/)はPodに対して異なる分離レベルを定義します。 これらの標準によって、Podの動作をどのように制限したいかを、明確かつ一貫した方法で定義することができます。 ベータ版機能として、Kubernetesは[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)の後継である組み込みの _Pod Security_ {{< glossary_tooltip text="アドミッションコントローラー" term_id="admission-controller" >}}を提供しています。 Podセキュリティの制限は、Pod作成時に{{< glossary_tooltip text="名前空間" term_id="namespace" >}}レベルで適用されます。 {{< note >}} PodSecurityPolicy APIは非推奨であり、v1.25でKubernetesから[削除](/docs/reference/using-api/deprecation-guide/#v1-25)される予定です。 {{< /note >}} <!-- body --> ## `PodSecurity`アドミッションプラグインの有効化 {#enabling-the-podsecurity-admission-plugin} v1.23において、`PodSecurity`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)はベータ版の機能で、デフォルトで有効化されています。 v1.22において、`PodSecurity`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)はアルファ版の機能で、組み込みのアドミッションプラグインを使用するには、`kube-apiserver`で有効にする必要があります。 ```shell --feature-gates="...,PodSecurity=true" ``` ## 代替案:`PodSecurity`アドミッションwebhookのインストール {#webhook} クラスターがv1.22より古い、あるいは`PodSecurity`機能を有効にできないなどの理由で、ビルトインの`PodSecurity`アドミッションプラグインが使えない環境では、`PodSecurity`はアドミッションロジックはベータ版の[validating admission webhook](https://git.k8s.io/pod-security-admission/webhook)としても提供されています。 ビルド前のコンテナイメージ、証明書生成スクリプト、マニフェストの例は、[https://git.k8s.io/pod-security-admission/webhook](https://git.k8s.io/pod-security-admission/webhook)で入手可能です。 インストール方法: ```shell git clone git@github.com:kubernetes/pod-security-admission.git cd pod-security-admission/webhook make certs kubectl apply -k . ``` {{< note >}} 生成された証明書の有効期限は2年間です。有効期限が切れる前に、証明書を再生成するか、内蔵のアドミッションプラグインを使用してWebhookを削除してください。 {{< /note >}} ## Podのセキュリティレベル {#pod-security-levels} Podのセキュリティアドミッションは、Podの[Security Context](/docs/tasks/configure-pod-container/security-context/)とその他の関連フィールドに、[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards)で定義された3つのレベル、`privileged`、`baseline`、`restricted`に従って要件を設定するものです。 これらの要件の詳細については、[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards)のページを参照してください。 ## Podの名前空間に対するセキュリティアドミッションラベル {#pod-security-admission-labels-for-namespaces} この機能を有効にするか、Webhookをインストールすると、名前空間を設定して、各名前空間でPodセキュリティに使用したいadmission controlモードを定義できます。 Kubernetesは、名前空間に使用したい定義済みのPodセキュリティの標準レベルのいずれかを適用するために設定できる{{< glossary_tooltip term_id="label" text="ラベル" >}}のセットを用意しています。 選択したラベルは、以下のように違反の可能性が検出された場合に{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}が取るアクションを定義します。 {{< table caption="Podのセキュリティアドミッションのモード" >}} モード | 説明 :---------|:------------ **enforce** | ポリシーに違反した場合、Podは拒否されます。 **audit** | ポリシー違反は、[監査ログ](/ja/docs/tasks/debug-application-cluster/audit/)に記録されるイベントに監査アノテーションを追加するトリガーとなりますが、それ以外は許可されます。 **warn** | ポリシーに違反した場合は、ユーザーへの警告がトリガーされますが、それ以外は許可されます。 {{< /table >}} 名前空間は、任意のまたはすべてのモードを設定することができ、異なるモードに対して異なるレベルを設定することもできます。 各モードには、使用するポリシーを決定する2つのラベルがあります。 ```yaml # モードごとのレベルラベルは、そのモードに適用するポリシーレベルを示す。 # # MODEは`enforce`、`audit`、`warn`のいずれかでなければならない。 # LEVELは`privileged`、`baseline`、`restricted`のいずれかでなければならない。 pod-security.kubernetes.io/<MODE>: <LEVEL> # オプション: モードごとのバージョンラベルは、Kubernetesのマイナーバージョンに同梱される # バージョンにポリシーを固定するために使用できる（例えばv{{< skew latestVersion >}}など）。 # # MODEは`enforce`、`audit`、`warn`のいずれかでなければならない。 # VERSIONは有効なKubernetesのマイナーバージョンか`latest`でなければならない。 pod-security.kubernetes.io/<MODE>-version: <VERSION> ``` [名前空間ラベルでのPodセキュリティの標準の適用](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels)で使用例を確認できます。 ## WorkloadのリソースとPodテンプレート {#workload-resources-and-pod-templates} Podは、{{< glossary_tooltip term_id="deployment" >}}や{{< glossary_tooltip term_id="job">}}のような[ワークロードオブジェクト](/ja/docs/concepts/workloads/controllers/)を作成することによって、しばしば間接的に生成されます。 ワークロードオブジェクトは_Pod template_を定義し、ワークロードリソースの{{< glossary_tooltip term_id="controller" text="コントローラー" >}}はそのテンプレートに基づきPodを作成します。 違反の早期発見を支援するために、auditモードとwarningモードは、ワークロードリソースに適用されます。 ただし、enforceモードはワークロードリソースには**適用されず**、結果としてのPodオブジェクトにのみ適用されます。 ## 適用除外(Exemption) {#exemptions} Podセキュリティの施行から _exemptions_ を定義することで、特定の名前空間に関連するポリシーのために禁止されていたPodの作成を許可することができます。 Exemptionは[アドミッションコントローラーの設定](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)で静的に設定することができます。 Exemptionは明示的に列挙する必要があります。 Exemptionを満たしたリクエストは、アドミッションコントローラーによって _無視_ されます(`enforce`、`audit`、`warn`のすべての動作がスキップされます)。Exemptionの次元は以下の通りです。 - **Usernames:** 認証されていない(あるいは偽装された)ユーザー名を持つユーザーからの要求は無視されます。 - **RuntimeClassNames:** Podと[ワークロードリソース](#workload-resources-and-pod-templates)で指定された除外ランタイムクラス名は、無視されます。 - **Namespaces:** 除外された名前空間のPodと[ワークロードリソース](#workload-resources-and-pod-templates)は、無視されます。 {{< caution >}} ほとんどのPodは、[ワークロードリソース](#workload-resources-and-pod-templates)に対応してコントローラーが作成します。つまり、エンドユーザーを適用除外にするのはPodを直接作成する場合のみで、ワークロードリソースを作成する場合は適用除外になりません。 コントローラーサービスアカウント(`system:serviceaccount:kube-system:replicaset-controller`など)は通常、除外してはいけません。そうした場合、対応するワークロードリソースを作成できるすべてのユーザーを暗黙的に除外してしまうためです。 {{< /caution >}} 以下のPodフィールドに対する更新は、ポリシーチェックの対象外となります。つまり、Podの更新要求がこれらのフィールドを変更するだけであれば、Podが現在のポリシーレベルに違反していても拒否されることはありません。 - すべてのメタデータの更新(seccompまたはAppArmorアノテーションへの変更を**除く**) - `seccomp.security.alpha.kubernetes.io/pod`(非推奨) - `container.seccomp.security.alpha.kubernetes.io/*`(非推奨) - `container.apparmor.security.beta.kubernetes.io/*` - `.spec.activeDeadlineSeconds`に対する有効な更新 - `.spec.tolerations`に対する有効な更新 ## {{% heading "whatsnext" %}} - [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards) - [Podセキュリティの標準の適用](/docs/setup/best-practices/enforcing-pod-security-standards) - [ビルトインのアドミッションコントローラーの設定によるPodセキュリティの標準の適用](/docs/tasks/configure-pod-container/enforce-standards-admission-controller) - [名前空間ラベルでのPodセキュリティの標準の適用](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) - [PodSecurityPolicyからビルトインのPodSecurityアドミッションコントローラーへの移行](/docs/tasks/configure-pod-container/migrate-from-psp) </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Japanese. Why is this needed This page has not been translated. 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: As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you append to the service's proxy URL: `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` <del> If you haven't specified a name for your port, you don't have to specify *port_name* in the URL. </del> <ins> If you haven't specified a name for your port, you don't have to specify *port_name* in the URL. You can also use the port number in place of the *port_name* for both named and unnamed ports. </ins> By default, the API server proxies to your service using http. To use https, prefix the service name with `https:`: `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`

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. --The is lacking clarity that both the port name or port number can be used when proxying to a service. The documentation should mention the field represented by can either be the name of a port in a service or the port number of a service for both forms and . Why is this needed The apiserver proxy endpoint supports using either a to locate the service to proxy to. The alternative form of using the port number could be useful if migrating from an unnamed/default service port to a named service port. Example: The following api server request could be used to proxy either form of the following service object since it references the port number, . If the query was constructed as , only the unnamed port would return a result. Conversely, if was used in the query only the named port would return a result. default/unnamed: named: Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/kind cleanup
/triage accepted
/priority backlog


Question: 1. Access the 2nd version of the Hello World app. <ins> {{< tabs name="ingress2-v2" >}} {{% tab name="Linux" %}} </ins> ```shell curl --resolve "hello-world.info:80:$( minikube ip )" -i http://hello-world.info/v2 ``` <ins> {{% /tab %}} {{% tab name="MacOS" %}} ```shell minikube tunnel ``` The output is similar to: ```none Tunnel successfully started NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ... The service/ingress example-ingress requires privileged ports to be exposed: [80 443] sudo permission will be asked for it. Starting tunnel for service example-ingress. ``` From within a new terminal, invoke the following command: ```shell curl --resolve "hello-world.info:80:127.0.0.1" -i http://hello-world.info/v2 ``` {{% /tab %}} {{< /tabs >}} </ins> The output is similar to:

Problem: Going through the documentation provided by the link such issue has being met on the step of verification that Ingress controller is directing the traffic using the command below: curl --resolve "hello-$( minikube ip )" -i http://hello- After running this command the terminal returns: Failed to connect to hello- port 80 after ms: Couldn't connect to server Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Kubernetes version: v1.28.3 <!--Additional Information:--Environment that is used: Macbook M1 Pro Minikube version: v1.32.0 Minikube uses the docker driver. Step on which problem has been met:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Page reported in issue: /language en
This is same as issue /triage duplicate I believe this should be fixed by updating the page by mentioning the instructions to create a for MacOS and Windows users. I'll try to work on a PR for this. Till the time the page is modified, the way around this is mentioned . The reason why it fails on MacOS and Windows is documented here , , You can also visit the page and view the tab in Step 4 Deploy applications.
/assign

you need start and then to solve same problem in mac
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
/triage needs-information Hi. Is this about a particular web page?
sorry, this is about following tutorial Create an Ingress step 4
/retitle Ingress tutorial does not mention commands needed for Mac /remove-triage needs-information
/kind bug /language en
I can confirm that this is a valid issue on MacOS and the page needs to be updated. I think we should move this to /triage accepted. I cannot test this on Windows at the moment, but suggests that the behaviour on Windows will be the same as MacOS. The network is limited if using the Docker driver on Darwin, Windows, or WSL, and the Node IP is not reachable directly.
/assign


Question: ### containerd <del> This section contains the necessary steps to use `containerd` as CRI runtime. </del> <ins> This section contains the necessary steps to use containerd as CRI runtime. </ins> Use the following commands to install Containerd on your system:

The current installation instructions for installing the third party Kubernetes Apt repository on Debian/Ubuntu, goes against best security practice. Currently the signing keys are to . The keychain should be downloaded to (file name to match the name used in ) using or (not as this is deprecated and will be last available in Debian 11 and Ubuntu 22.04) and referred to in as such Page to Update: References:
i read the linked pages and this change seems valid. thank you for bringing this up. would you help us by sending a PR for that? /sig cluster-lifecycle
/priority important-longterm /kind cleanup
/triage accepted
Please see
/sig cli


Question: - テナントは、Secretを各NamespaceのimagePullSecretsへ追加する 複数のレジストリへのアクセスが必要な場合、それぞれのレジストリ毎にひとつのSecretを作成する事ができます。 <del> Kubeletは複数の`imagePullSecrets`を単一の仮想的な`.docker/config.json`にマージします。 </del> ## {{% heading "whatsnext" %}} <del> * [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)を読みます。 </del> <ins> * [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)を読む * [コンテナのガベージコレクション](/ja/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)について学ぶ * [pulling an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry)について学ぶ </ins>

This is a Feature Request What would you like to be We need to update according to the English text, because it is outdated. Why is this needed is outdated. 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: One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). <ins> ### cluster-autoscaler.kubernetes.io/safe-to-evict Example: `cluster-autoscaler.kubernetes.io/safe-to-evict: "true"` Used on: Pod When this annotation is set to `"true"`, the cluster autoscaler is allowed to evict a Pod even if other rules would normally prevent that. The cluster autoscaler never evicts Pods that have this annotation explicitly set to `"false"`; you could set that on an important Pod that you want to keep running. If this annotation is not set then the cluster autoscaler follows its Pod-level behavior. </ins> ### kubernetes.io/arch Example: `kubernetes.io/arch: "amd64"`

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 cluster autoscaler uses an annotation, . However, we don't list that annotation in Well-Known Labels, Annotations and Taints. Proposed Solution: Update Well-Known Labels, Annotations and Taints to mention the Pod annotation and why you might use it. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en
/triage accepted /sig autoscaling
/assign


Question: <del> --- assignees: - dchen1107 --- Use the [master.yaml](/docs/getting-started-guides/coreos/cloud-configs/master.yaml) and [node.yaml](/docs/getting-started-guides/coreos/cloud-configs/node.yaml) cloud-configs to provision a multi-node Kubernetes cluster. > **Attention**: This requires at least CoreOS version **[695.0.0][coreos695]**, which includes `etcd2`. [coreos695]: https://coreos.com/releases/#695.0.0 * TOC {:toc} ### AWS *Attention:* Replace `<ami_image_id>` below for a [suitable version of CoreOS image for AWS](https://coreos.com/docs/running-coreos/cloud-providers/ec2/). #### Provision the Master ```shell aws ec2 create-security-group --group-name kubernetes --description "Kubernetes Security Group" aws ec2 authorize-security-group-ingress --group-name kubernetes --protocol tcp --port 22 --cidr 0.0.0.0/0 aws ec2 authorize-security-group-ingress --group-name kubernetes --protocol tcp --port 80 --cidr 0.0.0.0/0 aws ec2 authorize-security-group-ingress --group-name kubernetes --source-security-group-name kubernetes ``` ```shell aws ec2 run-instances  --image-id <ami_image_id>  --key-name <keypair>  --region us-west-2  --security-groups kubernetes  --instance-type m3.medium  --user-data file://master.yaml ``` #### Capture the private IP address ```shell aws ec2 describe-instances --instance-id <master-instance-id> ``` #### Edit node.yaml Edit `node.yaml` and replace all instances of `<master-private-ip>` with the private IP address of the master node. #### Provision worker nodes ```shell aws ec2 run-instances  --count 1  --image-id <ami_image_id>  --key-name <keypair>  --region us-west-2  --security-groups kubernetes  --instance-type m3.medium  --user-data file://node.yaml ``` ### Google Compute Engine (GCE) *Attention:* Replace `<gce_image_id>` below for a [suitable version of CoreOS image for Google Compute Engine](https://coreos.com/docs/running-coreos/cloud-providers/google-compute-engine/). #### Provision the Master ```shell gcloud compute instances create master  --image-project coreos-cloud  --image <gce_image_id>  --boot-disk-size 200GB  --machine-type n1-standard-1  --zone us-central1-a  --metadata-from-file user-data=master.yaml ``` #### Capture the private IP address ```shell gcloud compute instances list ``` #### Edit node.yaml Edit `node.yaml` and replace all instances of `<master-private-ip>` with the private IP address of the master node. #### Provision worker nodes ```shell gcloud compute instances create node1  --image-project coreos-cloud  --image <gce_image_id>  --boot-disk-size 200GB  --machine-type n1-standard-1  --zone us-central1-a  --metadata-from-file user-data=node.yaml ``` #### Establish network connectivity Next, setup an ssh tunnel to the master so you can run kubectl from your local host. In one terminal, run `gcloud compute ssh master --ssh-flag="-L 8080:127.0.0.1:8080"` and in a second run `gcloud compute ssh master --ssh-flag="-R 8080:127.0.0.1:8080"`. ### OpenStack These instructions are for running on the command line.  Most of this you can also do through the Horizon dashboard. These instructions were tested on the Ice House release on a Metacloud distribution of OpenStack but should be similar if not the same across other versions/distributions of OpenStack. #### Make sure you can connect with OpenStack Make sure the environment variables are set for OpenStack such as: ```shell OS_TENANT_ID OS_PASSWORD OS_AUTH_URL OS_USERNAME OS_TENANT_NAME ``` Test this works with something like: ```shell nova list ``` #### Get a Suitable CoreOS Image You'll need a [suitable version of CoreOS image for OpenStack](https://coreos.com/os/docs/latest/booting-on-openstack.html) Once you download that, upload it to glance.  An example is shown below: ```shell glance image-create --name CoreOS723  --container-format bare --disk-format qcow2  --file coreos_production_openstack_image.img  --is-public True ``` #### Create security group ```shell nova secgroup-create kubernetes "Kubernetes Security Group" nova secgroup-add-rule kubernetes tcp 22 22   0.0.0.0/0 nova secgroup-add-rule kubernetes tcp 80 80   0.0.0.0/0 ``` #### Provision the Master ```shell nova boot  --image <image_name>  --key-name <my_key>  --flavor <flavor id>  --security-group kubernetes  --user-data files/master.yaml  kube-master ``` `<image_name>` is the CoreOS image name. In our example we can use the image we created in the previous step and put in 'CoreOS723' `<my_key>` is the keypair name that you already generated to access the instance. `<flavor_id>` is the flavor ID you use to size the instance.  Run `nova flavor-list` to get the IDs.  3 on the system this was tested with gives the m1.large size. The important part is to ensure you have the files/master.yml as this is what will do all the post boot configuration. This path is relevant so we are assuming in this example that you are running the nova command in a directory where there is a subdirectory called files that has the master.yml file in it.  Absolute paths also work. Next, assign it a public IP address: ```shell nova floating-ip-list ``` Get an IP address that's free and run: ```shell nova floating-ip-associate kube-master <ip address> ``` where `<ip address>` is the IP address that was available from the `nova floating-ip-list` command. #### Provision Worker Nodes Edit `node.yaml` and replace all instances of `<master-private-ip>` with the private IP address of the master node.  You can get this by running `nova show kube-master` assuming you named your instance kube master.  This is not the floating IP address you just assigned it. ```shell nova boot  --image <image_name>  --key-name <my_key>  --flavor <flavor id>  --security-group kubernetes  --user-data files/node.yaml  minion01 ``` This is basically the same as the master nodes but with the node.yaml post-boot script instead of the master. </del>  No newline at end of file

A user linked to this guide from an issue: I believe that guide is unmaintained. It still specifies k8s 1.1.2. can we delete?
Thank you. Yes, this guide was unmaintained and community contributed. I am OK with this change. devin-donnelly wrote:


Question: ## Upcoming Release Webinar <del> Join members of the Kubernetes v1.28 release team on Friday, September 14, 2023, at 10 a.m. PDT to learn about the major features of this release, as well as deprecations and removals to help plan for upgrades. For more information and registration, visit the [event page](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-v128-release/) on the CNCF Online Programs site. </del> <ins> Join members of the Kubernetes v1.28 release team on Friday, September 14, 2023, at 10 A.M. PDT to learn about the major features of this release, as well as deprecations and removals to help plan for upgrades. For more information and registration, visit the [event page](https://community.cncf.io/events/) on the CNCF Online Programs site. </ins> ## Get Involved

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 release blog has this section: Join members of the Kubernetes v1.28 release team on Friday, September 14, 2023, at 10 a.m. PDT to learn about the major features of this release, as well as deprecations and removals to help plan for upgrades. For more information and registration, visit the on the CNCF Online Programs site. This currently has a broken link to the event page. Proposed Solution: Once the event is live on CNCF we should fix this in the blog or at least remove the link until then. Page to Update: /cc
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
Thanks confirmed it is broken talking with CNCF now regarding it. Will do a PR to remove for now
/assign


Question: 強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。 <ins> {{< caution >}} 即時削除では、実行中のリソースの終了を待ちません。 リソースはクラスタ上で無期限に実行し続ける可能性があります。 {{< /caution >}} </ins> StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-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: <ins> --- title: Container Runtime Interface (CRI) content_type: concept weight: 60 --- <!-- overview --> _CRI_ es una interfaz de plugin que permite que kubelet use una amplia variedad de container runtimes, sin necesidad de volver a compilar los componentes del clúster. Necesitas un _{{<glossary_tooltip text="container runtime" term_id="container-runtime">}}_ ejecutándose en cada Nodo en tu clúster, de manera que {{<glossary_tooltip text="kubelet" term_id="kubelet">}} pueda iniciar los {{<glossary_tooltip text="Pods" term_id="pod">}} y sus contenedores. {{<glossary_definition prepend="Container Runtime Interface (CRI) es" term_id="container-runtime-interface" length="all">}} <!-- body --> ## API {#api} {{< feature-state for_k8s_version="v1.23" state="stable" >}} Kubelet actúa como un cliente cuando se conecta al _runtime_ del contenedor a través de gRPC. El _runtime_ y los _endpoints_ del servicio de imágenes deben estar disponibles en el _runtime_ del contenedor, que se puede configurar por separado dentro del kubelet usando `--image-service-endpoint` [banderas de línea de comando](/docs/reference/command-line-tools-reference/kubelet). Para Kubernetes v{{< skew currentVersion >}}, kubelet prefiere usar CRI `v1`. Si el _runtime_ del contenedor no es compatible con `v1` del CRI, kubelet intenta negociar cualquier versión compatible anterior. El kubelet v{{< skew currentVersion >}} también puede negociar CRI `v1alpha2`, pero esta versión se considera obsoleta. Si el kubelet no puede negociar una versión CRI soportada, el kubelet se da por vencido y no se registra como un nodo. ## Actualizando Al actualizar Kubernetes, el kubelet intenta seleccionar automáticamente la última versión de CRI al reiniciar el componente. Si eso falla, entonces la alternativa se llevará a cabo como se mencionó anteriormente. Si se requirió una rellamada de gRPC porque el _runtime_ del contenedor se ha actualizado, entonces el _runtime_ del contenedor también debe soportar la versión seleccionada inicialmente o se espera que la rellamada falle. Esto requiere un reinicio del kubelet. ## {{% heading "whatsnext" %}} - Más información sobre CRI [definición de protocolo](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto) </ins>

This is a Feature Request What would you like to be Localize to Spanish Why is this needed Comments
/triage accepted
/language es
/kind feature
/assign
/assign


Question: <!-- overview --> This document helps you get started using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other. <ins> {{% thirdparty-content %}} </ins> ## {{% heading "prerequisites" %}}

Per our discussion in today's SIG Docs: Sections of the site, like will always have some degree of 3rd party content, due to the fact that a k8s developer must implement an external networking CNI. The majority of post-3rd party content KEP PR's we get that actually involve third party content are to pages like this one. A part of the reasons is that a change like the KEP requires initial communication (which was well done) but also ongoing communication. This change proposes the following: Create a reusable Note or similar shortcode for pages that fall under . The note should: Be translatable (use a key) Warn people that they must use a 3rd party plugin/software for this step Indicate that per the projects are listed alphabetically Indicate that additions to this list/page must directly provide a solution for this step of an implementation (i.e. for the cluster networking page, projects listed must provide a networking solution – no 'nice to haves' that make networking easier or somehow nicer.) Link to the content guidelines for more info on acceptable additions to the page.
/assign /area web-development /priority important-longterm
/language en
Wording for review: This section contains links to third party projects which provide functionality required by Kubernetes. The Kubernetes project authors are not responsible for these projects. Projects are listed alphabetically, in accordance with [CNCF website guidelines]. To add a project to this list, read the <a href="/contribute/style/content-guide/#third-party-content"content guide</abefore submitting a change.
Related:
How about:
LGTM, I'll go ahead and implement. Thank you for the edit!
Hello , Some late feedback (sorry I missed the meeting): Since this is a "special" note, I think it warrants a different color on the left hand border. Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? The language in the third party content message is a bit obtuse. When this label is applied, can the reader assume that all content on the page falls under these guidelines? This sentence, "Kubernetes project authors are not responsible for these projects" seems repetitive. Third party implies an external source and outside of the project's domain.

Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? All good feedback. How would you phrase it differently?
Hi. I am not entirely sure. The text is okay, though, it may not be clear about what is "required for Kubernetes to function". What do you want readers to do: determine if their project belongs in the section (read the content guide) read the content as third party content (Sig Docs is hosting the links but not responsible for the content on the page)? [One idea:] This section links to third party projects and follows [CNCF website guidelines] by listing projects alphabetically. [Do you want to suggest adding content or not?] If you are considering adding content in this section, read the before submitting a change. [Do you need a statement about content responsibility?]
Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? I think this is a good suggestion. I'll update the PR. What do you want readers to do: This section links to third party projects and follows [CNCF website guidelines] by listing projects alphabetically. If you are considering adding content in this section, read the content guide before submitting a change. Is this blocking for the PR? If we can't come up with a concrete alternative, I'd prefer to merge the PR, re-open this issue, and continue to work on the wording. Would that be okay,
Sure . I think what you have is fine. As an aside, did you consider using the theme's shortcode (which has a parameter)? It may work as well as wrapping the "third party content" shortcode in a note/warning shortcode. I think you can set the attribute too.
I'm imagining a one-line shortcode that, when rendered, closely matches the styles of existing callouts. I'd rather not use callouts from the Docsy theme because that's different from our existing callouts (something to handle in a separate issue, I feel). Wording-wise I'm happy to see something merged and leave room to iterate. Would you be happy to implement that?
Hi.

I agree, let's get this change moving forward with a single line shortcode with similar styling to the existing callouts. The shortcode would use two template strings: one variable for the message title and another variable for the message body. In the future, I could imagine a flexible interface or more generic shortcode that accepts at least one argument: the name of the variable representing the message title.


Question: {{< note >}} Para fazer o download de uma versão específica, substitua a parte `$(curl -L -s https://dl.k8s.io/release/stable.txt)` do comando pela versão específica. <del> Por exemplo, para fazer download da versão {{< param "fullversion" >}} no Linux, digite: </del> <ins> Por exemplo, para fazer download da versão {{< skew currentPatchVersion >}} no Linux, digite: </ins> ```bash <del> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/linux/amd64/kubectl </ins> ``` {{< /note >}}

Parent issue: Replace the deprecated shortcode with the shortcode in the Brazilian Portuguese localized docs. /assign /triage accepted /language pt


Question: ### DeletionPolicy <del> Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to is to be deleted. The deletionPolicy of a volume snapshot class can either be `Retain` or `Delete`. This field must be specified. </del> <ins> Volume snapshot classes have a [deletionPolicy](/docs/concepts/storage/volume-snapshots/#delete). It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to is to be deleted. The deletionPolicy of a volume snapshot class can either be `Retain` or `Delete`. This field must be specified. </ins> If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the VolumeSnapshotContent object. If the deletionPolicy is `Retain`,

The is a typo in the Deletion Policy section "It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to is to be deleted."
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
Can you please provide the issue description?
/triage needs-information /language en
The is a typo in the section "It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to is to be deleted."
Hey Can you tell me what's the type exactly in ?
/assign
Hi I'm not sure what they tried to say. My guess is this:
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]:
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]:
/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 . /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 . /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 .

/lifecycle stale [1]:
/remove-lifecycle-stale
Ugh. Typo. /remove-lifecycle stale
: The wording is correct IMO. The deletion policy allows you to configure what happens to a when the associated object will be deleted. For reference, if you checkout on the Volume Snapshots page, it explicitly states how the policy affects the behavior.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
I agree with It seems good. For better understanding can we link the of the Volume Snapshots page under the of the Volume Snapshot Classes? WDYT?
Hi, your thoughts on the above comment?
If anyone'd like to add that hyperlink, they are welcome to. /remove-triage needs-information /retitle Suggestion for
Thanks I will add hyperlink for it.
/assign
Added the hyperlink through the following PR:


Question: <ins> --- title: SIG Docsへの参加 content_type: concept weight: 60 card: name: contribute weight: 60 --- <!-- overview --> SIG Docsは、Kubernetesプロジェクト内の [special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)の1つであり、 Kubernetes全体のドキュメントの作成、更新、および保守に重点を置いています。 SIGの詳細については、[SIG DocsのGithubリポジトリ](https://github.com/kubernetes/community/blob/master/sig-list.md)を参照してください。 SIG Docsは、すべての寄稿者からのコンテンツとレビューを歓迎します。 誰でもPull Request(PR)を開くことができ、コンテンツに関するissueを提出したり、進行中のPull Requestにコメントしたりできます。 あなたは、[member](/docs/contribute/participate/roles-and-responsibilities/#members)や、 [reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers)、 [approver](/docs/contribute/participate/roles-and-responsibilities/#approvers)になることもできます。 これらの役割にはより多くのアクセスが必要であり、変更を承認およびコミットするための特定の責任が伴います。 Kubernetesコミュニティ内でメンバーシップがどのように機能するかについての詳細は、 [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) をご覧ください。 このドキュメントの残りの部分では、kubernetesの中で最も広く公開されている Kubernetesのウェブサイトとドキュメントの管理を担当しているSIG Docsの中で、これらの役割がどのように機能するのかを概説します。 <!-- body --> ## SIG Docs chairperson SIG Docsを含む各SIGは、議長として機能する1人以上のSIGメンバーを選択します。 これらは、SIGDocsとKubernetes organizationの他の部分との連絡先です。 それらには、Kubernetesプロジェクト全体の構造と、SIG Docsがその中でどのように機能するかについての広範な知識が必要です。 現在のchairpersonのリストについては、 [Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) を参照してください。 ## SIG Docs teamsと自動化 SIG Docsの自動化は、GitHub teamsとOWNERSファイルの2つの異なるメカニズムに依存しています。 ### GitHub teams GitHubには、二つのSIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) カテゴリがあります: - `@sig-docs-{language}-owners`は承認者かつリードです。 - `@sig-docs-{language}-reviewers` はレビュアーです。 それぞれをGitHubコメントの`@name`で参照して、そのグループの全員とコミュニケーションできます。 ProwチームとGitHub teamsが完全に一致せずに重複する場合があります。 問題の割り当て、Pull Request、およびPR承認のサポートのために、自動化ではOWNERSファイルからの情報を使用します。 ### OWNERSファイルとfront-matter Kubernetesプロジェクトは、GitHubのissueとPull Requestに関連する自動化のためにprowと呼ばれる自動化ツールを使用します。 [Kubernetes Webサイトリポジトリ](https://github.com/kubernetes/website) は、2つの[prowプラグイン](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)を使用します： - blunderbuss - approve これらの2つのプラグインは`kubernetes.website`のGithubリポジトリのトップレベルにある [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)ファイルと、 [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)ファイルを使用して、 リポジトリ内でのprowの動作を制御します。 OWNERSファイルには、SIG Docsのレビュー担当者および承認者であるユーザーのリストが含まれています。 OWNERSファイルはサブディレクトリに存在することもでき、そのサブディレクトリとその子孫のファイルのレビュー担当者または承認者として機能できるユーザーを上書きできます。 一般的なOWNERSファイルの詳細については、 [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)を参照してください。 さらに、個々のMarkdownファイルは、個々のGitHubユーザー名またはGitHubグループを一覧表示することにより、そのfront-matterでレビュー担当者と承認者を一覧表示できます。 OWNERSファイルとMarkdownファイルのfront-matterの組み合わせにより、PRの技術的および編集上のレビューを誰に依頼するかについてPRの所有者が自動化システムから得るアドバイスが決まります。 ## マージの仕組み Pull Requestがコンテンツの公開に使用されるブランチにマージされると、そのコンテンツは http://kubernetes.io に公開されます。 公開されたコンテンツの品質を高くするために、Pull RequestのマージはSIG Docsの承認者に限定しています。仕組みは次のとおりです。 - Pull Requestに`lgtm`ラベルと`approve`ラベルの両方があり、`hold`ラベルがなく、すべてのテストに合格すると、Pull Requestは自動的にマージされます。 - Kubernetes organizationのメンバーとSIG Docsの承認者はコメントを追加して、特定のPull Requestが自動的にマージされないようにすることができます(`/hold`コメントを追加するか、`/lgtm`コメントを保留します)。 - Kubernetesメンバーは誰でも、`/lgtm`コメントを追加することで`lgtm`ラベルを追加できます。 - `/approve`コメントを追加してPull Requestをマージできるのは、SIG Docsの承認者だけです。一部の承認者は、[PR Wrangler](/docs/contribute/participate/pr-wranglers/)や[SIG Docsのchairperson](#sig-docs-chairperson)など、追加の特定の役割も実行します。 ## {{% heading "whatsnext" %}} Kubernetesドキュメントへの貢献の詳細については、以下を参照してください： - [Contributing new content](/docs/contribute/new-content/overview/) - [Reviewing content](/docs/contribute/review/reviewing-prs) - [ドキュメントスタイルの概要](/ja/docs/contribute/style/) </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Japanese Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted


Question: <del> --- reviewers: - stclair title: Restrict a Container's Access to Resources with AppArmor content_type: tutorial weight: 10 --- <!-- overview --> {{< feature-state for_k8s_version="v1.4" state="beta" >}} AppArmor is a Linux kernel security module that supplements the standard Linux user and group based permissions to confine programs to a limited set of resources. AppArmor can be configured for any application to reduce its potential attack surface and provide greater in-depth defense. It is configured through profiles tuned to allow the access needed by a specific program or container, such as Linux capabilities, network access, file permissions, etc. Each profile can be run in either *enforcing* mode, which blocks access to disallowed resources, or *complain* mode, which only reports violations. AppArmor can help you to run a more secure deployment by restricting what containers are allowed to do, and/or provide better auditing through system logs. However, it is important to keep in mind that AppArmor is not a silver bullet and can only do so much to protect against exploits in your application code. It is important to provide good, restrictive profiles, and harden your applications and cluster from other angles as well. ## {{% heading "objectives" %}} * See an example of how to load a profile on a node * Learn how to enforce the profile on a Pod * Learn how to check that the profile is loaded * See what happens when a profile is violated * See what happens when a profile cannot be loaded ## {{% heading "prerequisites" %}} Make sure: 1. Kubernetes version is at least v1.4 -- Kubernetes support for AppArmor was added in v1.4. Kubernetes components older than v1.4 are not aware of the new AppArmor annotations, and will **silently ignore** any AppArmor settings that are provided. To ensure that your Pods are receiving the expected protections, it is important to verify the Kubelet version of your nodes: ```shell kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}n{end}' ``` ``` gke-test-default-pool-239f5d02-gyn2: v1.4.0 gke-test-default-pool-239f5d02-x1kf: v1.4.0 gke-test-default-pool-239f5d02-xwux: v1.4.0 ``` 2. AppArmor kernel module is enabled -- For the Linux kernel to enforce an AppArmor profile, the AppArmor kernel module must be installed and enabled. Several distributions enable the module by default, such as Ubuntu and SUSE, and many others provide optional support. To check whether the module is enabled, check the `/sys/module/apparmor/parameters/enabled` file: ```shell cat /sys/module/apparmor/parameters/enabled Y ``` If the Kubelet contains AppArmor support (>= v1.4), it will refuse to run a Pod with AppArmor options if the kernel module is not enabled. {{< note >}} Ubuntu carries many AppArmor patches that have not been merged into the upstream Linux kernel, including patches that add additional hooks and features. Kubernetes has only been tested with the upstream version, and does not promise support for other features. {{< /note >}} 3. Container runtime supports AppArmor -- Currently all common Kubernetes-supported container runtimes should support AppArmor, like {{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="cri-o" >}} or {{< glossary_tooltip term_id="containerd" >}}. Please refer to the corresponding runtime documentation and verify that the cluster fulfills the requirements to use AppArmor. 4. Profile is loaded -- AppArmor is applied to a Pod by specifying an AppArmor profile that each container should be run with. If any of the specified profiles is not already loaded in the kernel, the Kubelet (>= v1.4) will reject the Pod. You can view which profiles are loaded on a node by checking the `/sys/kernel/security/apparmor/profiles` file. For example: ```shell ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort" ``` ``` apparmor-test-deny-write (enforce) apparmor-test-audit-write (enforce) docker-default (enforce) k8s-nginx (enforce) ``` For more details on loading profiles on nodes, see [Setting up nodes with profiles](#setting-up-nodes-with-profiles). As long as the Kubelet version includes AppArmor support (>= v1.4), the Kubelet will reject a Pod with AppArmor options if any of the prerequisites are not met. You can also verify AppArmor support on nodes by checking the node ready condition message (though this is likely to be removed in a later release): ```shell kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}n{end}' ``` ``` gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor enabled gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled ``` <!-- lessoncontent --> ## Securing a Pod {{< note >}} AppArmor is currently in beta, so options are specified as annotations. Once support graduates to general availability, the annotations will be replaced with first-class fields (more details in [Upgrade path to GA](#upgrade-path-to-general-availability)). {{< /note >}} AppArmor profiles are specified *per-container*. To specify the AppArmor profile to run a Pod container with, add an annotation to the Pod's metadata: ```yaml container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref> ``` Where `<container_name>` is the name of the container to apply the profile to, and `<profile_ref>` specifies the profile to apply. The `profile_ref` can be one of: * `runtime/default` to apply the runtime's default profile * `localhost/<profile_name>` to apply the profile loaded on the host with the name `<profile_name>` * `unconfined` to indicate that no profiles will be loaded See the [API Reference](#api-reference) for the full details on the annotation and profile name formats. Kubernetes AppArmor enforcement works by first checking that all the prerequisites have been met, and then forwarding the profile selection to the container runtime for enforcement. If the prerequisites have not been met, the Pod will be rejected, and will not run. To verify that the profile was applied, you can look for the AppArmor security option listed in the container created event: ```shell kubectl get events | grep Created ``` ``` 22s        22s         1         hello-apparmor     Pod       spec.containers{hello}   Normal    Created     {kubelet e2e-test-stclair-node-pool-31nt}   Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write] ``` You can also verify directly that the container's root process is running with the correct profile by checking its proc attr: ```shell kubectl exec <pod_name> cat /proc/1/attr/current ``` ``` k8s-apparmor-example-deny-write (enforce) ``` ## Example *This example assumes you have already set up a cluster with AppArmor support.* First, we need to load the profile we want to use onto our nodes. This profile denies all file writes: ```shell #include <tunables/global> profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { #include <abstractions/base> file, # Deny all file writes. deny /** w, } ``` Since we don't know where the Pod will be scheduled, we'll need to load the profile on all our nodes. For this example we'll use SSH to install the profiles, but other approaches are discussed in [Setting up nodes with profiles](#setting-up-nodes-with-profiles). ```shell NODES=( # The SSH-accessible domain names of your nodes gke-test-default-pool-239f5d02-gyn2.us-central1-a.my-k8s gke-test-default-pool-239f5d02-x1kf.us-central1-a.my-k8s gke-test-default-pool-239f5d02-xwux.us-central1-a.my-k8s) for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF #include <tunables/global> profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { #include <abstractions/base> file, # Deny all file writes. deny /** w, } EOF' done ``` Next, we'll run a simple "Hello AppArmor" pod with the deny-write profile: {{< codenew file="pods/security/hello-apparmor.yaml" >}} ```shell kubectl create -f ./hello-apparmor.yaml ``` If we look at the pod events, we can see that the Pod container was created with the AppArmor profile "k8s-apparmor-example-deny-write": ```shell kubectl get events | grep hello-apparmor ``` ``` 14s        14s         1         hello-apparmor   Pod                                Normal    Scheduled   {default-scheduler }                           Successfully assigned hello-apparmor to gke-test-default-pool-239f5d02-gyn2 14s        14s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Pulling     {kubelet gke-test-default-pool-239f5d02-gyn2}   pulling image "busybox" 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Pulled      {kubelet gke-test-default-pool-239f5d02-gyn2}   Successfully pulled image "busybox" 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Created     {kubelet gke-test-default-pool-239f5d02-gyn2}   Created container with docker id 06b6cd1c0989; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write] 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Started     {kubelet gke-test-default-pool-239f5d02-gyn2}   Started container with docker id 06b6cd1c0989 ``` We can verify that the container is actually running with that profile by checking its proc attr: ```shell kubectl exec hello-apparmor -- cat /proc/1/attr/current ``` ``` k8s-apparmor-example-deny-write (enforce) ``` Finally, we can see what happens if we try to violate the profile by writing to a file: ```shell kubectl exec hello-apparmor -- touch /tmp/test ``` ``` touch: /tmp/test: Permission denied error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1 ``` To wrap up, let's look at what happens if we try to specify a profile that hasn't been loaded: ```shell kubectl create -f /dev/stdin <<EOF ``` ```yaml apiVersion: v1 kind: Pod metadata: name: hello-apparmor-2 annotations: container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-allow-write spec: containers: - name: hello image: busybox command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ] EOF pod/hello-apparmor-2 created ``` ```shell kubectl describe pod hello-apparmor-2 ``` ``` Name:          hello-apparmor-2 Namespace:     default Node:          gke-test-default-pool-239f5d02-x1kf/ Start Time:    Tue, 30 Aug 2016 17:58:56 -0700 Labels:        <none> Annotations:   container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write Status:        Pending Reason:        AppArmor Message:       Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded IP: Controllers:   <none> Containers: hello: Container ID: Image:     busybox Image ID: Port: Command: sh -c echo 'Hello AppArmor!' && sleep 1h State:              Waiting Reason:           Blocked Ready:              False Restart Count:      0 Environment:        <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-dnz7v (ro) Conditions: Type          Status Initialized   True Ready         False PodScheduled  True Volumes: default-token-dnz7v: Type:    Secret (a volume populated by a Secret) SecretName:    default-token-dnz7v Optional:   false QoS Class:      BestEffort Node-Selectors: <none> Tolerations:    <none> Events: FirstSeen    LastSeen    Count    From                        SubobjectPath    Type        Reason        Message ---------    --------    -----    ----                        -------------    --------    ------        ------- 23s          23s         1        {default-scheduler }                         Normal      Scheduled     Successfully assigned hello-apparmor-2 to e2e-test-stclair-node-pool-t1f5 23s          23s         1        {kubelet e2e-test-stclair-node-pool-t1f5}             Warning        AppArmor    Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded ``` Note the pod status is Pending, with a helpful error message: `Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded`. An event was also recorded with the same message. ## Administration ### Setting up nodes with profiles Kubernetes does not currently provide any native mechanisms for loading AppArmor profiles onto nodes. There are lots of ways to setup the profiles though, such as: * Through a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) that runs a Pod on each node to ensure the correct profiles are loaded. An example implementation can be found [here](https://git.k8s.io/kubernetes/test/images/apparmor-loader). * At node initialization time, using your node initialization scripts (e.g. Salt, Ansible, etc.) or image. * By copying the profiles to each node and loading them through SSH, as demonstrated in the [Example](#example). The scheduler is not aware of which profiles are loaded onto which node, so the full set of profiles must be loaded onto every node.  An alternative approach is to add a node label for each profile (or class of profiles) on the node, and use a [node selector](/docs/concepts/scheduling-eviction/assign-pod-node/) to ensure the Pod is run on a node with the required profile. ### Restricting profiles with the PodSecurityPolicy {{< note >}} PodSecurityPolicy is deprecated in Kubernetes v1.21, and will be removed in v1.25. See [PodSecurityPolicy documentation](/docs/concepts/policy/pod-security-policy/) for more information. {{< /note >}} If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To enable the PodSecurityPolicy, the following flag must be set on the `apiserver`: ``` --enable-admission-plugins=PodSecurityPolicy[,others...] ``` The AppArmor options can be specified as annotations on the PodSecurityPolicy: ```yaml apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref> apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others...] ``` The default profile name option specifies the profile to apply to containers by default when none is specified. The allowed profile names option specifies a list of profiles that Pod containers are allowed to be run with. If both options are provided, the default must be allowed. The profiles are specified in the same format as on containers. See the [API Reference](#api-reference) for the full specification. ### Disabling AppArmor If you do not want AppArmor to be available on your cluster, it can be disabled by a command-line flag: ``` --feature-gates=AppArmor=false ``` When disabled, any Pod that includes an AppArmor profile will fail validation with a "Forbidden" error. Note that by default docker always enables the "docker-default" profile on non-privileged pods (if the AppArmor kernel module is enabled), and will continue to do so even if the feature-gate is disabled. The option to disable AppArmor will be removed when AppArmor graduates to general availability (GA). ### Upgrading to Kubernetes v1.4 with AppArmor No action is required with respect to AppArmor to upgrade your cluster to v1.4. However, if any existing pods had an AppArmor annotation, they will not go through validation (or PodSecurityPolicy admission). If permissive profiles are loaded on the nodes, a malicious user could pre-apply a permissive profile to escalate the pod privileges above the docker-default. If this is a concern, it is recommended to scrub the cluster of any pods containing an annotation with `apparmor.security.beta.kubernetes.io`. ### Upgrade path to General Availability When AppArmor is ready to be graduated to general availability (GA), the options currently specified through annotations will be converted to fields. Supporting all the upgrade and downgrade paths through the transition is very nuanced, and will be explained in detail when the transition occurs. We will commit to supporting both fields and annotations for at least 2 releases, and will explicitly reject the annotations for at least 2 releases after that. ## Authoring Profiles Getting AppArmor profiles specified correctly can be a tricky business. Fortunately there are some tools to help with that: * `aa-genprof` and `aa-logprof` generate profile rules by monitoring an application's activity and logs, and admitting the actions it takes. Further instructions are provided by the [AppArmor documentation](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools). * [bane](https://github.com/jfrazelle/bane) is an AppArmor profile generator for Docker that uses a simplified profile language. It is recommended to run your application through Docker on a development workstation to generate the profiles, but there is nothing preventing running the tools on the Kubernetes node where your Pod is running. To debug problems with AppArmor, you can check the system logs to see what, specifically, was denied. AppArmor logs verbose messages to `dmesg`, and errors can usually be found in the system logs or through `journalctl`. More information is provided in [AppArmor failures](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures). ## API Reference ### Pod Annotation Specifying the profile a container will run with: - **key**: `container.apparmor.security.beta.kubernetes.io/<container_name>` Where `<container_name>` matches the name of a container in the Pod. A separate profile can be specified for each container in the Pod. - **value**: a profile reference, described below ### Profile Reference - `runtime/default`: Refers to the default runtime profile. - Equivalent to not specifying a profile (without a PodSecurityPolicy default), except it still requires AppArmor to be enabled. - For Docker, this resolves to the [`docker-default`](https://docs.docker.com/engine/security/apparmor/) profile for non-privileged containers, and unconfined (no profile) for privileged containers. - `localhost/<profile_name>`: Refers to a profile loaded on the node (localhost) by name. - The possible profile names are detailed in the [core policy reference](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications). - `unconfined`: This effectively disables AppArmor on the container. Any other profile reference format is invalid. ### PodSecurityPolicy Annotations Specifying the default profile to apply to containers when none is provided: * **key**: `apparmor.security.beta.kubernetes.io/defaultProfileName` * **value**: a profile reference, described above Specifying the list of profiles Pod containers is allowed to specify: * **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames` * **value**: a comma-separated list of profile references (described above) - Although an escaped comma is a legal character in a profile name, it cannot be explicitly allowed here. ## {{% heading "whatsnext" %}} Additional resources: * [Quick guide to the AppArmor profile language](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage) * [AppArmor core policy reference](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout) </del>

This is a Feature Request What would you like to be Post-merge of , move the tutorials under into Merge clusters section into security section here: Why is this needed Issue description is a slight modification from original request in the comment Comments /hold for /cc /sig docs security
this might be a good first issue for new contributors in sig-security-docs /triage accepted
Hi, I would like to work on this issue. /assign
/kind cleanup
Hi , I a query: moving the tutorials from the cluster sub-directory into the security sub-directory, the cluster sub-directory will only have its file so do I need to do something regarding it ( file)? Thanks
Whenever you are free can you please help me with the above mentioned query. Thanks


Question: * [Romana](/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/) * [Weave Net](/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/) <del> {{< note >}} The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers. {{< /note >}} </del> <!-- steps --> ## Create an `nginx` deployment and expose it via a service

Per our discussion in today's SIG Docs: Sections of the site, like will always have some degree of 3rd party content, due to the fact that a k8s developer must implement an external networking CNI. The majority of post-3rd party content KEP PR's we get that actually involve third party content are to pages like this one. A part of the reasons is that a change like the KEP requires initial communication (which was well done) but also ongoing communication. This change proposes the following: Create a reusable Note or similar shortcode for pages that fall under . The note should: Be translatable (use a key) Warn people that they must use a 3rd party plugin/software for this step Indicate that per the projects are listed alphabetically Indicate that additions to this list/page must directly provide a solution for this step of an implementation (i.e. for the cluster networking page, projects listed must provide a networking solution – no 'nice to haves' that make networking easier or somehow nicer.) Link to the content guidelines for more info on acceptable additions to the page.
/assign /area web-development /priority important-longterm
/language en
Wording for review: This section contains links to third party projects which provide functionality required by Kubernetes. The Kubernetes project authors are not responsible for these projects. Projects are listed alphabetically, in accordance with [CNCF website guidelines]. To add a project to this list, read the <a href="/contribute/style/content-guide/#third-party-content"content guide</abefore submitting a change.
Related:
How about:
LGTM, I'll go ahead and implement. Thank you for the edit!
Hello , Some late feedback (sorry I missed the meeting): Since this is a "special" note, I think it warrants a different color on the left hand border. Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? The language in the third party content message is a bit obtuse. When this label is applied, can the reader assume that all content on the page falls under these guidelines? This sentence, "Kubernetes project authors are not responsible for these projects" seems repetitive. Third party implies an external source and outside of the project's domain.

Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? All good feedback. How would you phrase it differently?
Hi. I am not entirely sure. The text is okay, though, it may not be clear about what is "required for Kubernetes to function". What do you want readers to do: determine if their project belongs in the section (read the content guide) read the content as third party content (Sig Docs is hosting the links but not responsible for the content on the page)? [One idea:] This section links to third party projects and follows [CNCF website guidelines] by listing projects alphabetically. [Do you want to suggest adding content or not?] If you are considering adding content in this section, read the before submitting a change. [Do you need a statement about content responsibility?]
Is there another shortcode besides note or warning that could be used to set off the text? Could substitute the shortcode "Note" text with "Third party content"? I think this is a good suggestion. I'll update the PR. What do you want readers to do: This section links to third party projects and follows [CNCF website guidelines] by listing projects alphabetically. If you are considering adding content in this section, read the content guide before submitting a change. Is this blocking for the PR? If we can't come up with a concrete alternative, I'd prefer to merge the PR, re-open this issue, and continue to work on the wording. Would that be okay,
Sure . I think what you have is fine. As an aside, did you consider using the theme's shortcode (which has a parameter)? It may work as well as wrapping the "third party content" shortcode in a note/warning shortcode. I think you can set the attribute too.
I'm imagining a one-line shortcode that, when rendered, closely matches the styles of existing callouts. I'd rather not use callouts from the Docsy theme because that's different from our existing callouts (something to handle in a separate issue, I feel). Wording-wise I'm happy to see something merged and leave room to iterate. Would you be happy to implement that?
Hi.

I agree, let's get this change moving forward with a single line shortcode with similar styling to the existing callouts. The shortcode would use two template strings: one variable for the message title and another variable for the message body. In the future, I could imagine a flexible interface or more generic shortcode that accepts at least one argument: the name of the variable representing the message title.


Question: この場合、なにも操作する必要はありません。 {{< note >}} <del> Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。 </del> <ins> Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルを読み込むため、後者の2つの方法が機能します。 </ins> {{< /note >}} どの場合でも、シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。

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. --Update Why is this needed Reflect the following feedback on this file, too. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/area localization /triage accepted


Question: labels: k8s-app: kube-dns-autoscaler kubernetes.io/cluster-service: "true" <del> addonmanager.kubernetes.io/mode: Reconcile </del> spec: selector: matchLabels:

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: mentions an annotation prefix that is deprecated / not actually official. Proposed Solution: Remove all mention of annotations from that page. Page to Update: and specifically Additional Information: This is a follow-up to /language en
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Remove labels from ”Autoscale the DNS Service in a Cluster”
/assign


Question: il ajoute une étiquette, `statefulset.kubernetes.io/pod-name`, renseignée avec le nom du Pod. Cette étiquette vous permet d'attacher un Service à un Pod spécifique du StatefulSet. <del> ## Garanties de déploiment et de mise à l'échelle </del> <ins> ## Garanties de déploiement et de mise à l'échelle </ins> * Pour un StatefulSet avec N réplicas, lorsque les Pods sont déployés, ils sont créés de manière séquentielle, dans l'ordre {0..N-1}. * Lorsque les Pods sont supprimés, ils sont terminés dans l'ordre inverse, {N-1..0}.

Typo in frensh Statefulset documentation: Garanties de déploiment et de mise à l'échelle -Garanties de déploiement et de mise à l'échelle
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind bug /language fr
/assign


Question: 1. Загрузите последнюю версию: ``` <del> curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" </del> <ins> curl -LO "https://dl.k8s.io/release/$(curl -LS https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" </ins> ``` <del> Чтобы загрузить определенную версию, вставьте в фрагмент команды `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` нужную версию. </del> <ins> Чтобы загрузить определенную версию, вставьте в фрагмент команды `$(curl -LS https://dl.k8s.io/release/stable.txt)` нужную версию. </ins> Например, команда загрузки версии {{< param "fullversion" >}} для macOS будет выглядеть следующим образом: ``` <del> curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl </ins> ``` 2. Сделайте двоичный файл kubectl исполняемым:

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: There are still references to instead of is the correct advertised download host and will eventually move to be fastly shielding a fully community-owned bucket ref: Proposed Solution: Replace with Also replace any references with using if applicable. Page to Update: Assorted e.g. , <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
hi Not a problem, didn't see anyone assigned to this issue. I am unassigning myself and assigning it to you. /unassign
/assign
Hi, I found a small issue with your proposed changes regarding one of the URLs, which is mentioned twice in the file. While returns as expected, I am getting an nginx-rendered HTML page saying for the new command () instead. As I understand, it happens due to the redirect configured on the new web server. Thus, works fine for me (it returns as expected).
i see Let me update it, thanks your work
Just done, please review all of PRs
Thanks!
And yes: These will need to follow redirects, in the future the tentative plan is it will redirect to a CDN in front of a different bucket created in a fully project / SIG-K8s-Infra controlled GCP or AWS account. I would recommend for downloading with curl more generally, even in docs / usage for other hosts.


Question: kube-proxy | kube-proxy | Kubelet | Kubelet | Kubernetes | 쿠버네티스 | <ins> Kube-router | Kube-router | </ins> label | 레이블 | lifecycle | 라이프사이클 | Linux | 리눅스 |

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. --There are several CNI plugins that need to be translated into Korean to be to . English --- --- Calico Cilium Flannel Kube-router Romana Weave-net Weaveworks 'Weave Net' . Why is this needed This is for standardization of terminology when document is localized. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --Page to update: - /language ko
/assign


Question: where: <del> * `<your-registry-server>` is your Private Docker Registry FQDN. (https://index.docker.io/v1/ for DockerHub) </del> <ins> * `<your-registry-server>` is your Private Docker Registry FQDN. Use `https://index.docker.io/v2/` for DockerHub. </ins> * `<your-name>` is your Docker username. * `<your-pword>` is your Docker password. * `<your-email>` is your Docker email.

This link "" appears to be broken in the line: " <your-registry-serveris your Private Docker Registry FQDN. ( for DockerHub) "
According to , the V1 API has been deprecated.
/triage accepted /assign


Question: ### オブジェクトリストのソート <del> ターミナルウィンドウで、オブジェクトをソートされたリストに出力するには、サポートされている`kubectl`コマンドに`--sort-by`フラグを追加します。`--sort-by`フラグで任意の数値フィールドや文字列フィールドを指定することで、オブジェクトをソートします。フィールドの指定には、[jsonpath](/docs/reference/kubectl/jsonpath/)式を使用します。 </del> <ins> ターミナルウィンドウで、オブジェクトをソートされたリストに出力するには、サポートされている`kubectl`コマンドに`--sort-by`フラグを追加します。`--sort-by`フラグで任意の数値フィールドや文字列フィールドを指定することで、オブジェクトをソートします。フィールドの指定には、[jsonpath](/ja/docs/reference/kubectl/jsonpath/)式を使用します。 </ins> #### 構文

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate reference/kubectl/jsonpath/ into Japanese. Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted


Question: <ins> <?xml version="1.0" encoding="utf-8"?> <!-- Generator: Adobe Illustrator 19.2.1, SVG Export Plug-In . SVG Version: 6.00 Build 0)  --> <svg version="1.1" id="svg2" inkscape:export-filename="/usr/local/google/home/thockin/src/kubernetes/docs/services-ipvs-overview.png" inkscape:export-xdpi="76.910004" inkscape:export-ydpi="76.910004" inkscape:version="0.48.4 r9939" sodipodi:docname="services-ipvs-overview.svg" xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 656 486" style="enable-background:new 0 0 656 486;" xml:space="preserve"> <style type="text/css"> .st0{fill:none;stroke:#000000;stroke-width:0.8425;} .st1{fill:none;stroke:#000000;stroke-width:2.0786;} .st2{stroke:#000000;stroke-width:2.0786;stroke-linecap:round;} .st3{fill:none;stroke:#000000;stroke-width:5;} .st4{stroke:#000000;stroke-width:4.7036;stroke-linecap:round;} .st5{fill:none;stroke:#000000;stroke-width:4.2928;} .st6{stroke:#000000;stroke-width:4.2928;stroke-linecap:round;} .st7{fill:#85BFF1;stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round;} .st8{font-family:'ArialMT';} .st9{font-size:32px;} .st10{font-size:24px;} .st11{fill:none;stroke:#000000;stroke-width:5.1965;} .st12{stroke:#000000;stroke-width:5.1965;stroke-linecap:round;} .st13{fill:#F1CB85;stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round;} .st14{fill:#B9F185;stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round;} .st15{fill:#EDC1F8;stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round;} .st16{fill:#FFE680;stroke:#000000;stroke-width:1.7787;} .st17{font-family:'MyriadPro-Regular';} .st18{font-size:40px;} </style> <sodipodi:namedview  bordercolor="#666666" borderopacity="1.0" id="base" inkscape:current-layer="layer1" inkscape:cx="115.9218" inkscape:cy="392.30545" inkscape:document-units="px" inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:window-height="822" inkscape:window-maximized="0" inkscape:window-width="1552" inkscape:window-x="203" inkscape:window-y="50" inkscape:zoom="1.0318369" pagecolor="#ffffff" showgrid="false"> </sodipodi:namedview> <g id="layer1" inkscape:groupmode="layer" inkscape:label="Layer 1"> <rect id="rect3116" height="105.80995" width="645.257723" class="st0" y="350.381592" x="5	.318098"/> <rect id="rect3115" x="104.3" y="72.5" class="st0" width="545.8" height="253.1"/> <g id="g4178-3-0" transform="matrix(1,0,0,-0.92578962,15.303948,1193.1996)"> <path id="path4174-3-7" inkscape:connector-curvature="0" class="st1" d="M485.1,1264.5c0-71.3,0-71.3,0-71.3"/> <path id="path4176-9-1" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st2" d=" M476.8,1202.5l8.7-15l8.7,15H476.8z"/> </g> <g id="g4178-3-8" transform="matrix(-0.83212211,-1.1231515,0.89570092,-0.89430772,-72.942206,1678.3161)" inkscape:transform-center-x="84.098741" inkscape:transform-center-y="1.4572787e-05"> <path id="path4174-3-4" inkscape:connector-curvature="0" class="st1" d="M501.5,1075.9c0-71.3,0-71.3,0-71.3"/> <path id="path4176-9-0" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st2" d=" M493.2,1013.9l8.7-15l8.7,15L493.2,1013.9z"/> </g> <g id="g4324" transform="matrix(0.96592583,0.25881905,0.25881905,-0.96592583,-272.81074,1126.238)"> <path id="path4174-3-2" inkscape:connector-curvature="0" class="st3" d="M362,988.4C260,874.6,260,874.6,260,874.6"/> <path id="path4176-9-9" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st4" d=" M253,881.5l-4.8-18.4l17.8,6.9L253,881.5z"/> </g> <g id="g4324-8" transform="matrix(-0.96592583,0.25881905,-0.25881905,-0.96592583,654.32964,1126.238)"> <path id="path4174-3-2-7" inkscape:connector-curvature="0" class="st3" d="M76.1,911.8C-25.9,798-25.9,798-25.9,798"/> <path id="path4176-9-9-3" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st4" d=" M-32.9,804.9l-4.8-18.4l17.8,6.9L-32.9,804.9z"/> </g> <g id="g4178-3-9" transform="matrix(1,0,0,-1.3566066,-154.75999,1749.5431)"> <path id="path4174-3-8" inkscape:connector-curvature="0" class="st5" d="M485.1,1103.7c0-71.3,0-71.3,0-71.3"/> <path id="path4176-9-5" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st6" d=" M476.8,1041.6l8.7-15l8.7,15H476.8z"/> </g> <g id="g3937" transform="translate(-212.35646,769.73074)"> <g id="g3868" transform="matrix(0.88792337,0,0,1,43.50975,6.5250001e-6)"> <rect id="rect2985" x="196.7" y="-408.1" class="st7" width="224.3" height="50"/> <g id="g3861"> <text transform="matrix(1 0 0 1 203.3918 -377.1545)" class="st8 st9">Backend Pod 1</text> </g> </g> <g id="g3868-7" transform="matrix(0.88792337,0,0,1,262.00231,6.5250001e-6)"> <rect id="rect2985-1" x="196.7" y="-408.1" class="st7" width="224.3" height="50"/> <g id="g3861-9"> <text transform="matrix(1 0 0 1 203.3919 -377.1545)" class="st8 st9">Backend Pod 2</text> </g> </g> <g id="g3868-3" transform="matrix(0.88792337,0,0,1,480.49489,6.5250001e-6)"> <rect id="rect2985-2" x="196.7" y="-408.1" class="st7" width="224.3" height="50"/> <g id="g3861-3"> <text transform="matrix(1 0 0 1 203.392 -377.1545)" class="st8 st9">Backend Pod 3</text> </g> </g> </g> <g id="g4178-3" transform="matrix(0.91192623,-0.41035418,-0.37990164,-0.84425184,113.60453,1385.4009)"> <path id="path4174-3" inkscape:connector-curvature="0" class="st11" d="M664.6,1154.3c0-71.3,0-71.3,0-71.3"/> <path id="path4176-9" inkscape:flatsided="true" inkscape:randomized="0" inkscape:rounded="0" inkscape:transform-center-y="-2.5" sodipodi:arg1="2.6179939" sodipodi:arg2="3.6651914" sodipodi:cx="308.85715" sodipodi:cy="753.79077" sodipodi:r1="10" sodipodi:r2="5" sodipodi:sides="3" sodipodi:type="star" class="st12" d=" M656.2,1092.3l8.7-15l8.7,15H656.2z"/> </g> <g id="g4090" transform="matrix(0.89067003,0,0,1,-194.97295,-142.36286)"> <rect id="rect2985-4" x="388" y="235.5" class="st13" width="224.3" height="58.6"/> <g id="g3861-6" transform="translate(217.6177,652.82516)"> <text transform="matrix(1 0 0 1 233.7419 -377.2347)" class="st8 st9">Client </text> </g> </g> <g id="g4168" transform="matrix(0.89067003,0,0,1,199.65922,-24.251798)"> <rect id="rect2985-4-0" x="216.9" y="119.8" class="st14" width="250" height="58.6"/> <g id="g3861-6-2" transform="translate(34.747433,534.26287)"> <text transform="matrix(1 0 0 1 226.622 -376.7865)" class="st8 st9">kube-proxy</text> </g> </g> <g id="g4168-5" transform="translate(188.04333,-29.041887)"> <g id="g4238" transform="translate(22.087429,-86.34177)"> <rect id="rect2985-4-0-6" x="199.9" y="119.8" class="st15" width="191.8" height="58.6"/> <g id="g3861-6-2-6" transform="translate(39.107429,534.26287)"> <text transform="matrix(1 0 0 1 184.7109 -377.1544)" class="st8 st9">apiserver</text> </g> </g> </g> <path id="path3884" inkscape:connector-curvature="0" class="st16" d="M332.5,202c-14.5,0-27,8.6-33,21.2c-5-0.9-10.3-1.4-15.8-1.4 c-34.3,0-62.2,19.1-62.2,42.6s27.8,42.6,62.2,42.6c16.9,0,32.2-4.6,43.4-12.2c7.4,16.3,34,28.3,65.7,28.3 c33.5,0,61.4-13.4,66.8-31.1c17-5.3,28.6-15.7,28.6-27.7c0-17.3-24.4-31.4-54.4-31.4c-8.5,0-16.5,1.1-23.6,3.1 c-2-10.5-14.8-18.6-30.3-18.6c-5.8,0-11.2,1.2-15.9,3.1C357.7,209.5,345.9,202,332.5,202L332.5,202z"/> <g id="g3861-6-28" transform="matrix(0.89067003,0,0,1,34.810052,629.61733)"> <text transform="matrix(1 0 0 1 259.8564 -379.173)" class="st8 st9">ServiceIP</text> <text transform="matrix(1 0 0 1 240.8564 -339.173)" class="st8 st9" fill="red">(Virtual Server) </text> </g> <text transform="matrix(1 0 0 1 537.5965 317.8163)" class="st17 st18">Node</text> <text transform="matrix(1 0 0 1 230 450)" class="st8 st9" fill="red">(Real Server) </text> </g> </svg> </ins>

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [x] Bug Report Problem: For users using K8S versions 1.8 and lower that don't have the fix contained in it may be necessary to set for the OpenStack cloud provider when installing on OpenStack clusters that expose their Cinder endpoint using paths rather than ports to avoid auto-detection errors such as: This includes for users trying out K8S on a devstack environment, and potentially other deployment tools. In this situation it is possible to resolve using: Valid values for are: With being the default. Proposed Solution: Highlight the bs-version parameter as optional (so not minimal configuration) but required in some circumstances. Page to Update:


Question:
 ## `ClientConnectionConfiguration`     {#ClientConnectionConfiguration} **Appears in:** - [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration) ClientConnectionConfiguration contains details for constructing a client.

Field	Description

kubeconfig [Required]
 string 	  kubeconfig is the path to a KubeConfig file.

acceptContentTypes [Required]
 string 	  acceptContentTypes defines the Accept header sent by clients when connecting to a server, overriding the default value of 'application/json'. This field will control all connections to the server used by a particular client.

contentType [Required]
 string 	  contentType is the content type used when sending data to the server from this client.

qps [Required]
 float32 	  qps controls the number of queries per second allowed for this connection.

burst [Required]
 int32 	  burst allows extra queries to accumulate when a client is exceeding its rate.

links to in the table, but does not exist. Probably it should be linked to another page?
/triage accepted /kind bug /assign


Question: cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes <del> baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch </del> <ins> baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch </ins> enabled=1 gpgcheck=1 repo_gpgcheck=1

This is a Bug Report Problem: The getting started guide doesn't work on CentOS 7.7.1908. The section Installing kubeadm, kubelet and kubectl contains an error in this line: Whereas is not defined. Proposed Solution: Replace with Page to Update:
Ah I'm wrong /remove-kind bug /remove-good-first-issue /remove-priority important-longterm /triage support
What's the error on CentOS 7.7.1908 YUM usually lets you use and other built-in variables in a repository configuration.
/remove-good-first-issue
/remove-help
The error is: As it seems is evaluated to "" BTW, returns empty as well.
Hmm. Try this: What's the output?
Loaded plugins: fastestmirror {'arch': 'ia32e', 'basearch': 'x86_64', 'contentdir': 'centos', 'infra': 'stock', 'releasever': '7', 'uuid': '-e4c7-4444-9d2f-'}
Looks like is set in YUM. The problem is that the page instructs the reader to use a “here document” to edit the YUM configuration. /remove-triage support /kind bug /sig cluster-lifecycle /priority important-soon thanks for clarifying.