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

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


Question: sudo sysctl --system ``` <del> Make sure that the `br_netfilter` module is loaded before this step. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`. </del> For more details please see the [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page. ## Check required ports

This paragraph is a bit backwards. It would be more intuitive to start with the "Make sure that the br_netfilter module is loaded before this step..." phrases.
/language en /kind cleanup /priority backlog /good-first-issue Thanks
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /language en /kind cleanup /priority backlog /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cluster-lifecycle


Question: - containerPort: 80 ``` <del> ### Deployment with kubeadm and cluster API </del> <ins> ### kubeadmとクラスターAPIを使用したデプロイ </ins> <del> Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm will come in a future release. We are also making investments in cluster API to ensure Windows nodes are properly provisioned. </del> <ins> Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは、将来のリリースで提供予定です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。 </ins> <del> ### A few other key features * Beta support for Group Managed Service Accounts * More CNIs * More Storage Plugins </del> <ins> ### その他の主な機能 * グループ管理サービスアカウントのベータサポート * その他のCNI * その他のストレージプラグイン </ins>

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


Question: #### Configure and start the Kubernetes cluster The startup process will first download all the required binaries automatically. <del> By default etcd version is 2.2.1, flannel version is 0.5.5 and k8s version is 1.1.4. </del> <ins> By default etcd version is 2.2.1, flannel version is 0.5.5 and k8s version is 1.1.8. </ins> You can customize your etcd version, flannel version, k8s version by changing corresponding variables `ETCD_VERSION` , `FLANNEL_VERSION` and `KUBE_VERSION` like following. ```shell <del> $ export KUBE_VERSION=1.0.5 </del> <ins> $ export KUBE_VERSION=1.1.8 </ins> $ export FLANNEL_VERSION=0.5.0 $ export ETCD_VERSION=2.2.0 ```

The script actually defaults to k8s version 1.1.8, but the docs says it is 1.1.4
Thank you for the PR, Mike!


Question: service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" #  A list of additional security groups to be added to the created ELB, this leaves the uniquely generated security group in place, this ensures that every ELB # has a unique security group ID and a matching permit line to allow traffic to the target worker nodes (service traffic and health checks). <del> # Security groups defined here can be shared between services. </del> <ins> # Security groups defined here can be shared between services. </ins> service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api" # A comma separated list of key-value pairs which are used

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: marks the userspace kube-proxy as deprecated. This was missed from the v1.23 docs updates and . Proposed Solution: Mark the kube-proxy in userspace mode as deprecated. Page to Update: <!--Additional Information:--/sig network /language en /priority important-longterm
/lifecycle frozen /triage accepted
/assign


Question: <ins> --- title: "Containers" weight: 40 --- </ins>

I would like to have the "Container Environment" page to be translated into Italian page /language it /priority important-soon
/assign /lifecycle active


Question: 为客户提供无缝的服务。 <!-- <del> ## Enabling API groups </del> <ins> ## Enabling or disabling API groups </ins> Certain resources and API groups are enabled by default.  They can be enabled or disabled by setting `--runtime-config` <del> on apiserver. `--runtime-config` accepts comma separated values. For ex: to disable batch/v1, set </del> <ins> on apiserver. `--runtime-config` accepts comma separated values. For example: to disable batch/v1, set </ins> `--runtime-config=batch/v1=false`, to enable batch/v2alpha1, set `--runtime-config=batch/v2alpha1`. The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver. <del> IMPORTANT: Enabling or disabling groups or resources requires restarting apiserver and controller-manager </del> <ins> Enabling or disabling groups or resources requires restarting apiserver and controller-manager </ins> to pick up the `--runtime-config` changes. -->

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


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

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale


Question: <ins> --- title: ConfigMap content_type: concept weight: 20 --- <!-- overview --> {{< glossary_definition term_id="configmap" prepend="ConfigMapは、" length="all" >}} {{< caution >}} ConfigMapは機密性や暗号化を提供しません。保存したいデータが機密情報である場合は、ConfigMapの代わりに{{< glossary_tooltip text="Secret" term_id="secret" >}}を使用するか、追加の(サードパーティー)ツールを使用してデータが非公開になるようにしてください。 {{< /caution >}} <!-- body --> ## 動機 アプリケーションのコードとは別に設定データを設定するには、ConfigMapを使用します。 たとえば、アプリケーションを開発していて、(開発用時には)自分のコンピューター上と、(実際のトラフィックをハンドルするときは)クラウド上とで実行することを想像してみてください。あなたは、`DATABASE_HOST`という名前の環境変数を使用するコードを書きます。ローカルでは、この変数を`localhost`に設定します。クラウド上では、データベースコンポーネントをクラスター内に公開するKubernetesの{{< glossary_tooltip text="Service" term_id="service" >}}を指すように設定します。 こうすることで、必要であればクラウド上で実行しているコンテナイメージを取得することで、ローカルでも完全に同じコードを使ってデバッグができるようになります。 ## ConfigMapオブジェクト ConfigMapは、他のオブジェクトが使うための設定を保存できるAPI[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)です。ほとんどのKubernetesオブジェクトに`spec`セクションがあるのとは違い、ConfigMapにはアイテム(キー)と値を保存するための`data`セクションがあります。 ConfigMapの名前は、有効な[DNSのサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。 ## ConfigMapとPod ConfigMapを参照して、ConfigMap内のデータを元にしてPod内のコンテナの設定をするPodの`spec`を書くことができます。このとき、PodとConfigMapは同じ{{< glossary_tooltip text="名前空間" term_id="namespace" >}}内に存在する必要があります。 以下に、ConfigMapの例を示します。単一の値を持つキーと、Configuration形式のデータ片のような値を持つキーがあります。 ```yaml apiVersion: v1 kind: ConfigMap metadata: name: game-demo data: # プロパティーに似たキー。各キーは単純な値にマッピングされている player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # # ファイルに似たキー game.properties: | enemy.types=aliens,monsters player.maximum-lives=5 user-interface.properties: | color.good=purple color.bad=yellow allow.textmode=true ``` ConfigMapを利用してPod内のコンテナを設定する方法には、次の4種類があります。 1. コマンドライン引数をコンテナのエントリーポイントに渡す 1. 環境変数をコンテナに渡す 1. 読み取り専用のボリューム内にファイルを追加し、アプリケーションがそのファイルを読み取る 1. Kubernetes APIを使用してConfigMapを読み込むコードを書き、そのコードをPod内で実行する これらのさまざまな方法は、利用するデータをモデル化するのに役立ちます。最初の3つの方法では、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}がPodのコンテナを起動する時にConfigMapのデータを使用します。 4番目の方法では、ConfigMapとそのデータを読み込むためのコードを自分自身で書く必要があります。しかし、Kubernetes APIを直接使用するため、アプリケーションはConfigMapがいつ変更されても更新イベントを受信でき、変更が発生したときにすぐに反応できます。この手法では、Kubernetes APIに直接アクセスすることで、別の名前空間にあるConfigMapにもアクセスできます。 以下に、Podを設定するために`game-demo`から値を使用するPodの例を示します。 ```yaml apiVersion: v1 kind: Pod metadata: name: configmap-demo-pod spec: containers: - name: demo image: game.example/demo-game env: # 環境変数を定義します。 - name: PLAYER_INITIAL_LIVES # ここではConfigMap内のキーの名前とは違い # 大文字が使われていることに着目してください。 valueFrom: configMapKeyRef: name: game-demo           # この値を取得するConfigMap。 key: player_initial_lives # 取得するキー。 - name: UI_PROPERTIES_FILE_NAME valueFrom: configMapKeyRef: name: game-demo key: ui_properties_file_name volumeMounts: - name: config mountPath: "/config" readOnly: true volumes: # Podレベルでボリュームを設定し、Pod内のコンテナにマウントします。 - name: config configMap: # マウントしたいConfigMapの名前を指定します。 name: game-demo # ファイルとして作成するConfigMapのキーの配列 items: - key: "game.properties" path: "game.properties" - key: "user-interface.properties" path: "user-interface.properties" ``` ConfigMapは1行のプロパティの値と複数行のファイルに似た形式の値を区別しません。問題となるのは、Podや他のオブジェクトによる値の使用方法です。 この例では、ボリュームを定義して、`demo`コンテナの内部で`/config`にマウントしています。これにより、ConfigMap内には4つのキーがあるにもかかわらず、2つのファイル`/config/game.properties`および`/config/user-interface.properties`だけが作成されます。 これは、Podの定義が`volumes`セクションで`items`という配列を指定しているためです。もし`items`の配列を完全に省略すれば、ConfigMap内の各キーがキーと同じ名前のファイルになり、4つのファイルが作成されます。 ## ConfigMapを使う ConfigMapは、データボリュームとしてマウントできます。ConfigMapは、Podへ直接公開せずにシステムの他の部品として使うこともできます。たとえば、ConfigMapには、システムの他の一部が設定のために使用するデータを保存できます。 {{< note >}} ConfigMapの最も一般的な使い方では、同じ名前空間にあるPod内で実行されているコンテナに設定を構成します。ConfigMapを独立して使用することもできます。 たとえば、ConfigMapに基づいて動作を調整する{{< glossary_tooltip text="アドオン" term_id="addons" >}}や{{< glossary_tooltip text="オペレーター" term_id="operator-pattern" >}}を見かけることがあるかもしれません。 {{< /note >}} ### ConfigMapをPodからファイルとして使う ConfigMapをPod内のボリュームで使用するには、次のようにします。 1. ConfigMapを作成するか、既存のConfigMapを使用します。複数のPodから同じConfigMapを参照することもできます。 1. Podの定義を修正して、`.spec.volumes[]`以下にボリュームを追加します。ボリュームに任意の名前を付け、`.spec.volumes[].configMap.name`フィールドにConfigMapオブジェクトへの参照を設定します。 1. ConfigMapが必要な各コンテナに`.spec.containers[].volumeMounts[]`を追加します。`.spec.containers[].volumeMounts[].readOnly = true`を指定して、`.spec.containers[].volumeMounts[].mountPath`には、ConfigMapのデータを表示したい未使用のディレクトリ名を指定します。 1. イメージまたはコマンドラインを修正して、プログラムがそのディレクトリ内のファイルを読み込むように設定します。ConfigMapの`data`マップ内の各キーが、`mountPath`以下のファイル名になります。 以下は、ボリューム内にConfigMapをマウントするPodの例です。 ```yaml apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: mypod image: redis volumeMounts: - name: foo mountPath: "/etc/foo" readOnly: true volumes: - name: foo configMap: name: myconfigmap ``` 使用したいそれぞれのConfigMapごとに、`.spec.volumes`内で参照する必要があります。 Pod内に複数のコンテナが存在する場合、各コンテナにそれぞれ別の`volumeMounts`のブロックが必要ですが、`.spec.volumes`はConfigMapごとに1つしか必要ありません。 #### マウントしたConfigMapの自動的な更新 ボリューム内で現在使用中のConfigMapが更新されると、射影されたキーも最終的に(eventually)更新されます。kubeletは定期的な同期のたびにマウントされたConfigMapが新しいかどうか確認します。しかし、kubeletが現在のConfigMapの値を取得するときにはローカルキャッシュを使用します。キャッシュの種類は、[KubeletConfiguration構造体](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)の中の`ConfigMapAndSecretChangeDetectionStrategy`フィールドで設定可能です。ConfigMapは、監視(デフォルト)、ttlベース、またはすべてのリクエストを直接APIサーバーへ単純にリダイレクトする方法のいずれかによって伝搬されます。その結果、ConfigMapが更新された瞬間から、新しいキーがPodに射影されるまでの遅延の合計は、最長でkubeletの同期期間+キャッシュの伝搬遅延になります。ここで、キャッシュの伝搬遅延は選択したキャッシュの種類に依存します(監視の伝搬遅延、キャッシュのttl、または0に等しくなります)。 {{< feature-state for_k8s_version="v1.18" state="alpha" >}} Kubernetesのアルファ版の機能である _イミュータブルなSecretおよびConfigMap_ は、個別のSecretやConfigMapをイミュータブルに設定するオプションを提供します。ConfigMapを広範に使用している(少なくとも数万のConfigMapがPodにマウントされている)クラスターでは、データの変更を防ぐことにより、以下のような利点が得られます。 - アプリケーションの停止を引き起こす可能性のある予想外の(または望まない)変更を防ぐことができる - ConfigMapをイミュータブルにマークして監視を停止することにより、kube-apiserverへの負荷を大幅に削減し、クラスターの性能が向上する この機能を使用するには、`ImmutableEmphemeralVolumes`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretやConfigMapの`immutable`フィールドを`true`に設定してください。次に例を示します。 ```yaml apiVersion: v1 kind: ConfigMap metadata: ... data: ... immutable: true ``` {{< note >}} 一度ConfigMapやSecretがイミュータブルに設定すると、この変更を元に戻したり、`data`フィールドのコンテンツを変更することは*できません*。既存のPodは削除されたConfigMapのマウントポイントを保持するため、こうしたPodは再作成することをおすすめします。 {{< /note >}} ## {{% heading "whatsnext" %}} * [Secret](/docs/concepts/configuration/secret/)について読む。 * [Podを構成してConfigMapを使用する](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を読む。 * コードを設定から分離する動機を理解するために[The Twelve-Factor App](https://12factor.net/ja/)を読む。 </ins>

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


Question: weight: 40 --> <ins> {{< feature-state for_k8s_version="v1.19" state="stable" >}} <!-- leave this shortcode in place until the note about EvenPodsSpread is obsolete --> </ins> <!-- overview --> <!--

<!-- 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: [zh] Need trans for <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh
/assign


Question: <del> --- reviewers: - bowei - zihongz title:  Debugging DNS Resolution content_type: task min-kubernetes-server-version: v1.6 --- <!-- overview --> This page provides hints on diagnosing DNS problems. ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} Your cluster must be configured to use the CoreDNS {{< glossary_tooltip text="addon" term_id="addons" >}} or its precursor, kube-dns. {{% version-check %}} <!-- steps --> ### Create a simple Pod to use as a test environment {{< codenew file="admin/dns/dnsutils.yaml" >}} Use that manifest to create a Pod: ```shell kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml ``` ``` pod/dnsutils created ``` …and verify its status: ```shell kubectl get pods dnsutils ``` ``` NAME      READY     STATUS    RESTARTS   AGE dnsutils   1/1       Running   0          <some-time> ``` Once that Pod is running, you can exec `nslookup` in that environment. If you see something like the following, DNS is working correctly. ```shell kubectl exec -i -t dnsutils -- nslookup kubernetes.default ``` ``` Server:    10.0.0.10 Address 1: 10.0.0.10 Name:      kubernetes.default Address 1: 10.0.0.1 ``` If the `nslookup` command fails, check the following: ### Check the local DNS configuration first Take a look inside the resolv.conf file. (See [Inheriting DNS from the node](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) and [Known issues](#known-issues) below for more information) ```shell kubectl exec -ti dnsutils -- cat /etc/resolv.conf ``` Verify that the search path and name server are set up like the following (note that search path may vary for different cloud providers): ``` search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal nameserver 10.0.0.10 options ndots:5 ``` Errors such as the following indicate a problem with the CoreDNS (or kube-dns) add-on or with associated Services: ```shell kubectl exec -i -t dnsutils -- nslookup kubernetes.default ``` ``` Server:    10.0.0.10 Address 1: 10.0.0.10 nslookup: can't resolve 'kubernetes.default' ``` or ```shell kubectl exec -i -t dnsutils -- nslookup kubernetes.default ``` ``` Server:    10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local nslookup: can't resolve 'kubernetes.default' ``` ### Check if the DNS pod is running Use the `kubectl get pods` command to verify that the DNS pod is running. ```shell kubectl get pods --namespace=kube-system -l k8s-app=kube-dns ``` ``` NAME                       READY     STATUS    RESTARTS   AGE ... coredns-7b96bf9f76-5hsxb   1/1       Running   0           1h coredns-7b96bf9f76-mvmmt   1/1       Running   0           1h ... ``` {{< note >}} The value for label `k8s-app` is `kube-dns` for both CoreDNS and kube-dns deployments. {{< /note >}} If you see that no CoreDNS Pod is running or that the Pod has failed/completed, the DNS add-on may not be deployed by default in your current environment and you will have to deploy it manually. ### Check for errors in the DNS pod Use the `kubectl logs` command to see logs for the DNS containers. For CoreDNS: ```shell kubectl logs --namespace=kube-system -l k8s-app=kube-dns ``` Here is an example of a healthy CoreDNS log: ``` .:53 2018/08/15 14:37:17 [INFO] CoreDNS-1.2.2 2018/08/15 14:37:17 [INFO] linux/amd64, go1.10.3, 2e322f6 CoreDNS-1.2.2 linux/amd64, go1.10.3, 2e322f6 2018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1c ``` See if there are any suspicious or unexpected messages in the logs. ### Is DNS service up? Verify that the DNS service is up by using the `kubectl get service` command. ```shell kubectl get svc --namespace=kube-system ``` ``` NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE ... kube-dns     ClusterIP   10.0.0.10      <none>        53/UDP,53/TCP        1h ... ``` {{< note >}} The service name is `kube-dns` for both CoreDNS and kube-dns deployments. {{< /note >}} If you have created the Service or in the case it should be created by default but it does not appear, see [debugging Services](/docs/tasks/debug-application-cluster/debug-service/) for more information. ### Are DNS endpoints exposed? You can verify that DNS endpoints are exposed by using the `kubectl get endpoints` command. ```shell kubectl get endpoints kube-dns --namespace=kube-system ``` ``` NAME       ENDPOINTS                       AGE kube-dns   10.180.3.17:53,10.180.3.17:53    1h ``` If you do not see the endpoints, see the endpoints section in the [debugging Services](/docs/tasks/debug-application-cluster/debug-service/) documentation. For additional Kubernetes DNS examples, see the [cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns) in the Kubernetes GitHub repository. ### Are DNS queries being received/processed? You can verify if queries are being received by CoreDNS by adding the `log` plugin to the CoreDNS configuration (aka Corefile). The CoreDNS Corefile is held in a {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} named `coredns`. To edit it, use the command: ``` kubectl -n kube-system edit configmap coredns ``` Then add `log` in the Corefile section per the example below: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: coredns namespace: kube-system data: Corefile: | .:53 { log errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 proxy . /etc/resolv.conf cache 30 loop reload loadbalance } ``` After saving the changes, it may take up to minute or two for Kubernetes to propagate these changes to the CoreDNS pods. Next, make some queries and view the logs per the sections above in this document. If CoreDNS pods are receiving the queries, you should see them in the logs. Here is an example of a query in the log: ``` .:53 2018/08/15 14:37:15 [INFO] CoreDNS-1.2.0 2018/08/15 14:37:15 [INFO] linux/amd64, go1.10.3, 2e322f6 CoreDNS-1.2.0 linux/amd64, go1.10.3, 2e322f6 2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f 2018/09/07 15:29:04 [INFO] Reloading complete 172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s ``` ## Known issues Some Linux distributions (e.g. Ubuntu) use a local DNS resolver by default (systemd-resolved). Systemd-resolved moves and replaces `/etc/resolv.conf` with a stub file that can cause a fatal forwarding loop when resolving names in upstream servers. This can be fixed manually by using kubelet's `--resolv-conf` flag to point to the correct `resolv.conf` (With `systemd-resolved`, this is `/run/systemd/resolve/resolv.conf`). kubeadm automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly. Kubernetes installs do not configure the nodes' `resolv.conf` files to use the cluster DNS by default, because that process is inherently distribution-specific. This should probably be implemented eventually. Linux's libc (a.k.a. glibc) has a limit for the DNS `nameserver` records to 3 by default. What's more, for the glibc versions which are older than glibc-2.17-222 ([the new versions update see this issue](https://access.redhat.com/solutions/58028)), the allowed number of DNS `search` records has been limited to 6 ([see this bug from 2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)). Kubernetes needs to consume 1 `nameserver` record and 3 `search` records. This means that if a local installation already uses 3 `nameserver`s or uses more than 3 `search`es while your glibc version is in the affected list, some of those settings will be lost. To work around the DNS `nameserver` records limit, the node can run `dnsmasq`, which will provide more `nameserver` entries. You can also use kubelet's `--resolv-conf` flag. To fix the DNS `search` records limit, consider upgrading your linux distribution or upgrading to an unaffected version of glibc. If you are using Alpine version 3.3 or earlier as your base image, DNS may not work properly due to a known issue with Alpine. Kubernetes [issue 30215](https://github.com/kubernetes/kubernetes/issues/30215) details more information on this. ## {{% heading "whatsnext" %}} - See [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). - Read [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/) </del>

This page returns 404 not found.
Yup. It was moved over to a different folder ...
/language en
Thanks! Do you know what is the currently available link for the English doc? The search is not very helpful btw, the Chinese link is still working though...
Well, I think we should move it back. Proposing a fix now. If it turns out that team doesn't want to move it back, we may need to add a redirect entry as an alternative.
let's discuss the move back in this issue. Can you set out a case for reverting?
Sure. I'm assuming that there are audiences from different user groups reading the docs and even learn by doing. A long while ago, we (primarily chenopis) started an initiative to provider journeys for different group of users. Some of those efforts are still , archived into a directory. The idea was to help users find the materials they need based on their roles in operating or using Kubernetes. This background is where I came from. For cluster operators (or admins, or whatever you call them), they often times enjoy a higher privilege (aka more responsibilities) to keep the cluster running healthily. That means they need to ensure the following things work properly: access control and admission control storage provisioning and networking setup auditing, logging and monitoring upgrade cluster config secure cluster data and backup them properly ... These are not concerns of an application developer. An application developer uses the cluster to deploy, scale their applications. For example, they rarely have a say regarding when to evict a Pod out of a node and they cannot decide whether and which upstream DNS server is used. Similarly, a cluster operator doesn't care that much how application Helm charts are composed, version controlled. A production deployment is pretty different from the minikube one we use for learning and erring. So ... DNS and related tasks is not an application level thing. It is a cluster administering job. That is the reason I'm proposing this (partial) revert.


Question: <!-- overview --> <del> This document catalogs the communication paths between the API server and the Kubernetes cluster. </del> <ins> This document catalogs the communication paths between the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} and the Kubernetes {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}. </ins> The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider).

This is a Feature Request What would you like to be There are terms that can use the addition of a glossary tooltip to show the meaning of the said term. There is no or reference section Some terms can use references like : , Why is this needed Rather than searching for the definitions of some terms , the references can help understanding the concept while staying on same page or finding more about the concept with right link. it will enhance user experience and bring more clarity and less confusion. Comments The page needed to be updated here is :
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 feature /language en /sig docs
If the triage is accepted would be happy to contribute references I have searched while reading the concept. /assign
Worth doing, but the change I outline in is more valuable to work on.
here seems to be about the and page in particular. I'd agree with the general idea of making the content brief and putting extra information in the reference. For control-plane-node-communication page, I see your comment about adding a diagram there. Will try to add that as well.
For now, I'll push this commit, in case even if we shift this content to reference or another section, we would still need some of the links and references.
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


Question: ## {{% heading "prerequisites" %}} <del> {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} </del> <ins> {{< include "task-tutorial-prereqs-node-upgrade.md" >}} {{< version-check >}} </ins> * Familiarize yourself with [the process for upgrading the rest of your kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to upgrade the control plane nodes before upgrading your Linux Worker nodes.

Missing important step new people SSH into the node
/language en
Hi could you please explain the issue in detail. /triage needs-information
Page mentioned in the issue (based on the title): /language en
/retitle Users not instructed to SSH into the node before executing commands in "Upgrading Linux nodes" page
/sig cluster-lifecycle
I'm not sure this is valid, though there isn't much detail to the issue to explain what the concern is. The commands on that page need to be run on the node being upgraded, but I think how the administrator connects to that node is out of scope. It may be SSH, it may be by accessing the cloud providers console. It may be by rolling up a crash cart and plugging in a monitor and keyboard. That all depends on the individuals environment.
/remove-triage needs-information
/remove-kind support /priority awaiting-more-evidence /kind feature /sig cluster-lifecycle
Those labels are not set on the issue: <detailsIn response to : /remove-kind support /priority awaiting-more-evidence /kind feature /sig cluster-lifecycle Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
My opinion: if you (the reader) don't know how to get a shell on a node, it may not be a good idea to try upgrading it. Best learn the basics first.
We could list “shell access to the node“ as a prerequisite. I don't think we can or should assume SSH; I'm barely happy that we assume superuser access comes via .
for new contributors. page to update: change: to: make sure you add in the PR description. /help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met.


Question: ## {{% heading "prerequisites" %}} <del> {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} </del> <ins> {{< include "task-tutorial-prereqs-node-upgrade.md" >}} {{< version-check >}} </ins> * Familiarize yourself with [the process for upgrading the rest of your kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to upgrade the control plane nodes before upgrading your Linux Worker nodes.

If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : for new contributors. You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster You need to have a Kubernetes cluster, shell access to all its nodes, and the kubectl command-line tool must be configured to communicate with your cluster /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind feature /remove-priority awaiting-more-evidence
/priority backlog
This one looks like a candidate for a "good first issue" label. I think that the page should also have the shell access note, regardless of the method used (ssh, rdp, etc).
I don't think this is a good first issue. A good first issue would have a description that helped totally new contributors find out how to help, and the description for this issue at the time of writing is:
/assign
Got it. Going through the details, I see another problem here. The pre-req of having shell access to the nodes seems mostly relevant (a corner case) for the node upgrade task, for other cluster maintenance tasks, API access to node management seems enough. The problem is that the , and many other pages use the same prerequisites document (). So, adding the "get shell access to the nodes" phrase will alter all these documents where this step is not needed. I think that, for this particular task, we should not use the include prerequisite doc and rewrite the paragraph locally on the pages, as a compromise between convenience and accuracy. What do you think?
That'll work fine.
Given the need to modify two documents and the potential for content drift across releases, etc, I decided to add a new prereqs include file with the modified paragraph instead of rewriting the whole prerequisites section on both documents. Let me know what you think. Thanks


Question: <ins> --- layout: blog title: 'Kubernetes史上最大の移行作業を完了' date: 2024-05-20 slug: completing-cloud-provider-migration --- **著者:** Andrew Sy Kim (Google), Michelle Au (Google), Walter Fender (Google), Michael McCune (Red Hat) **翻訳者:** Taisuke Okamoto (IDC Frontier Inc), [Junya Okabe](https://github.com/Okabe-Junya) (University of Tsukuba) Kubernetes v1.7以降、Kubernetesプロジェクトは、クラウドプロバイダーとの統合機能をKubernetesのコアコンポーネントから分離するという野心的な目標を追求してきました([KEP-2395](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cloud-provider/2395-removing-in-tree-cloud-providers/README.md))。 この統合機能はKubernetesの初期の開発と成長に重要な役割を果たしつつも、２つの重要な要因によってその分離が推進されました。 1つは、何百万行ものGoコードにわたってすべてのクラウドプロバイダーのネイティブサポートを維持することの複雑さが増大していたこと、もう1つは、Kubernetesを真にベンダーニュートラルなプラットフォームとして確立したいという願望です。 多くのリリースを経て、すべてのクラウドプロバイダー統合が、Kubernetesのコアリポジトリから外部プラグインに正常に移行されたことを喜ばしく思います。 当初の目的を達成したことに加えて、約150万行のコードを削除し、コアコンポーネントのバイナリサイズを約40%削減することで、Kubernetesを大幅に合理化しました。 この移行は、影響を受けるコンポーネントが多数あり、Google Cloud、AWS、Azure、OpenStack、vSphereの5つの初期クラウドプロバイダーの組み込み統合に依存していた重要なコードパスがあったため、複雑で長期にわたる作業となりました。 この移行を成功させるために、私たちは4つの新しいサブシステムを一から構築する必要がありました。 1. **クラウドコントローラーマネージャー** ([KEP-2392](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cloud-provider/2392-cloud-controller-manager/README.md)) 2. **APIサーバーネットワークプロキシ** ([KEP-1281](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1281-network-proxy)) 3. **kubeletクレデンシャルプロバイダープラグイン** ([KEP-2133](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2133-kubelet-credential-providers)) 4. **[CSI](https://github.com/container-storage-interface/spec?tab=readme-ov-file#container-storage-interface-csi-specification-)を使用するストレージの移行** ([KEP-625](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/625-csi-migration/README.md)) 各サブシステムは、組み込み機能と同等の機能を実現するために不可欠であり、安全で信頼できる移行パスを使用して各サブシステムをGAレベルの成熟度にするために、いくつかのリリースが必要でした。 以下に、各サブシステムの詳細を説明します。 ### クラウドコントローラーマネージャー クラウドコントローラーマネージャーは、この取り組みで導入された最初の外部コンポーネントであり、`kube-controller-manager`と`kubelet`のうち、クラウドAPIと直接やり取りする機能を置き換えるものです。 この重要なコンポーネントは、ノードが実行されているクラウドのリージョンとゾーンを示すメタデータラベルや、クラウドプロバイダーのみが知っているIPアドレスを適用することにより、ノードを初期化する役割を担っています。 さらに、LoadBalancerタイプのServiceに対してクラウドロードバランサーをプロビジョニングするサービスコントローラーも実行します。 ![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.svg) 詳細については、Kubernetesドキュメントの[クラウドコントローラーマネージャー](/ja/docs/concepts/architecture/cloud-controller/)を参照してください。 ### APIサーバーネットワークプロキシ 2018年にSIG API Machineryと共同で開始されたAPIサーバーネットワークプロキシプロジェクトは、`kube-apiserver`内のSSHトンネラー機能を置き換えることを目的としていました。 このトンネラーは、Kubernetesのコントロールプレーンとノードとのトラフィックを安全にプロキシするために使用されていましたが、これらのSSHトンネルを確立するために、`kube-apiserver`内に組み込まれたプロバイダー固有の実装の詳細に大きく依存していました。 現在、APIサーバーネットワークプロキシは、`kube-apiserver`内のGAレベルの拡張ポイントとなっています。 これは、APIサーバーからノードへのトラフィックを安全なプロキシを介してルーティングできる汎用的なプロキシメカニズムを提供し、APIサーバーが実行されているクラウドプロバイダーを認識する必要がなくなりました。 このプロジェクトでは、本番環境での採用が進んでいるKonnectivityプロジェクトも導入されました。 APIサーバーネットワークプロキシの詳細については、[README](https://github.com/kubernetes-sigs/apiserver-network-proxy#readme)を参照してください。 ### kubeletのクレデンシャルプロバイダープラグイン `kubelet`のクレデンシャルプロバイダープラグインは、Google Cloud、AWS、またはAzureでホストされているイメージレジストリのクレデンシャルを動的に取得する`kubelet`の組み込み機能を置き換えるために開発されました。 従来の機能は便利で、`kubelet`がGCR、ECR、またはACRからイメージを取得するための短期間のトークンをシームレスに取得できるようにしていました。 しかし、Kubernetesの他の領域と同様に、これをサポートするには、`kubelet`が異なるクラウド環境とAPIについて特定の知識を持つ必要がありました。 2019年に導入されたクレデンシャルプロバイダープラグインメカニズムは、`kubelet`が様々なクラウドでホストされているイメージのクレデンシャルを動的に提供するプラグインバイナリを実行するための汎用的な拡張ポイントを提供します。 この拡張性により、`kubelet`の短期間のトークンを取得する機能が、最初の3つのクラウドプロバイダーを超えて拡張されました。 詳細については、[認証されたイメージプルのためのkubeletクレデンシャルプロバイダー](/ja/docs/concepts/containers/images/#kubelet-credential-provider)を参照してください。 ### ストレージプラグインのKubernetesコアからCSIへの移行 Container Storage Interface(CSI)は、Kubernetesやそのほかのコンテナオーケストレーターにおいてブロックおよびファイルストレージシステムを管理するためのコントロールプレーン標準であり、1.13でGAになりました。 これは、Kubernetesに直接組み込まれていたボリュームプラグインを、Kubernetesクラスター内のPodとして実行できるドライバーに置き換えるために設計されました。 これらのドライバーは、Kubernetes APIを介して`kube-controller-manager`ストレージコントローラーと通信し、ローカルのgRPCエンドポイントを介して`kubelet`と通信します。 現在、すべての主要なクラウドとストレージベンダーにわたって100以上のCSIドライバーが利用可能であり、Kubernetesでステートフルなワークロードが現実のものとなっています。 ただし、KubernetesコアのボリュームAPIの既存のすべてのユーザーをどのように扱うかという大きな課題が残っていました。 APIの後方互換性を維持するために、Kubernetesコアのボリューム APIを同等のCSI APIに変換するAPIトランスレーション層をコントローラーに組み込みました。 これにより、すべてのストレージ操作をCSIドライバーにリダイレクトすることができ、APIを削除せずにKubernetesコアのボリュームプラグインのコードを削除する道が開けました。 Kubernetesコアのストレージの移行の詳細については、[Kubernetes In-Tree to CSI Volume Migration Moves to Beta](https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/)を参照してください。 ## 今後の展望 この移行は、ここ数年のSIG Cloud Providerがもっとも注力してきたことでした。 この重要なマイルストーンを達成したことで、これまでに構築してきた外部サブシステムを活用して、Kubernetesとクラウドプロバイダーをより良く統合するための新しい革新的な方法を模索する取り組みにシフトしていきます。 これには、クラスター内のノードがパブリッククラウドとプライベートクラウドの両方で実行できるハイブリッド環境でKubernetesをより賢くすることや、外部プロバイダーの開発者が統合の取り組みを簡素化・合理化するためのより良いツールとフレームワークを提供することが含まれます。 新機能やツール、フレームワークの開発が進む一方で、SIG Cloud Providerはテストの重要性も忘れてはいません。 SIGの将来の活動のもう1つの重点分野は、より多くのプロバイダーを含めるためのクラウドコントローラーテストの改善です。 この取り組みの最終目標は、できるだけ多くのプロバイダーを含むテストフレームワークを作成し、Kubernetesコミュニティに対して、Kubernetes環境に関する最高レベルの信頼性を提供することです。 v1.29より前のバージョンのKubernetesを使用していて、まだ外部クラウドプロバイダーに移行していない場合は、以前のブログ記事[Kubernetes 1.29: Cloud Provider Integrations Are Now Separate Components](/blog/2023/12/14/cloud-provider-integration-changes/)を確認することをおすすめします。 この記事では、私たちが行った変更について詳細な情報を提供し、外部プロバイダーへの移行方法についてガイダンスを提供しています。 v1.31以降、Kubernetesコアのクラウドプロバイダーは永続的に無効化され、Kubernetesのコアコンポーネントから削除されます。 貢献に興味がある方は、[隔週のSIGミーティング](https://github.com/kubernetes/community/tree/master/sig-cloud-provider#meetings)にぜひご参加ください！ </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 "" Why is this needed There is no Japanese translation for this page Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/area localization /language ja /assign
thank you!! /triage accepted


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

No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
…until now:
I reckon will close this issue.


Question: If you would like to write a tutorial, see <del> [Content Page Types](/docs/home/contribute/style/page-content-types/) </del> <ins> [Content Page Types](/docs/contribute/style/page-content-types/) </ins> for information about the tutorial page type.

This is a Bug Report Problem: The link (/docs/home/contribute/style/page-content-types/#concept) from the Concept page is not correct. Proposed Solution: Page to Update:
Thanks for spotting this. /kind bug /priority backlog /language en


Question: {{% tab name="CentOS" %}} <!-- <del> To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table: </del> <ins> To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table: </ins> | Operating system | `$OS`             | | ---------------- | ----------------- |

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


Question: ## {{% heading "whatsnext" %}} <del> * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) * Learn how to [debug init containers](/docs/tasks/debug/debug-application/debug-init-containers/) * Read about an overview of [kubelet](/docs/reference/command-line-tools-reference/kubelet/) and [kubectl](/docs/reference/kubectl/) * Learn about the [types of probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe): liveness, readiness, startup probe. </del> <ins> Learn more about the following: * [Creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container). * [Debug init containers](/docs/tasks/debug/debug-application/debug-init-containers/). * Overview of [kubelet](/docs/reference/command-line-tools-reference/kubelet/) and [kubectl](/docs/reference/kubectl/). * [Types of probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe): liveness, readiness, startup probe. * [Sidecar containers](/docs/concepts/workloads/pods/sidecar-containers). </ins>

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


Question: <ins> --- title: "验证 kubectl 的安装效果" description: "如何验证 kubectl。" headless: true --- <!-- --- title: "verify kubectl install" description: "How to verify kubectl." headless: true --- --> <!-- In order for kubectl to find and access a Kubernetes cluster, it needs a [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), which is created automatically when you create a cluster using [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) or successfully deploy a Minikube cluster. By default, kubectl configuration is located at `~/.kube/config`. Check that kubectl is properly configured by getting the cluster state: --> 为了让 kubectl 能发现并访问 Kubernetes 集群，你需要一个 [kubeconfig 文件](/docs/zh/concepts/configuration/organize-cluster-access-kubeconfig/)， 该文件在 [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) 创建集群时，或成功部署一个 Miniube 集群时，均会自动生成。 通常，kubectl 的配置信息存放于文件 `~/.kube/config` 中。 通过获取集群状态的方法，检查是否已恰当的配置了 kubectl： ```shell kubectl cluster-info ``` <!-- If you see a URL response, kubectl is correctly configured to access your cluster. If you see a message similar to the following, kubectl is not configured correctly or is not able to connect to a Kubernetes cluster. --> 如果返回一个 URL，则意味着 kubectl 成功的访问到了你的集群。 如果你看到如下所示的消息，则代表 kubectl 配置出了问题，或无法连接到 Kubernetes 集群。 ``` The connection to the server <server-name:port> was refused - did you specify the right host or port? （访问 <server-name:port> 被拒绝 - 你指定的主机和端口是否有误？） ``` <!-- For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like Minikube to be installed first and then re-run the commands stated above. If kubectl cluster-info returns the url response but you can't access your cluster, to check whether it is configured properly, use: --> 例如，如果你想在自己的笔记本上（本地）运行 Kubernetes 集群，你需要先安装一个 Minikube 这样的工具，然后再重新运行上面的命令。 如果命令 `kubectl cluster-info` 返回了 url，但你还不能访问集群，那可以用以下命令来检查配置是否妥当： ```shell kubectl cluster-info dump ``` </ins>  No newline at end of file

This is a Feature Request translate content/docs/tasks/tools/install-kubectl- into Chinese What would you like to be content/zh/docs/tasks/tools/install-kubectl- /assign /language zh
/triage accepted


Question: padding-top: 40px; } <ins> // Don't show announcements when javascript is not available html.no-js body div#announcement { display: none; } #announcement.display-announcement{ display: block; // apply this class to display the announcement } </ins> #announcement { // default background is blue; overrides are possible color: #fff; <ins> display: none; // When javascript is available, Let javascript handle the state of the announcement </ins> .announcement-main { margin-left: auto; margin-right: auto;

This is a Feature Request The red banner introduced with is too intrusive. Most Kubernetes users don't actually care about this deadline, and there is no way to dismiss it. What would you like to be A simple "dismiss" button that sets a cookie to hide the banner in any future visit, like other websites do. Why is this needed I'd argue that most users of the website just want to read the documentation, they aren't going to submit images to that registry, so the warning isn't useful. Comments This could be reused for future banners.
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 Add way to dismiss banners in the K8s website We would implement this for all banners, not just red ones.
/area web-development
oh boy! are you in for a ride!!
xref: also, here's how i deal with papercuts on the web -
Which all banners are you referring to? I'd be willing to take this up.
There's a banner displayed now, it looks like this: ! Imagine if you could click to acknowledge that you'd read it and didn't want to see it again for a fortnight. (separately: does feel relevant - ruled out taking action as they don't plan to push a container image there, which I think reveals a misunderstanding. I think it's worth repeating banners every couple of weeks in case it helps a message to land better).
Which ...To clarify for anyone reading: This banner applies to pulling / downloading container images from the Kubernetes project, this banner is aimed at users, not Kubernetes developers. Nobody can push directly to either of these hosts and the change isn't related to pushing / submitting images.
Thanks and for the explanation! I'll take this up and try to resolve this. /assign
are you working on this issue? I would like to help if you want. Do let me know.
Yes, I'm working on this still, mostly it's completed already, but thanks for the offer!


Question: padding-top: 40px; } <ins> // Don't show announcements when javascript is not available html.no-js body div#announcement { display: none; } #announcement.display-announcement{ display: block; // apply this class to display the announcement } </ins> #announcement { // default background is blue; overrides are possible color: #fff; <ins> display: none; // When javascript is available, Let javascript handle the state of the announcement </ins> .announcement-main { margin-left: auto; margin-right: auto;

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]:
As XDRAGON2002 seems is evaded, could you please proceed?
/remove-lifecycle stale
I'll help with this, it seems like a good feature
/sig docs


Question: ### SEE ALSO <del> * [kubectl](kubectl.md)	 - kubectl controls the Kubernetes cluster manager </del> <ins> * [kubectl](../kubectl.md)	 - kubectl controls the Kubernetes cluster manager </ins> ###### Auto generated by spf13/cobra on 12-Aug-2016

I wish /docs/getting-started-guides/docker/ I wish this page existed


Question: ### SEE ALSO <del> * [kubectl](kubectl.md)	 - kubectl controls the Kubernetes cluster manager </del> <ins> * [kubectl](../kubectl.md)	 - kubectl controls the Kubernetes cluster manager </ins> ###### Auto generated by spf13/cobra on 12-Aug-2016


Question: ### SEE ALSO <del> * [kubectl](kubectl.md)	 - kubectl controls the Kubernetes cluster manager </del> <ins> * [kubectl](../kubectl.md)	 - kubectl controls the Kubernetes cluster manager </ins> ###### Auto generated by spf13/cobra on 12-Aug-2016

I wish /docs/admin/dns/ linked correctly to the federation guide, at


Question: <ins> --- reviewers: - rickypai - thockin title: Adding entries to Pod /etc/hosts with HostAliases content_type: task weight: 60 min-kubernetes-server-version: 1.7 --- <!-- overview --> Adding entries to a Pod's `/etc/hosts` file provides Pod-level override of hostname resolution when DNS and other options are not applicable. You can add these custom entries with the HostAliases field in PodSpec. Modification not using HostAliases is not suggested because the file is managed by the kubelet and can be overwritten on during Pod creation/restart. <!-- steps --> ## Default hosts file content Start an Nginx Pod which is assigned a Pod IP: ```shell kubectl run nginx --image nginx ``` ``` pod/nginx created ``` Examine a Pod IP: ```shell kubectl get pods --output=wide ``` ``` NAME     READY     STATUS    RESTARTS   AGE    IP           NODE nginx    1/1       Running   0          13s    10.200.0.4   worker0 ``` The hosts file content would look like this: ```shell kubectl exec nginx -- cat /etc/hosts ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.4	nginx ``` By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like `localhost` and its own hostname. ## Adding additional entries with hostAliases In addition to the default boilerplate, you can add additional entries to the `hosts` file. For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`, `bar.remote` to `10.1.2.3`, you can configure HostAliases for a Pod under `.spec.hostAliases`: {{< codenew file="service/networking/hostaliases-pod.yaml" >}} You can start a Pod with that configuration by running: ```shell kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml ``` ``` pod/hostaliases-pod created ``` Examine a Pod's details to see its IPv4 address and its status: ```shell kubectl get pod --output=wide ``` ``` NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE hostaliases-pod                0/1       Completed   0          6s        10.200.0.5      worker0 ``` The `hosts` file content looks like this: ```shell kubectl logs hostaliases-pod ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.5	hostaliases-pod # Entries added by HostAliases. 127.0.0.1	foo.local	bar.local 10.1.2.3	foo.remote	bar.remote ``` with the additional entries specified at the bottom. ## Why does the kubelet manage the hosts file? {#why-does-kubelet-manage-the-hosts-file} The kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the `hosts` file for each container of the Pod to prevent Docker from [modifying](https://github.com/moby/moby/issues/17190) the file after the containers have already been started. {{< caution >}} Avoid making manual changes to the hosts file inside a container. If you make manual changes to the hosts file, those changes are lost when the container exits. {{< /caution >}} </ins>

Affected page: Move this page from Concepts to Tasks (potentially under Tasks Networking). Update to redirect the old URL to the new location (use a 301 code, similar to other entries in this file). /sig docs /language en
/triage accepted /help
/remove-help
I'd like to work on this one to learn something new in website page organizing. Thanks. /assign


Question: ### CNI-Genie from Huawei <del> [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Weave-net](https://www.weave.works/products/weave-net/). </del> <ins> [CNI-Genie](https://github.com/cni-genie/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/flannel-io/flannel#flannel), [Calico](https://projectcalico.docs.tigera.io/about/about-calico/), [Weave-net](https://www.weave.works/oss/net/). </ins> <del> CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin. </del> <ins> CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin. </ins> ### cni-ipvlan-vpc-k8s [cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) contains a set

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


Question: <!-- body --> <del> ## Introduction </del> Kubernetes DNS schedules a DNS Pod and Service on the cluster, and configures the kubelets to tell individual containers to use the DNS Service's IP to resolve DNS names.

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 page has a heading, , that isn't actually needed. Readers can work out that the page has an introduction by reading the text from the start. Typically, we don't start our document pages with a heading such as Introduction; instead, we have introductory text before the first heading. Proposed Solution: Delete the line from Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /good-first-issue /language en If you have already worked on an issue and have had your change merged, please consider holding back on this one. That will let other, less experienced, contributors find this to work on it.
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The page has a heading, , that isn't actually needed. Proposed Solution: Delete the line from <!--Kubernetes Version:--/good-first-issue /language en </details
/triage accepted /priority backlog
/assign
I'm closing my PR and expecting new folks to actually contribute to fixing this minor issue. Feel free to raise a PR for this issue! /unassign
can I work on this issue! /assign


Question: ### Flannel <del> [Flannel](https://github.com/coreos/flannel#flannel) is a very simple overlay </del> <ins> [Flannel](https://github.com/flannel-io/flannel#flannel) is a very simple overlay </ins> network that satisfies the Kubernetes requirements. Many people have reported success with Flannel and Kubernetes.


Question: {{< glossary_definition term_id="etcd" length="all" prepend="etcd is a ">}} ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} <!-- steps --> ## Prerequisites * Run etcd as a cluster of odd members. <del> * etcd is a leader-based distributed system. Ensure that the leader periodically send heartbeats on time to all followers to keep the cluster stable. </del> <ins> * etcd is a leader-based distributed system. Ensure that the leader periodically send heartbeats on time to all followers to keep the cluster stable. </ins> * Ensure that no resource starvation occurs. <del> Performance and stability of the cluster is sensitive to network and disk IO. Any resource starvation can lead to heartbeat timeout, causing instability of the cluster. An unstable etcd indicates that no leader is elected. Under such circumstances, a cluster cannot make any changes to its current state, which implies no new pods can be scheduled. </del> <ins> Performance and stability of the cluster is sensitive to network and disk I/O. Any resource starvation can lead to heartbeat timeout, causing instability of the cluster. An unstable etcd indicates that no leader is elected. Under such circumstances, a cluster cannot make any changes to its current state, which implies no new pods can be scheduled. </ins> <del> * Keeping stable etcd clusters is critical to the stability of Kubernetes clusters. Therefore, run etcd clusters on dedicated machines or isolated environments for [guaranteed resource requirements](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#hardware-recommendations). </del> <ins> * Keeping etcd clusters stable is critical to the stability of Kubernetes clusters. Therefore, run etcd clusters on dedicated machines or isolated environments for [guaranteed resource requirements](https://etcd.io/docs/current/op-guide/hardware/). </ins> * The minimum recommended version of etcd to run in production is `3.2.10+`. ## Resource requirements <del> Operating etcd with limited resources is suitable only for testing purposes. For deploying in production, advanced hardware configuration is required. Before deploying etcd in production, see [resource requirement reference documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#example-hardware-configurations). </del> <ins> Operating etcd with limited resources is suitable only for testing purposes. For deploying in production, advanced hardware configuration is required. Before deploying etcd in production, see [resource requirement reference](https://etcd.io/docs/current/op-guide/hardware/#example-hardware-configurations). </ins> ## Starting etcd clusters

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


Question: hello world ``` <del> ``` </del> <ins> ```shell </ins> # we can "uninstall" a plugin, by simply removing it from our PATH sudo rm /usr/local/bin/kubectl-hello ```

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: line 35~39, there are extra spaces(more than 4 spaces) in front of shell box. line 427~430, it should be a shell box. So, we need shell code. line 445~451, it should be a shell box. So, we need shell code. Proposed Solution: [1] : Specifies the . Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: [2] [3] Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign


Question: <ins> --- title: "zsh 自动补全" description: "zsh 自动补全的一些可选配置" headless: true --- <!-- --- title: "zsh auto-completion" description: "Some optional configuration for zsh auto-completion." headless: true --- --> <!-- The kubectl completion script for Zsh can be generated with the command `kubectl completion zsh`. Sourcing the completion script in your shell enables kubectl autocompletion. To do so in all your shell sessions, add the following to your `~/.zshrc` file: --> kubectl 通过命令 `kubectl completion zsh` 生成 Zsh 自动补全脚本。 在 shell 中导入（Sourcing）该自动补全脚本，将启动 kubectl 自动补全功能。 为了在所有的 shell 会话中实现此功能，请将下面内容加入到文件 `~/.zshrc` 中。 ```zsh source <(kubectl completion zsh) ``` <!-- If you have an alias for kubectl, you can extend shell completion to work with that alias: --> 如果你为 kubectl 定义了别名，可以扩展脚本补全，以兼容该别名。 ```zsh echo 'alias k=kubectl' >>~/.zshrc echo 'complete -F __start_kubectl k' >>~/.zshrc ``` <!-- After reloading your shell, kubectl autocompletion should be working. If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file: --> 重新加载 shell 后，kubectl 自动补全功能将立即生效。 如果你收到 `complete:13: command not found: compdef` 这样的错误提示，那请将下面内容添加到 `~/.zshrc` 文件的开头： ```zsh autoload -Uz compinit compinit ``` </ins>


Question: * `apiserver_flowcontrol_current_inqueue_requests` is a gauge vector holding the instantaneous number of queued (not executing) requests, <del> broken down by the labels `priorityLevel` and `flowSchema`. </del> <ins> broken down by the labels `priority_level` and `flow_schema`. </ins> * `apiserver_flowcontrol_current_executing_requests` is a gauge vector holding the instantaneous number of executing (not waiting in a <del> queue) requests, broken down by the labels `priorityLevel` and `flowSchema`. </del> <ins> queue) requests, broken down by the labels `priority_level` and `flow_schema`. </ins> * `apiserver_flowcontrol_priority_level_request_count_samples` is a histogram vector of observations of the then-current number of requests broken down by the labels `phase` (which takes on the <del> values `waiting` and `executing`) and `priorityLevel`.  Each </del> <ins> values `waiting` and `executing`) and `priority_level`.  Each </ins> histogram gets observations taken periodically, up through the last activity of the relevant sort.  The observations are made at a high rate.

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


Question: If you need access to multiple registries, you can create one secret for each registry. <del> Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.json` </del> ## {{% heading "whatsnext" %}}

Ref: needs a rewrite. It mentions Docker (and Podman!) all over the place, which is a good indication that the docs are old enough to need a rewrite. At a minimum, remove mentions of Docker in these topics: /triage accepted /milestone 1.24
/assign
/assign
Reasked folks in Slack for correct disposition
Asked in the SIG Node slack channel:
To summarize the consensus from talking with folks about this issue, specifically the examples in Using a Private Registry section: The steps in the Using a Private Registry section are still valid. However, as written, it makes it sound like Docker is the only/recommended way to do this-which we dont want. We should be able to remove the docker examples and point folks to this page , which covers most of the same content with third party disclaimers already written into the examples. I plan to open a PR later this week with these changes!
Has anyone opened a PR for this issue? It seems to be referring to


Question: abstract: "자동화된 컨테이너 배포, 스케일링과 관리" cid: home --- <del> {{< announcement >}} {{< deprecationwarning >}} </del> {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}}

Umbrella issue: Remove the following from L6-8:
/kind cleanup
/language ko
/assign
This issue is included in also.


Question: # replace <node-to-drain> with the name of your node kubectl uncordon <node-to-drain> ``` <ins> ## {{% heading "whatsnext" %}} * See how to [Upgrade Linux nodes](/docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes/). </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 Add a page titled “Upgrading Linux Nodes” Why is this needed We have an for Windows. Someone who runs Linux worker nodes may well want to see a page just like that, but explaining what to do for their Linux-based node OS. It is OK to adapt existing pages and to link to them. Comments /sig cluster-lifecycle /priority backlog /language en
Hi there is a section on in the , which has the content for upgrading Linux worker nodes. I wonder do you want a separate document for it?
Yes. This issue is a request for a document just like but with Linux in the title. It is OK to adapt existing pages and to link to them.
right, i can recall the section only says: From the Windows node, upgrade kubeadm: and no addition for another os. This will be helpful. are you working on it?
Thanks, for the information!
Hi thanks for your comments. Yeah, I am working on it. I will soon open a PR for it.
/assign
/triage accepted
I have raised a PR: Please take a look!


Question: Inspecting the logs for docker may also be useful: ```sh <del> journalctl -ul docker </del> <ins> journalctl -u docker </ins> ``` ## Pods in `RunContainerError`, `CrashLoopBackOff` or `Error` state

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: Documentation contains an error: URL: chapter: kubeadm blocks when removing managed containers: Text in doc: Inspecting the logs for docker may also be useful: Error: This command runs into an error (on my ubuntu 18.04 distribution): Proposed Solution: Replace command with: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version: v1.18--<!--Additional Information:--
/sig cluster-lifecycle /good-first-issue /help /kind bug it should have been or just let's go with:
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig cluster-lifecycle /good-first-issue /help /kind bug Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: The Kubernetes DNS server is the only way to access `ExternalName` Services. You can find more information about `ExternalName` resolution in <del> [DNS Pods and Services](/docs/concepts/services-networking/dns-pod-service/). </del> <ins> [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/). </ins> ## Headless Services

A link reference from to has the title text whereas the current title of that page is It will be a little less confusing if the link title was adjusted to be the same as the page title.
/sig docs /language en /assign
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /kind suggestion I Agree on your point. If triage accepted, i will update this reference text from to that can avoid confusion. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I Agree on your point. If triage accepted, i will update this reference text from to that can avoid confusion.
This issue got resolved with PR .
/triage accepted


Question: * [Removing Dockershim from kubelet](https://github.com/kubernetes/enhancements/issues/2221): the Container Runtime Interface (CRI) for Docker (i.e. Dockershim) is currently a built-in container runtime in the kubelet code base. It was deprecated in v1.20. As of v1.24, the kubelet will no longer have dockershim. Check out this blog on [what you need to do be ready for v1.24](/blog/2022/03/31/ready-for-dockershim-removal/). * [Storage capacity tracking for pod scheduling](https://github.com/kubernetes/enhancements/issues/1472): The CSIStorageCapacity API supports exposing currently available storage capacity via CSIStorageCapacity objects and enhances scheduling of pods that use CSI volumes with late binding. In v1.24, the CSIStorageCapacity API will be stable. The API graduating to stable initates the deprecation of the v1beta1 CSIStorageCapacity API. Refer to the [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking) for more information. * [The `master` label is no longer present on kubeadm control plane nodes](https://github.com/kubernetes/kubernetes/pull/107533). For new clusters, the label 'node-role.kubernetes.io/master' will no longer be added to control plane nodes, only the label 'node-role.kubernetes.io/control-plane' will be added. For more information, refer to [KEP-2067: Rename the kubeadm "master" label and taint](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint). <del> * [VolumeSnapshot v1beta1 CRD will be removed](https://github.com/kubernetes/enhancements/issues/177). Volume snapshot and restore functionality for Kubernetes and the [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, entered beta in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.21 and is now unsupported. Refer to [KEP-177: CSI Snapshot](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) and [kubernetes-csi/external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter/releases/tag/v4.1.0) for more information. </del> <ins> * [VolumeSnapshot v1beta1 CRD will be removed](https://github.com/kubernetes/enhancements/issues/177). Volume snapshot and restore functionality for Kubernetes and the [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, moved to GA in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.20 and will become unsupported with the v1.24 release. Refer to [KEP-177: CSI Snapshot](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) and the [Volume Snapshot GA blog](/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/) blog article for more information. </ins> ## What to do

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: Information regarding volume snapshot API in the following blog is not accurate. Volume snapshot API moved to GA in 1.20, so volume snapshot v1beta1 was deprecated in 1.20. Proposed Solution: Information regarding volume snapshot API in this blog is correct: Please update the API Removals Deprecations blog accordingly. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Incorrect information regarding VolumeSnapshot API in v1.24 upcoming removals article /area blog /language en What is the correct statement about the fate of the v1beta1 API for VolumeSnapshot When did (or will) that API version transition from deprecated to unsupported?
I suspect the fix is to edit: to: Does that sound right? /triage needs-information
Change 1: which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, entered beta in v1.20 Change 2: Above has to be: [diff ]
The following is correct: . Volume snapshot and restore functionality for Kubernetes and the Container Storage Interface (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, moved to GA in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.20 and is now unsupported. Refer to and for more information.
/assign
I completely agree with the contexts that has shared.
New PR has been raised for this issue.


Question: You can use {{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+ as the container runtime for Kubernetes nodes that run Windows. <del> Learn how to [install ContainerD on a Windows node](/docs/setup/production-environment/container-runtimes/#install-containerd). </del> <ins> Learn how to [install ContainerD on a Windows node](/docs/setup/production-environment/container-runtimes/#containerd). </ins> {{< note >}} There is a [known limitation](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations) when using GMSA with containerd to access Windows network shares, which requires a

This is a Bug Report Problem: The link for in  is incorrect. It is redirecting to but it should redirect to Proposed Solution: should redirect to instead of
/sig docs /kind bug
Page related to the issue:
/language en
I would to like to solve this issue if triage gets accepted.
/triage accepted
/assign
The issue is fixed here:


Question: ```shell kubectl get -f myapp.yaml <ins> ``` 実行結果は下記のようになります。 ``` </ins> NAME        READY     STATUS    RESTARTS   AGE myapp-pod   1/1       Running   0          9m ``` <del> このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#whats-next)にさらに詳細な使用例に関するリンクがあります。 </del> <ins> このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#what-s-next)にさらに詳細な使用例に関するリンクがあります。 </ins> ## Initコンテナのふるまいに関する詳細 {#detailed-behavior} <del> Podの起動時は各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従ってPodのInitコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 </del> <ins> Podの起動時に、kubeletはネットワークおよびストレージの準備が整うまで、Initコンテナを実行可能な状態にしません。また、kubeletはPodのspecに定義された順番に従ってPodのInitコンテナを起動します。 各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムにより起動失敗した場合、もしくはエラーで終了した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 </ins> Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initialized`という値はtrueとなります。 <del> もしそのPodが[再起動](#pod-restart-reasons)されたとき、全てのInitコンテナは必ず再度実行されます。 </del> <ins> もしそのPodを[再起動](#pod-restart-reasons)するとき、または再起動されたとき、全てのInitコンテナは必ず再度実行されます。 </ins> Initコンテナの仕様の変更は、コンテナイメージのフィールドのみに制限されています。 Initコンテナのイメージフィールド値を変更すると、そのPodは再起動されます。 <del> Initコンテナは何度も再起動およびリトライ可能なため、べき等(Idempotent)である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。 </del> <ins> Initコンテナは何度も再起動、リトライおよび再実行可能なため、べき等(Idempotent)である必要があります。特に、`EmptyDirs`にファイルを書き込むコードは、書き込み先のファイルがすでに存在している可能性を考慮に入れる必要があります。 </ins> Initコンテナはアプリケーションコンテナの全てのフィールドを持っています。しかしKubernetesは、Initコンテナが完了と異なる状態を定義できないため`readinessProbe`が使用されることを禁止しています。これはバリデーションの際に適用されます。 <del> Initコンテナがずっと失敗し続けたままの状態を防ぐために、Podに`activeDeadlineSeconds`を、コンテナに`livenessProbe`をそれぞれ設定してください。`activeDeadlineSeconds`の設定はInitコンテナが実行中の時間にも適用されます。 </del> <ins> Initコンテナがずっと失敗し続けたままの状態を防ぐために、Podに`activeDeadlineSeconds`を設定してください。`activeDeadlineSeconds`の設定はInitコンテナが実行中の時間にも適用されます。しかし`activeDeadlineSeconds`はInitコンテナが終了した後でも効果があるため、チームがアプリケーションをJobとしてデプロイする場合にのみ使用することが推奨されています。 すでに正しく動作しているPodは`activeDeadlineSeconds`を設定すると強制終了されます。 </ins> Pod内の各アプリケーションコンテナとInitコンテナの名前はユニークである必要があります。他のコンテナと同じ名前を共有していた場合、バリデーションエラーが返されます。

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details