Merge pull request #32393 from nate-double-u/merged-main-dev-1.24

Merged main into dev 1.24

content/en/docs/concepts/configuration/configmap.md

@@ -42,7 +42,7 @@ that lets you store configuration for other objects to use. Unlike most
 Kubernetes objects that have a `spec`, a ConfigMap has `data` and `binaryData`
 fields. These fields accept key-value pairs as their values.  Both the `data`
 field and the `binaryData` are optional. The `data` field is designed to
-contain UTF-8 byte sequences while the `binaryData` field is designed to
+contain UTF-8 strings while the `binaryData` field is designed to
 contain binary data as base64-encoded strings.
 
 The name of a ConfigMap must be a valid

content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -344,7 +344,7 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
 Here are some examples of device plugin implementations:
 
 * The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
-* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for Intel GPU, FPGA and QuickAssist devices
+* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for Intel GPU, FPGA, QAT, VPU, SGX, DSA, DLB and IAA devices
 * The [KubeVirt device plugins](https://github.com/kubevirt/kubernetes-device-plugins) for hardware-assisted virtualization
 * The [NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
     * Requires [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) 2.0, which allows you to run GPU-enabled Docker containers.

content/en/docs/concepts/services-networking/ingress.md

@@ -316,7 +316,7 @@ spec:
   parameters:
     # The parameters for this IngressClass are specified in an
     # IngressParameter (API group k8s.example.com) named "external-config",
-    # that's in the "external-configuration" configuration namespace.
+    # that's in the "external-configuration" namespace.
     scope: Namespace
     apiGroup: k8s.example.com
     kind: IngressParameter

content/en/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -136,7 +136,7 @@ completion or failed for some reason. When you use `kubectl` to query a Pod with
 a container that is `Terminated`, you see a reason, an exit code, and the start and
 finish time for that container's period of execution.
 
-If a container has a `preStop` hook configured, that runs before the container enters
+If a container has a `preStop` hook configured, this hook runs before the container enters
 the `Terminated` state.
 
 ## Container restart policy {#restart-policy}

content/en/docs/reference/kubectl/cheatsheet.md

@@ -238,7 +238,7 @@ kubectl rollout status -w deployment/frontend                    # Watch rolling
 kubectl rollout restart deployment/frontend                      # Rolling restart of the "frontend" deployment
 
 
-cat pod.json | kubectl replace -f -                              # Replace a pod based on the JSON passed into std
+cat pod.json | kubectl replace -f -                              # Replace a pod based on the JSON passed into stdin
 
 # Force replace, delete and then re-create the resource. Will cause a service outage.
 kubectl replace --force -f ./pod.json

content/en/docs/reference/labels-annotations-taints/_index.md

@@ -184,6 +184,16 @@ Used on: PersistentVolumeClaim
 
 This annotation has been deprecated.
 
+### volume.beta.kubernetes.io/mount-options (deprecated) {#mount-options}
+
+Example : `volume.beta.kubernetes.io/mount-options: "ro,soft"`
+
+Used on: PersistentVolume
+
+A Kubernetes administrator can specify additional [mount options](/docs/concepts/storage/persistent-volumes/#mount-options) for when a PersistentVolume is mounted on a node.
+
+This annotation has been deprecated.
+
 ### volume.kubernetes.io/storage-provisioner
 
 Used on: PersistentVolumeClaim
@@ -475,7 +485,7 @@ The [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1
 When you [specify the security context for a Pod](/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod),
 the settings you specify apply to all containers in that Pod.
 
-### container.seccomp.security.alpha.kubernetes.io/[NAME] {#container-seccomp-security-alpha-kubernetes-io}
+### container.seccomp.security.alpha.kubernetes.io/[NAME] (deprecated) {#container-seccomp-security-alpha-kubernetes-io}
 
 This annotation has been deprecated since Kubernetes v1.19 and will become non-functional in v1.25.
 The tutorial [Restrict a Container's Syscalls with seccomp](/docs/tutorials/security/seccomp/) takes

content/en/docs/tasks/configure-pod-container/assign-memory-resource.md

@@ -99,10 +99,10 @@ and a memory limit of 200 MiB.
 ```yaml
 ...
 resources:
-  limits:
-    memory: 200Mi
   requests:
     memory: 100Mi
+  limits:
+    memory: 200Mi
 ...
 ```
 

content/en/docs/tasks/tools/install-kubectl-linux.md

@@ -83,7 +83,7 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
 
    ```bash
    chmod +x kubectl
-   mkdir -p ~/.local/bin/kubectl
+   mkdir -p ~/.local/bin
    mv ./kubectl ~/.local/bin/kubectl
    # and then append (or prepend) ~/.local/bin to $PATH
    ```

content/en/examples/pods/resource/memory-request-limit-3.yaml

@@ -8,9 +8,9 @@ spec:
   - name: memory-demo-3-ctr
     image: polinux/stress
     resources:
-      limits:
-        memory: "1000Gi"
       requests:
         memory: "1000Gi"
+      limits:
+        memory: "1000Gi"
     command: ["stress"]
     args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

content/en/examples/pods/resource/memory-request-limit.yaml

@@ -8,9 +8,9 @@ spec:
   - name: memory-demo-ctr
     image: polinux/stress
     resources:
-      limits:
-        memory: "200Mi"
       requests:
         memory: "100Mi"
+      limits:
+        memory: "200Mi"
     command: ["stress"]
     args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

content/ja/docs/concepts/cluster-administration/addons.md

@@ -21,7 +21,6 @@ content_type: concept
 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install)はFlannelとCalicoをあわせたもので、ネットワークとネットワークポリシーを提供します。
 * [Cilium](https://github.com/cilium/cilium)は、L3のネットワークとネットワークポリシーのプラグインで、HTTP/API/L7のポリシーを透過的に強制できます。ルーティングとoverlay/encapsulationモードの両方をサポートしており、他のCNIプラグイン上で機能できます。
 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)は、KubernetesをCalico、Canal、Flannel、Romana、Weaveなど選択したCNIプラグインをシームレスに接続できるようにするプラグインです。
-* [Contiv](https://contiv.github.io)は、さまざまなユースケースと豊富なポリシーフレームワーク向けに設定可能なネットワーク(BGPを使用したネイティブのL3、vxlanを使用したオーバーレイ、古典的なL2、Cisco-SDN/ACI)を提供します。Contivプロジェクトは完全に[オープンソース](https://github.com/contiv)です。[インストーラ](https://github.com/contiv/install)はkubeadmとkubeadm以外の両方をベースとしたインストールオプションがあります。
 * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)は、[Tungsten Fabric](https://tungsten.io)をベースにしている、オープンソースでマルチクラウドに対応したネットワーク仮想化およびポリシー管理プラットフォームです。ContrailおよびTungsten Fabricは、Kubernetes、OpenShift、OpenStack、Mesosなどのオーケストレーションシステムと統合されており、仮想マシン、コンテナ/Pod、ベアメタルのワークロードに隔離モードを提供します。
 * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)は、Kubernetesで使用できるオーバーレイネットワークプロバイダーです。
 * [Knitter](https://github.com/ZTE/Knitter/)は、1つのKubernetes Podで複数のネットワークインターフェイスをサポートするためのプラグインです。

content/ja/docs/concepts/scheduling-eviction/pod-overhead.md

@@ -0,0 +1,160 @@
+---
+title: Podのオーバーヘッド
+content_type: concept
+weight: 30
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+
+PodをNode上で実行する時に、Pod自身は大量のシステムリソースを消費します。これらのリソースは、Pod内のコンテナ(群)を実行するために必要なリソースとして追加されます。Podのオーバーヘッドは、コンテナの要求と制限に加えて、Podのインフラストラクチャで消費されるリソースを計算するための機能です。
+
+
+
+
+<!-- body -->
+
+Kubernetesでは、Podの[RuntimeClass](/docs/concepts/containers/runtime-class/)に関連するオーバーヘッドに応じて、[アドミッション](/ja/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)時にPodのオーバーヘッドが設定されます。
+
+Podのオーバーヘッドを有効にした場合、Podのスケジューリング時にコンテナのリソース要求の合計に加えて、オーバーヘッドも考慮されます。同様に、Kubeletは、Podのcgroupのサイズ決定時およびPodの退役の順位付け時に、Podのオーバーヘッドを含めます。
+
+## Podのオーバーヘッドの有効化　{#set-up}
+
+クラスター全体で`PodOverhead`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効になっていること（1.18時点ではデフォルトでオンになっています）と、`overhead`フィールドを定義する`RuntimeClass`が利用されていることを確認する必要があります。
+
+## 使用例
+
+Podのオーバーヘッド機能を使用するためには、`overhead`フィールドが定義されたRuntimeClassが必要です。例として、仮想マシンとゲストOSにPodあたり約120MiBを使用する仮想化コンテナランタイムで、次のようなRuntimeClassを定義できます。
+
+```yaml
+---
+kind: RuntimeClass
+apiVersion: node.k8s.io/v1
+metadata:
+    name: kata-fc
+handler: kata-fc
+overhead:
+    podFixed:
+        memory: "120Mi"
+        cpu: "250m"
+```
+
+`kata-fc`RuntimeClassハンドラーを指定して作成されたワークロードは、リソースクォータの計算や、Nodeのスケジューリング、およびPodのcgroupのサイズ決定にメモリーとCPUのオーバーヘッドが考慮されます。
+
+次のtest-podのワークロードの例を実行するとします。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: test-pod
+spec:
+  runtimeClassName: kata-fc
+  containers:
+  - name: busybox-ctr
+    image: busybox
+    stdin: true
+    tty: true
+    resources:
+      limits:
+        cpu: 500m
+        memory: 100Mi
+  - name: nginx-ctr
+    image: nginx
+    resources:
+      limits:
+        cpu: 1500m
+        memory: 100Mi
+```
+
+アドミッション時、RuntimeClass[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)は、RuntimeClass内に記述された`オーバーヘッド`を含むようにワークロードのPodSpecを更新します。もし既にPodSpec内にこのフィールドが定義済みの場合、そのPodは拒否されます。この例では、RuntimeClassの名前しか指定されていないため、アドミッションコントローラーは`オーバーヘッド`を含むようにPodを変更します。
+
+RuntimeClassのアドミッションコントローラーの後、更新されたPodSpecを確認できます。
+
+```bash
+kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
+```
+
+出力は次の通りです:
+```
+map[cpu:250m memory:120Mi]
+```
+ResourceQuotaが定義されている場合、コンテナ要求の合計と`オーバーヘッド`フィールドがカウントされます。
+
+kube-schedulerが新しいPodを実行すべきNodeを決定する際、スケジューラーはそのPodの`オーバーヘッド`と、そのPodに対するコンテナ要求の合計を考慮します。この例だと、スケジューラーは、要求とオーバーヘッドを追加し、2.25CPUと320MiBのメモリを持つNodeを探します。
+
+PodがNodeにスケジュールされると、そのNodeのkubeletはPodのために新しい{{< glossary_tooltip text="cgroup" term_id="cgroup" >}}を生成します。基盤となるコンテナランタイムがコンテナを作成するのは、このPod内です。
+
+リソースにコンテナごとの制限が定義されている場合(制限が定義されているGuaranteed QoSまたはBustrable QoS)、kubeletはそのリソース(CPUはcpu.cfs_quota_us、メモリはmemory.limit_in_bytes)に関連するPodのcgroupの上限を設定します。この上限は、コンテナの制限とPodSpecで定義された`オーバーヘッド`の合計に基づきます。
+
+CPUについては、PodがGuaranteedまたはBurstable QoSの場合、kubeletはコンテナの要求の合計とPodSpecに定義された`オーバーヘッド`に基づいて`cpu.share`を設定します。
+
+次の例より、ワークロードに対するコンテナの要求を確認できます。
+```bash
+kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'
+```
+
+コンテナの要求の合計は、CPUは2000m、メモリーは200MiBです。
+```
+map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
+```
+
+Nodeで観測される値と比較してみましょう。
+```bash
+kubectl describe node | grep test-pod -B2
+```
+
+出力では、2250mのCPUと320MiBのメモリーが要求されており、Podのオーバーヘッドが含まれていることが分かります。
+```
+  Namespace                   Name                CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE
+  ---------                   ----                ------------  ----------   ---------------  -------------  ---
+  default                     test-pod            2250m (56%)   2250m (56%)  320Mi (1%)       320Mi (1%)     36m
+```
+
+## Podのcgroupの制限を確認
+
+ワークロードで実行中のNode上にある、Podのメモリーのcgroupを確認します。次に示す例では、CRI互換のコンテナランタイムのCLIを提供するNodeで[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)を使用しています。これはPodのオーバーヘッドの動作を示すための高度な例であり、ユーザーがNode上で直接cgroupsを確認する必要はありません。
+
+まず、特定のNodeで、Podの識別子を決定します。
+
+```bash
+# PodがスケジュールされているNodeで実行
+POD_ID="$(sudo crictl pods --name test-pod -q)"
+```
+
+ここから、Podのcgroupのパスが決定します。
+```bash
+# PodがスケジュールされているNodeで実行
+sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
+```
+
+結果のcgroupパスにはPodの`ポーズ中`コンテナも含まれます。Podレベルのcgroupは１つ上のディレクトリです。
+```
+        "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
+```
+
+今回のケースでは、Podのcgroupパスは、`kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`となります。メモリーのPodレベルのcgroupの設定を確認しましょう。
+```bash
+# PodがスケジュールされているNodeで実行
+# また、Podに割り当てられたcgroupと同じ名前に変更
+ cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes
+```
+
+予想通り320MiBです。
+```
+335544320
+```
+
+### Observability
+
+Podのオーバヘッドが利用されているタイミングを特定し、定義されたオーバーヘッドで実行されているワークロードの安定性を観察するため、[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)には`kube_pod_overhead`というメトリクスが用意されています。この機能はv1.9のkube-state-metricsでは利用できませんが、次のリリースで期待されています。それまでは、kube-state-metricsをソースからビルドする必要があります。
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [RuntimeClass](/ja/docs/concepts/containers/runtime-class/)
+* [Podのオーバーヘッドの設計](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)