From cf858d854fe68c4f6afad23d21b69bef3fbdafdb Mon Sep 17 00:00:00 2001
From: Riita <42636694+riita10069@users.noreply.github.com>
Date: Wed, 20 Oct 2021 19:17:34 +0900
Subject: [PATCH 001/167] Update nodes.md
---
.../ja/docs/concepts/architecture/nodes.md | 131 +++++++++++++-----
1 file changed, 97 insertions(+), 34 deletions(-)
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index bf5fa1acb9..ec52ee7b1b 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -137,7 +137,7 @@ kubectl describe node <ノード名をここに挿入>
`SchedulingDisabled`はKubernetesのAPIにおけるConditionではありません;その代わり、cordonされたノードはUnschedulableとしてマークされます。
{{< /note >}}
-ノードのConditionはJSONオブジェクトで表現されます。例えば、正常なノードの場合は以下のような構造体が表示されます。
+Nodeの状態は、Nodeリソースの`.status`の一部として表現されます。例えば、正常なノードの場合は以下のようなjson構造が表示されます。
```json
"conditions": [
@@ -173,36 +173,25 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で
### Info {#info}
カーネルのバージョン、Kubernetesのバージョン（kubeletおよびkube-proxyのバージョン）、（使用されている場合）Dockerのバージョン、OS名など、ノードに関する一般的な情報です。
-この情報はノードからkubeletを通じて取得されます。
+この情報はノードからkubeletを通じて取得され、Kubernetes APIに公開されます。
-## 管理 {#management}
-[Pod](/ja/docs/concepts/workloads/pods/pod/)や[Service](/ja/docs/concepts/services-networking/service/)と違い、ノードは本質的にはKubernetesによって作成されません。GCPのようなクラウドプロバイダーによって外的に作成されるか、VMや物理マシンのプールに存在するものです。そのため、Kubernetesがノードを作成すると、そのノードを表すオブジェクトが作成されます。作成後、Kubernetesはそのノードが有効かどうかを確認します。 たとえば、次の内容からノードを作成しようとしたとします:
+## ハートビート
+ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。
+以下の２つのハートビートがあります：
+* ノードの`.status`の更新
+* [Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。
+各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。
+Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。
-```json
-{
- "kind": "Node",
- "apiVersion": "v1",
- "metadata": {
- "name": "10.240.79.157",
- "labels": {
- "name": "my-first-k8s-node"
- }
- }
-}
-```
+kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。
-Kubernetesは内部的にNodeオブジェクトを作成し、 `metadata.name`フィールドに基づくヘルスチェックによってノードを検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。
-Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです）
+- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。
-{{< note >}}
-Kubernetesは無効なノードのためにオブジェクトを保存し、それをチェックし続けます。
-このプロセスを停止するには、Nodeオブジェクトを明示的に削除する必要があります。
-{{< /note >}}
-現在、Kubernetesのノードインターフェースと相互作用する3つのコンポーネントがあります。ノードコントローラー、kubelet、およびkubectlです。
-### ノードコントローラー
+## ノードコントローラー
ノード{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は、ノードのさまざまな側面を管理するKubernetesのコントロールプレーンコンポーネントです。
@@ -216,16 +205,6 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ
ノードが到達不能(例えば、ノードがダウンしているなどので理由で、ノードコントローラーがハートビートの受信を停止した場合)になると、ノードコントローラーは、NodeStatusのNodeReady conditionをConditionUnknownに変更する役割があります。その後も該当ノードが到達不能のままであった場合、Graceful Terminationを使って全てのPodを退役させます。デフォルトのタイムアウトは、ConditionUnknownの報告を開始するまで40秒、その後Podの追い出しを開始するまで5分に設定されています。
ノードコントローラーは、`--node-monitor-period`に設定された秒数ごとに各ノードの状態をチェックします。
-#### ハートビート
-ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。
-２つのハートビートがあります：`NodeStatus`の更新と[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。
-各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。
-Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。
-
-kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。
-
-- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです）
-- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。
#### 信頼性
@@ -269,6 +248,90 @@ Pod以外のプロセス用にリソースを明示的に予約したい場合
kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。
詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。
+## Graceful node shutdown {#graceful-node-shutdown}
+
+{{< feature-state state="beta" for_k8s_version="v1.21" >}}
+
+kubeletは、ノードのシステムシャットダウンを検出すると、ノード上で動作しているポッドを終了させます。
+
+Kubelet は、ノードのシャットダウン時に、ポッドが通常の[通常のポッド終了プロセス](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)に従うようにします。
+
+Graceful node shutdownはsystemdに依存しているため、[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)を
+利用してノードのシャットダウンを一定時間遅らせることができます。
+
+Graceful node shutdownは、v1.21でデフォルトで有効になっている`GracefulNodeShutdown` [feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)で制御されます。
+
+なお、デフォルトでは、後述の設定オプション`ShutdownGracePeriod`および`ShutdownGracePeriodCriticalPods`の両方がゼロに設定されているため、Graceful node shutdownは有効になりません。この機能を有効にするには、この2つのkubeletの設定を適切に設定し、ゼロ以外の値を設定する必要があります。
+
+Graceful shutdownには, kubeletは以下の2段階でPodを終了させます。
+
+1. そのノード上で動作している通常のPodを終了させます。
+2. そのノード上で動作している[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)を終了させます。
+
+Graceful node shutdownには、2つの[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/)オプションを設定します。:
+* `ShutdownGracePeriod`:
+ * ノードがシャットダウンを遅らせるべき合計期間を指定します。これは、通常のPodと[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)の両方のPod終了の合計猶予期間です。
+* `ShutdownGracePeriodCriticalPods`:
+ * ノードのシャットダウン時に[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)を終了させるために使用する期間を指定します。この値は、ShutdownGracePeriodよりも小さくする必要があります。
+
+例えば、`ShutdownGracePeriod=30s`、`ShutdownGracePeriodCriticalPods=10s`とすると、
+kubeletはノードのシャットダウンを30秒遅らせます。シャットダウンの間、最初の20(30-10)秒は通常のポッドを優雅に終了させるために確保され、
+残りの10秒は重要なポッドを終了させるために確保されることになります。
+
+{{< note >}}
+Graceful node shutdown中にPodが退避された場合、それらのPodの`.status`は`Failed`になります。
+`kubectl get pods`を実行すると、退避させられたPodのステータスが `Shutdown` と表示されます。
+また、`kubectl describe pod`を実行すると、ノードのシャットダウンのためにPodが退避されたことがわかります。
+
+```
+Status: Failed
+Reason: Shutdown
+Message: Node is shutting, evicting pods
+```
+
+失敗したポッドオブジェクトは、明示的に削除されるか、[GCによってクリーンアップ](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)されるまで保存されます。
+これは、ノードが突然終了した場合とは異なった振る舞いです。
+
+{{< /note >}}
+
+## Swap memory management {#swap-memory}
+
+{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
+
+Kubernetes 1.22以前では、ノードはスワップメモリの使用をサポートしておらず、ノード上でスワップが検出された場合、
+kubeletはデフォルトで起動に失敗していました。1.22以降では、スワップメモリのサポートをノードごとに有効にすることができます。
+
+
+
+ノードでスワップを有効にするには、kubelet の `NodeSwap` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にし、
+`--fail-swap-on`コマンドラインフラグまたは`failSwapOn`[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)を false に設定する必要があります。
+
+
+ユーザーはオプションで、ノードがスワップメモリをどのように使用するかを指定するために、`memorySwap.swapBehavior`を設定することもできます。ノードがスワップメモリをどのように使用するかを指定します。例えば、以下のようになります。
+
+```yaml
+memorySwap:
+ swapBehavior: LimitedSwap
+```
+
+swapBehaviorで使用できる設定オプションは以下の通りです。:
+- `LimitedSwap`: Kubernetesのワークロードが、使用できるスワップ量に制限を設けます。Kubernetesが管理していないノード上のワークロードは、依然としてスワップを使用できます。
+- `UnlimitedSwap`: Kubernetesのワークロードが使用できるスワップ量に制限を設けません。システムの限界まで、要求されただけのスワップメモリを使用することができます。
+
+`memorySwap`の設定が指定されておらず、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、
+デフォルトのkubeletは`LimitedSwap`の設定と同じ動作を適用します。
+
+LimitedSwap`設定の動作は、ノードがコントロールグループ（「cgroups」とも呼ばれる）のv1とv2のどちらで動作しているかによって異なります。
+
+Kubernetesのワークロードでは、メモリとスワップを組み合わせて使用することができ、ポッドのメモリ制限が設定されている場合はその制限まで使用できます。
+- **cgroupsv1:** Kubernetesのワークロードは、メモリとスワップを組み合わせて使用することができ、ポッドのメモリ制限が設定されている場合はその制限まで使用できます。
+- **cgroupsv2:** Kubernetesのワークロードは、スワップメモリを使用できません。
+
+詳しくは、[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400)と
+[design proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)
+をご覧いただき、テストにご協力、ご意見をお聞かせください。
+
+
## {{% heading "whatsnext" %}}
* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について学習する。
From 2fdb8e2c1753e9bb102eb48c0c11c3848be5984e Mon Sep 17 00:00:00 2001
From: Riita <42636694+riita10069@users.noreply.github.com>
Date: Wed, 20 Oct 2021 23:10:30 +0900
Subject: [PATCH 002/167] Update pod-security-standards.md
---
.../security/pod-security-standards.md | 163 +++++++++++++++---
1 file changed, 138 insertions(+), 25 deletions(-)
diff --git a/content/ja/docs/concepts/security/pod-security-standards.md b/content/ja/docs/concepts/security/pod-security-standards.md
index 7b0f16dff1..dd3f91e79f 100644
--- a/content/ja/docs/concepts/security/pod-security-standards.md
+++ b/content/ja/docs/concepts/security/pod-security-standards.md
@@ -49,6 +49,25 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
| 項目 |
ポリシー |
+
+ | ホストのプロセス |
+
+ Windows ポッドは、Windows ノードへの特権的なアクセスを可能にするHostProcessコンテナを実行する機能を提供します。ベースラインポリシーでは、ホストへの特権的なアクセスは禁止されています。HostProcessポッドは、Kubernetes v1.22時点ではアルファ版の機能です。
+ ホストのネームスペースの共有は無効化すべきです。
+ 制限されるフィールド
+
+ spec.securityContext.windowsOptions.hostProcessspec.containers[*].securityContext.windowsOptions.hostProcessspec.initContainers[*].securityContext.windowsOptions.hostProcessspec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess
+ 認められる値
+
+ - Undefined/nil
+ false
+ |
+
| ホストのネームスペース |
@@ -57,7 +76,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
spec.hostNetwork
spec.hostPID
spec.hostIPC
-
認められる値: false
+
認められる値: false, Undefined/nil
|
@@ -67,6 +86,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
制限されるフィールド:
spec.containers[*].securityContext.privileged
spec.initContainers[*].securityContext.privileged
+ spec.ephemeralContainers[*].securityContext.privileged
認められる値: false, undefined/nil
@@ -77,7 +97,22 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
制限されるフィールド:
spec.containers[*].securityContext.capabilities.add
spec.initContainers[*].securityContext.capabilities.add
-
認められる値: 空 (または既知のリストに限定)
+ spec.ephemeralContainers[*].securityContext.capabilities.add
+
認められる値:
+ Undefined/nil
+ AUDIT_WRITE
+ CHOWN
+ DAC_OVERRIDE
+ FOWNER
+ FSETID
+ KILL
+ MKNOD
+ NET_BIND_SERVICE
+ SETFCAP
+ SETGID
+ SETPCAP
+ SETUID
+ SYS_CHROOT
@@ -96,6 +131,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
制限されるフィールド:
spec.containers[*].ports[*].hostPort
spec.initContainers[*].ports[*].hostPort
+ spec.ephemeralContainers[*].ports[*].hostPort
認められる値: 0, undefined (または既知のリストに限定)
@@ -105,7 +141,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
サポートされるホストでは、AppArmorの'runtime/default'プロファイルがデフォルトで適用されます。デフォルトのポリシーはポリシーの上書きや無効化を防ぎ、許可されたポリシーのセットを上書きできないよう制限すべきです。
制限されるフィールド:
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']
-
認められる値: 'runtime/default', undefined
+
認められる値: 'runtime/default', undefined, localhost/*
@@ -116,7 +152,24 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
spec.securityContext.seLinuxOptions
spec.containers[*].securityContext.seLinuxOptions
spec.initContainers[*].securityContext.seLinuxOptions
+ spec.ephemeralContainers[*].securityContext.seLinuxOptions.type
認められる値: undefined/nil
+ Undefined/""
+ container_t
+ container_init_t
+ container_kvm_t
+
+
制限されるフィールド:
+ spec.securityContext.seLinuxOptions.user
+ spec.containers[*].securityContext.seLinuxOptions.user
+ spec.initContainers[*].securityContext.seLinuxOptions.user
+ spec.ephemeralContainers[*].securityContext.seLinuxOptions.user
+ spec.securityContext.seLinuxOptions.role
+ spec.containers[*].securityContext.seLinuxOptions.role
+ spec.initContainers[*].securityContext.seLinuxOptions.role
+ spec.ephemeralContainers[*].securityContext.seLinuxOptions.role
+
認められる値: undefined/nil
+ Undefined/""
@@ -126,9 +179,29 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
制限されるフィールド:
spec.containers[*].securityContext.procMount
spec.initContainers[*].securityContext.procMount
+ spec.ephemeralContainers[*].securityContext.procMount
認められる値: undefined/nil, 'Default'
+
+ | Seccomp |
+
+ Seccompプロファイルを明示的にUnconfinedに設定することはできません。
+ Restricted Fields
+
+ spec.securityContext.seccompProfile.typespec.containers[*].securityContext.seccompProfile.typespec.initContainers[*].securityContext.seccompProfile.typespec.ephemeralContainers[*].securityContext.seccompProfile.type
+ Allowed Values
+
+ - Undefined/nil
+ RuntimeDefaultLocalhost
+ |
+
| Sysctl |
@@ -169,27 +242,27 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
HostPathボリュームの制限に加え、制限プロファイルではコアでない種類のボリュームの利用をPersistentVolumeにより定義されたものに限定します。
制限されるフィールド:
- spec.volumes[*].hostPath
- spec.volumes[*].gcePersistentDisk
- spec.volumes[*].awsElasticBlockStore
- spec.volumes[*].gitRepo
- spec.volumes[*].nfs
- spec.volumes[*].iscsi
- spec.volumes[*].glusterfs
- spec.volumes[*].rbd
- spec.volumes[*].flexVolume
- spec.volumes[*].cinder
- spec.volumes[*].cephFS
- spec.volumes[*].flocker
- spec.volumes[*].fc
- spec.volumes[*].azureFile
- spec.volumes[*].vsphereVolume
- spec.volumes[*].quobyte
- spec.volumes[*].azureDisk
- spec.volumes[*].portworxVolume
- spec.volumes[*].scaleIO
- spec.volumes[*].storageos
- spec.volumes[*].csi
+ spec.volumes[*].hostPath
+ spec.volumes[*].gcePersistentDisk
+ spec.volumes[*].awsElasticBlockStore
+ spec.volumes[*].gitRepo
+ spec.volumes[*].nfs
+ spec.volumes[*].iscsi
+ spec.volumes[*].glusterfs
+ spec.volumes[*].rbd
+ spec.volumes[*].flexVolume
+ spec.volumes[*].cinder
+ spec.volumes[*].cephfs
+ spec.volumes[*].flocker
+ spec.volumes[*].fc
+ spec.volumes[*].azureFile
+ spec.volumes[*].vsphereVolume
+ spec.volumes[*].quobyte
+ spec.volumes[*].azureDisk
+ spec.volumes[*].portworxVolume
+ spec.volumes[*].scaleIO
+ spec.volumes[*].storageos
+ spec.volumes[*].photonPersistentDisk
認められる値: undefined/nil
|
@@ -200,6 +273,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
制限されるフィールド:
spec.containers[*].securityContext.allowPrivilegeEscalation
spec.initContainers[*].securityContext.allowPrivilegeEscalation
+ spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation
認められる値: false
@@ -211,6 +285,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
spec.securityContext.runAsNonRoot
spec.containers[*].securityContext.runAsNonRoot
spec.initContainers[*].securityContext.runAsNonRoot
+ spec.ephemeralContainers[*].securityContext.runAsNonRoot
認められる値: true
@@ -242,6 +317,36 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
undefined / nil
+
+ | Capabilities (v1.22+) |
+
+
+ コンテナはすべてのケイパビリティを削除する必要があり、NET_BIND_SERVICEケイパビリティを追加することだけが許可されています。
+
+ Restricted Fields
+
+ spec.containers[*].securityContext.capabilities.dropspec.initContainers[*].securityContext.capabilities.dropspec.ephemeralContainers[*].securityContext.capabilities.drop
+ Allowed Values
+
+ - Any list of capabilities that includes
ALL
+
+
+ Restricted Fields
+
+ spec.containers[*].securityContext.capabilities.addspec.initContainers[*].securityContext.capabilities.addspec.ephemeralContainers[*].securityContext.capabilities.add
+ Allowed Values
+
+ - Undefined/nil
+ NET_BIND_SERVICE
+ |
+
@@ -281,9 +386,17 @@ Gatekeeper](https://github.com/open-policy-agent/gatekeeper)があります。
### WindowsのPodにはどのプロファイルを適用すればよいですか?
Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使用は制限や差異があります。
-特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
+特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
したがって、現段階では標準化されたセキュリティポリシーは存在しません。
+Windows Podに制限付きプロファイルを適用すると、実行時にPodに影響が出る場合があります。
+制限付きプロファイルでは、Linux 固有の制限 (seccomp プロファイルや特権昇格の不許可など) を適用する必要があります。
+kubelet および/またはそのコンテナランタイムがこれらの Linux 固有の値を無視した場合、Windows Podは制限付きプロファイル内で正常に動作します。
+ただし、強制力がないため、Windows コンテナを使用するPodについては、ベースラインプロファイルと比較して追加の制限はありません。
+
+HostProcess Podを作成するための HostProcess フラグの使用は、特権的なポリシーに沿ってのみ行われるべきです。
+Windows HostProcess Podの作成は、ベースラインおよび制限されたポリシーの下でブロックされているため、いかなる HostProcess Podも特権的であるとみなされるべきです。
+
### サンドボックス化されたPodはどのように扱えばよいでしょうか?
現在のところ、Podがサンドボックス化されていると見なされるかどうかを制御できるAPI標準はありません。
From 79a6b1972ff56469407e476e3b7955b7931fb3e8 Mon Sep 17 00:00:00 2001
From: Riita <42636694+riita10069@users.noreply.github.com>
Date: Sat, 30 Oct 2021 00:29:55 +0900
Subject: [PATCH 003/167] Update nodes.md
---
content/ja/docs/concepts/architecture/nodes.md | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index ec52ee7b1b..e1dcea5be5 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -248,7 +248,7 @@ Pod以外のプロセス用にリソースを明示的に予約したい場合
kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。
詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。
-## Graceful node shutdown {#graceful-node-shutdown}
+## Graceful Node Shutdown {#graceful-node-shutdown}
{{< feature-state state="beta" for_k8s_version="v1.21" >}}
@@ -256,10 +256,10 @@ kubeletは、ノードのシステムシャットダウンを検出すると、
Kubelet は、ノードのシャットダウン時に、ポッドが通常の[通常のポッド終了プロセス](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)に従うようにします。
-Graceful node shutdownはsystemdに依存しているため、[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)を
+Graceful Node Shutdownはsystemdに依存しているため、[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)を
利用してノードのシャットダウンを一定時間遅らせることができます。
-Graceful node shutdownは、v1.21でデフォルトで有効になっている`GracefulNodeShutdown` [feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)で制御されます。
+Graceful Node Shutdownは、v1.21でデフォルトで有効になっている`GracefulNodeShutdown` [feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)で制御されます。
なお、デフォルトでは、後述の設定オプション`ShutdownGracePeriod`および`ShutdownGracePeriodCriticalPods`の両方がゼロに設定されているため、Graceful node shutdownは有効になりません。この機能を有効にするには、この2つのkubeletの設定を適切に設定し、ゼロ以外の値を設定する必要があります。
@@ -268,7 +268,7 @@ Graceful shutdownには, kubeletは以下の2段階でPodを終了させます
1. そのノード上で動作している通常のPodを終了させます。
2. そのノード上で動作している[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)を終了させます。
-Graceful node shutdownには、2つの[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/)オプションを設定します。:
+Graceful Node Shutdownには、2つの[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/)オプションを設定します。:
* `ShutdownGracePeriod`:
* ノードがシャットダウンを遅らせるべき合計期間を指定します。これは、通常のPodと[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)の両方のPod終了の合計猶予期間です。
* `ShutdownGracePeriodCriticalPods`:
@@ -279,7 +279,7 @@ kubeletはノードのシャットダウンを30秒遅らせます。シャッ
残りの10秒は重要なポッドを終了させるために確保されることになります。
{{< note >}}
-Graceful node shutdown中にPodが退避された場合、それらのPodの`.status`は`Failed`になります。
+Graceful Node Shutdown中にPodが退避された場合、それらのPodの`.status`は`Failed`になります。
`kubectl get pods`を実行すると、退避させられたPodのステータスが `Shutdown` と表示されます。
また、`kubectl describe pod`を実行すると、ノードのシャットダウンのためにPodが退避されたことがわかります。
@@ -294,7 +294,7 @@ Message: Node is shutting, evicting pods
{{< /note >}}
-## Swap memory management {#swap-memory}
+## スワップメモリの管理 {#swap-memory}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
@@ -321,7 +321,7 @@ swapBehaviorで使用できる設定オプションは以下の通りです。:
`memorySwap`の設定が指定されておらず、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、
デフォルトのkubeletは`LimitedSwap`の設定と同じ動作を適用します。
-LimitedSwap`設定の動作は、ノードがコントロールグループ（「cgroups」とも呼ばれる）のv1とv2のどちらで動作しているかによって異なります。
+`LimitedSwap`設定の動作は、ノードがコントロールグループ（「cgroups」とも呼ばれる）のv1とv2のどちらで動作しているかによって異なります。
Kubernetesのワークロードでは、メモリとスワップを組み合わせて使用することができ、ポッドのメモリ制限が設定されている場合はその制限まで使用できます。
- **cgroupsv1:** Kubernetesのワークロードは、メモリとスワップを組み合わせて使用することができ、ポッドのメモリ制限が設定されている場合はその制限まで使用できます。
From 54cd481f36cd36a4c2270b37eccfcd34e139a66e Mon Sep 17 00:00:00 2001
From: Riita <42636694+riita10069@users.noreply.github.com>
Date: Sat, 30 Oct 2021 00:32:32 +0900
Subject: [PATCH 004/167] Update nodes.md
---
content/ja/docs/concepts/architecture/nodes.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index e1dcea5be5..000c4944e6 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -248,7 +248,7 @@ Pod以外のプロセス用にリソースを明示的に予約したい場合
kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。
詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。
-## Graceful Node Shutdown {#graceful-node-shutdown}
+## ノードの正常終了 {#graceful-node-shutdown}
{{< feature-state state="beta" for_k8s_version="v1.21" >}}
From 7d24269a648b223a693743add270714cd9a0d977 Mon Sep 17 00:00:00 2001
From: Riita <42636694+riita10069@users.noreply.github.com>
Date: Tue, 16 Nov 2021 19:32:40 +0900
Subject: [PATCH 005/167] Update pod-security-standards.md
---
.../security/pod-security-standards.md | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/content/ja/docs/concepts/security/pod-security-standards.md b/content/ja/docs/concepts/security/pod-security-standards.md
index dd3f91e79f..3a7bf61003 100644
--- a/content/ja/docs/concepts/security/pod-security-standards.md
+++ b/content/ja/docs/concepts/security/pod-security-standards.md
@@ -52,7 +52,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
| ホストのプロセス |
- Windows ポッドは、Windows ノードへの特権的なアクセスを可能にするHostProcessコンテナを実行する機能を提供します。ベースラインポリシーでは、ホストへの特権的なアクセスは禁止されています。HostProcessポッドは、Kubernetes v1.22時点ではアルファ版の機能です。
+ Windows Podは、Windowsノードへの特権的なアクセスを可能にするHostProcessコンテナを実行する機能を提供します。ベースラインポリシーでは、ホストへの特権的なアクセスは禁止されています。HostProcess Podは、Kubernetes v1.22時点ではアルファ版の機能です。
ホストのネームスペースの共有は無効化すべきです。
制限されるフィールド
@@ -136,7 +136,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
- | AppArmor (任意) |
+ AppArmor(任意) |
サポートされるホストでは、AppArmorの'runtime/default'プロファイルがデフォルトで適用されます。デフォルトのポリシーはポリシーの上書きや無効化を防ぎ、許可されたポリシーのセットを上書きできないよう制限すべきです。
制限されるフィールド:
@@ -153,7 +153,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
spec.containers[*].securityContext.seLinuxOptions
spec.initContainers[*].securityContext.seLinuxOptions
spec.ephemeralContainers[*].securityContext.seLinuxOptions.type
-
認められる値: undefined/nil
+
認められる値:undefined/nil
Undefined/""
container_t
container_init_t
@@ -168,7 +168,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
spec.containers[*].securityContext.seLinuxOptions.role
spec.initContainers[*].securityContext.seLinuxOptions.role
spec.ephemeralContainers[*].securityContext.seLinuxOptions.role
-
認められる値: undefined/nil
+
認められる値:undefined/nil
Undefined/""
|
@@ -180,7 +180,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
spec.containers[*].securityContext.procMount
spec.initContainers[*].securityContext.procMount
spec.ephemeralContainers[*].securityContext.procMount
-
認められる値: undefined/nil, 'Default'
+
認められる値:undefined/nil, 'Default'
@@ -390,12 +390,12 @@ Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使
したがって、現段階では標準化されたセキュリティポリシーは存在しません。
Windows Podに制限付きプロファイルを適用すると、実行時にPodに影響が出る場合があります。
-制限付きプロファイルでは、Linux 固有の制限 (seccomp プロファイルや特権昇格の不許可など) を適用する必要があります。
-kubelet および/またはそのコンテナランタイムがこれらの Linux 固有の値を無視した場合、Windows Podは制限付きプロファイル内で正常に動作します。
+制限付きプロファイルでは、Linux固有の制限 (seccompプロファイルや特権昇格の不許可など) を適用する必要があります。
+kubeletおよび/またはそのコンテナランタイムがこれらのLinux固有の値を無視した場合、Windows Podは制限付きプロファイル内で正常に動作します。
ただし、強制力がないため、Windows コンテナを使用するPodについては、ベースラインプロファイルと比較して追加の制限はありません。
-HostProcess Podを作成するための HostProcess フラグの使用は、特権的なポリシーに沿ってのみ行われるべきです。
-Windows HostProcess Podの作成は、ベースラインおよび制限されたポリシーの下でブロックされているため、いかなる HostProcess Podも特権的であるとみなされるべきです。
+HostProcess Podを作成するためのHostProcessフラグの使用は、特権的なポリシーに沿ってのみ行われるべきです。
+Windows HostProcess Podの作成は、ベースラインおよび制限されたポリシーの下でブロックされているため、いかなるHostProcess Podも特権的であるとみなされるべきです。
### サンドボックス化されたPodはどのように扱えばよいでしょうか?
From b37a9ca3618a9ce8089fbd0fd744cee9cf00e035 Mon Sep 17 00:00:00 2001
From: Riita <42636694+riita10069@users.noreply.github.com>
Date: Wed, 17 Nov 2021 00:45:02 +0900
Subject: [PATCH 006/167] Update secret.md
---
.../ja/docs/concepts/configuration/secret.md | 56 ++++++++++++++-----
1 file changed, 41 insertions(+), 15 deletions(-)
diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md
index f2a71e1860..0821b42a80 100644
--- a/content/ja/docs/concepts/configuration/secret.md
+++ b/content/ja/docs/concepts/configuration/secret.md
@@ -10,14 +10,31 @@ weight: 30
-KubernetesのSecretはパスワード、OAuthトークン、SSHキーのような機密情報を保存し、管理できるようにします。
-Secretに機密情報を保存することは、それらを{{< glossary_tooltip text="Pod" term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載するより、安全で柔軟です。
-詳しくは[Secretの設計文書](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)を参照してください。
-Secretはパスワード、トークン、キーのような小容量の機密データを含むオブジェクトです。
-他の方法としては、そのような情報はPodの定義やイメージに含めることができます。
-ユーザーはSecretを作ることができ、またシステムが作るSecretもあります。
+Secretとは、パスワードやトークン、キーなどの少量の機密データを含むオブジェクトのことです。
+このような情報は、Secretを用いないと {{< glossary_tooltip term_id="pod" >}} の定義や
+{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載することになってしまうかもしれません。
+シークレットを使用すれば、アプリケーションコードに機密データを含める必要がなくなります。
+なぜなら、シークレットは、それを使用するポッドとは独立して作成することができ、
+ポッドの作成、閲覧、編集といったワークフローの中でシークレット（およびそのデータ）が漏洩する危険性が低くなるためです。
+また、Kubernetesやクラスタ内で動作するアプリケーションは、不揮発性ストレージに機密データを書き込まないようにするなど、Secretsで追加の予防措置を取ることができます。
+
+Secretsは、{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}
+に似ていますが、機密データを保持するために用います。
+
+
+{{< caution >}}
+KubernetesのSecretは、デフォルトでは、APIサーバーの基礎となるデータストア（etcd）に暗号化されずに保存されます。APIにアクセスできる人は誰でもSecretを取得または変更でき、etcdにアクセスできる人も同様です。
+さらに、名前空間でPodを作成する権限を持つ人は、そのアクセスを使用して、その名前空間のあらゆるSecretを読むことができます。これには、Deploymentを作成する能力などの間接的なアクセスも含まれます。
+
+Secretsを安全に使用するには、以下の手順を推奨します。
+
+1. Secretsを[安全に暗号化する](/docs/tasks/administer-cluster/encrypt-data/)
+2. Secretsのデータの読み取りを制限する[RBACルール](/docs/reference/access-authn-authz/authorization/)の有効化または設定
+3. 適切な場合には、RBACなどのメカニズムを使用して、どの原則が新しいSecretの作成や既存のSecretの置き換えを許可されるかを制限します。
+
+{{< /caution >}}
@@ -30,6 +47,7 @@ PodがSecretを使う方法は3種類あります。
- [コンテナの環境変数](#using-secrets-as-environment-variables)として利用する
- Podを生成するために[kubeletがイメージをpullする](#using-imagepullsecrets)ときに使用する
+KubernetesのコントロールプレーンでもSecretsは使われています。例えば、[bootstrap token Secrets](#bootstrap-token-secrets)は、ノード登録を自動化するための仕組みです。
Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
シークレットの構成ファイルを作成するときに、`data`および/または`stringData`フィールドを指定できます。`data`フィールドと`stringData`フィールドはオプションです。
@@ -145,7 +163,8 @@ Docker configファイルがない場合、または`kubectl`を使用してDock
kubectl create secret docker-registry secret-tiger-docker \
--docker-username=tiger \
--docker-password=pass113 \
- --docker-email=tiger@acme.com
+ --docker-email=tiger@acme.com \
+ --docker-server=my-registry.example:5000
```
このコマンドは、`kubernetes.io/dockerconfigjson`型のSecretを作成します。
@@ -153,15 +172,21 @@ kubectl create secret docker-registry secret-tiger-docker \
```json
{
- "auths": {
- "https://index.docker.io/v1/": {
- "username": "tiger",
- "password": "pass113",
- "email": "tiger@acme.com",
- "auth": "dGlnZXI6cGFzczExMw=="
- }
- }
+ "apiVersion": "v1",
+ "data": {
+ ".dockerconfigjson": "eyJhdXRocyI6eyJteS1yZWdpc3RyeTo1MDAwIjp7InVzZXJuYW1lIjoidGlnZXIiLCJwYXNzd29yZCI6InBhc3MxMTMiLCJlbWFpbCI6InRpZ2VyQGFjbWUuY29tIiwiYXV0aCI6ImRHbG5aWEk2Y0dGemN6RXhNdz09In19fQ=="
+ },
+ "kind": "Secret",
+ "metadata": {
+ "creationTimestamp": "2021-07-01T07:30:59Z",
+ "name": "secret-tiger-docker",
+ "namespace": "default",
+ "resourceVersion": "566718",
+ "uid": "e15c1d7b-9071-4100-8681-f3a7a2ce89ca"
+ },
+ "type": "kubernetes.io/dockerconfigjson"
}
+
```
### Basic authentication Secret
@@ -1062,3 +1087,4 @@ Podに複数のコンテナが含まれることもあります。しかし、Po
- [`kubectl`を使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を学ぶ
- [config fileを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を学ぶ
- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を学ぶ
+- [SecretのAPIリファレンス](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)を読む
From 8dd92746a486d64c46502fbd692eb78b2fd52bb9 Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:23:07 +0900
Subject: [PATCH 007/167] Update
content/ja/docs/concepts/security/pod-security-standards.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/security/pod-security-standards.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/security/pod-security-standards.md b/content/ja/docs/concepts/security/pod-security-standards.md
index 3a7bf61003..f55dc75ef5 100644
--- a/content/ja/docs/concepts/security/pod-security-standards.md
+++ b/content/ja/docs/concepts/security/pod-security-standards.md
@@ -390,7 +390,7 @@ Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使
したがって、現段階では標準化されたセキュリティポリシーは存在しません。
Windows Podに制限付きプロファイルを適用すると、実行時にPodに影響が出る場合があります。
-制限付きプロファイルでは、Linux固有の制限 (seccompプロファイルや特権昇格の不許可など) を適用する必要があります。
+制限付きプロファイルでは、Linux固有の制限(seccompプロファイルや特権昇格の不許可など)を適用する必要があります。
kubeletおよび/またはそのコンテナランタイムがこれらのLinux固有の値を無視した場合、Windows Podは制限付きプロファイル内で正常に動作します。
ただし、強制力がないため、Windows コンテナを使用するPodについては、ベースラインプロファイルと比較して追加の制限はありません。
From e0d3ec65b63132e402c2fd785640f4a800e1723c Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:24:53 +0900
Subject: [PATCH 008/167] Update
content/ja/docs/concepts/configuration/secret.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/configuration/secret.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md
index 0821b42a80..2aa3a99b3b 100644
--- a/content/ja/docs/concepts/configuration/secret.md
+++ b/content/ja/docs/concepts/configuration/secret.md
@@ -12,7 +12,7 @@ weight: 30
Secretとは、パスワードやトークン、キーなどの少量の機密データを含むオブジェクトのことです。
-このような情報は、Secretを用いないと {{< glossary_tooltip term_id="pod" >}} の定義や
+このような情報は、Secretを用いないと{{< glossary_tooltip term_id="pod" >}}の定義や
{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載することになってしまうかもしれません。
シークレットを使用すれば、アプリケーションコードに機密データを含める必要がなくなります。
From 93c0c2a51499627c3112139deafe69c0f7c0c386 Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:25:03 +0900
Subject: [PATCH 009/167] Update
content/ja/docs/concepts/configuration/secret.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/configuration/secret.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md
index 2aa3a99b3b..c9f95e4241 100644
--- a/content/ja/docs/concepts/configuration/secret.md
+++ b/content/ja/docs/concepts/configuration/secret.md
@@ -14,7 +14,7 @@ weight: 30
Secretとは、パスワードやトークン、キーなどの少量の機密データを含むオブジェクトのことです。
このような情報は、Secretを用いないと{{< glossary_tooltip term_id="pod" >}}の定義や
{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載することになってしまうかもしれません。
-シークレットを使用すれば、アプリケーションコードに機密データを含める必要がなくなります。
+Secretを使用すれば、アプリケーションコードに機密データを含める必要がなくなります。
なぜなら、シークレットは、それを使用するポッドとは独立して作成することができ、
ポッドの作成、閲覧、編集といったワークフローの中でシークレット（およびそのデータ）が漏洩する危険性が低くなるためです。
From f829e1698d3e65e34a0d7675b87843365897f286 Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:25:12 +0900
Subject: [PATCH 010/167] Update
content/ja/docs/concepts/configuration/secret.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/configuration/secret.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md
index c9f95e4241..7105a6df7e 100644
--- a/content/ja/docs/concepts/configuration/secret.md
+++ b/content/ja/docs/concepts/configuration/secret.md
@@ -17,7 +17,7 @@ Secretとは、パスワードやトークン、キーなどの少量の機密
Secretを使用すれば、アプリケーションコードに機密データを含める必要がなくなります。
なぜなら、シークレットは、それを使用するポッドとは独立して作成することができ、
-ポッドの作成、閲覧、編集といったワークフローの中でシークレット（およびそのデータ）が漏洩する危険性が低くなるためです。
+Podの作成、閲覧、編集といったワークフローの中でSecret(およびそのデータ)が漏洩する危険性が低くなるためです。
また、Kubernetesやクラスタ内で動作するアプリケーションは、不揮発性ストレージに機密データを書き込まないようにするなど、Secretsで追加の予防措置を取ることができます。
Secretsは、{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}
From 6c6d267a48a44af0f5d337a55bda643a77dcdf2a Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:25:23 +0900
Subject: [PATCH 011/167] Update
content/ja/docs/concepts/configuration/secret.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/configuration/secret.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md
index 7105a6df7e..d7435d9752 100644
--- a/content/ja/docs/concepts/configuration/secret.md
+++ b/content/ja/docs/concepts/configuration/secret.md
@@ -25,7 +25,7 @@ Secretsは、{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}
{{< caution >}}
-KubernetesのSecretは、デフォルトでは、APIサーバーの基礎となるデータストア（etcd）に暗号化されずに保存されます。APIにアクセスできる人は誰でもSecretを取得または変更でき、etcdにアクセスできる人も同様です。
+KubernetesのSecretは、デフォルトでは、APIサーバーの基礎となるデータストア(etcd)に暗号化されずに保存されます。APIにアクセスできる人は誰でもSecretを取得または変更でき、etcdにアクセスできる人も同様です。
さらに、名前空間でPodを作成する権限を持つ人は、そのアクセスを使用して、その名前空間のあらゆるSecretを読むことができます。これには、Deploymentを作成する能力などの間接的なアクセスも含まれます。
Secretsを安全に使用するには、以下の手順を推奨します。
From 76fdf0e3e66393f218e3397fb31f1b33913cbf7f Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:25:32 +0900
Subject: [PATCH 012/167] Update
content/ja/docs/concepts/configuration/secret.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/configuration/secret.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md
index d7435d9752..58728bc1b5 100644
--- a/content/ja/docs/concepts/configuration/secret.md
+++ b/content/ja/docs/concepts/configuration/secret.md
@@ -16,7 +16,7 @@ Secretとは、パスワードやトークン、キーなどの少量の機密
{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載することになってしまうかもしれません。
Secretを使用すれば、アプリケーションコードに機密データを含める必要がなくなります。
-なぜなら、シークレットは、それを使用するポッドとは独立して作成することができ、
+なぜなら、Secretは、それを使用するPodとは独立して作成することができ、
Podの作成、閲覧、編集といったワークフローの中でSecret(およびそのデータ)が漏洩する危険性が低くなるためです。
また、Kubernetesやクラスタ内で動作するアプリケーションは、不揮発性ストレージに機密データを書き込まないようにするなど、Secretsで追加の予防措置を取ることができます。
From 61cbfe80b2b94ee223a34b94933fa19b1dd06d65 Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:25:37 +0900
Subject: [PATCH 013/167] Update
content/ja/docs/concepts/configuration/secret.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/configuration/secret.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md
index 58728bc1b5..689fcdb4ac 100644
--- a/content/ja/docs/concepts/configuration/secret.md
+++ b/content/ja/docs/concepts/configuration/secret.md
@@ -18,7 +18,7 @@ Secretを使用すれば、アプリケーションコードに機密データ
なぜなら、Secretは、それを使用するPodとは独立して作成することができ、
Podの作成、閲覧、編集といったワークフローの中でSecret(およびそのデータ)が漏洩する危険性が低くなるためです。
-また、Kubernetesやクラスタ内で動作するアプリケーションは、不揮発性ストレージに機密データを書き込まないようにするなど、Secretsで追加の予防措置を取ることができます。
+また、Kubernetesやクラスター内で動作するアプリケーションは、不揮発性ストレージに機密データを書き込まないようにするなど、Secretで追加の予防措置を取ることができます。
Secretsは、{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}
に似ていますが、機密データを保持するために用います。
From 7a4cc6ca6611a2acc86baa0c2be6e6d44d9b2e8c Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:28:03 +0900
Subject: [PATCH 014/167] Update secret.md
---
content/ja/docs/concepts/configuration/secret.md | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md
index 689fcdb4ac..795196c3b2 100644
--- a/content/ja/docs/concepts/configuration/secret.md
+++ b/content/ja/docs/concepts/configuration/secret.md
@@ -12,16 +12,14 @@ weight: 30
Secretとは、パスワードやトークン、キーなどの少量の機密データを含むオブジェクトのことです。
-このような情報は、Secretを用いないと{{< glossary_tooltip term_id="pod" >}}の定義や
-{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載することになってしまうかもしれません。
+このような情報は、Secretを用いないと{{< glossary_tooltip term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載することになってしまうかもしれません。
Secretを使用すれば、アプリケーションコードに機密データを含める必要がなくなります。
なぜなら、Secretは、それを使用するPodとは独立して作成することができ、
Podの作成、閲覧、編集といったワークフローの中でSecret(およびそのデータ)が漏洩する危険性が低くなるためです。
また、Kubernetesやクラスター内で動作するアプリケーションは、不揮発性ストレージに機密データを書き込まないようにするなど、Secretで追加の予防措置を取ることができます。
-Secretsは、{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}
-に似ていますが、機密データを保持するために用います。
+Secretsは、{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}に似ていますが、機密データを保持するために用います。
{{< caution >}}
From 396ce8ed36c26c84c9f7120046c70130f2ef5b1e Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:29:57 +0900
Subject: [PATCH 015/167] Update content/ja/docs/concepts/architecture/nodes.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/architecture/nodes.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index 000c4944e6..9e0ba6f8b7 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -179,7 +179,7 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で
## ハートビート
ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。
以下の２つのハートビートがあります：
-* ノードの`.status`の更新
+* Nodeの`.status`の更新
* [Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。
各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。
Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。
From a4e66916cc9a7c0b7e7c8d720a858dfd5a2e015d Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:30:03 +0900
Subject: [PATCH 016/167] Update content/ja/docs/concepts/architecture/nodes.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/architecture/nodes.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index 9e0ba6f8b7..b0ee7d3fad 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -186,7 +186,7 @@ Leaseは軽量なリソースで、クラスターのスケールに応じてノ
kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。
-- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです）
+- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。(到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです)
- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。
From dc5509d1078cb8c56b2bb3ceb9f51b2db70b3b82 Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:30:09 +0900
Subject: [PATCH 017/167] Update content/ja/docs/concepts/architecture/nodes.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/architecture/nodes.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index b0ee7d3fad..cd07854eb6 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -252,7 +252,7 @@ kubeletはリソースの割当を決定する際にトポロジーのヒント
{{< feature-state state="beta" for_k8s_version="v1.21" >}}
-kubeletは、ノードのシステムシャットダウンを検出すると、ノード上で動作しているポッドを終了させます。
+kubeletは、ノードのシステムシャットダウンを検出すると、ノード上で動作しているPodを終了させます。
Kubelet は、ノードのシャットダウン時に、ポッドが通常の[通常のポッド終了プロセス](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)に従うようにします。
From db97e76b4137afed87a1be874e34c2b62d6e1e89 Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:30:19 +0900
Subject: [PATCH 018/167] Update content/ja/docs/concepts/architecture/nodes.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/architecture/nodes.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index cd07854eb6..0d88aa8f78 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -263,7 +263,7 @@ Graceful Node Shutdownは、v1.21でデフォルトで有効になっている`G
なお、デフォルトでは、後述の設定オプション`ShutdownGracePeriod`および`ShutdownGracePeriodCriticalPods`の両方がゼロに設定されているため、Graceful node shutdownは有効になりません。この機能を有効にするには、この2つのkubeletの設定を適切に設定し、ゼロ以外の値を設定する必要があります。
-Graceful shutdownには, kubeletは以下の2段階でPodを終了させます。
+Graceful shutdownでは、kubeletは以下の2段階でPodを終了させます。
1. そのノード上で動作している通常のPodを終了させます。
2. そのノード上で動作している[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)を終了させます。
From 6cc732a81760601c7b72bf673a58f89d8b900d69 Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:30:37 +0900
Subject: [PATCH 019/167] Update content/ja/docs/concepts/architecture/nodes.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/architecture/nodes.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index 0d88aa8f78..fec8de2a19 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -303,7 +303,7 @@ kubeletはデフォルトで起動に失敗していました。1.22以降では
-ノードでスワップを有効にするには、kubelet の `NodeSwap` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にし、
+ノードでスワップを有効にするには、kubeletの `NodeSwap` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にし、
`--fail-swap-on`コマンドラインフラグまたは`failSwapOn`[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)を false に設定する必要があります。
From a7e39dfeeaa4f926bbec78294c0362eca3311cc5 Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:30:48 +0900
Subject: [PATCH 020/167] Update content/ja/docs/concepts/architecture/nodes.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/architecture/nodes.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index fec8de2a19..9d2102c72e 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -259,7 +259,7 @@ Kubelet は、ノードのシャットダウン時に、ポッドが通常の[
Graceful Node Shutdownはsystemdに依存しているため、[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)を
利用してノードのシャットダウンを一定時間遅らせることができます。
-Graceful Node Shutdownは、v1.21でデフォルトで有効になっている`GracefulNodeShutdown` [feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)で制御されます。
+Graceful Node Shutdownは、v1.21でデフォルトで有効になっている`GracefulNodeShutdown` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)で制御されます。
なお、デフォルトでは、後述の設定オプション`ShutdownGracePeriod`および`ShutdownGracePeriodCriticalPods`の両方がゼロに設定されているため、Graceful node shutdownは有効になりません。この機能を有効にするには、この2つのkubeletの設定を適切に設定し、ゼロ以外の値を設定する必要があります。
From 5b8e9f968441b8851111c36306ad014f55657f4f Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:30:57 +0900
Subject: [PATCH 021/167] Update content/ja/docs/concepts/architecture/nodes.md
Co-authored-by: nasa9084
---
content/ja/docs/concepts/architecture/nodes.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index 9d2102c72e..b8cb9d3edd 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -321,7 +321,7 @@ swapBehaviorで使用できる設定オプションは以下の通りです。:
`memorySwap`の設定が指定されておらず、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、
デフォルトのkubeletは`LimitedSwap`の設定と同じ動作を適用します。
-`LimitedSwap`設定の動作は、ノードがコントロールグループ（「cgroups」とも呼ばれる）のv1とv2のどちらで動作しているかによって異なります。
+`LimitedSwap`設定の動作は、ノードがコントロールグループ(「cgroups」とも呼ばれる)のv1とv2のどちらで動作しているかによって異なります。
Kubernetesのワークロードでは、メモリとスワップを組み合わせて使用することができ、ポッドのメモリ制限が設定されている場合はその制限まで使用できます。
- **cgroupsv1:** Kubernetesのワークロードは、メモリとスワップを組み合わせて使用することができ、ポッドのメモリ制限が設定されている場合はその制限まで使用できます。
From 6530c8c1eef04b39afd1facb6a3eac33a6aac1a1 Mon Sep 17 00:00:00 2001
From: Ryota Yamada <42636694+riita10069@users.noreply.github.com>
Date: Sun, 2 Jan 2022 18:32:17 +0900
Subject: [PATCH 022/167] Update nodes.md
---
content/ja/docs/concepts/architecture/nodes.md | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md
index b8cb9d3edd..9db1841c3a 100644
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@@ -318,8 +318,7 @@ swapBehaviorで使用できる設定オプションは以下の通りです。:
- `LimitedSwap`: Kubernetesのワークロードが、使用できるスワップ量に制限を設けます。Kubernetesが管理していないノード上のワークロードは、依然としてスワップを使用できます。
- `UnlimitedSwap`: Kubernetesのワークロードが使用できるスワップ量に制限を設けません。システムの限界まで、要求されただけのスワップメモリを使用することができます。
-`memorySwap`の設定が指定されておらず、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、
-デフォルトのkubeletは`LimitedSwap`の設定と同じ動作を適用します。
+`memorySwap`の設定が指定されておらず、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、デフォルトのkubeletは`LimitedSwap`の設定と同じ動作を適用します。
`LimitedSwap`設定の動作は、ノードがコントロールグループ(「cgroups」とも呼ばれる)のv1とv2のどちらで動作しているかによって異なります。
@@ -328,8 +327,7 @@ Kubernetesのワークロードでは、メモリとスワップを組み合わ
- **cgroupsv2:** Kubernetesのワークロードは、スワップメモリを使用できません。
詳しくは、[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400)と
-[design proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)
-をご覧いただき、テストにご協力、ご意見をお聞かせください。
+[design proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)をご覧いただき、テストにご協力、ご意見をお聞かせください。
## {{% heading "whatsnext" %}}
From 730b9b09e98b3febb2b39787cd7c85c3eeb48139 Mon Sep 17 00:00:00 2001
From: Josh Berkus
Date: Thu, 13 Jan 2022 17:45:04 -0800
Subject: [PATCH 023/167] Fix link to dev@kubernetes mailing list
Signed-off-by: Josh Berkus
---
content/ja/docs/setup/learning-environment/minikube.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/setup/learning-environment/minikube.md b/content/ja/docs/setup/learning-environment/minikube.md
index 171d2b1b1e..58fce33a34 100644
--- a/content/ja/docs/setup/learning-environment/minikube.md
+++ b/content/ja/docs/setup/learning-environment/minikube.md
@@ -522,4 +522,4 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr
## コミュニティ
-コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の`#minikube`チャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
+コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の`#minikube`チャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[dev@kubernetes Google Groupsメーリングリスト](https://groups.google.com/a/kubernetes.io/g/dev/)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
From f5fac359bb64637abdb68443c5ff0e9c3b05df3c Mon Sep 17 00:00:00 2001
From: Kobayashi Daisuke
Date: Tue, 18 Jan 2022 15:35:10 +0900
Subject: [PATCH 024/167] translate topology-aware-hints into Japanese
---
.../topology-aware-hints.md | 105 ++++++++++++++++++
1 file changed, 105 insertions(+)
create mode 100644 content/ja/docs/concepts/services-networking/topology-aware-hints.md
diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
new file mode 100644
index 0000000000..e56d7bf73d
--- /dev/null
+++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
@@ -0,0 +1,105 @@
+---
+reviewers:
+- robscott
+title: Topology Aware Hints
+content_type: concept
+weight: 45
+---
+
+
+
+
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
+
+*Topology Aware Hints*は、クライアントがendpointをどのように使用するかについての提案を含めることにより、トポロジーを考慮したルーティングを可能にします。このアプローチでは、EndpointSliceおよび/またはEndpointオブジェクトの消費者が、これらのネットワークエンドポイントへのトラフィックを、それが発生した場所の近くにルーティングできるように、メタデータを追加します。
+
+たとえば、ローカリティ内でトラフィックをルーティングすることで、コストを削減したり、ネットワークパフォーマンスを向上させたりできます。
+
+
+
+## 動機
+
+Kubernetesクラスタは、マルチゾーン環境で展開されることが多くなっています。
+トポロジー・アウェア・ヒント_は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
+EndpointSliceコントローラは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
+{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスタコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です。(トポロジー的に近いendpointを優先する)。
+
+
+## Topology Aware Hintを使う
+
+`service.kubernetes.io/topology-aware-hints`アノテーションを`auto`に設定すると、サービスに対してTopology Aware Hintを有効にすることができます。これは、EndpointSliceコントローラーが安全と判断した場合に、トポロジーヒントを設定するように指示します。
+重要なのは、これはヒントが常に設定されることを保証するものではないことです。
+
+## 使い方 {#implementation}
+
+この機能を有効にする機能は、EndpointSliceコントローラーとkube-proxyの2つのコンポーネントに分かれています。このセクションでは、各コンポーネントがこの機能をどのように実装しているか、高レベルの概要を説明します。
+
+### EndpointSliceコントローラー {#implementation-control-plane}
+
+この機能が有効な場合、EndpointSliceコントローラーはEndpointSliceにヒントを設定する役割を担います。
+コントローラーは、各ゾーンに比例した量のendpointを割り当てます。
+この割合は、そのゾーンで実行されているノードの[割り当て可能な](/ja/docs/task/administer-cluster/reserve-compute-resources/#node-allocatable)CPUコアを基に決定されます。
+
+たとえば、あるゾーンに2つのCPUコアがあり、別のゾーンに1つのCPUコアしかない場合、コントローラは2つのCPUコアを持つゾーンに2倍のendpointを割り当てます。
+
+次の例は、ヒントが入力されたときのEndpointSliceの外観を示しています。
+
+```yaml
+apiVersion: discovery.k8s.io/v1
+kind: EndpointSlice
+metadata:
+ name: example-hints
+ labels:
+ kubernetes.io/service-name: example-svc
+addressType: IPv4
+ports:
+ - name: http
+ protocol: TCP
+ port: 80
+endpoints:
+ - addresses:
+ - "10.1.2.3"
+ conditions:
+ ready: true
+ hostname: pod-1
+ zone: zone-a
+ hints:
+ forZones:
+ - name: "zone-a"
+```
+
+### kube-proxy {#implementation-kube-proxy}
+
+kube-proxyは、EndpointSliceコントローラーによって設定されたヒントに基づいて、ルーティング先のendpointをフィルター処理します。ほとんどの場合、これは、kube-proxyが同じゾーン内のendpointにトラフィックをルーティングできることを意味します。コントローラーが別のゾーンからendpointを割り当てて、ゾーン間でendpointがより均等に分散されるようにする場合があります。これにより、一部のトラフィックが他のゾーンにルーティングされます。
+
+## セーフガード
+
+各ノードのKubernetesコントロールプレーンとkube-proxyは、Topology Aware Hintを使用する前に、いくつかのセーフガードルールを適用します。これらがチェックアウトされない場合、kube-proxyは、ゾーンに関係なく、クラスター内のどこからでもendpointを選択します。
+
+1. **endpointの数が不十分です：** クラスター内のゾーンよりもendpointが少ない場合、コントローラーはヒントを割り当てません。
+
+2. **バランスの取れた割り当てを実現できません：** 場合によっては、ゾーン間でendpointのバランスの取れた割り当てを実現できないことがあります。たとえば、ゾーンaがゾーンbの2倍の大きさであるが、endpointが2つしかない場合、ゾーンaに割り当てられたendpointはゾーンbの2倍のトラフィックを受信する可能性があります。この「予想される過負荷」値が各ゾーンの許容しきい値を下回ることができない場合、コントローラーはヒントを割り当てません。重要なことに、これはリアルタイムのフィードバックに基づいていません。それでも、個々のendpointが過負荷になる可能性があります。
+
+3. **1つ以上のノードの情報が不十分です：**ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。
+
+4. **1つ以上のendpointにゾーンヒントが存在しません：** これが発生すると、kube-proxyはTopology Aware Hintsから、またはTopology Aware Hintsへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。
+
+5. **ゾーンはヒントで表されません：** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは、既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。
+
+## Constraints
+
+* サービスで`externalTrafficPolicy`または`internalTrafficPolicy`が`Local`に設定されている場合、Topology Aware Hintは使用されません。同じServiceではなく、異なるServiceの同じクラスターで両方の機能を使用することができます。
+
+* このアプローチは、ゾーンのサブセットから発信されるトラフィックの割合が高いサービスではうまく機能しません。代わりに、これは、着信トラフィックが各ゾーンのノードの容量にほぼ比例することを前提としています。
+
+* EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。
+
+* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip
+ text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスタ内のノードのサブセットに制限されている場合、これは考慮されません。
+
+* これは、オートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip
+ text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。
+
+## {{% heading "whatsnext" %}}
+
+* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。
From d2ad1640c3a5ad540bb6ef858dc64be51bfdbe52 Mon Sep 17 00:00:00 2001
From: Kobayashi Daisuke
Date: Tue, 18 Jan 2022 15:40:34 +0900
Subject: [PATCH 025/167] fix build error
---
.../docs/concepts/services-networking/topology-aware-hints.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
index e56d7bf73d..f69bf04b64 100644
--- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md
+++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
@@ -20,7 +20,7 @@ weight: 45
## 動機
Kubernetesクラスタは、マルチゾーン環境で展開されることが多くなっています。
-トポロジー・アウェア・ヒント_は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
+トポロジー・アウェア・ヒント_は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
EndpointSliceコントローラは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスタコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です。(トポロジー的に近いendpointを優先する)。
From 027b08ca2202531c4d4255ab876c9928292408b4 Mon Sep 17 00:00:00 2001
From: Kobayashi Daisuke
Date: Tue, 18 Jan 2022 16:07:37 +0900
Subject: [PATCH 026/167] fix some mistakes
---
.../services-networking/topology-aware-hints.md | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
index f69bf04b64..d988388c90 100644
--- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md
+++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
@@ -1,7 +1,7 @@
---
reviewers:
- robscott
-title: Topology Aware Hints
+title: Topology Aware Hint
content_type: concept
weight: 45
---
@@ -11,7 +11,7 @@ weight: 45
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
-*Topology Aware Hints*は、クライアントがendpointをどのように使用するかについての提案を含めることにより、トポロジーを考慮したルーティングを可能にします。このアプローチでは、EndpointSliceおよび/またはEndpointオブジェクトの消費者が、これらのネットワークエンドポイントへのトラフィックを、それが発生した場所の近くにルーティングできるように、メタデータを追加します。
+*Topology Aware Hint*は、クライアントがendpointをどのように使用するかについての提案を含めることにより、トポロジーを考慮したルーティングを可能にします。このアプローチでは、EndpointSliceおよび/またはEndpointオブジェクトの消費者が、これらのネットワークエンドポイントへのトラフィックを、それが発生した場所の近くにルーティングできるように、メタデータを追加します。
たとえば、ローカリティ内でトラフィックをルーティングすることで、コストを削減したり、ネットワークパフォーマンスを向上させたりできます。
@@ -20,9 +20,9 @@ weight: 45
## 動機
Kubernetesクラスタは、マルチゾーン環境で展開されることが多くなっています。
-トポロジー・アウェア・ヒント_は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
+*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
EndpointSliceコントローラは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
-{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスタコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です。(トポロジー的に近いendpointを優先する)。
+{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスタコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。
## Topology Aware Hintを使う
@@ -80,9 +80,9 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ
2. **バランスの取れた割り当てを実現できません：** 場合によっては、ゾーン間でendpointのバランスの取れた割り当てを実現できないことがあります。たとえば、ゾーンaがゾーンbの2倍の大きさであるが、endpointが2つしかない場合、ゾーンaに割り当てられたendpointはゾーンbの2倍のトラフィックを受信する可能性があります。この「予想される過負荷」値が各ゾーンの許容しきい値を下回ることができない場合、コントローラーはヒントを割り当てません。重要なことに、これはリアルタイムのフィードバックに基づいていません。それでも、個々のendpointが過負荷になる可能性があります。
-3. **1つ以上のノードの情報が不十分です：**ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。
+3. **1つ以上のノードの情報が不十分です：** ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。
-4. **1つ以上のendpointにゾーンヒントが存在しません：** これが発生すると、kube-proxyはTopology Aware Hintsから、またはTopology Aware Hintsへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。
+4. **1つ以上のendpointにゾーンヒントが存在しません：** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。
5. **ゾーンはヒントで表されません：** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは、既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。
From d48800b7632030e4ca719f7efa8e75dfc0e708ed Mon Sep 17 00:00:00 2001
From: Kobayashi Daisuke
Date: Wed, 19 Jan 2022 17:21:35 +0900
Subject: [PATCH 027/167] =?UTF-8?q?address=20reviews=20(change=20"?=
=?UTF-8?q?=E3=83=BC",=20"=EF=BC=9A")?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
.../topology-aware-hints.md | 26 +++++++++----------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
index d988388c90..70b710de91 100644
--- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md
+++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
@@ -1,7 +1,5 @@
---
-reviewers:
-- robscott
-title: Topology Aware Hint
+title: トポロジーを意識したヒント
content_type: concept
weight: 45
---
@@ -19,10 +17,10 @@ weight: 45
## 動機
-Kubernetesクラスタは、マルチゾーン環境で展開されることが多くなっています。
-*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
-EndpointSliceコントローラは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
-{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスタコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。
+Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。
+*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
+EndpointSliceコントローラーは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
+{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。
## Topology Aware Hintを使う
@@ -40,7 +38,7 @@ EndpointSliceコントローラは、各endpointのトポロジー（地域と
コントローラーは、各ゾーンに比例した量のendpointを割り当てます。
この割合は、そのゾーンで実行されているノードの[割り当て可能な](/ja/docs/task/administer-cluster/reserve-compute-resources/#node-allocatable)CPUコアを基に決定されます。
-たとえば、あるゾーンに2つのCPUコアがあり、別のゾーンに1つのCPUコアしかない場合、コントローラは2つのCPUコアを持つゾーンに2倍のendpointを割り当てます。
+たとえば、あるゾーンに2つのCPUコアがあり、別のゾーンに1つのCPUコアしかない場合、コントローラーは2つのCPUコアを持つゾーンに2倍のendpointを割り当てます。
次の例は、ヒントが入力されたときのEndpointSliceの外観を示しています。
@@ -76,15 +74,15 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ
各ノードのKubernetesコントロールプレーンとkube-proxyは、Topology Aware Hintを使用する前に、いくつかのセーフガードルールを適用します。これらがチェックアウトされない場合、kube-proxyは、ゾーンに関係なく、クラスター内のどこからでもendpointを選択します。
-1. **endpointの数が不十分です：** クラスター内のゾーンよりもendpointが少ない場合、コントローラーはヒントを割り当てません。
+1. **endpointの数が不十分です:** クラスター内のゾーンよりもendpointが少ない場合、コントローラーはヒントを割り当てません。
-2. **バランスの取れた割り当てを実現できません：** 場合によっては、ゾーン間でendpointのバランスの取れた割り当てを実現できないことがあります。たとえば、ゾーンaがゾーンbの2倍の大きさであるが、endpointが2つしかない場合、ゾーンaに割り当てられたendpointはゾーンbの2倍のトラフィックを受信する可能性があります。この「予想される過負荷」値が各ゾーンの許容しきい値を下回ることができない場合、コントローラーはヒントを割り当てません。重要なことに、これはリアルタイムのフィードバックに基づいていません。それでも、個々のendpointが過負荷になる可能性があります。
+2. **バランスの取れた割り当てを実現できません:** 場合によっては、ゾーン間でendpointのバランスの取れた割り当てを実現できないことがあります。たとえば、ゾーンaがゾーンbの2倍の大きさであるが、endpointが2つしかない場合、ゾーンaに割り当てられたendpointはゾーンbの2倍のトラフィックを受信する可能性があります。この「予想される過負荷」値が各ゾーンの許容しきい値を下回ることができない場合、コントローラーはヒントを割り当てません。重要なことに、これはリアルタイムのフィードバックに基づいていません。それでも、個々のendpointが過負荷になる可能性があります。
-3. **1つ以上のノードの情報が不十分です：** ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。
+3. **1つ以上のノードの情報が不十分です:** ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。
-4. **1つ以上のendpointにゾーンヒントが存在しません：** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。
+4. **1つ以上のendpointにゾーンヒントが存在しません:** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。
-5. **ゾーンはヒントで表されません：** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは、既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。
+5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは、既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。
## Constraints
@@ -95,7 +93,7 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ
* EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。
* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip
- text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスタ内のノードのサブセットに制限されている場合、これは考慮されません。
+ text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。
* これは、オートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip
text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。
From ffa586acf4fb8b6368eafc975e331bdcea0bd81e Mon Sep 17 00:00:00 2001
From: Kobayashi Daisuke
Date: Wed, 19 Jan 2022 18:03:14 +0900
Subject: [PATCH 028/167] Corresponds to review comments about comma.
---
.../services-networking/topology-aware-hints.md | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
index 70b710de91..cefba8b322 100644
--- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md
+++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
@@ -18,14 +18,14 @@ weight: 45
## 動機
Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。
-*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
+*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
EndpointSliceコントローラーは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。
## Topology Aware Hintを使う
-`service.kubernetes.io/topology-aware-hints`アノテーションを`auto`に設定すると、サービスに対してTopology Aware Hintを有効にすることができます。これは、EndpointSliceコントローラーが安全と判断した場合に、トポロジーヒントを設定するように指示します。
+`service.kubernetes.io/topology-aware-hints`アノテーションを`auto`に設定すると、サービスに対してTopology Aware Hintを有効にすることができます。これはEndpointSliceコントローラーが安全と判断した場合に、トポロジーヒントを設定するように指示します。
重要なのは、これはヒントが常に設定されることを保証するものではないことです。
## 使い方 {#implementation}
@@ -40,7 +40,7 @@ EndpointSliceコントローラーは、各endpointのトポロジー（地域
たとえば、あるゾーンに2つのCPUコアがあり、別のゾーンに1つのCPUコアしかない場合、コントローラーは2つのCPUコアを持つゾーンに2倍のendpointを割り当てます。
-次の例は、ヒントが入力されたときのEndpointSliceの外観を示しています。
+次の例は、ヒントが入力されたときのEndpointSliceの様子を示しています。
```yaml
apiVersion: discovery.k8s.io/v1
@@ -68,7 +68,7 @@ endpoints:
### kube-proxy {#implementation-kube-proxy}
-kube-proxyは、EndpointSliceコントローラーによって設定されたヒントに基づいて、ルーティング先のendpointをフィルター処理します。ほとんどの場合、これは、kube-proxyが同じゾーン内のendpointにトラフィックをルーティングできることを意味します。コントローラーが別のゾーンからendpointを割り当てて、ゾーン間でendpointがより均等に分散されるようにする場合があります。これにより、一部のトラフィックが他のゾーンにルーティングされます。
+kube-proxyは、EndpointSliceコントローラーによって設定されたヒントに基づいて、ルーティング先のendpointをフィルター処理します。ほとんどの場合、これはkube-proxyが同じゾーン内のendpointにトラフィックをルーティングできることを意味します。コントローラーが別のゾーンからendpointを割り当てて、ゾーン間でendpointがより均等に分散されるようにする場合があります。これにより、一部のトラフィックが他のゾーンにルーティングされます。
## セーフガード
@@ -82,20 +82,20 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ
4. **1つ以上のendpointにゾーンヒントが存在しません:** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。
-5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは、既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。
+5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。
-## Constraints
+## 制約事項
* サービスで`externalTrafficPolicy`または`internalTrafficPolicy`が`Local`に設定されている場合、Topology Aware Hintは使用されません。同じServiceではなく、異なるServiceの同じクラスターで両方の機能を使用することができます。
-* このアプローチは、ゾーンのサブセットから発信されるトラフィックの割合が高いサービスではうまく機能しません。代わりに、これは、着信トラフィックが各ゾーンのノードの容量にほぼ比例することを前提としています。
+* このアプローチは、ゾーンのサブセットから発信されるトラフィックの割合が高いサービスではうまく機能しません。代わりに、これは着信トラフィックが各ゾーンのノードの容量にほぼ比例することを前提としています。
* EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。
* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip
text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。
-* これは、オートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip
+* これはオートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip
text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。
## {{% heading "whatsnext" %}}
From 849a28d4aaf4bf2a31f256ac832b3689c4ff7a8b Mon Sep 17 00:00:00 2001
From: Kobayashi Daisuke
Date: Tue, 1 Feb 2022 11:51:29 +0900
Subject: [PATCH 029/167] Update
content/ja/docs/concepts/services-networking/topology-aware-hints.md
Co-authored-by: nasa9084
---
.../docs/concepts/services-networking/topology-aware-hints.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
index cefba8b322..f6361fe447 100644
--- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md
+++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
@@ -82,7 +82,7 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ
4. **1つ以上のendpointにゾーンヒントが存在しません:** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。
-5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。
+5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを1つも見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。
## 制約事項
From 01abcb22e055ea2e0a4d1b181b6fad4bb0e3e33c Mon Sep 17 00:00:00 2001
From: Kobayashi Daisuke
Date: Tue, 1 Feb 2022 11:55:19 +0900
Subject: [PATCH 030/167] fix some points commented
---
.../services-networking/topology-aware-hints.md | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
index f6361fe447..c0131d42cd 100644
--- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md
+++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
@@ -11,15 +11,15 @@ weight: 45
*Topology Aware Hint*は、クライアントがendpointをどのように使用するかについての提案を含めることにより、トポロジーを考慮したルーティングを可能にします。このアプローチでは、EndpointSliceおよび/またはEndpointオブジェクトの消費者が、これらのネットワークエンドポイントへのトラフィックを、それが発生した場所の近くにルーティングできるように、メタデータを追加します。
-たとえば、ローカリティ内でトラフィックをルーティングすることで、コストを削減したり、ネットワークパフォーマンスを向上させたりできます。
+たとえば、局所的にトラフィックをルーティングすることで、コストを削減したり、ネットワークパフォーマンスを向上させたりできます。
## 動機
Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。
-*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
-EndpointSliceコントローラーは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
+*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー(地域とゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
+EndpointSliceコントローラーは、各endpointのトポロジー(地域とゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。
@@ -86,17 +86,15 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ
## 制約事項
-* サービスで`externalTrafficPolicy`または`internalTrafficPolicy`が`Local`に設定されている場合、Topology Aware Hintは使用されません。同じServiceではなく、異なるServiceの同じクラスターで両方の機能を使用することができます。
+* Serviceで`externalTrafficPolicy`または`internalTrafficPolicy`が`Local`に設定されている場合、Topology Aware Hintは使用されません。同じServiceではなく、異なるServiceの同じクラスターで両方の機能を使用することができます。
* このアプローチは、ゾーンのサブセットから発信されるトラフィックの割合が高いサービスではうまく機能しません。代わりに、これは着信トラフィックが各ゾーンのノードの容量にほぼ比例することを前提としています。
* EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。
-* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip
- text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。
+* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。
-* これはオートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip
- text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。
+* これはオートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。
## {{% heading "whatsnext" %}}
From 9e65cf1ba862d85db78ed76d9ac1d653447bcfa4 Mon Sep 17 00:00:00 2001
From: Kobayashi Daisuke
Date: Tue, 1 Feb 2022 12:06:30 +0900
Subject: [PATCH 031/167] update
---
.../docs/concepts/services-networking/topology-aware-hints.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
index c0131d42cd..b119dad348 100644
--- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md
+++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
@@ -92,7 +92,7 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ
* EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。
-* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。
+* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip text="toleration" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。
* これはオートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。
From 8b1b8a4f801ddbef52f5dc609b5013eff91f7621 Mon Sep 17 00:00:00 2001
From: PranshuSrivastava
Date: Thu, 21 Oct 2021 02:53:49 +0530
Subject: [PATCH 032/167] updated the container-runtime page to include info
about dockershim deprecation.
---
.../container-runtimes.md | 41 +++++++++++++------
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md
index 3d351c4dda..54897a1c59 100644
--- a/content/en/docs/setup/production-environment/container-runtimes.md
+++ b/content/en/docs/setup/production-environment/container-runtimes.md
@@ -16,7 +16,7 @@ what is involved and describes related tasks for setting up nodes.
Kubernetes {{< skew currentVersion >}} requires that you use a runtime that
-conforms with the
+conforms with the
{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI).
See [CRI version support](#cri-versions) for more information.
@@ -29,6 +29,19 @@ Kubernetes, on Linux:
- [Docker Engine](#docker)
- [Mirantis Container Runtime](#mcr)
+{{< note >}}
+Dockershim, the portion of code in Kubernetes that provided direct
+integration with Docker in prior releases, was removed from Kubernetes
+version 1.24. This removal was announced as a [deprecation in Kubernetes v 1.20](
+/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
+You can check out this [documentation](
+/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
+to understand how this deprecation might affect you. To migrate from
+dockershim you can follow [this migration guide](
+/docs/tasks/administer-cluster/migrating-from-dockershim/)
+to migrate from dockershim.
+{{< /note >}}
+
{{< note >}}
For other operating systems, look for documentation specific to your platform.
{{< /note >}}
@@ -151,10 +164,11 @@ Install containerd:
{{< tabs name="tab-cri-containerd-installation" >}}
{{% tab name="Linux" %}}
-1. Install the `containerd.io` package from the official Docker repositories.
-Instructions for setting up the Docker repository for your respective Linux distribution and
-installing the `containerd.io` package can be found at
-[Install Docker Engine](https://docs.docker.com/engine/install/#server).
+1. Install the `containerd.io` package from the [official containerd website](
+ https://containerd.io/downloads/).Instructions for setting up the Docker
+ repository for your respective Linux distribution and
+ installing the `containerd.io` package can be found at
+ [Install Docker Engine](https://docs.docker.com/engine/install/#server).
2. Configure containerd:
@@ -172,7 +186,7 @@ installing the `containerd.io` package can be found at
{{% /tab %}}
{{% tab name="Windows (PowerShell)" %}}
-Start a Powershell session, set `$Version` to the desired version (ex: `$Version="1.4.3"`),
+Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`),
and then run the following commands:
1. Download containerd:
@@ -299,7 +313,7 @@ sudo apt-get install cri-o cri-o-runc
{{% tab name="Ubuntu" %}}
-To install on the following operating systems, set the environment variable `OS`
+To install on the following operating systems, set the environment variable `OS`
to the appropriate field in the following table:
| Operating system | `$OS` |
@@ -335,7 +349,7 @@ sudo apt-get install cri-o cri-o-runc
{{% tab name="CentOS" %}}
-To install on the following operating systems, set the environment variable `OS`
+To install on the following operating systems, set the environment variable `OS`
to the appropriate field in the following table:
| Operating system | `$OS` |
@@ -416,10 +430,8 @@ in sync.
### Docker Engine {#docker}
-Docker Engine is the container runtime that started it all. Formerly known just as Docker,
-this container runtime is available in various forms.
-[Install Docker Engine](https://docs.docker.com/engine/install/) explains your options
-for installing this runtime.
+On each of your nodes, install Docker for your Linux distribution as per
+[Install Docker Engine](https://docs.docker.com/engine/install/#server).
Docker Engine is directly compatible with Kubernetes {{< skew currentVersion >}}, using the deprecated `dockershim` component. For more information
and context, see the [Dockershim deprecation FAQ](/dockershim).
@@ -428,7 +440,10 @@ You can also find third-party adapters that let you use Docker Engine with Kuber
through the supported {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}}
(CRI).
-The following CRI adaptors are designed to work with Docker Engine:
+{{< note >}}
+`overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher,
+or RHEL or CentOS using version 3.10.0-514 and above.
+{{< /note >}}
- [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) from Mirantis
From 33d4e36f6ecf2581004b258b7f71409705fede13 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <196thinline@gmail.com>
Date: Sun, 27 Feb 2022 15:04:19 +0900
Subject: [PATCH 033/167] docs:translate resource-bin-packing
---
.../resource-bin-packing.md | 197 ++++++++++++++++++
1 file changed, 197 insertions(+)
create mode 100644 content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
diff --git a/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
new file mode 100644
index 0000000000..cd976fff1d
--- /dev/null
+++ b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -0,0 +1,197 @@
+---
+title: 拡張リソースのリソースビンパッキング
+content_type: concept
+weight: 80
+---
+
+
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+kube-schedulerでは、優先度関数`RequestedToCapacityRatioResourceAllocation`を使用した、
+拡張リソースを含むリソースのビンパッキングを有効化できます。優先度関数はそれぞれのニーズに応じて、kube-schedulerを微調整するために使用できます。
+
+
+
+## `RequestedToCapacityRatioResourceAllocation`を使用したビンパッキングの有効化
+
+Kubernetesでは、キャパシティー比率への要求に基づいたNodeのスコアリングをするために、各リソースの重みと共にリソースを指定することができます。これにより、ユーザーは適切なパラメーターを使用することで拡張リソースをビンパックすることができ、大規模クラスターにおける希少なリソースを有効活用できるようになります。優先度関数`RequestedToCapacityRatioResourceAllocation`の動作は`RequestedToCapacityRatioArgs`と呼ばれる設定オプションによって変わります。この引数は`shape`と`resources`パラメーターによって構成されます。`shape`パラメーターは`利用率`と`スコア`の値に基づいて、最も要求が多い場合と最も要求が少ない場合の関数をチューニングできます。`resources`パラメーターは、スコアリングの際に考慮されるリソース名の`name`と、各リソースの重みを指定する`weight`で構成されます。
+
+以下は、拡張リソース`intel.com/foo`と`intel.com/bar`のビンパッキングに`requestedToCapacityRatioArguments`を設定する例になります。
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+profiles:
+# ...
+ pluginConfig:
+ - name: RequestedToCapacityRatio
+ args:
+ shape:
+ - utilization: 0
+ score: 10
+ - utilization: 100
+ score: 0
+ resources:
+ - name: intel.com/foo
+ weight: 3
+ - name: intel.com/bar
+ weight: 5
+```
+スケジューラには、kube-schedulerフラグ`--config=/path/to/config/file`を使用して`KubeSchedulerConfiguration`のファイルを指定することで渡すことができます。
+
+**この機能はデフォルトで無効化されています**
+
+### 優先度関数のチューニング
+
+`shape`は`RequestedToCapacityRatioPriority`関数の動作を指定するために使用されます。
+
+```yaml
+shape:
+ - utilization: 0
+ score: 0
+ - utilization: 100
+ score: 10
+```
+
+上記の引数は、`利用率`が0%の場合は0、`利用率`が100%の場合は10という`スコア`をNodeに与え、ビンパッキングの動作を有効にしています。最小要求を有効にするには、次のようにスコアを反転させる必要があります。
+
+```yaml
+shape:
+ - utilization: 0
+ score: 10
+ - utilization: 100
+ score: 0
+```
+
+`resources`はオプションパラメーターで、デフォルトでは以下の通りです。
+
+``` yaml
+resources:
+ - name: cpu
+ weight: 1
+ - name: memory
+ weight: 1
+```
+
+
+以下のように拡張リソースの追加に利用できます。
+
+```yaml
+resources:
+ - name: intel.com/foo
+ weight: 5
+ - name: cpu
+ weight: 3
+ - name: memory
+ weight: 1
+```
+
+`weight`はオプションパラメーターで、指定されてない場合1が設定されます。また、マイナスの値は設定できません。
+
+### キャパシティ割り当てのためのNodeスコアリング
+
+このセクションは、本機能の内部詳細について理解したい方を対象としています。以下は、与えられた値に対してNodeのスコアがどのように計算されるかの例です。
+
+要求されたリソース:
+
+```
+intel.com/foo : 2
+memory: 256MB
+cpu: 2
+```
+
+リソースの重み:
+
+```
+intel.com/foo : 5
+memory: 1
+cpu: 3
+```
+
+`shape`の値 {{0, 0}, {100, 10}}
+
+Node1のスペック:
+
+```
+Available:
+ intel.com/foo: 4
+ memory: 1 GB
+ cpu: 8
+
+Used:
+ intel.com/foo: 1
+ memory: 256MB
+ cpu: 1
+```
+
+Nodeのスコア:
+
+```
+intel.com/foo = resourceScoringFunction((2+1),4)
+ = (100 - ((4-3)*100/4)
+ = (100 - 25)
+ = 75 # requested + used = 75% * available
+ = rawScoringFunction(75)
+ = 7 # floor(75/10)
+
+memory = resourceScoringFunction((256+256),1024)
+ = (100 -((1024-512)*100/1024))
+ = 50 # requested + used = 50% * available
+ = rawScoringFunction(50)
+ = 5 # floor(50/10)
+
+cpu = resourceScoringFunction((2+1),8)
+ = (100 -((8-3)*100/8))
+ = 37.5 # requested + used = 37.5% * available
+ = rawScoringFunction(37.5)
+ = 3 # floor(37.5/10)
+
+NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
+ = 5
+```
+
+Node2のスペック:
+
+```
+Available:
+ intel.com/foo: 8
+ memory: 1GB
+ cpu: 8
+Used:
+ intel.com/foo: 2
+ memory: 512MB
+ cpu: 6
+```
+
+Nodeのスコア:
+
+```
+intel.com/foo = resourceScoringFunction((2+2),8)
+ = (100 - ((8-4)*100/8)
+ = (100 - 50)
+ = 50
+ = rawScoringFunction(50)
+ = 5
+
+memory = resourceScoringFunction((256+512),1024)
+ = (100 -((1024-768)*100/1024))
+ = 75
+ = rawScoringFunction(75)
+ = 7
+
+cpu = resourceScoringFunction((2+6),8)
+ = (100 -((8-8)*100/8))
+ = 100
+ = rawScoringFunction(100)
+ = 10
+
+NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
+ = 7
+
+```
+
+## {{% heading "whatsnext" %}}
+
+- [スケジューリングフレームワーク](/ja/docs/concepts/scheduling-eviction/scheduling-framework/)について更に読む
+- [スケジューラーの設定](/docs/reference/scheduling/config/)について更に読む
From 3359ef1ad1440d3b0908eaacee4d66e6de2fce46 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <196thinline@gmail.com>
Date: Sun, 6 Mar 2022 10:59:33 +0900
Subject: [PATCH 034/167] add:content/ja/docs/reference/scheduling/_index.md
---
content/ja/docs/reference/scheduling/_index.md | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 content/ja/docs/reference/scheduling/_index.md
diff --git a/content/ja/docs/reference/scheduling/_index.md b/content/ja/docs/reference/scheduling/_index.md
new file mode 100644
index 0000000000..316b774081
--- /dev/null
+++ b/content/ja/docs/reference/scheduling/_index.md
@@ -0,0 +1,5 @@
+---
+title: Scheduling
+weight: 70
+toc-hide: true
+---
From 46a13354a14701e3b78dda8d23b6699e42e40de3 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <196thinline@gmail.com>
Date: Sun, 6 Mar 2022 23:09:46 +0900
Subject: [PATCH 035/167] add:config.md
---
.../ja/docs/reference/scheduling/config.md | 417 ++++++++++++++++++
1 file changed, 417 insertions(+)
create mode 100644 content/ja/docs/reference/scheduling/config.md
diff --git a/content/ja/docs/reference/scheduling/config.md b/content/ja/docs/reference/scheduling/config.md
new file mode 100644
index 0000000000..9e2c0b4ce2
--- /dev/null
+++ b/content/ja/docs/reference/scheduling/config.md
@@ -0,0 +1,417 @@
+---
+title: スケジューラーの設定
+content_type: concept
+weight: 20
+---
+
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+設定ファイルを作成し、そのパスをコマンドライン引数として渡すことで`kube-scheduler`の振る舞いをカスタマイズすることができます。
+
+
+
+
+
+
+スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの
+異なるステージを設定することができます。
+各ステージは、拡張点に公開されています。プラグインをそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。
+
+KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
+か [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/)) 構造体を使用し、`kube-scheduler --config `を実行することで、スケジューリングプロファイルを指定することができます。
+
+最小限の設定は次の通りです。
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta2
+kind: KubeSchedulerConfiguration
+clientConnection:
+ kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
+```
+
+## プロファイル
+
+スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの
+異なるステージを設定することができます。
+各ステージは[拡張点](#extension-points)に公開されています。
+[プラグイン](#scheduling-plugins)をそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。
+
+単一の`kube-scheduler`インスタンスで[複数のプロファイル](#multiple-profiles)を実行するように設定することも可能です。
+
+### 拡張点 {#extension-points}
+
+スケジューリングは一連のステージで行われ、以下の拡張点に公開されています。
+
+1. `queueSort`: これらのプラグインは、スケジューリングキューにある`pending`状態のPodを
+ ソートするための順序付け関数を提供します。同時に有効化できるプラグインは1つだけです。
+1. `preFilter`: これらのプラグインは、フィルタリングをする前にPodやクラスターの情報のチェックや
+ 前処理のために使用されます。これらのプラグインは、設定された順序で呼び出されます。
+1. `filter`: これらのプラグインは、スケジューリングポリシーにおけるPredicatesに相当するもので、
+ Podを実行不可能なNodeをフィルターするために使用されます。
+ もし全てのNodeがフィルターされてしまった場合、Podはunschedulableとしてマークされます。
+1. `postFilter`:これらのプラグインは、Podの実行可能なNodeが見つからなかった場合、
+ 設定された順序で呼び出されます。もし`postFilter`プラグインのいずれかが、Podを __スケジュール可能__
+ とマークした場合、残りの`postFilter`プラグインは呼び出されません。
+1. `preScore`: これは、スコアリング前の作業を行う際に使用できる情報提供のための拡張点です。
+1. `score`: これらのプラグインはフィルタリングフェーズを通過してきたそれぞれのNodeに対して
+ スコア付けを行います。その後スケジューラーは、最も高い重み付きスコアの合計を持つノードを選択します。
+1. `reserve`: これは、指定されたPodのためにリソースが予約された際に、プラグインに通知する、
+ 情報提供のための拡張点です。また、プラグインは`Reserve`中に失敗した際、または`Reserve`の後に
+ 呼び出される`Unreserve`も実装しています。
+1. `permit`: これらのプラグインではPodのバインディングを拒む、または遅延させることができます。
+1. `preBind`: これらのプラグインは、Podがバインドされる前に必要な処理を実行できます。
+1. `bind`: これらのプラグインはPodをNodeにバインドします。`bind`プラグインは順番に呼び出され、
+ 1つのプラグインがバインドを完了すると、残りのプラグインはスキップされます。`bind`プラグインは
+ 少なくとも1つは必要です。
+1. `postBind`: これは、Podがバインドされた後に呼び出される情報提供のための拡張点です。
+1. `multiPoint`: このフィールドは設定のみ可能で、プラグインが適用されるすべての拡張点に対して
+ 同時に有効化または無効化することができます。
+
+次の例のように、それぞれの拡張点に対して、特定の[デフォルトプラグイン](#scheduling-plugins)を無効化、または自作のプラグイン有効化することができます。
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta2
+kind: KubeSchedulerConfiguration
+profiles:
+ - plugins:
+ score:
+ disabled:
+ - name: PodTopologySpread
+ enabled:
+ - name: MyCustomPluginA
+ weight: 2
+ - name: MyCustomPluginB
+ weight: 1
+```
+
+`disabled`配列の`name`として`*`を使用することで、その拡張点の全てのデフォルトプラグインを無効化できます。また、必要に応じてプラグインの順序を入れ替える場合にも使用されます。
+
+### Scheduling plugins {#scheduling-plugins}
+
+以下のプラグインはデフォルトで有効化されており、1つ以上の拡張点に実装されています。
+
+- `ImageLocality`:Podが実行するコンテナーイメージを既に持っているNodeを優先します。
+ 拡張点:`score`
+- `TaintToleration`:[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を実行します。
+ 実装する拡張点:`filter`、`preScore`、`score`
+- `NodeName`: PodのSpecのNode名が、現在のNodeと一致するかをチェックします。
+ 拡張点:`filter`
+- `NodePorts`:要求されたPodのポートに対して、Nodeが空きポートを持っているかチェックします。
+ 拡張点:`preFilter`、`filter`
+- `NodeAffinity`:[nodeselectors](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
+ と[Nodeアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)
+ を実行します。
+ 拡張点:`filter`、`score`
+- `PodTopologySpread`:[Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を実行します。
+ 拡張点:`preFilter`、`filter`、`preScore`、`score`
+- `NodeUnschedulable`:`.spec.unschedulable`がtrueに設定されているNodeをフィルタリングします。
+ 拡張点:`filter`.
+- `NodeResourcesFit`:Podが要求しているすべてのリソースがNodeにあるかをチェックします。
+ スコアは3つのストラテジのうちの1つを使用します:`LeastAllocated`(デフォルト)、`MostAllocated`、 と`RequestedToCapacityRatio`
+ 拡張点:`preFilter`、`filter`、`score`
+- `NodeResourcesBalancedAllocation`:Podがスケジュールされた場合に、よりバランスの取れた
+ リソース使用量となるNodeを優先します。
+ 拡張点:`score`
+- `VolumeBinding`:Nodeが、要求された{{< glossary_tooltip text="ボリューム" term_id="volume" >}}
+ を持っている、もしくはバインドしているかチェックします。
+ 拡張点:`preFilter`、`filter`、`reserve`、`preBind`、`score`
+ {{< note >}}
+ `score`拡張点は、`VolumeCapacityPriority`機能が有効になっている時に有効化されます。
+ 要求されたボリュームに適合する最小のPVを優先的に使用します。
+ {{< /note >}}
+- `VolumeRestrictions`:Nodeにマウントされたボリュームが、ボリュームプロバイダ固有の制限を満たしているかを確認します。
+ 拡張点:`filter`
+- `VolumeZone`:要求されたボリュームがゾーン要件を満たしているかどうかを確認します。
+ 拡張点:`filter`
+- `NodeVolumeLimits`:NodeのCSIボリューム制限を満たすかどうかをチェックします。
+ 拡張点:`filter`
+- `EBSLimits`:NodeのAWSのEBSボリューム制限を満たすかどうかをチェックします。
+ 拡張点:`filter`
+- `GCEPDLimits`:NodeのGCP-PDボリューム制限を満たすかどうかをチェックします。
+ 拡張点:`filter`
+- `AzureDiskLimits`:NodeのAzureディスクボリューム制限を満たすかどうかをチェックします。
+ 拡張点:`filter`
+- `InterPodAffinity`:[Pod間のaffinityとanti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
+ を実行します。
+ 拡張点:`preFilter`、`filter`、`preScore`、`score`
+- `PrioritySort`:デフォルトの優先順位に基づくソートを提供する。
+ 拡張点:`queueSort`.
+- `DefaultBinder`:デフォルトのバインディングメカニズムを提供する。
+ 拡張点:`bind`
+- `DefaultPreemption`:デフォルトのプリエンプションメカニズムを提供する。
+ 拡張点:`postFilter`
+
+また、コンポーネント設定のAPIにより、以下のプラグインを有効にすることができます。
+デフォルトでは有効になっていません。
+
+- `SelectorSpread`:{{< glossary_tooltip text="サービス" term_id="service" >}}と
+ {{< glossary_tooltip text="レプリカセット" term_id="replica-set" >}}、
+ {{< glossary_tooltip text="ステートフルセット" term_id="statefulset" >}}、
+ に属するPodのNode間の拡散を優先します。
+ 拡張点:`preScore`、`score`
+- `CinderLimits`:Nodeが[OpenStack Cinder](https://docs.openstack.org/cinder/)
+ ボリューム制限を満たせるかチェックします。
+ 拡張点:`filter`
+
+### 複数のプロファイル {#multiple-profiles}
+
+`kube-scheduler`は複数のプロファイルを実行するように設定することができます。
+各プラグインは関連するスケジューラー名を持ち、その[拡張点](#extension-points)に異なるプラグインを
+設定することが可能です。
+
+以下のサンプル設定では、スケジューラーは2つのプロファイルで実行されます。1つはデフォルトプラグインで、
+もう1つはすべてのスコアリングプラグインを無効にしたものです。
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta2
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: default-scheduler
+ - schedulerName: no-scoring-scheduler
+ plugins:
+ preScore:
+ disabled:
+ - name: '*'
+ score:
+ disabled:
+ - name: '*'
+```
+
+特定のプロファイルに従ってスケジュールさせたいPodは、その`.spec.schedulerName`に、対応するスケジューラ名を含めることができます。
+
+デフォルトでは、スケジューラー名`default-scheduler`としてプロファイルが生成されます。
+このプロファイルは、上記のデフォルトプラグインを含みます。複数のプロファイルを宣言する場合は、
+それぞれユニークなスケジューラ-名にする必要があります。
+
+もしPodがスケジューラー名を指定しない場合、kube-apiserverは`default-scheduler`を設定します。
+従って、これらのPodをスケジュールするために、このスケジューラー名を持つプロファイルが存在する必要があります。
+
+{{< note >}}
+Podのスケジューリングイベントには、ReportingControllerとして`.spec.schedulerName`が設定されています。
+リーダー選出のイベントには、リスト先頭のプロファイルのスケジューラ名が使用されます。
+{{< /note >}}
+
+{{< note >}}
+すべてのプロファイルは、`queueSort`拡張点で同じプラグインを使用し、同じ設定パラメーターを持つ必要があります (該当する場合)。これは、pending状態のPodキューがスケジューラーに1つしかないためです。
+{{< /note >}}
+
+### 複数の拡張点に適用されるプラグイン {#multipoint}
+
+`kubescheduler.config.k8s.io/v1beta3`からは、プロファイル設定に`multiPoint`というフィールドが追加され、複数の拡張ポイントでプラグインを簡単に有効・無効化できるようになりました。
+`multiPoint`設定の目的は、カスタムプロファイルを使用する際に、ユーザーや管理者が必要とする設定を簡素化することです。
+
+`MyPlugin`というプラグインがあり、`preScore`、`score`、`preFilter`、`filter`拡張点を実装しているとします。
+すべての利用可能な拡張点で`MyPlugin`を有効化するためには、プロファイル設定は次のようにします。
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: multipoint-scheduler
+ plugins:
+ multiPoint:
+ enabled:
+ - name: MyPlugin
+```
+
+これは以下のように、`MyPlugin`を手動ですべての拡張ポイントに対して有効にすることと同じです。
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: non-multipoint-scheduler
+ plugins:
+ preScore:
+ enabled:
+ - name: MyPlugin
+ score:
+ enabled:
+ - name: MyPlugin
+ preFilter:
+ enabled:
+ - name: MyPlugin
+ filter:
+ enabled:
+ - name: MyPlugin
+```
+
+`multiPoint`を使用する利点の一つは、将来的に`MyPlugin`が別の拡張点を実装した場合に、
+`multiPoint`設定が自動的に新しい拡張点に対しても有効化されることです。
+
+特定の拡張点は、その拡張点の`disabled`フィールドを使用して、`MultiPoint`の展開から除外することができます。
+これは、デフォルトのプラグインを無効にしたり、デフォルト以外のプラグインを無効にしたり、
+ワイルドカード(`'*'`)を使ってすべてのプラグインを無効にしたりする場合に有効です。
+この例として、`Score`と`PreScore`を無効にするためには、次のようにします。
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: non-multipoint-scheduler
+ plugins:
+ multiPoint:
+ enabled:
+ - name: 'MyPlugin'
+ preScore:
+ disabled:
+ - name: '*'
+ score:
+ disabled:
+ - name: '*'
+```
+
+`v1beta3`では、`MultiPoint`を通じて、内部的に全ての[デフォルトプラグイン](#scheduling-plugins)が有効化されています。
+しかしながら、デフォルト値(並び順やスコアの重みなど)を柔軟に設定し直せるように、個別の拡張点は用意されています。
+例えば、2つのスコアプラグイン`DefaultScore1`と`DefaultScore2`に、重み1が設定されているとします。
+その場合、次のようにに重さを変更し、並べ替えることができます
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: multipoint-scheduler
+ plugins:
+ score:
+ enabled:
+ - name: 'DefaultScore2'
+ weight: 5
+```
+
+この例では、`MultiPoint`はデフォルトプラグインであるため、明示的にプラグイン名を指定する必要はありません。
+そして、`Score`に指定されているプラグインは`DefaultScore2`のみです。
+これは、特定の拡張点を通じて設定されたプラグインは、常に`MultiPoint`プラグインよりも優先されるためです。つまり、この設定例では、結果的に2つのプラグインを両方指定することなく、並び替えが行えます。
+
+`MultiPoint`プラグインを設定する際の一般的な優先順位は、以下の通りです。
+1. 特定の拡張点が最初に実行され、その設定は他の場所で設定されたものよりも優先される
+2. `MultiPoint`を使用して、手動で設定したプラグインとその設定内容
+3. デフォルトプラグインとそのデフォルト設定
+
+上記の優先順位を示すために、次の例はこれらのプラグインをベースにします。
+|プラグイン|拡張点|
+|---|---|
+|`DefaultQueueSort`|`QueueSort`|
+|`CustomQueueSort`|`QueueSort`|
+|`DefaultPlugin1`|`Score`, `Filter`|
+|`DefaultPlugin2`|`Score`|
+|`CustomPlugin1`|`Score`, `Filter`|
+|`CustomPlugin2`|`Score`, `Filter`|
+
+これらのプラグインの有効な設定例は次の通りです。
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: multipoint-scheduler
+ plugins:
+ multiPoint:
+ enabled:
+ - name: 'CustomQueueSort'
+ - name: 'CustomPlugin1'
+ weight: 3
+ - name: 'CustomPlugin2'
+ disabled:
+ - name: 'DefaultQueueSort'
+ filter:
+ disabled:
+ - name: 'DefaultPlugin1'
+ score:
+ enabled:
+ - name: 'DefaultPlugin2'
+```
+
+なお、特定の拡張点に`MultiPoint`プラグインを再宣言しても、エラーにはなりません。
+特定の拡張点が優先されるため、再宣言は無視されます(ログは記録されます)。
+
+
+このサンプルは、ほとんどのコンフィグを一箇所にまとめるだけでなく、いくつかの工夫をしています。
+* カスタムの`queueSort`プラグインを有効にし、デフォルトのプラグインを無効にする。
+* `CustomPlugin1`と`CustomPlugin2`を有効にし、この拡張点のプラグイン内で、最初に実行されるようにする。
+* `filter`拡張点でのみ、`DefaultPlugin1`を無効にする。
+* `score`拡張点で`DefaultPlugin2`が最初に実行されるように並べ替える(カスタムプラグインより先に)
+
+`v1beta3`以前のバージョンで、`multiPoint`がない場合、上記の設定例は、次のものと同等になります。
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta2
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: multipoint-scheduler
+ plugins:
+
+ # デフォルトQueueSortプラグインを無効化
+ queueSort:
+ enabled:
+ - name: 'CustomQueueSort'
+ disabled:
+ - name: 'DefaultQueueSort'
+
+ # カスタムFilterプラグインを有効化
+ filter:
+ enabled:
+ - name: 'CustomPlugin1'
+ - name: 'CustomPlugin2'
+ - name: 'DefaultPlugin2'
+ disabled:
+ - name: 'DefaultPlugin1'
+
+ # カスタムScoreプラグインを有効化し、実行順を並べ替える
+ score:
+ enabled:
+ - name: 'DefaultPlugin2'
+ weight: 1
+ - name: 'DefaultPlugin1'
+ weight: 3
+```
+
+これは複雑な例ですが、`MultiPoint`設定の柔軟性と、拡張点を設定する既存の方法とのシームレスな統合を実証しています。
+
+## スケジューラー設定の移行
+
+{{< tabs name="tab_with_md" >}}
+{{% tab name="v1beta1 → v1beta2" %}}
+* v1beta2`のバージョン`の設定では、新しい`NodeResourcesFit`プラグインをスコア拡張点で使用できます。
+ この新しい拡張機能は、`NodeResourcesLeastAllocated`、`NodeResourcesMostAllocated`、 `RequestedToCapacityRatio`プラグインの機能を組み合わせたものです。
+ 例えば、以前は`NodeResourcesMostAllocated`プラグインを使っていたなら、代わりに`NodeResourcesFitプラグイン
+ を使用し(デフォルトで有効)、`pluginConfig`に次のような`scoreStrategy`を追加することになるでしょう。
+
+ ```yaml
+ apiVersion: kubescheduler.config.k8s.io/v1beta2
+ kind: KubeSchedulerConfiguration
+ profiles:
+ - pluginConfig:
+ - args:
+ scoringStrategy:
+ resources:
+ - name: cpu
+ weight: 1
+ type: MostAllocated
+ name: NodeResourcesFit
+ ```
+
+* スケジューラープラグインの`NodeLabel`は廃止されました。代わりに[`NodeAffinity`](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)プラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。
+
+* スケジューラープラグインの`ServiceAffinity`は廃止されました。代わりに[`InterPodAffinity`](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)プラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。
+
+* スケジューラープラグインの`NodePreferAvoidPods`は廃止されました。代わりに[Node taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を使用することで同様の振る舞いを実現できます。
+
+* v1beta2で有効化されたプラグインは、そのプラグインのデフォルトの設定より優先されます。
+
+* スケジューラーの、ヘルスとメトリクスのバインドアドレスに設定されている`host`や`port`が無効な場合、バリデーションに失敗します。
+{{% /tab %}}
+
+{{% tab name="v1beta2 → v1beta3" %}}
+* デフォルトで3つのプラグインの重みが増加しました。
+ * `InterPodAffinity`:1から2
+ * `NodeAffinity`:1から2
+ * `TaintToleration`:1から3
+{{% /tab %}}
+{{< /tabs >}}
+
+## {{% heading "whatsnext" %}}
+
+* [kube-schedulerリファレンス](/docs/reference/command-line-tools-reference/kube-scheduler/)を読む
+* [scheduling](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ
+* [kube-scheduler設定(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)のリファレンスを読む
+* [kube-scheduler設定(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)のリファレンスを読む
From 8981587a68393e3b2401f3ae668162f89c89d597 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <196thinline@gmail.com>
Date: Sun, 6 Mar 2022 23:09:58 +0900
Subject: [PATCH 036/167] add:replica-set.md
---
.../ja/docs/reference/glossary/replica-set.md | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 content/ja/docs/reference/glossary/replica-set.md
diff --git a/content/ja/docs/reference/glossary/replica-set.md b/content/ja/docs/reference/glossary/replica-set.md
new file mode 100644
index 0000000000..a3accce55a
--- /dev/null
+++ b/content/ja/docs/reference/glossary/replica-set.md
@@ -0,0 +1,20 @@
+---
+title: ReplicaSet
+id: replica-set
+date: 2018-04-12
+full_link: /ja/docs/concepts/workloads/controllers/replicaset/
+short_description: >
+ ReplicaSetは、指定された数のPodレプリカが一度に動作するように保証します。
+
+aka:
+tags:
+- fundamental
+- core-object
+- workload
+---
+ ReplicaSetは、任意の時点で動作しているレプリカPodの集合を保持します。(保持することを目指します。)
+
+
+{{< glossary_tooltip term_id="deployment" >}}などのワークロードオブジェクトは、ReplicaSetの仕様に基づいて、
+設定された数の{{< glossary_tooltip term_id="pod" text="Pods" >}がクラスタで稼働することを保証するために、
+ReplicaSetを使用します。
From 1a4044bf3048deb05670f9598c2d9c89b8e684ab Mon Sep 17 00:00:00 2001
From: 196Ikuchil <196thinline@gmail.com>
Date: Sun, 6 Mar 2022 23:48:53 +0900
Subject: [PATCH 037/167] add:policies.md
---
.../ja/docs/reference/scheduling/policies.md | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 content/ja/docs/reference/scheduling/policies.md
diff --git a/content/ja/docs/reference/scheduling/policies.md b/content/ja/docs/reference/scheduling/policies.md
new file mode 100644
index 0000000000..5bdcdcc353
--- /dev/null
+++ b/content/ja/docs/reference/scheduling/policies.md
@@ -0,0 +1,19 @@
+---
+title: スケジューリングポリシー
+content_type: concept
+sitemap:
+ priority: 0.2 # スケジューリングポリシーは廃止されました。
+---
+
+
+
+バージョンv1.2以前のKubernetesでは、スケジューリングポリシーを使用して、*predicates*と*priorities*の処理を指定することができました。例えば、`kube-scheduler --policy-config-file ` または `kube-scheduler --policy-configmap ` を実行すると、スケジューリングポリシーを設定することが可能です。
+
+このスケジューリングポリシーは、バージョンv1.23以降のKubernetesではサポートされていません。関連するフラグである、`policy-config-file`,`policy-configmap`、`policy-configmap-namespace`、`use-legacy-policy-config`も同様にサポートされていません。
+代わりに、[スケジューラー設定](/ja/docs/reference/scheduling/config/)を使用してください。
+
+## {{% heading "whatsnext" %}}
+
+* [スケジューリング](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ
+* [kube-scheduler設定](/ja/docs/reference/scheduling/config/)
+* [kube-scheduler設定リファレンス(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)について読む
From d1c505e171e57a7356a0d0d74ae893ef8657e674 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <196thinline@gmail.com>
Date: Mon, 7 Mar 2022 00:06:44 +0900
Subject: [PATCH 038/167] fix:test errors
---
content/ja/docs/reference/glossary/replica-set.md | 2 +-
content/ja/docs/reference/scheduling/config.md | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/content/ja/docs/reference/glossary/replica-set.md b/content/ja/docs/reference/glossary/replica-set.md
index a3accce55a..a198b71d46 100644
--- a/content/ja/docs/reference/glossary/replica-set.md
+++ b/content/ja/docs/reference/glossary/replica-set.md
@@ -16,5 +16,5 @@ tags:
{{< glossary_tooltip term_id="deployment" >}}などのワークロードオブジェクトは、ReplicaSetの仕様に基づいて、
-設定された数の{{< glossary_tooltip term_id="pod" text="Pods" >}がクラスタで稼働することを保証するために、
+設定された数の{{< glossary_tooltip term_id="pod" text="Pods" >}}がクラスタで稼働することを保証するために、
ReplicaSetを使用します。
diff --git a/content/ja/docs/reference/scheduling/config.md b/content/ja/docs/reference/scheduling/config.md
index 9e2c0b4ce2..3eb8a8f53c 100644
--- a/content/ja/docs/reference/scheduling/config.md
+++ b/content/ja/docs/reference/scheduling/config.md
@@ -17,8 +17,8 @@ weight: 20
異なるステージを設定することができます。
各ステージは、拡張点に公開されています。プラグインをそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。
-KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
-か [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/)) 構造体を使用し、`kube-scheduler --config `を実行することで、スケジューリングプロファイルを指定することができます。
+KubeSchedulerConfiguration([`v1beta2`](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
+か[`v1beta3`](/docs/reference/config-api/kube-scheduler-config.v1beta3/))構造体を使用して、`kube-scheduler --config `を実行することで、スケジューリングプロファイルを指定することができます。
最小限の設定は次の通りです。
From 2a638d61c208c620eea94522350db8e73a68db20 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Wed, 16 Mar 2022 23:21:01 +0900
Subject: [PATCH 039/167] Update replica-set.md
---
content/ja/docs/reference/glossary/replica-set.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/reference/glossary/replica-set.md b/content/ja/docs/reference/glossary/replica-set.md
index a198b71d46..97134927b9 100644
--- a/content/ja/docs/reference/glossary/replica-set.md
+++ b/content/ja/docs/reference/glossary/replica-set.md
@@ -16,5 +16,5 @@ tags:
{{< glossary_tooltip term_id="deployment" >}}などのワークロードオブジェクトは、ReplicaSetの仕様に基づいて、
-設定された数の{{< glossary_tooltip term_id="pod" text="Pods" >}}がクラスタで稼働することを保証するために、
+設定された数の{{< glossary_tooltip term_id="pod" text="Pods" >}}がクラスターで稼働することを保証するために、
ReplicaSetを使用します。
From 5f47ac7965f14a1fca384e4464737880890b655d Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Wed, 16 Mar 2022 23:32:27 +0900
Subject: [PATCH 040/167] Update config.md
---
.../ja/docs/reference/scheduling/config.md | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/content/ja/docs/reference/scheduling/config.md b/content/ja/docs/reference/scheduling/config.md
index 3eb8a8f53c..1b2d242e5d 100644
--- a/content/ja/docs/reference/scheduling/config.md
+++ b/content/ja/docs/reference/scheduling/config.md
@@ -47,7 +47,7 @@ clientConnection:
1. `preFilter`: これらのプラグインは、フィルタリングをする前にPodやクラスターの情報のチェックや
前処理のために使用されます。これらのプラグインは、設定された順序で呼び出されます。
1. `filter`: これらのプラグインは、スケジューリングポリシーにおけるPredicatesに相当するもので、
- Podを実行不可能なNodeをフィルターするために使用されます。
+ Podの実行不可能なNodeをフィルターするために使用されます。
もし全てのNodeがフィルターされてしまった場合、Podはunschedulableとしてマークされます。
1. `postFilter`:これらのプラグインは、Podの実行可能なNodeが見つからなかった場合、
設定された順序で呼び出されます。もし`postFilter`プラグインのいずれかが、Podを __スケジュール可能__
@@ -84,13 +84,13 @@ profiles:
weight: 1
```
-`disabled`配列の`name`として`*`を使用することで、その拡張点の全てのデフォルトプラグインを無効化できます。また、必要に応じてプラグインの順序を入れ替える場合にも使用されます。
+`disabled`配列の`name`フィールドに`*`を使用することで、その拡張点の全てのデフォルトプラグインを無効化できます。また、必要に応じてプラグインの順序を入れ替える場合にも使用されます。
### Scheduling plugins {#scheduling-plugins}
以下のプラグインはデフォルトで有効化されており、1つ以上の拡張点に実装されています。
-- `ImageLocality`:Podが実行するコンテナーイメージを既に持っているNodeを優先します。
+- `ImageLocality`:Podが実行するコンテナイメージを既に持っているNodeを優先します。
拡張点:`score`
- `TaintToleration`:[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を実行します。
実装する拡張点:`filter`、`preScore`、`score`
@@ -134,11 +134,11 @@ profiles:
- `InterPodAffinity`:[Pod間のaffinityとanti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
を実行します。
拡張点:`preFilter`、`filter`、`preScore`、`score`
-- `PrioritySort`:デフォルトの優先順位に基づくソートを提供する。
+- `PrioritySort`:デフォルトの優先順位に基づくソートを提供します。
拡張点:`queueSort`.
-- `DefaultBinder`:デフォルトのバインディングメカニズムを提供する。
+- `DefaultBinder`:デフォルトのバインディングメカニズムを提供します。
拡張点:`bind`
-- `DefaultPreemption`:デフォルトのプリエンプションメカニズムを提供する。
+- `DefaultPreemption`:デフォルトのプリエンプションメカニズムを提供します。
拡張点:`postFilter`
また、コンポーネント設定のAPIにより、以下のプラグインを有効にすることができます。
@@ -149,14 +149,14 @@ profiles:
{{< glossary_tooltip text="ステートフルセット" term_id="statefulset" >}}、
に属するPodのNode間の拡散を優先します。
拡張点:`preScore`、`score`
-- `CinderLimits`:Nodeが[OpenStack Cinder](https://docs.openstack.org/cinder/)
+- `CinderLimits`:Nodeが[`OpenStack Cinder`](https://docs.openstack.org/cinder/)
ボリューム制限を満たせるかチェックします。
拡張点:`filter`
### 複数のプロファイル {#multiple-profiles}
`kube-scheduler`は複数のプロファイルを実行するように設定することができます。
-各プラグインは関連するスケジューラー名を持ち、その[拡張点](#extension-points)に異なるプラグインを
+各プラグインは関連するー名を持ち、その[拡張点](#extension-points)に異なるプラグインを
設定することが可能です。
以下のサンプル設定では、スケジューラーは2つのプロファイルで実行されます。1つはデフォルトプラグインで、
@@ -177,18 +177,18 @@ profiles:
- name: '*'
```
-特定のプロファイルに従ってスケジュールさせたいPodは、その`.spec.schedulerName`に、対応するスケジューラ名を含めることができます。
+特定のプロファイルに従ってスケジュールさせたいPodは、その`.spec.schedulerName`に、対応するスケジューラー名を含めることができます。
デフォルトでは、スケジューラー名`default-scheduler`としてプロファイルが生成されます。
このプロファイルは、上記のデフォルトプラグインを含みます。複数のプロファイルを宣言する場合は、
-それぞれユニークなスケジューラ-名にする必要があります。
+それぞれユニークなスケジューラー名にする必要があります。
もしPodがスケジューラー名を指定しない場合、kube-apiserverは`default-scheduler`を設定します。
従って、これらのPodをスケジュールするために、このスケジューラー名を持つプロファイルが存在する必要があります。
{{< note >}}
Podのスケジューリングイベントには、ReportingControllerとして`.spec.schedulerName`が設定されています。
-リーダー選出のイベントには、リスト先頭のプロファイルのスケジューラ名が使用されます。
+リーダー選出のイベントには、リスト先頭のプロファイルのスケジューラー名が使用されます。
{{< /note >}}
{{< note >}}
@@ -197,7 +197,7 @@ Podのスケジューリングイベントには、ReportingControllerとして`
### 複数の拡張点に適用されるプラグイン {#multipoint}
-`kubescheduler.config.k8s.io/v1beta3`からは、プロファイル設定に`multiPoint`というフィールドが追加され、複数の拡張ポイントでプラグインを簡単に有効・無効化できるようになりました。
+`kubescheduler.config.k8s.io/v1beta3`からは、プロファイル設定に`multiPoint`というフィールドが追加され、複数の拡張点でプラグインを簡単に有効・無効化できるようになりました。
`multiPoint`設定の目的は、カスタムプロファイルを使用する際に、ユーザーや管理者が必要とする設定を簡素化することです。
`MyPlugin`というプラグインがあり、`preScore`、`score`、`preFilter`、`filter`拡張点を実装しているとします。
@@ -398,7 +398,7 @@ profiles:
* v1beta2で有効化されたプラグインは、そのプラグインのデフォルトの設定より優先されます。
-* スケジューラーの、ヘルスとメトリクスのバインドアドレスに設定されている`host`や`port`が無効な場合、バリデーションに失敗します。
+* スケジューラーのヘルスとメトリクスのバインドアドレスに設定されている`host`や`port`が無効な場合、バリデーションに失敗します。
{{% /tab %}}
{{% tab name="v1beta2 → v1beta3" %}}
From a3808431433665d0eb9202dbdab4dab594daa74b Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Tue, 22 Mar 2022 19:58:33 +0900
Subject: [PATCH 041/167] Update
content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
Co-authored-by: nasa9084
---
.../docs/concepts/scheduling-eviction/resource-bin-packing.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
index cd976fff1d..fccccb17de 100644
--- a/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
+++ b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -38,7 +38,7 @@ profiles:
- name: intel.com/bar
weight: 5
```
-スケジューラには、kube-schedulerフラグ`--config=/path/to/config/file`を使用して`KubeSchedulerConfiguration`のファイルを指定することで渡すことができます。
+スケジューラーには、kube-schedulerフラグ`--config=/path/to/config/file`を使用して`KubeSchedulerConfiguration`のファイルを指定することで渡すことができます。
**この機能はデフォルトで無効化されています**
From f99e18c7811c79916ffee3357a956fe63938220c Mon Sep 17 00:00:00 2001
From: 196Ikuchil <196thinline@gmail.com>
Date: Tue, 22 Mar 2022 20:05:52 +0900
Subject: [PATCH 042/167] fix:utilization and score
---
.../docs/concepts/scheduling-eviction/resource-bin-packing.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
index fccccb17de..d394bdbd7f 100644
--- a/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
+++ b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -15,7 +15,7 @@ kube-schedulerでは、優先度関数`RequestedToCapacityRatioResourceAllocatio
## `RequestedToCapacityRatioResourceAllocation`を使用したビンパッキングの有効化
-Kubernetesでは、キャパシティー比率への要求に基づいたNodeのスコアリングをするために、各リソースの重みと共にリソースを指定することができます。これにより、ユーザーは適切なパラメーターを使用することで拡張リソースをビンパックすることができ、大規模クラスターにおける希少なリソースを有効活用できるようになります。優先度関数`RequestedToCapacityRatioResourceAllocation`の動作は`RequestedToCapacityRatioArgs`と呼ばれる設定オプションによって変わります。この引数は`shape`と`resources`パラメーターによって構成されます。`shape`パラメーターは`利用率`と`スコア`の値に基づいて、最も要求が多い場合と最も要求が少ない場合の関数をチューニングできます。`resources`パラメーターは、スコアリングの際に考慮されるリソース名の`name`と、各リソースの重みを指定する`weight`で構成されます。
+Kubernetesでは、キャパシティー比率への要求に基づいたNodeのスコアリングをするために、各リソースの重みと共にリソースを指定することができます。これにより、ユーザーは適切なパラメーターを使用することで拡張リソースをビンパックすることができ、大規模クラスターにおける希少なリソースを有効活用できるようになります。優先度関数`RequestedToCapacityRatioResourceAllocation`の動作は`RequestedToCapacityRatioArgs`と呼ばれる設定オプションによって変わります。この引数は`shape`と`resources`パラメーターによって構成されます。`shape`パラメーターは`utilization`と`score`の値に基づいて、最も要求が多い場合と最も要求が少ない場合の関数をチューニングできます。`resources`パラメーターは、スコアリングの際に考慮されるリソース名の`name`と、各リソースの重みを指定する`weight`で構成されます。
以下は、拡張リソース`intel.com/foo`と`intel.com/bar`のビンパッキングに`requestedToCapacityRatioArguments`を設定する例になります。
From e9f7ba6b93fb1fca2d64d8c5ae86c7ace5dd456a Mon Sep 17 00:00:00 2001
From: 196Ikuchil <196thinline@gmail.com>
Date: Tue, 22 Mar 2022 20:07:56 +0900
Subject: [PATCH 043/167] =?UTF-8?q?fix:=E6=9C=80=E3=82=82=E8=A6=81?=
=?UTF-8?q?=E6=B1=82=E3=81=8C=E5=A4=9A=E3=81=84=E5=A0=B4=E5=90=88=E3=81=8B?=
=?UTF-8?q?=E6=9C=80=E3=82=82=E8=A6=81=E6=B1=82=E3=81=8C=E5=B0=91=E3=81=AA?=
=?UTF-8?q?=E3=81=84?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
.../docs/concepts/scheduling-eviction/resource-bin-packing.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
index d394bdbd7f..6b30fb61a0 100644
--- a/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
+++ b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -15,7 +15,7 @@ kube-schedulerでは、優先度関数`RequestedToCapacityRatioResourceAllocatio
## `RequestedToCapacityRatioResourceAllocation`を使用したビンパッキングの有効化
-Kubernetesでは、キャパシティー比率への要求に基づいたNodeのスコアリングをするために、各リソースの重みと共にリソースを指定することができます。これにより、ユーザーは適切なパラメーターを使用することで拡張リソースをビンパックすることができ、大規模クラスターにおける希少なリソースを有効活用できるようになります。優先度関数`RequestedToCapacityRatioResourceAllocation`の動作は`RequestedToCapacityRatioArgs`と呼ばれる設定オプションによって変わります。この引数は`shape`と`resources`パラメーターによって構成されます。`shape`パラメーターは`utilization`と`score`の値に基づいて、最も要求が多い場合と最も要求が少ない場合の関数をチューニングできます。`resources`パラメーターは、スコアリングの際に考慮されるリソース名の`name`と、各リソースの重みを指定する`weight`で構成されます。
+Kubernetesでは、キャパシティー比率への要求に基づいたNodeのスコアリングをするために、各リソースの重みと共にリソースを指定することができます。これにより、ユーザーは適切なパラメーターを使用することで拡張リソースをビンパックすることができ、大規模クラスターにおける希少なリソースを有効活用できるようになります。優先度関数`RequestedToCapacityRatioResourceAllocation`の動作は`RequestedToCapacityRatioArgs`と呼ばれる設定オプションによって変わります。この引数は`shape`と`resources`パラメーターによって構成されます。`shape`パラメーターは`utilization`と`score`の値に基づいて、最も要求が多い場合か最も要求が少ない場合の関数をチューニングできます。`resources`パラメーターは、スコアリングの際に考慮されるリソース名の`name`と、各リソースの重みを指定する`weight`で構成されます。
以下は、拡張リソース`intel.com/foo`と`intel.com/bar`のビンパッキングに`requestedToCapacityRatioArguments`を設定する例になります。
From c7b87d9143889696193486b5a6b112f40f3ea185 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Tue, 22 Mar 2022 20:08:51 +0900
Subject: [PATCH 044/167] Update
content/ja/docs/reference/scheduling/policies.md
Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
content/ja/docs/reference/scheduling/policies.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/reference/scheduling/policies.md b/content/ja/docs/reference/scheduling/policies.md
index 5bdcdcc353..64bdf4f9eb 100644
--- a/content/ja/docs/reference/scheduling/policies.md
+++ b/content/ja/docs/reference/scheduling/policies.md
@@ -7,7 +7,7 @@ sitemap:
-バージョンv1.2以前のKubernetesでは、スケジューリングポリシーを使用して、*predicates*と*priorities*の処理を指定することができました。例えば、`kube-scheduler --policy-config-file ` または `kube-scheduler --policy-configmap ` を実行すると、スケジューリングポリシーを設定することが可能です。
+バージョンv1.23より前のKubernetesでは、スケジューリングポリシーを使用して、*predicates*と*priorities*の処理を指定することができました。例えば、`kube-scheduler --policy-config-file ` または `kube-scheduler --policy-configmap ` を実行すると、スケジューリングポリシーを設定することが可能です。
このスケジューリングポリシーは、バージョンv1.23以降のKubernetesではサポートされていません。関連するフラグである、`policy-config-file`,`policy-configmap`、`policy-configmap-namespace`、`use-legacy-policy-config`も同様にサポートされていません。
代わりに、[スケジューラー設定](/ja/docs/reference/scheduling/config/)を使用してください。
From e853954a19d315bb4347722aec43c5b651bfdc7d Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Tue, 22 Mar 2022 20:10:35 +0900
Subject: [PATCH 045/167] Update content/ja/docs/reference/scheduling/config.md
Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
content/ja/docs/reference/scheduling/config.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/reference/scheduling/config.md b/content/ja/docs/reference/scheduling/config.md
index 1b2d242e5d..5b4cccf3f5 100644
--- a/content/ja/docs/reference/scheduling/config.md
+++ b/content/ja/docs/reference/scheduling/config.md
@@ -67,7 +67,7 @@ clientConnection:
1. `multiPoint`: このフィールドは設定のみ可能で、プラグインが適用されるすべての拡張点に対して
同時に有効化または無効化することができます。
-次の例のように、それぞれの拡張点に対して、特定の[デフォルトプラグイン](#scheduling-plugins)を無効化、または自作のプラグイン有効化することができます。
+次の例のように、それぞれの拡張点に対して、特定の[デフォルトプラグイン](#scheduling-plugins)を無効化、または自作のプラグインを有効化することができます。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta2
From d8e4686ab7a70b653a9de0931c106983b3b23033 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Tue, 22 Mar 2022 20:11:06 +0900
Subject: [PATCH 046/167] Update content/ja/docs/reference/scheduling/config.md
Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
content/ja/docs/reference/scheduling/config.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/reference/scheduling/config.md b/content/ja/docs/reference/scheduling/config.md
index 5b4cccf3f5..86ed0d2661 100644
--- a/content/ja/docs/reference/scheduling/config.md
+++ b/content/ja/docs/reference/scheduling/config.md
@@ -156,7 +156,7 @@ profiles:
### 複数のプロファイル {#multiple-profiles}
`kube-scheduler`は複数のプロファイルを実行するように設定することができます。
-各プラグインは関連するー名を持ち、その[拡張点](#extension-points)に異なるプラグインを
+各プロファイルは関連するスケジューラー名を持ち、その[拡張点](#extension-points)に異なるプラグインを
設定することが可能です。
以下のサンプル設定では、スケジューラーは2つのプロファイルで実行されます。1つはデフォルトプラグインで、
From 87733b3a57c2ca4e7e30515f63cda693140bbb00 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Tue, 22 Mar 2022 20:11:17 +0900
Subject: [PATCH 047/167] Update content/ja/docs/reference/scheduling/config.md
Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
content/ja/docs/reference/scheduling/config.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/reference/scheduling/config.md b/content/ja/docs/reference/scheduling/config.md
index 86ed0d2661..86c86dd07f 100644
--- a/content/ja/docs/reference/scheduling/config.md
+++ b/content/ja/docs/reference/scheduling/config.md
@@ -264,7 +264,7 @@ profiles:
`v1beta3`では、`MultiPoint`を通じて、内部的に全ての[デフォルトプラグイン](#scheduling-plugins)が有効化されています。
しかしながら、デフォルト値(並び順やスコアの重みなど)を柔軟に設定し直せるように、個別の拡張点は用意されています。
例えば、2つのスコアプラグイン`DefaultScore1`と`DefaultScore2`に、重み1が設定されているとします。
-その場合、次のようにに重さを変更し、並べ替えることができます
+その場合、次のように重さを変更し、並べ替えることができます
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
From 32852dca8b8f20e01e3e1e7fe25b54ea07bcbfc6 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Tue, 22 Mar 2022 20:12:02 +0900
Subject: [PATCH 048/167] Update content/ja/docs/reference/scheduling/config.md
Co-authored-by: nasa9084
---
content/ja/docs/reference/scheduling/config.md | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/content/ja/docs/reference/scheduling/config.md b/content/ja/docs/reference/scheduling/config.md
index 86c86dd07f..071042752c 100644
--- a/content/ja/docs/reference/scheduling/config.md
+++ b/content/ja/docs/reference/scheduling/config.md
@@ -17,8 +17,7 @@ weight: 20
異なるステージを設定することができます。
各ステージは、拡張点に公開されています。プラグインをそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。
-KubeSchedulerConfiguration([`v1beta2`](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
-か[`v1beta3`](/docs/reference/config-api/kube-scheduler-config.v1beta3/))構造体を使用して、`kube-scheduler --config `を実行することで、スケジューリングプロファイルを指定することができます。
+KubeSchedulerConfiguration([`v1beta2`](/docs/reference/config-api/kube-scheduler-config.v1beta2/)か[`v1beta3`](/docs/reference/config-api/kube-scheduler-config.v1beta3/))構造体を使用して、`kube-scheduler --config `を実行することで、スケジューリングプロファイルを指定することができます。
最小限の設定は次の通りです。
From 3ab3a17d4852443b7d064b08b3b171fbffc8717a Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Tue, 22 Mar 2022 20:12:13 +0900
Subject: [PATCH 049/167] Update content/ja/docs/reference/scheduling/config.md
Co-authored-by: nasa9084
---
content/ja/docs/reference/scheduling/config.md | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/content/ja/docs/reference/scheduling/config.md b/content/ja/docs/reference/scheduling/config.md
index 071042752c..29b9fa70ca 100644
--- a/content/ja/docs/reference/scheduling/config.md
+++ b/content/ja/docs/reference/scheduling/config.md
@@ -30,8 +30,7 @@ clientConnection:
## プロファイル
-スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの
-異なるステージを設定することができます。
+スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの異なるステージを設定することができます。
各ステージは[拡張点](#extension-points)に公開されています。
[プラグイン](#scheduling-plugins)をそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。
From 2f438dd5103d1eda78bb6cceb3f13c52dc2cc6cf Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Tue, 22 Mar 2022 20:12:21 +0900
Subject: [PATCH 050/167] Update content/ja/docs/reference/scheduling/config.md
Co-authored-by: nasa9084
---
content/ja/docs/reference/scheduling/config.md | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/content/ja/docs/reference/scheduling/config.md b/content/ja/docs/reference/scheduling/config.md
index 29b9fa70ca..62269e9b16 100644
--- a/content/ja/docs/reference/scheduling/config.md
+++ b/content/ja/docs/reference/scheduling/config.md
@@ -40,8 +40,7 @@ clientConnection:
スケジューリングは一連のステージで行われ、以下の拡張点に公開されています。
-1. `queueSort`: これらのプラグインは、スケジューリングキューにある`pending`状態のPodを
- ソートするための順序付け関数を提供します。同時に有効化できるプラグインは1つだけです。
+1. `queueSort`: これらのプラグインは、スケジューリングキューにある`pending`状態のPodをソートするための順序付け関数を提供します。同時に有効化できるプラグインは1つだけです。
1. `preFilter`: これらのプラグインは、フィルタリングをする前にPodやクラスターの情報のチェックや
前処理のために使用されます。これらのプラグインは、設定された順序で呼び出されます。
1. `filter`: これらのプラグインは、スケジューリングポリシーにおけるPredicatesに相当するもので、
From 019bc6195126540740d37f77e4b402870bf712bd Mon Sep 17 00:00:00 2001
From: 196Ikuchil <196thinline@gmail.com>
Date: Tue, 22 Mar 2022 20:27:30 +0900
Subject: [PATCH 051/167] fix:remove line feeds in text
---
.../ja/docs/reference/scheduling/config.md | 77 ++++++-------------
1 file changed, 25 insertions(+), 52 deletions(-)
diff --git a/content/ja/docs/reference/scheduling/config.md b/content/ja/docs/reference/scheduling/config.md
index 62269e9b16..8bf593ff4c 100644
--- a/content/ja/docs/reference/scheduling/config.md
+++ b/content/ja/docs/reference/scheduling/config.md
@@ -13,8 +13,7 @@ weight: 20
-スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの
-異なるステージを設定することができます。
+スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの異なるステージを設定することができます。
各ステージは、拡張点に公開されています。プラグインをそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。
KubeSchedulerConfiguration([`v1beta2`](/docs/reference/config-api/kube-scheduler-config.v1beta2/)か[`v1beta3`](/docs/reference/config-api/kube-scheduler-config.v1beta3/))構造体を使用して、`kube-scheduler --config `を実行することで、スケジューリングプロファイルを指定することができます。
@@ -41,28 +40,17 @@ clientConnection:
スケジューリングは一連のステージで行われ、以下の拡張点に公開されています。
1. `queueSort`: これらのプラグインは、スケジューリングキューにある`pending`状態のPodをソートするための順序付け関数を提供します。同時に有効化できるプラグインは1つだけです。
-1. `preFilter`: これらのプラグインは、フィルタリングをする前にPodやクラスターの情報のチェックや
- 前処理のために使用されます。これらのプラグインは、設定された順序で呼び出されます。
-1. `filter`: これらのプラグインは、スケジューリングポリシーにおけるPredicatesに相当するもので、
- Podの実行不可能なNodeをフィルターするために使用されます。
- もし全てのNodeがフィルターされてしまった場合、Podはunschedulableとしてマークされます。
-1. `postFilter`:これらのプラグインは、Podの実行可能なNodeが見つからなかった場合、
- 設定された順序で呼び出されます。もし`postFilter`プラグインのいずれかが、Podを __スケジュール可能__
- とマークした場合、残りの`postFilter`プラグインは呼び出されません。
+1. `preFilter`: これらのプラグインは、フィルタリングをする前にPodやクラスターの情報のチェックや前処理のために使用されます。これらのプラグインは、設定された順序で呼び出されます。
+1. `filter`: これらのプラグインは、スケジューリングポリシーにおけるPredicatesに相当するもので、Podの実行不可能なNodeをフィルターするために使用されます。もし全てのNodeがフィルターされてしまった場合、Podはunschedulableとしてマークされます。
+1. `postFilter`:これらのプラグインは、Podの実行可能なNodeが見つからなかった場合、設定された順序で呼び出されます。もし`postFilter`プラグインのいずれかが、Podを __スケジュール可能__ とマークした場合、残りの`postFilter`プラグインは呼び出されません。
1. `preScore`: これは、スコアリング前の作業を行う際に使用できる情報提供のための拡張点です。
-1. `score`: これらのプラグインはフィルタリングフェーズを通過してきたそれぞれのNodeに対して
- スコア付けを行います。その後スケジューラーは、最も高い重み付きスコアの合計を持つノードを選択します。
-1. `reserve`: これは、指定されたPodのためにリソースが予約された際に、プラグインに通知する、
- 情報提供のための拡張点です。また、プラグインは`Reserve`中に失敗した際、または`Reserve`の後に
- 呼び出される`Unreserve`も実装しています。
+1. `score`: これらのプラグインはフィルタリングフェーズを通過してきたそれぞれのNodeに対してスコア付けを行います。その後スケジューラーは、最も高い重み付きスコアの合計を持つノードを選択します。
+1. `reserve`: これは、指定されたPodのためにリソースが予約された際に、プラグインに通知する、情報提供のための拡張点です。また、プラグインは`Reserve`中に失敗した際、または`Reserve`の後に呼び出される`Unreserve`も実装しています。
1. `permit`: これらのプラグインではPodのバインディングを拒む、または遅延させることができます。
1. `preBind`: これらのプラグインは、Podがバインドされる前に必要な処理を実行できます。
-1. `bind`: これらのプラグインはPodをNodeにバインドします。`bind`プラグインは順番に呼び出され、
- 1つのプラグインがバインドを完了すると、残りのプラグインはスキップされます。`bind`プラグインは
- 少なくとも1つは必要です。
+1. `bind`: これらのプラグインはPodをNodeにバインドします。`bind`プラグインは順番に呼び出され、1つのプラグインがバインドを完了すると、残りのプラグインはスキップされます。`bind`プラグインは少なくとも1つは必要です。
1. `postBind`: これは、Podがバインドされた後に呼び出される情報提供のための拡張点です。
-1. `multiPoint`: このフィールドは設定のみ可能で、プラグインが適用されるすべての拡張点に対して
- 同時に有効化または無効化することができます。
+1. `multiPoint`: このフィールドは設定のみ可能で、プラグインが適用されるすべての拡張点に対して同時に有効化または無効化することができます。
次の例のように、それぞれの拡張点に対して、特定の[デフォルトプラグイン](#scheduling-plugins)を無効化、または自作のプラグインを有効化することができます。
@@ -95,22 +83,17 @@ profiles:
拡張点:`filter`
- `NodePorts`:要求されたPodのポートに対して、Nodeが空きポートを持っているかチェックします。
拡張点:`preFilter`、`filter`
-- `NodeAffinity`:[nodeselectors](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
- と[Nodeアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)
- を実行します。
+- `NodeAffinity`:[nodeselectors](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)と[Nodeアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)を実行します。
拡張点:`filter`、`score`
- `PodTopologySpread`:[Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を実行します。
拡張点:`preFilter`、`filter`、`preScore`、`score`
- `NodeUnschedulable`:`.spec.unschedulable`がtrueに設定されているNodeをフィルタリングします。
拡張点:`filter`.
-- `NodeResourcesFit`:Podが要求しているすべてのリソースがNodeにあるかをチェックします。
- スコアは3つのストラテジのうちの1つを使用します:`LeastAllocated`(デフォルト)、`MostAllocated`、 と`RequestedToCapacityRatio`
+- `NodeResourcesFit`:Podが要求しているすべてのリソースがNodeにあるかをチェックします。スコアは3つのストラテジのうちの1つを使用します:`LeastAllocated`(デフォルト)、`MostAllocated`、 と`RequestedToCapacityRatio`
拡張点:`preFilter`、`filter`、`score`
-- `NodeResourcesBalancedAllocation`:Podがスケジュールされた場合に、よりバランスの取れた
- リソース使用量となるNodeを優先します。
+- `NodeResourcesBalancedAllocation`:Podがスケジュールされた場合に、よりバランスの取れたリソース使用量となるNodeを優先します。
拡張点:`score`
-- `VolumeBinding`:Nodeが、要求された{{< glossary_tooltip text="ボリューム" term_id="volume" >}}
- を持っている、もしくはバインドしているかチェックします。
+- `VolumeBinding`:Nodeが、要求された{{< glossary_tooltip text="ボリューム" term_id="volume" >}}を持っている、もしくはバインドしているかチェックします。
拡張点:`preFilter`、`filter`、`reserve`、`preBind`、`score`
{{< note >}}
`score`拡張点は、`VolumeCapacityPriority`機能が有効になっている時に有効化されます。
@@ -128,8 +111,7 @@ profiles:
拡張点:`filter`
- `AzureDiskLimits`:NodeのAzureディスクボリューム制限を満たすかどうかをチェックします。
拡張点:`filter`
-- `InterPodAffinity`:[Pod間のaffinityとanti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
- を実行します。
+- `InterPodAffinity`:[Pod間のaffinityとanti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)を実行します。
拡張点:`preFilter`、`filter`、`preScore`、`score`
- `PrioritySort`:デフォルトの優先順位に基づくソートを提供します。
拡張点:`queueSort`.
@@ -141,23 +123,17 @@ profiles:
また、コンポーネント設定のAPIにより、以下のプラグインを有効にすることができます。
デフォルトでは有効になっていません。
-- `SelectorSpread`:{{< glossary_tooltip text="サービス" term_id="service" >}}と
- {{< glossary_tooltip text="レプリカセット" term_id="replica-set" >}}、
- {{< glossary_tooltip text="ステートフルセット" term_id="statefulset" >}}、
- に属するPodのNode間の拡散を優先します。
+- `SelectorSpread`:{{< glossary_tooltip text="サービス" term_id="service" >}}と{{< glossary_tooltip text="レプリカセット" term_id="replica-set" >}}、{{< glossary_tooltip text="ステートフルセット" term_id="statefulset" >}}、に属するPodのNode間の拡散を優先します。
拡張点:`preScore`、`score`
-- `CinderLimits`:Nodeが[`OpenStack Cinder`](https://docs.openstack.org/cinder/)
- ボリューム制限を満たせるかチェックします。
+- `CinderLimits`:Nodeが[`OpenStack Cinder`](https://docs.openstack.org/cinder/)ボリューム制限を満たせるかチェックします。
拡張点:`filter`
### 複数のプロファイル {#multiple-profiles}
`kube-scheduler`は複数のプロファイルを実行するように設定することができます。
-各プロファイルは関連するスケジューラー名を持ち、その[拡張点](#extension-points)に異なるプラグインを
-設定することが可能です。
+各プロファイルは関連するスケジューラー名を持ち、その[拡張点](#extension-points)に異なるプラグインを設定することが可能です。
-以下のサンプル設定では、スケジューラーは2つのプロファイルで実行されます。1つはデフォルトプラグインで、
-もう1つはすべてのスコアリングプラグインを無効にしたものです。
+以下のサンプル設定では、スケジューラーは2つのプロファイルで実行されます。1つはデフォルトプラグインで、もう1つはすべてのスコアリングプラグインを無効にしたものです。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta2
@@ -177,8 +153,7 @@ profiles:
特定のプロファイルに従ってスケジュールさせたいPodは、その`.spec.schedulerName`に、対応するスケジューラー名を含めることができます。
デフォルトでは、スケジューラー名`default-scheduler`としてプロファイルが生成されます。
-このプロファイルは、上記のデフォルトプラグインを含みます。複数のプロファイルを宣言する場合は、
-それぞれユニークなスケジューラー名にする必要があります。
+このプロファイルは、上記のデフォルトプラグインを含みます。複数のプロファイルを宣言する場合は、それぞれユニークなスケジューラー名にする必要があります。
もしPodがスケジューラー名を指定しない場合、kube-apiserverは`default-scheduler`を設定します。
従って、これらのPodをスケジュールするために、このスケジューラー名を持つプロファイルが存在する必要があります。
@@ -233,13 +208,11 @@ profiles:
- name: MyPlugin
```
-`multiPoint`を使用する利点の一つは、将来的に`MyPlugin`が別の拡張点を実装した場合に、
-`multiPoint`設定が自動的に新しい拡張点に対しても有効化されることです。
+`multiPoint`を使用する利点の一つは、将来的に`MyPlugin`が別の拡張点を実装した場合に、`multiPoint`設定が自動的に新しい拡張点に対しても有効化されることです。
特定の拡張点は、その拡張点の`disabled`フィールドを使用して、`MultiPoint`の展開から除外することができます。
-これは、デフォルトのプラグインを無効にしたり、デフォルト以外のプラグインを無効にしたり、
-ワイルドカード(`'*'`)を使ってすべてのプラグインを無効にしたりする場合に有効です。
-この例として、`Score`と`PreScore`を無効にするためには、次のようにします。
+これは、デフォルトのプラグインを無効にしたり、デフォルト以外のプラグインを無効にしたり、ワイルドカード(`'*'`)を使ってすべてのプラグインを無効にしたりする場合に有効です。
+`Score`と`PreScore`を無効にするためには、次の例のようにします。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
@@ -261,7 +234,7 @@ profiles:
`v1beta3`では、`MultiPoint`を通じて、内部的に全ての[デフォルトプラグイン](#scheduling-plugins)が有効化されています。
しかしながら、デフォルト値(並び順やスコアの重みなど)を柔軟に設定し直せるように、個別の拡張点は用意されています。
例えば、2つのスコアプラグイン`DefaultScore1`と`DefaultScore2`に、重み1が設定されているとします。
-その場合、次のように重さを変更し、並べ替えることができます
+その場合、次のように重さを変更し、並べ替えることができます。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
@@ -285,6 +258,7 @@ profiles:
3. デフォルトプラグインとそのデフォルト設定
上記の優先順位を示すために、次の例はこれらのプラグインをベースにします。
+
|プラグイン|拡張点|
|---|---|
|`DefaultQueueSort`|`QueueSort`|
@@ -326,7 +300,7 @@ profiles:
* カスタムの`queueSort`プラグインを有効にし、デフォルトのプラグインを無効にする。
* `CustomPlugin1`と`CustomPlugin2`を有効にし、この拡張点のプラグイン内で、最初に実行されるようにする。
* `filter`拡張点でのみ、`DefaultPlugin1`を無効にする。
-* `score`拡張点で`DefaultPlugin2`が最初に実行されるように並べ替える(カスタムプラグインより先に)
+* `score`拡張点で`DefaultPlugin2`が最初に実行されるように並べ替える(カスタムプラグインより先に)。
`v1beta3`以前のバージョンで、`multiPoint`がない場合、上記の設定例は、次のものと同等になります。
@@ -370,8 +344,7 @@ profiles:
{{% tab name="v1beta1 → v1beta2" %}}
* v1beta2`のバージョン`の設定では、新しい`NodeResourcesFit`プラグインをスコア拡張点で使用できます。
この新しい拡張機能は、`NodeResourcesLeastAllocated`、`NodeResourcesMostAllocated`、 `RequestedToCapacityRatio`プラグインの機能を組み合わせたものです。
- 例えば、以前は`NodeResourcesMostAllocated`プラグインを使っていたなら、代わりに`NodeResourcesFitプラグイン
- を使用し(デフォルトで有効)、`pluginConfig`に次のような`scoreStrategy`を追加することになるでしょう。
+ 例えば、以前は`NodeResourcesMostAllocated`プラグインを使っていたなら、代わりに`NodeResourcesFitプラグインを使用し(デフォルトで有効)、`pluginConfig`に次のような`scoreStrategy`を追加することになるでしょう。
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta2
From ad2921225b661359a4d83d2beb8aff09486ea383 Mon Sep 17 00:00:00 2001
From: serewicz
Date: Thu, 24 Mar 2022 09:58:58 -0500
Subject: [PATCH 052/167] Update install-kubeadm.md
Telnet is a command that really should not be used, as there is too great a chance it could be misused. NetCat, nc, is a better and newer tool for testing single open ports.
---
.../production-environment/tools/kubeadm/install-kubeadm.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index dc3ad5d7a6..d3db020b99 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -69,10 +69,10 @@ For more details please see the [Network Plugin Requirements](/docs/concepts/ext
## Check required ports
These
[required ports](/docs/reference/ports-and-protocols/)
-need to be open in order for Kubernetes components to communicate with each other. You can use telnet to check if a port is open. For example:
+need to be open in order for Kubernetes components to communicate with each other. You can use NetCat to check if a port is open. For example:
```shell
-telnet 127.0.0.1 6443
+nc 127.0.0.1 6443
```
The pod network plugin you use (see below) may also require certain ports to be
From 43efe8258a36945eb63a39e1caa54a0f005fcbbd Mon Sep 17 00:00:00 2001
From: howieyuen
Date: Sat, 26 Mar 2022 15:31:54 +0800
Subject: [PATCH 053/167] [zh]translate
content/docs/reference/kubernetes-api/common-definitions/status.md into
Chinese
---
.../common-definitions/status.md | 208 ++++++++++++++++++
1 file changed, 208 insertions(+)
create mode 100644 content/zh/docs/reference/kubernetes-api/common-definitions/status.md
diff --git a/content/zh/docs/reference/kubernetes-api/common-definitions/status.md b/content/zh/docs/reference/kubernetes-api/common-definitions/status.md
new file mode 100644
index 0000000000..54e8033160
--- /dev/null
+++ b/content/zh/docs/reference/kubernetes-api/common-definitions/status.md
@@ -0,0 +1,208 @@
+---
+api_metadata:
+ apiVersion: ""
+ import: "k8s.io/apimachinery/pkg/apis/meta/v1"
+ kind: "Status"
+content_type: "api_reference"
+description: "状态（Status）是不返回其他对象的调用的返回值。"
+title: "Status"
+weight: 12
+auto_generated: true
+---
+
+
+
+
+
+
+
+`import "k8s.io/apimachinery/pkg/apis/meta/v1"`
+
+
+
+状态（Status）是不返回其他对象的调用的返回值。
+
+
+
+- **apiVersion** (string)
+
+
+
+ APIVersion 定义对象表示的版本化模式。
+ 服务器应将已识别的模式转换为最新的内部值，并可能拒绝无法识别的值。
+ 更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
+
+- **code** (int32)
+
+
+ 此状态的建议 HTTP 返回代码，如果未设置，则为 0。
+
+- **details** (StatusDetails)
+
+
+ 与原因（Reason）相关的扩展数据。每个原因都可以定义自己的扩展细节。
+ 此字段是可选的，并且不保证返回的数据符合任何模式，除非由原因类型定义。
+
+
+
+ *StatusDetails 是一组附加属性，可以由服务器设置以提供有关响应的附加信息。*
+ *状态对象的原因字段定义将设置哪些属性。*
+ *客户端必须忽略与每个属性的定义类型不匹配的字段，并且应该假定任何属性可能为空、无效或未定义。*
+
+ - **details.causes** ([]StatusCause)
+
+
+ Causes 数组包含与 StatusReason 故障相关的更多详细信息。
+ 并非所有 StatusReasons 都可以提供详细的原因。
+
+
+
+ *StatusCause 提供有关 api.Status 失败的更多信息，包括遇到多个错误的情况。*
+
+ - **details.causes.field** (string)
+
+
+ 导致此错误的资源字段，由其 JSON 序列化命名。
+ 可能包括嵌套属性的点和后缀表示法。数组是从零开始索引的。
+ 由于字段有多个错误，字段可能会在一系列原因中出现多次。可选。
+
+
+ 示例：
+ - “name”：当前资源上的字段 “name”
+ - “items[0].name”：“items” 中第一个数组条目上的字段 “name”
+
+ - **details.causes.message** (string)
+
+
+ 对错误原因的可读描述。该字段可以按原样呈现给读者。
+
+ - **details.causes.reason** (string)
+
+
+ 错误原因的机器可读描述。如果此值为空，则没有可用信息。
+
+ - **details.group** (string)
+
+
+ 与状态 StatusReason 关联的资源的组属性。
+
+ - **details.kind** (string)
+
+
+ 与状态 StatusReason 关联的资源的种类属性。
+ 在某些操作上可能与请求的资源种类不同。
+ 更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
+
+ - **details.name** (string)
+
+
+ 与状态 StatusReason 关联的资源的名称属性（当有一个可以描述的名称时）。
+
+ - **details.retryAfterSeconds** (int32)
+
+
+ 如果指定，则应重试操作前的时间（以秒为单位）。
+ 一些错误可能表明客户端必须采取替代操作——对于这些错误，此字段可能指示在采取替代操作之前等待多长时间。
+
+ - **details.uid** (string)
+
+
+ 资源的 UID（当有单个可以描述的资源时）。
+ 更多信息：http://kubernetes.io/docs/user-guide/identifiers#uids
+
+- **kind** (string)
+
+
+ Kind 是一个字符串值，表示此对象表示的 REST 资源。
+ 服务器可以从客户端提交请求的端点推断出这一点。
+ 无法更新。驼峰式规则。
+ 更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
+
+- **message** (string)
+
+
+ 此操作状态的人类可读描述。
+
+- **metadata** (}}">ListMeta)
+
+
+ 标准列表元数据。
+ 更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
+
+
+- **reason** (string)
+
+
+ 机器可读的说明，说明此操作为何处于“失败”状态。
+ 如果此值为空，则没有可用信息。
+ Reason 澄清了 HTTP 状态代码，但不会覆盖它。
+
+- **status** (string)
+
+
+ 操作状态。“Success”或“Failure” 之一。
+ 更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
From a3ab2f3412b6cc76d62c1baff5d2c0b667511755 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <196thinline@gmail.com>
Date: Mon, 28 Mar 2022 22:09:56 +0900
Subject: [PATCH 054/167] fix:parameter name
---
.../docs/concepts/scheduling-eviction/resource-bin-packing.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
index 6b30fb61a0..fd2404984c 100644
--- a/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
+++ b/content/ja/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -54,7 +54,7 @@ shape:
score: 10
```
-上記の引数は、`利用率`が0%の場合は0、`利用率`が100%の場合は10という`スコア`をNodeに与え、ビンパッキングの動作を有効にしています。最小要求を有効にするには、次のようにスコアを反転させる必要があります。
+上記の引数は、`utilization`が0%の場合は0、`utilization`が100%の場合は10という`score`をNodeに与え、ビンパッキングの動作を有効にしています。最小要求を有効にするには、次のようにスコアを反転させる必要があります。
```yaml
shape:
From 550bfd539140d8afc87460e82c08fafbe9b3d7fd Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Tue, 29 Mar 2022 18:28:00 +0900
Subject: [PATCH 055/167] Update
content/ja/docs/reference/scheduling/policies.md
Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
content/ja/docs/reference/scheduling/policies.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/reference/scheduling/policies.md b/content/ja/docs/reference/scheduling/policies.md
index 64bdf4f9eb..7cd9b6ba98 100644
--- a/content/ja/docs/reference/scheduling/policies.md
+++ b/content/ja/docs/reference/scheduling/policies.md
@@ -7,7 +7,7 @@ sitemap:
-バージョンv1.23より前のKubernetesでは、スケジューリングポリシーを使用して、*predicates*と*priorities*の処理を指定することができました。例えば、`kube-scheduler --policy-config-file ` または `kube-scheduler --policy-configmap ` を実行すると、スケジューリングポリシーを設定することが可能です。
+バージョンv1.23より前のKubernetesでは、スケジューリングポリシーを使用して、*predicates*と*priorities*の処理を指定することができました。例えば、`kube-scheduler --policy-config-file `または`kube-scheduler --policy-configmap `を実行すると、スケジューリングポリシーを設定することが可能です。
このスケジューリングポリシーは、バージョンv1.23以降のKubernetesではサポートされていません。関連するフラグである、`policy-config-file`,`policy-configmap`、`policy-configmap-namespace`、`use-legacy-policy-config`も同様にサポートされていません。
代わりに、[スケジューラー設定](/ja/docs/reference/scheduling/config/)を使用してください。
From f1ae421043dddc4d1b2ae4be1ca23e85e3f8a78a Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Tue, 29 Mar 2022 18:28:06 +0900
Subject: [PATCH 056/167] Update
content/ja/docs/reference/scheduling/policies.md
Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
content/ja/docs/reference/scheduling/policies.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/reference/scheduling/policies.md b/content/ja/docs/reference/scheduling/policies.md
index 7cd9b6ba98..a42d43a757 100644
--- a/content/ja/docs/reference/scheduling/policies.md
+++ b/content/ja/docs/reference/scheduling/policies.md
@@ -9,7 +9,7 @@ sitemap:
バージョンv1.23より前のKubernetesでは、スケジューリングポリシーを使用して、*predicates*と*priorities*の処理を指定することができました。例えば、`kube-scheduler --policy-config-file `または`kube-scheduler --policy-configmap `を実行すると、スケジューリングポリシーを設定することが可能です。
-このスケジューリングポリシーは、バージョンv1.23以降のKubernetesではサポートされていません。関連するフラグである、`policy-config-file`,`policy-configmap`、`policy-configmap-namespace`、`use-legacy-policy-config`も同様にサポートされていません。
+このスケジューリングポリシーは、バージョンv1.23以降のKubernetesではサポートされていません。関連するフラグである、`policy-config-file`、`policy-configmap`、`policy-configmap-namespace`、`use-legacy-policy-config`も同様にサポートされていません。
代わりに、[スケジューラー設定](/ja/docs/reference/scheduling/config/)を使用してください。
## {{% heading "whatsnext" %}}
From 2cdd9e9db41a2cdd0fb14508ba81ddfdcb28646e Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Tue, 29 Mar 2022 18:28:12 +0900
Subject: [PATCH 057/167] Update
content/ja/docs/reference/scheduling/policies.md
Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com>
---
content/ja/docs/reference/scheduling/policies.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/reference/scheduling/policies.md b/content/ja/docs/reference/scheduling/policies.md
index a42d43a757..dd236d3c3d 100644
--- a/content/ja/docs/reference/scheduling/policies.md
+++ b/content/ja/docs/reference/scheduling/policies.md
@@ -15,5 +15,5 @@ sitemap:
## {{% heading "whatsnext" %}}
* [スケジューリング](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ
-* [kube-scheduler設定](/ja/docs/reference/scheduling/config/)
+* [kube-scheduler設定](/ja/docs/reference/scheduling/config/)について学ぶ
* [kube-scheduler設定リファレンス(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)について読む
From db65b54571d15657adb114a6844886252ab3eafa Mon Sep 17 00:00:00 2001
From: 196Ikuchil <196thinline@gmail.com>
Date: Thu, 31 Mar 2022 19:01:19 +0900
Subject: [PATCH 058/167] fix:weight & some links
---
.../docs/concepts/scheduling-eviction/kube-scheduler.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md
index d1b249f24e..12a7971d88 100644
--- a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -1,7 +1,7 @@
---
title: Kubernetesのスケジューラー
content_type: concept
-weight: 60
+weight: 10
---
@@ -62,9 +62,9 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適
* [Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を参照してください。
* kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。
* [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
-* [トポロジーの管理ポリシー](/docs/tasks/administer-cluster/topology-manager/)について学んでください。
-* [Podのオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)について学んでください。
+* [トポロジーの管理ポリシー](/ja/docs/tasks/administer-cluster/topology-manager/)について学んでください。
+* [Podのオーバーヘッド](/ja/docs/concepts/scheduling-eviction/pod-overhead/)について学んでください。
* ボリュームを使用するPodのスケジューリングについて以下で学んでください。
* [Volume Topology Support](/docs/concepts/storage/storage-classes/#volume-binding-mode)
- * [ストレージ容量の追跡](/ja//ja/docs/concepts/storage/storage-capacity/)
+ * [ストレージ容量の追跡](/ja/docs/concepts/storage/storage-capacity/)
* [Node-specific Volume Limits](/docs/concepts/storage/storage-limits/)
From a86a5c6511e30bc25d0c8db5aa08209a9131c155 Mon Sep 17 00:00:00 2001
From: Kobayashi Daisuke
Date: Fri, 1 Apr 2022 14:36:48 +0900
Subject: [PATCH 059/167] Update
content/ja/docs/concepts/services-networking/topology-aware-hints.md
Co-authored-by: nasa9084
---
.../docs/concepts/services-networking/topology-aware-hints.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
index b119dad348..ca41ef1367 100644
--- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md
+++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
@@ -18,7 +18,7 @@ weight: 45
## 動機
Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。
-*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー(地域とゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
+*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー(リージョンとゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
EndpointSliceコントローラーは、各endpointのトポロジー(地域とゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。
From 020a6aa13ae2c20088a15ae6e66c7b6d0f717834 Mon Sep 17 00:00:00 2001
From: Kobayashi Daisuke
Date: Fri, 1 Apr 2022 14:36:55 +0900
Subject: [PATCH 060/167] Update
content/ja/docs/concepts/services-networking/topology-aware-hints.md
Co-authored-by: nasa9084
---
.../docs/concepts/services-networking/topology-aware-hints.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
index ca41ef1367..ed26561f40 100644
--- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md
+++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md
@@ -19,7 +19,7 @@ weight: 45
Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。
*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー(リージョンとゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
-EndpointSliceコントローラーは、各endpointのトポロジー(地域とゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
+EndpointSliceコントローラーは、各endpointのトポロジー(リージョンとゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。
From 82456a84decddc456b6cac4a65525a32eab0ba0b Mon Sep 17 00:00:00 2001
From: Cheng Wang
Date: Sat, 2 Apr 2022 13:09:56 +0800
Subject: [PATCH 061/167] Update quality-service-pod.md
Update `Burstable` conditions
---
.../docs/tasks/configure-pod-container/quality-service-pod.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
index abe6320563..c1a00bcc3d 100644
--- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -107,7 +107,7 @@ kubectl delete pod qos-demo --namespace=qos-example
A Pod is given a QoS class of Burstable if:
* The Pod does not meet the criteria for QoS class Guaranteed.
-* At least one Container in the Pod has a memory or CPU request.
+* At least one Container in the Pod has a memory or CPU request or limit.
Here is the configuration file for a Pod that has one Container. The Container has a memory limit of 200 MiB
and a memory request of 100 MiB.
From afe13e859a74c651d77f685b7e3a57640647aa6e Mon Sep 17 00:00:00 2001
From: Tim Bannister
Date: Sun, 3 Apr 2022 12:31:25 +0100
Subject: [PATCH 062/167] (Further) update Container Runtmes to prepare for
dockershim removal
---
.../container-runtimes.md | 360 ++++--------------
1 file changed, 82 insertions(+), 278 deletions(-)
diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md
index 54897a1c59..7b5d4e315e 100644
--- a/content/en/docs/setup/production-environment/container-runtimes.md
+++ b/content/en/docs/setup/production-environment/container-runtimes.md
@@ -2,7 +2,7 @@
reviewers:
- vincepri
- bart0sh
-title: Container runtimes
+title: Container Runtimes
content_type: concept
weight: 20
---
@@ -13,7 +13,6 @@ You need to install a
into each node in the cluster so that Pods can run there. This page outlines
what is involved and describes related tasks for setting up nodes.
-
Kubernetes {{< skew currentVersion >}} requires that you use a runtime that
conforms with the
@@ -21,8 +20,8 @@ conforms with the
See [CRI version support](#cri-versions) for more information.
-This page lists details for using several common container runtimes with
-Kubernetes, on Linux:
+This page provides an outline of how to use several common container runtimes with
+Kubernetes.
- [containerd](#containerd)
- [CRI-O](#cri-o)
@@ -30,25 +29,27 @@ Kubernetes, on Linux:
- [Mirantis Container Runtime](#mcr)
{{< note >}}
-Dockershim, the portion of code in Kubernetes that provided direct
-integration with Docker in prior releases, was removed from Kubernetes
-version 1.24. This removal was announced as a [deprecation in Kubernetes v 1.20](
-/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
-You can check out this [documentation](
-/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
-to understand how this deprecation might affect you. To migrate from
-dockershim you can follow [this migration guide](
-/docs/tasks/administer-cluster/migrating-from-dockershim/)
-to migrate from dockershim.
+Kubernetes releases before v1.24 included a direct integration with Docker Engine,
+using a component named _dockershim_. That special direct integration is no longer
+part of Kubernetes (this removal was
+[announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
+as part of the v1.20 release).
+You can read
+[Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) to understand how this removal might
+affect you. To learn about migrating from using dockershim, see
+[Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/).
+
+If you are running a version of Kubernetes other than v{{< skew currentVersion >}},
+check the documentation for that version.
{{< /note >}}
-{{< note >}}
-For other operating systems, look for documentation specific to your platform.
-{{< /note >}}
+
+
## Cgroup drivers
-Control groups are used to constrain resources that are allocated to processes.
+On Linux, {{< glossary_tooltip text="control groups" term_id="cgroup" >}}
+are used to constrain resources that are allocated to processes.
When [systemd](https://www.freedesktop.org/wiki/Software/systemd/) is chosen as the init
system for a Linux distribution, the init process generates and consumes a root control group
@@ -77,7 +78,7 @@ If you have automation that makes it feasible, replace the node with another usi
configuration, or reinstall it using automation.
{{< /caution >}}
-## Cgroup v2
+### Cgroup version 2 {#cgroup-v2}
Cgroup v2 is the next version of the cgroup Linux API. Differently than cgroup v1, there is a single
hierarchy instead of a different one for each controller.
@@ -115,8 +116,8 @@ In order to use it, cgroup v2 must be supported by the CRI runtime as well.
### Migrating to the `systemd` driver in kubeadm managed clusters
-Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)
-if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters.
+If you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters,
+follow [configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/).
## CRI version support {#cri-versions}
@@ -133,96 +134,51 @@ using the (deprecated) v1alpha2 API instead.
### containerd
-This section contains the necessary steps to use containerd as CRI runtime.
+This section outlines the necessary steps to use containerd as CRI runtime.
Use the following commands to install Containerd on your system:
-Install and configure prerequisites:
+1. Install and configure prerequisites:
-```shell
-cat <}}
-{{% tab name="Linux" %}}
-
-1. Install the `containerd.io` package from the [official containerd website](
- https://containerd.io/downloads/).Instructions for setting up the Docker
- repository for your respective Linux distribution and
- installing the `containerd.io` package can be found at
- [Install Docker Engine](https://docs.docker.com/engine/install/#server).
-
-2. Configure containerd:
+ (these instructions apply to Linux nodes only)
```shell
- sudo mkdir -p /etc/containerd
- containerd config default | sudo tee /etc/containerd/config.toml
+ cat <}}
-
-#### Using the `systemd` cgroup driver {#containerd-systemd}
+#### Configuring the `systemd` cgroup driver {#containerd-systemd}
To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set
@@ -233,7 +189,7 @@ To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`,
SystemdCgroup = true
```
-If you apply this change make sure to restart containerd again:
+If you apply this change, make sure to restart containerd:
```shell
sudo systemctl restart containerd
@@ -246,176 +202,14 @@ When using kubeadm, manually configure the
This section contains the necessary steps to install CRI-O as a container runtime.
-Use the following commands to install CRI-O on your system:
-
-{{< note >}}
-The CRI-O major and minor versions must match the Kubernetes major and minor versions.
-For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes).
-{{< /note >}}
-
-Install and configure prerequisites:
-
-```shell
-# Create the .conf file to load the modules at bootup
-cat <}}
-{{% tab name="Debian" %}}
-
-To install CRI-O on the following operating systems, set the environment variable `OS`
-to the appropriate value from the following table:
-
-| Operating system | `$OS` |
-| ---------------- | ----------------- |
-| Debian Unstable | `Debian_Unstable` |
-| Debian Testing | `Debian_Testing` |
-
-
-Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
-For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
-You can pin your installation to a specific release.
-To install version 1.20.0, set `VERSION=1.20:1.20.0`.
-
-
-Then run
-```shell
-cat <
-Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
-For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
-You can pin your installation to a specific release.
-To install version 1.20.0, set `VERSION=1.20:1.20.0`.
-
-
-Then run
-```shell
-cat <
-Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
-For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
-You can pin your installation to a specific release.
-To install version 1.20.0, set `VERSION=1.20:1.20.0`.
-
-
-Then run
-```shell
-sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
-sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
-sudo yum install cri-o
-```
-
-{{% /tab %}}
-
-{{% tab name="openSUSE Tumbleweed" %}}
-
-```shell
-sudo zypper install cri-o
-```
-{{% /tab %}}
-{{% tab name="Fedora" %}}
-
-Set `$VERSION` to the CRI-O version that matches your Kubernetes version.
-For instance, if you want to install CRI-O 1.20, `VERSION=1.20`.
-
-You can find available versions with:
-```shell
-sudo dnf module list cri-o
-```
-CRI-O does not support pinning to specific releases on Fedora.
-
-Then run
-```shell
-sudo dnf module enable cri-o:$VERSION
-sudo dnf install cri-o
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Start CRI-O:
-
-```shell
-sudo systemctl daemon-reload
-sudo systemctl enable crio --now
-```
-
-Refer to the [CRI-O installation guide](https://github.com/cri-o/cri-o/blob/master/install.md)
-for more information.
-
+To install CRI-O, follow [CRI-O Install Instructions](https://github.com/cri-o/cri-o/blob/main/install.md#readme).
#### cgroup driver
-CRI-O uses the systemd cgroup driver per default. To switch to the `cgroupfs`
-cgroup driver, either edit `/etc/crio/crio.conf` or place a drop-in
-configuration in `/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example:
+CRI-O uses the systemd cgroup driver per default, which is likely to work fine
+for you. To switch to the `cgroupfs` cgroup driver, either editi
+`/etc/crio/crio.conf` or place a drop-in configuration in
+`/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example:
```toml
[crio.runtime]
@@ -423,29 +217,28 @@ conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
```
-Please also note the changed `conmon_cgroup`, which has to be set to the value
+You should also note the changed `conmon_cgroup`, which has to be set to the value
`pod` when using CRI-O with `cgroupfs`. It is generally necessary to keep the
cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O
in sync.
+For CRI-O, the CRI socket is `/var/run/crio/crio.sock` by default.
+
### Docker Engine {#docker}
-On each of your nodes, install Docker for your Linux distribution as per
-[Install Docker Engine](https://docs.docker.com/engine/install/#server).
-
-Docker Engine is directly compatible with Kubernetes {{< skew currentVersion >}}, using the deprecated `dockershim` component. For more information
-and context, see the [Dockershim deprecation FAQ](/dockershim).
-
-You can also find third-party adapters that let you use Docker Engine with Kubernetes
-through the supported {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}}
-(CRI).
-
{{< note >}}
-`overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher,
-or RHEL or CentOS using version 3.10.0-514 and above.
+These instructions assume that you are using the
+[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) adapter to integrate
+Docker Engine with Kubernetes.
{{< /note >}}
-- [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) from Mirantis
+1. On each of your nodes, install Docker for your Linux distribution as per
+ [Install Docker Engine](https://docs.docker.com/engine/install/#server).
+
+2. Install [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd), following
+ the instructions in that source code repository.
+
+For `cri-dockerd`, the CRI socket is `/run/cri-dockerd.sock` by default.
### Mirantis Container Runtime {#mcr}
@@ -454,3 +247,14 @@ available container runtime that was formerly known as Docker Enterprise Edition
You can use Mirantis Container Runtime with Kubernetes using the open source
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) component, included with MCR.
+
+To learn more about how to install Mirantis Container Runtime,
+visit [MCR Deployment Guide](https://docs.mirantis.com/mcr/20.10/install.html).
+
+Check the systemd unit named `cri-docker.socket` to find out the path to the CRI
+socket.
+
+## {{% heading "whatsnext" %}}
+
+As well as a container runtime, your cluster will need a working
+[network plugin](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
From ba811914401718b05b9a4b52b788fed790c7fad0 Mon Sep 17 00:00:00 2001
From: Tim Bannister
Date: Sun, 3 Apr 2022 19:24:23 +0100
Subject: [PATCH 063/167] Fix typo
Co-authored-by: Qiming Teng
---
.../en/docs/setup/production-environment/container-runtimes.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md
index 7b5d4e315e..98c187e7bd 100644
--- a/content/en/docs/setup/production-environment/container-runtimes.md
+++ b/content/en/docs/setup/production-environment/container-runtimes.md
@@ -207,7 +207,7 @@ To install CRI-O, follow [CRI-O Install Instructions](https://github.com/cri-o/c
#### cgroup driver
CRI-O uses the systemd cgroup driver per default, which is likely to work fine
-for you. To switch to the `cgroupfs` cgroup driver, either editi
+for you. To switch to the `cgroupfs` cgroup driver, either edit
`/etc/crio/crio.conf` or place a drop-in configuration in
`/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example:
From 4a05cab07e8859611af87bdd7eaf9284e027af4a Mon Sep 17 00:00:00 2001
From: Vitthal Sai
Date: Mon, 7 Mar 2022 17:46:14 +0530
Subject: [PATCH 064/167] Adds documentation for PR Wrangler Shadow program
---
.../en/docs/contribute/participate/pr-wranglers.md | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/content/en/docs/contribute/participate/pr-wranglers.md b/content/en/docs/contribute/participate/pr-wranglers.md
index fb6f54e2d9..865af35805 100644
--- a/content/en/docs/contribute/participate/pr-wranglers.md
+++ b/content/en/docs/contribute/participate/pr-wranglers.md
@@ -87,3 +87,17 @@ To close a pull request, leave a `/close` comment on the PR.
The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them. PR wranglers should close issues after 14-30 days of inactivity.
{{< /note >}}
+
+## PR Wrangler shadow program
+
+In late 2021, SIG Docs introduced the PR Wrangler Shadow Program. The program was introduced to help new contributors understand the PR wrangling process.
+
+### Become a shadow
+
+- If you are interested in shadowing as a PR wrangler, please visit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) to see the PR wrangling schedule for this year and sign up.
+
+- Kubernetes org members can edit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) and sign up to shadow an existing PR Wrangler for a week.
+
+- Others can reach out on the [#sig-docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) for requesting to shadow an assigned PR Wrangler for a specific week. Feel free to reach out to Brad Topol (`@bradtopol`) or one of the [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership).
+
+- Once you've signed up to shadow a PR Wrangler, introduce yourself to the PR Wrangler on the [Kubernetes Slack](slack.k8s.io).
\ No newline at end of file
From 8c48fa656fde48d9dd10784c37498741dd0a1a07 Mon Sep 17 00:00:00 2001
From: Akihiro Suda
Date: Tue, 5 Apr 2022 18:36:56 +0900
Subject: [PATCH 065/167] runtime-class.md: update containerd/cri link
The `containerd/cri` repo was merged into the `containerd/containerd` repo.
The `containerd/cri` repo is now archived.
Signed-off-by: Akihiro Suda
---
content/en/docs/concepts/containers/runtime-class.md | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md
index 849cd98782..9e68ede443 100644
--- a/content/en/docs/concepts/containers/runtime-class.md
+++ b/content/en/docs/concepts/containers/runtime-class.md
@@ -126,8 +126,7 @@ Runtime handlers are configured through containerd's configuration at
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
```
-See containerd's config documentation for more details:
-https://github.com/containerd/cri/blob/master/docs/config.md
+See the containerd [CRI Plugin Config Guide](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) for more details.
#### {{< glossary_tooltip term_id="cri-o" >}}
From 9c8227a521b7d2bd5687934f613e9aaf9be2d319 Mon Sep 17 00:00:00 2001
From: Tim Bannister
Date: Tue, 5 Apr 2022 15:39:47 +0100
Subject: [PATCH 066/167] Update kubeadm CRI detection docs
Update kubeadm CRI detection docs in light of dockershim deprecation.
Co-authored-by: Lubomir I. Ivanov
---
.../tools/kubeadm/install-kubeadm.md | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index dc3ad5d7a6..917c384766 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -93,30 +93,30 @@ to interface with your chosen container runtime.
If you don't specify a runtime, kubeadm automatically tries to detect an installed
container runtime by scanning through a list of well known Unix domain sockets.
-The following table lists container runtimes and their associated socket paths:
+The following table lists container runtimes that kubeadm looks for, and their associated socket paths:
{{< table caption = "Container runtimes and their socket paths" >}}
-| Runtime | Path to Unix domain socket |
-|------------|-----------------------------------|
-| Docker | `/var/run/dockershim.sock` |
-| containerd | `/run/containerd/containerd.sock` |
-| CRI-O | `/var/run/crio/crio.sock` |
+| Runtime | Path to Unix domain socket |
+|----------------|-----------------------------------|
+| Docker Engine | `/var/run/dockershim.sock` |
+| containerd | `/run/containerd/containerd.sock` |
+| CRI-O | `/var/run/crio/crio.sock` |
{{< /table >}}
-If both Docker and containerd are detected, Docker takes precedence. This is
+If both Docker Engine and containerd are detected, kubeadm will give precedence to Docker Engine. This is
needed because Docker 18.09 ships with containerd and both are detectable even if you only
installed Docker.
-If any other two or more runtimes are detected, kubeadm exits with an error.
+**If any other two or more runtimes are detected, kubeadm exits with an error.**
-The kubelet integrates with Docker through the built-in `dockershim` CRI implementation.
+The kubelet can integrate with Docker Engine using the deprecated `dockershim` adapter (the dockershim is part of the kubelet itself).
See [container runtimes](/docs/setup/production-environment/container-runtimes/)
for more information.
{{% /tab %}}
{{% tab name="other operating systems" %}}
By default, kubeadm uses {{< glossary_tooltip term_id="docker" >}} as the container runtime.
-The kubelet integrates with Docker through the built-in `dockershim` CRI implementation.
+The kubelet can integrate with Docker Engine using the deprecated `dockershim` adapter (the dockershim is part of the kubelet itself).
See [container runtimes](/docs/setup/production-environment/container-runtimes/)
for more information.
From 8bdb53b2ef111f2e566dc48812d02d2583892e1c Mon Sep 17 00:00:00 2001
From: Christopher Negus
Date: Thu, 7 Apr 2022 21:02:25 +0000
Subject: [PATCH 067/167] Create dockershim banner
---
data/announcements/scheduled.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/data/announcements/scheduled.yaml b/data/announcements/scheduled.yaml
index 831ad1ebb6..635071dd4a 100644
--- a/data/announcements/scheduled.yaml
+++ b/data/announcements/scheduled.yaml
@@ -30,6 +30,15 @@
# leave the "announcements" key in place
announcements:
+- name: Dockershim removal coming in Kubernetes 1.24
+ startTime: 2022-04-13T00:00:00 # Added in PR:
+ endTime: 2022-05-13T00:00:00 # Expires 2022-05-19
+ style: "background: #3d4cb7"
+ title: "Dockershim removal: Read the FAQ"
+ message: |
+ As of Kubernetes 1.24, Dockershim will no longer be included in Kubernetes.
+ Read the [Dockershim Removal FAQ](https://kubernetes.io/blog/2022/02/17/dockershim-faq/) to see what this means to you.
+
- name: Kubecon 2020 NA
startTime: 2020-10-26T00:00:00 # Added in https://github.com/kubernetes/website/pull/24714
endTime: 2020-11-23T00:00:00 # Removed in https://github.com/kubernetes/website/pull/25173
From f5f099c71d13ccdc5b1df96d196dd757f33febe5 Mon Sep 17 00:00:00 2001
From: Christopher Negus
Date: Thu, 7 Apr 2022 21:08:40 +0000
Subject: [PATCH 068/167] Changed the wording
---
data/announcements/scheduled.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/data/announcements/scheduled.yaml b/data/announcements/scheduled.yaml
index 635071dd4a..fb049a84df 100644
--- a/data/announcements/scheduled.yaml
+++ b/data/announcements/scheduled.yaml
@@ -30,11 +30,11 @@
# leave the "announcements" key in place
announcements:
-- name: Dockershim removal coming in Kubernetes 1.24
+- name: Dockershim removal
startTime: 2022-04-13T00:00:00 # Added in PR:
endTime: 2022-05-13T00:00:00 # Expires 2022-05-19
style: "background: #3d4cb7"
- title: "Dockershim removal: Read the FAQ"
+ title: "Dockershim removal set for Kubernetes 1.24"
message: |
As of Kubernetes 1.24, Dockershim will no longer be included in Kubernetes.
Read the [Dockershim Removal FAQ](https://kubernetes.io/blog/2022/02/17/dockershim-faq/) to see what this means to you.
From 7365b45a2d468412ad2bd9a1805b2e2fb75cba62 Mon Sep 17 00:00:00 2001
From: Christopher Negus
Date: Thu, 7 Apr 2022 21:36:40 +0000
Subject: [PATCH 069/167] Added PR and changed expiration date
---
data/announcements/scheduled.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/data/announcements/scheduled.yaml b/data/announcements/scheduled.yaml
index fb049a84df..7dce812568 100644
--- a/data/announcements/scheduled.yaml
+++ b/data/announcements/scheduled.yaml
@@ -31,8 +31,8 @@
announcements:
- name: Dockershim removal
- startTime: 2022-04-13T00:00:00 # Added in PR:
- endTime: 2022-05-13T00:00:00 # Expires 2022-05-19
+ startTime: 2022-04-13T00:00:00 # Added in PR: https://github.com/kubernetes/website/pull/32805
+ endTime: 2022-05-19T00:00:00 # Expires 2022-05-19
style: "background: #3d4cb7"
title: "Dockershim removal set for Kubernetes 1.24"
message: |
From b51b1d6b1d4274b8728f5023de4ec232924791a7 Mon Sep 17 00:00:00 2001
From: Qiming Teng
Date: Fri, 8 Apr 2022 16:00:56 +0800
Subject: [PATCH 070/167] Move NetworkPolicy into examples
---
.../services-networking/network-policies.md | 37 +------------------
content/en/examples/examples_test.go | 2 +
.../service/networking/networkpolicy.yaml | 35 ++++++++++++++++++
3 files changed, 38 insertions(+), 36 deletions(-)
create mode 100644 content/en/examples/service/networking/networkpolicy.yaml
diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md
index 884cfc960d..dc4e2b76ca 100644
--- a/content/en/docs/concepts/services-networking/network-policies.md
+++ b/content/en/docs/concepts/services-networking/network-policies.md
@@ -45,42 +45,7 @@ See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "vers
An example NetworkPolicy might look like this:
-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
- name: test-network-policy
- namespace: default
-spec:
- podSelector:
- matchLabels:
- role: db
- policyTypes:
- - Ingress
- - Egress
- ingress:
- - from:
- - ipBlock:
- cidr: 172.17.0.0/16
- except:
- - 172.17.1.0/24
- - namespaceSelector:
- matchLabels:
- project: myproject
- - podSelector:
- matchLabels:
- role: frontend
- ports:
- - protocol: TCP
- port: 6379
- egress:
- - to:
- - ipBlock:
- cidr: 10.0.0.0/24
- ports:
- - protocol: TCP
- port: 5978
-```
+{{< codenew file="service/networking/networkpolicy.yaml" >}}
{{< note >}}
POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy.
diff --git a/content/en/examples/examples_test.go b/content/en/examples/examples_test.go
index eaf6e5808e..27eae2eadf 100644
--- a/content/en/examples/examples_test.go
+++ b/content/en/examples/examples_test.go
@@ -647,6 +647,7 @@ func TestExampleObjectSchemas(t *testing.T) {
"service/networking": {
"curlpod": {&apps.Deployment{}},
"custom-dns": {&api.Pod{}},
+ "default-ingressclass": {&networking.IngressClass{}},
"dual-stack-default-svc": {&api.Service{}},
"dual-stack-ipfamilies-ipv6": {&api.Service{}},
"dual-stack-ipv6-svc": {&api.Service{}},
@@ -662,6 +663,7 @@ func TestExampleObjectSchemas(t *testing.T) {
"name-virtual-host-ingress": {&networking.Ingress{}},
"name-virtual-host-ingress-no-third-host": {&networking.Ingress{}},
"namespaced-params": {&networking.IngressClass{}},
+ "networkpolicy": {&networking.NetworkPolicy{}},
"network-policy-allow-all-egress": {&networking.NetworkPolicy{}},
"network-policy-allow-all-ingress": {&networking.NetworkPolicy{}},
"network-policy-default-deny-egress": {&networking.NetworkPolicy{}},
diff --git a/content/en/examples/service/networking/networkpolicy.yaml b/content/en/examples/service/networking/networkpolicy.yaml
new file mode 100644
index 0000000000..e91eed2f67
--- /dev/null
+++ b/content/en/examples/service/networking/networkpolicy.yaml
@@ -0,0 +1,35 @@
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+ name: test-network-policy
+ namespace: default
+spec:
+ podSelector:
+ matchLabels:
+ role: db
+ policyTypes:
+ - Ingress
+ - Egress
+ ingress:
+ - from:
+ - ipBlock:
+ cidr: 172.17.0.0/16
+ except:
+ - 172.17.1.0/24
+ - namespaceSelector:
+ matchLabels:
+ project: myproject
+ - podSelector:
+ matchLabels:
+ role: frontend
+ ports:
+ - protocol: TCP
+ port: 6379
+ egress:
+ - to:
+ - ipBlock:
+ cidr: 10.0.0.0/24
+ ports:
+ - protocol: TCP
+ port: 5978
+
From 1fba7dcc8a9b5feedb91b08e9c71e0aa3fa9a8d9 Mon Sep 17 00:00:00 2001
From: Christopher Negus
Date: Fri, 8 Apr 2022 11:18:14 +0000
Subject: [PATCH 071/167] Fixed link
---
data/announcements/scheduled.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/data/announcements/scheduled.yaml b/data/announcements/scheduled.yaml
index 7dce812568..1568b8ee79 100644
--- a/data/announcements/scheduled.yaml
+++ b/data/announcements/scheduled.yaml
@@ -31,13 +31,13 @@
announcements:
- name: Dockershim removal
- startTime: 2022-04-13T00:00:00 # Added in PR: https://github.com/kubernetes/website/pull/32805
+ startTime: 2022-04-07T00:00:00 # Added in PR: https://github.com/kubernetes/website/pull/32805
endTime: 2022-05-19T00:00:00 # Expires 2022-05-19
style: "background: #3d4cb7"
title: "Dockershim removal set for Kubernetes 1.24"
message: |
As of Kubernetes 1.24, Dockershim will no longer be included in Kubernetes.
- Read the [Dockershim Removal FAQ](https://kubernetes.io/blog/2022/02/17/dockershim-faq/) to see what this means to you.
+ Read the [Dockershim Removal FAQ](/blog/2022/02/17/dockershim-faq/) to see what this means to you.
- name: Kubecon 2020 NA
startTime: 2020-10-26T00:00:00 # Added in https://github.com/kubernetes/website/pull/24714
From c44f50decf35cfa98b9734ad59eb221aea665b13 Mon Sep 17 00:00:00 2001
From: Qiming Teng
Date: Sun, 10 Apr 2022 20:11:46 +0800
Subject: [PATCH 072/167] [zh] Resync deployment page
---
.../workloads/controllers/deployment.md | 634 ++++++++++++------
1 file changed, 414 insertions(+), 220 deletions(-)
diff --git a/content/zh/docs/concepts/workloads/controllers/deployment.md b/content/zh/docs/concepts/workloads/controllers/deployment.md
index 0f6ea1846f..d4ef2b43a8 100644
--- a/content/zh/docs/concepts/workloads/controllers/deployment.md
+++ b/content/zh/docs/concepts/workloads/controllers/deployment.md
@@ -24,8 +24,8 @@ weight: 10
A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
-->
-一个 _Deployment_ 为 {{< glossary_tooltip text="Pods" term_id="pod" >}}
-和 {{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}
+一个 Deployment 为 {{< glossary_tooltip text="Pod" term_id="pod" >}}
+和 {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}
提供声明式的更新能力。
-{{< note >}}
不要管理 Deployment 所拥有的 ReplicaSet 。
如果存在下面未覆盖的使用场景，请考虑在 Kubernetes 仓库中提出 Issue。
{{< /note >}}
@@ -58,17 +58,19 @@ The following are typical use cases for Deployments:
* [创建 Deployment 以将 ReplicaSet 上线](#creating-a-deployment)。 ReplicaSet 在后台创建 Pods。
检查 ReplicaSet 的上线状态，查看其是否成功。
* 通过更新 Deployment 的 PodTemplateSpec，[声明 Pod 的新状态](#updating-a-deployment) 。
新的 ReplicaSet 会被创建，Deployment 以受控速率将 Pod 从旧 ReplicaSet 迁移到新 ReplicaSet。
每个新的 ReplicaSet 都会更新 Deployment 的修订版本。
+
* 如果 Deployment 的当前状态不稳定，[回滚到较早的 Deployment 版本](#rolling-back-a-deployment)。
每次回滚都会更新 Deployment 的修订版本。
* [扩大 Deployment 规模以承担更多负载](#scaling-a-deployment)。
@@ -84,7 +86,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
-->
## 创建 Deployment {#creating-a-deployment}
-下面是 Deployment 示例。其中创建了一个 ReplicaSet，负责启动三个 `nginx` Pods：
+下面是一个 Deployment 示例。其中创建了一个 ReplicaSet，负责启动三个 `nginx` Pods：
{{< codenew file="controllers/nginx-deployment.yaml" >}}
@@ -125,17 +127,17 @@ In this example:
* `template` 字段包含以下子字段：
- * Pod 被使用 `labels` 字段打上 `app: nginx` 标签。
+ * Pod 被使用 `.metadata.labels` 字段打上 `app: nginx` 标签。
* Pod 模板规约（即 `.template.spec` 字段）指示 Pods 运行一个 `nginx` 容器，
该容器运行版本为 1.14.2 的 `nginx` [Docker Hub](https://hub.docker.com/)镜像。
- * 创建一个容器并使用 `name` 字段将其命名为 `nginx`。
+ * 创建一个容器并使用 `.spec.template.spec.containers[0].name` 字段将其命名为 `nginx`。
- {{< note >}}
- 你可以设置 `--record` 标志将所执行的命令写入资源注解 `kubernetes.io/change-cause` 中。
- 这对于以后的检查是有用的。例如，要查看针对每个 Deployment 修订版本所执行过的命令。
- {{< /note >}}
-2. 运行 `kubectl get deployments` 检查 Deployment 是否已创建。如果仍在创建 Deployment，
- 则输出类似于：
+2. 运行 `kubectl get deployments` 检查 Deployment 是否已创建。
+ 如果仍在创建 Deployment，则输出类似于：
```
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- nginx-deployment 3 0 0 0 1s
+ NAME READY UP-TO-DATE AVAILABLE AGE
+ nginx-deployment 0/3 0 0 1s
```
* `NAME` 列出了集群中 Deployment 的名称。
- * `READY` 显示应用程序的可用的 _副本_ 数。显示的模式是“就绪个数/期望个数”。
+ * `READY` 显示应用程序的可用的“副本”数。显示的模式是“就绪个数/期望个数”。
* `UP-TO-DATE` 显示为了达到期望状态已经更新的副本数。
* `AVAILABLE` 显示应用可供用户使用的副本数。
* `AGE` 显示应用程序运行的时间。
@@ -216,8 +211,8 @@ Follow the steps given below to create the above Deployment:
4. 几秒钟后再次运行 `kubectl get deployments`。输出类似于：
```
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- nginx-deployment 3 3 3 3 18s
+ NAME READY UP-TO-DATE AVAILABLE AGE
+ nginx-deployment 3/3 3 3 18s
```
注意 ReplicaSet 的名称始终被格式化为`[Deployment名称]-[随机字符串]`。
- 其中的随机字符串是使用 pod-template-hash 作为种子随机生成的。
+ 其中的随机字符串是使用 `pod-template-hash` 作为种子随机生成的。
6. 要查看每个 Pod 自动生成的标签，运行 `kubectl get pods --show-labels`。返回以下输出：
@@ -279,17 +275,17 @@ Follow the steps given below to create the above Deployment:
-->
所创建的 ReplicaSet 确保总是存在三个 `nginx` Pod。
-
{{< note >}}
+
你必须在 Deployment 中指定适当的选择算符和 Pod 模板标签（在本例中为 `app: nginx`）。
标签或者选择算符不要与其他控制器（包括其他 Deployment 和 StatefulSet）重叠。
-Kubernetes 不会阻止你这样做，但是如果多个控制器具有重叠的选择算符，它们可能会发生冲突
-执行难以预料的操作。
+Kubernetes 不会阻止你这样做，但是如果多个控制器具有重叠的选择算符，
+它们可能会发生冲突执行难以预料的操作。
{{< /note >}}
### Pod-template-hash 标签
-
{{< note >}}
+
不要更改此标签。
{{< /note >}}
-Deployment 控制器将 `pod-template-hash` 标签添加到 Deployment 所创建或收留的
-每个 ReplicaSet 。
+Deployment 控制器将 `pod-template-hash` 标签添加到 Deployment
+所创建或收留的每个 ReplicaSet 。
## 更新 Deployment {#updating-a-deployment}
+{{< note >}}
-{{< note >}}
仅当 Deployment Pod 模板（即 `.spec.template`）发生改变时，例如模板的标签或容器镜像被更新，
-才会触发 Deployment 上线。
-其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作。
+才会触发 Deployment 上线。其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作。
{{< /note >}}
按照以下步骤更新 Deployment：
@@ -344,8 +340,7 @@ is changed, for example if the labels or container images of the template are up
1. 先来更新 nginx Pod 以使用 `nginx:1.16.1` 镜像，而不是 `nginx:1.14.2` 镜像。
```shell
- kubectl --record deployment.apps/nginx-deployment set image \
- deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+ kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
```
- 输出类似于：
-
- ```
- deployment.apps/nginx-deployment image updated
+ kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
```
- 或者，可以 `edit` Deployment 并将 `.spec.template.spec.containers[0].image` 从
- `nginx:1.14.2` 更改至 `nginx:1.16.1`。
-
- ```shell
- kubectl edit deployment.v1.apps/nginx-deployment
- ```
-
-
输出类似于：
```
- deployment.apps/nginx-deployment edited
+ deployment/nginx-deployment image updated
+ ```
+
+
+ 或者，可以对 Deployment 执行 `edit` 操作并将 `.spec.template.spec.containers[0].image` 从
+ `nginx:1.14.2` 更改至 `nginx:1.16.1`。
+
+ ```shell
+ kubectl edit deployment/nginx-deployment
+ ```
+
+
+ 输出类似于：
+
+ ```
+ deployment/nginx-deployment edited
```
+
输出类似于：
```
@@ -414,9 +415,9 @@ Get more details on your updated Deployment:
* 在上线成功后，可以通过运行 `kubectl get deployments` 来查看 Deployment：
输出类似于：
- ```shell
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- nginx-deployment 3 3 3 3 36s
+ ```ini
+ NAME READY UP-TO-DATE AVAILABLE AGE
+ nginx-deployment 3/3 3 3 36s
```
+
输出类似于：
```
@@ -448,7 +451,9 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
kubectl get pods
```
-
+
输出类似于：
```
@@ -480,12 +485,14 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
For example, if you look at the above Deployment closely, you will see that it first created a new Pod,
then deleted some old Pods, and created new ones. It does not kill old Pods until a sufficient number of
new Pods have come up, and does not create new Pods until a sufficient number of old Pods have been killed.
- It makes sure that at least 2 Pods are available and that at max 4 Pods in total are available.
+ It makes sure that at least 2 Pods are available and that at max 4 Pods in total are available. In case of
+ a Deployment with 4 replicas, the number of Pods would be between 3 and 5.
-->
例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除了一些旧的 Pods，
并创建了新的 Pods。它不会杀死老 Pods，直到有足够的数量新的 Pods 已经出现。
- 在足够数量的旧 Pods 被杀死前并没有创建新 Pods。它确保至少 2 个 Pod 可用，同时
- 最多总共 4 个 Pod 可用。
+ 在足够数量的旧 Pods 被杀死前并没有创建新 Pods。它确保至少 2 个 Pod 可用，
+ 同时最多总共 4 个 Pod 可用。
+ 当 Deployment 设置为 4 个副本时，Pod 的个数会介于 3 和 5 之间。
+
输出类似于：
```
@@ -541,18 +550,33 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
- 可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet（nginx-deployment-2035384211）
+ 可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet（`nginx-deployment-2035384211`）
并将其直接扩容至 3 个副本。更新 Deployment 时，它创建了一个新的 ReplicaSet
- （nginx-deployment-1564180365），并将其扩容为 1，然后将旧 ReplicaSet 缩容到 2，
- 以便至少有 2 个 Pod 可用且最多创建 4 个 Pod。
+ （nginx-deployment-1564180365），并将其扩容为 1，等待其就绪；然后将旧 ReplicaSet 缩容到 2，
+ 将新的 ReplicaSet 扩容到 2 以便至少有 3 个 Pod 可用且最多创建 4 个 Pod。
然后，它使用相同的滚动更新策略继续对新的 ReplicaSet 扩容并对旧的 ReplicaSet 缩容。
最后，你将有 3 个可用的副本在新的 ReplicaSet 中，旧 ReplicaSet 将缩容到 0。
+{{< note >}}
+
+Kubernetes 在计算 `availableReplicas` 数值时不考虑终止过程中的 Pod，
+`availableReplicas` 的值一定介于 `replicas - maxUnavailable` 和 `replicas + maxSurge` 之间。
+因此，你可能在上线期间看到 Pod 个数比预期的多，Deployment 所消耗的总的资源也大于
+`replicas + maxSurge` 个 Pod 所用的资源，直到被终止的 Pod 所设置的
+`terminationGracePeriodSeconds` 到期为止。
+{{< /note >}}
+
-### 更改标签选择算符
+### 更改标签选择算符 {#label-selector-updates}
通常不鼓励更新标签选择算符。建议你提前规划选择算符。
-在任何情况下，如果需要更新标签选择算符，请格外小心，并确保自己了解
-这背后可能发生的所有事情。
+在任何情况下，如果需要更新标签选择算符，请格外小心，
+并确保自己了解这背后可能发生的所有事情。
+{{< note >}}
-{{< note >}}
在 API 版本 `apps/v1` 中，Deployment 标签选择算符在创建后是不可变的。
{{< /note >}}
@@ -643,6 +667,7 @@ By default, all of the Deployment's rollout history is kept in the system so tha
默认情况下，Deployment 的所有上线记录都保留在系统中，以便可以随时回滚
（你可以通过修改修订历史记录限制来更改这一约束）。
+{{< note >}}
-{{< note >}}
Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版本。
这意味着仅当 Deployment 的 Pod 模板（`.spec.template`）发生更改时，才会创建新修订版本
-- 例如，模板的标签或容器镜像发生变化。
@@ -667,14 +691,14 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
`nginx:1.161` 而不是 `nginx:1.16.1`：
```shell
- kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
+ kubectl set image deployment/nginx-deployment nginx=nginx:1.161 --record=true
```
输出类似于：
- ```shell
- deployment.apps/nginx-deployment image updated
+ ```
+ deployment/nginx-deployment image updated
```
{{< note >}}
+
Deployment 控制器自动停止有问题的上线过程，并停止对新的 ReplicaSet 扩容。
这行为取决于所指定的 rollingUpdate 参数（具体为 `maxUnavailable`）。
默认情况下，Kubernetes 将此值设置为 25%。
{{< /note >}}
* 获取 Deployment 描述信息：
@@ -762,7 +784,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
输出类似于：
- ```shell
+ ```
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
@@ -822,18 +844,18 @@ Follow the steps given below to check the rollout history:
1. 首先，检查 Deployment 修订历史：
```shell
- kubectl rollout history deployment.v1.apps/nginx-deployment
+ kubectl rollout history deployment/nginx-deployment
```
输出类似于：
- ```shell
+ ```
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
- 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
- 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
- 3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
+ 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
+ 2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
+ 3 kubectl set image deployment/nginx-deployment nginx=nginx:1.161
```
- * 使用 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` 为 Deployment 添加注解。
- * 追加 `--record` 命令行标志以保存正在更改资源的 `kubectl` 命令。
+ * 使用 `kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"`
+ 为 Deployment 添加注解。
* 手动编辑资源的清单。
+
输出类似于：
- ```shell
+ ```
deployments "nginx-deployment" revision 2
Labels: app=nginx
pod-template-hash=1159050644
- Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
+ Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
Containers:
nginx:
Image: nginx:1.16.1
@@ -893,10 +916,12 @@ Follow the steps given below to rollback the Deployment from the current version
1. 假定现在你已决定撤消当前上线并回滚到以前的修订版本：
```shell
- kubectl rollout undo deployment.v1.apps/nginx-deployment
+ kubectl rollout undo deployment/nginx-deployment
```
-
+
输出类似于：
```
@@ -909,10 +934,12 @@ Follow the steps given below to rollback the Deployment from the current version
或者，你也可以通过使用 `--to-revision` 来回滚到特定修订版本：
```shell
- kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
+ kubectl rollout undo deployment/nginx-deployment --to-revision=2
```
-
+
输出类似于：
```
@@ -922,14 +949,15 @@ Follow the steps given below to rollback the Deployment from the current version
- 与回滚相关的指令的更详细信息，请参考 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)。
+ 与回滚相关的指令的更详细信息，请参考
+ [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)。
- 现在，Deployment 正在回滚到以前的稳定版本。正如你所看到的，Deployment 控制器生成了
- 回滚到修订版本 2 的 `DeploymentRollback` 事件。
+ 现在，Deployment 正在回滚到以前的稳定版本。正如你所看到的，Deployment
+ 控制器生成了回滚到修订版本 2 的 `DeploymentRollback` 事件。
+
输出类似于：
- ```shell
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- nginx-deployment 3 3 3 3 30m
+ ```
+ NAME READY UP-TO-DATE AVAILABLE AGE
+ nginx-deployment 3/3 3 3 30m
```
+
输出类似于：
```
@@ -966,7 +998,7 @@ Follow the steps given below to rollback the Deployment from the current version
CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=4
- kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
+ kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
@@ -1014,10 +1046,12 @@ You can scale a Deployment by using the following command:
你可以使用如下指令缩放 Deployment：
```shell
-kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
+kubectl scale deployment/nginx-deployment --replicas=10
```
-
+
输出类似于：
```
@@ -1030,14 +1064,16 @@ in your cluster, you can setup an autoscaler for your Deployment and choose the
Pods you want to run based on the CPU utilization of your existing Pods.
-->
假设集群启用了[Pod 的水平自动缩放](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)，
-你可以为 Deployment 设置自动缩放器，并基于现有 Pods 的 CPU 利用率选择
-要运行的 Pods 个数下限和上限。
+你可以为 Deployment 设置自动缩放器，并基于现有 Pod 的 CPU 利用率选择要运行的
+Pod 个数下限和上限。
```shell
-kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
+kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80
```
-
+
输出类似于：
```
@@ -1062,7 +1098,8 @@ Deployment 控制器会平衡现有的活跃状态的 ReplicaSets（含 Pods 的
-例如，你正在运行一个 10 个副本的 Deployment，其 [maxSurge](#max-surge)=3，[maxUnavailable](#max-unavailable)=2。
+例如，你正在运行一个 10 个副本的 Deployment，其
+[maxSurge](#max-surge)=3，[maxUnavailable](#max-unavailable)=2。
+
输出类似于：
```
@@ -1086,10 +1125,12 @@ For example, you are running a Deployment with 10 replicas, [maxSurge](#max-surg
* 更新 Deployment 使用新镜像，碰巧该镜像无法从集群内部解析。
```shell
- kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
+ kubectl set image deployment/nginx-deployment nginx=nginx:sometag
```
-
+
输出类似于：
```
@@ -1106,7 +1147,10 @@ For example, you are running a Deployment with 10 replicas, [maxSurge](#max-surg
```shell
kubectl get rs
```
-
+
+
输出类似于：
```
@@ -1142,7 +1186,10 @@ the new replicas become healthy. To confirm this, run:
```shell
kubectl get deploy
```
-
+
+
输出类似于：
```
@@ -1159,7 +1206,9 @@ The rollout status confirms how the replicas were added to each ReplicaSet.
kubectl get rs
```
-
+
输出类似于：
```shell
@@ -1169,27 +1218,37 @@ nginx-deployment-618515232 11 11 11 7m
```
-## 暂停、恢复 Deployment {#pausing-and-resuming-a-deployment}
+## 暂停、恢复 Deployment 的上线过程 {#pausing-and-resuming-a-deployment}
-你可以在触发一个或多个更新之前暂停 Deployment，然后再恢复其执行。
+在你更新一个 Deployment 的时候，或者计划更新它的时候，
+你可以在触发一个或多个更新之前暂停 Deployment 的上线过程。
+当你准备行应用这些变更时，你可以重新恢复 Deployment 上线过程。
这样做使得你能够在暂停和恢复执行之间应用多个修补程序，而不会触发不必要的上线操作。
* 例如，对于一个刚刚创建的 Deployment：
- 获取 Deployment 信息：
+
+ 获取该 Deployment 信息：
```shell
kubectl get deploy
```
-
+
+
输出类似于：
```
@@ -1197,17 +1256,21 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
nginx 3 3 3 3 1m
```
-
+
获取上线状态：
```shell
kubectl get rs
```
-
+
输出类似于：
- ```shell
+ ```
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 1m
```
@@ -1215,13 +1278,15 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
-* 使用如下指令暂停运行：
+* 使用如下指令暂停上线：
```shell
- kubectl rollout pause deployment.v1.apps/nginx-deployment
+ kubectl rollout pause deployment/nginx-deployment
```
-
+
输出类似于：
```shell
@@ -1234,10 +1299,12 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
* 接下来更新 Deployment 镜像：
```shell
- kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+ kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
```
-
+
输出类似于：
```
@@ -1250,28 +1317,30 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
* 注意没有新的上线被触发：
```shell
- kubectl rollout history deployment.v1.apps/nginx-deployment
+ kubectl rollout history deployment/nginx-deployment
```
输出类似于：
- ```shell
+ ```
deployments "nginx"
REVISION CHANGE-CAUSE
1
```
-* 获取上线状态确保 Deployment 更新已经成功：
+* 获取上线状态验证现有的 ReplicaSet 没有被更改：
```shell
kubectl get rs
```
-
+
输出类似于：
```shell
@@ -1285,10 +1354,12 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
* 你可以根据需要执行很多更新操作，例如，可以要使用的资源：
```shell
- kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
+ kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
```
-
+
输出类似于：
```
@@ -1296,25 +1367,27 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
```
- 暂停 Deployment 之前的初始状态将继续发挥作用，但新的更新在 Deployment 被
- 暂停期间不会产生任何效果。
+ 暂停 Deployment 上线之前的初始状态将继续发挥作用，但新的更新在 Deployment
+ 上线被暂停期间不会产生任何效果。
-* 最终，恢复 Deployment 执行并观察新的 ReplicaSet 的创建过程，其中包含了所应用的所有更新：
+* 最终，恢复 Deployment 上线并观察新的 ReplicaSet 的创建过程，其中包含了所应用的所有更新：
```shell
- kubectl rollout resume deployment.v1.apps/nginx-deployment
+ kubectl rollout resume deployment/nginx-deployment
```
-
- 输出：
+
+ 输出类似于这样：
- ```shell
+ ```
deployment.apps/nginx-deployment resumed
```
@@ -1327,7 +1400,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
kubectl get rs -w
```
-
+
输出类似于：
```
@@ -1357,7 +1432,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
kubectl get rs
```
-
+
输出类似于：
```
@@ -1366,10 +1443,10 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
nginx-3926361531 3 3 3 28s
```
+{{< note >}}
-{{< note >}}
你不可以回滚处于暂停状态的 Deployment，除非先恢复其执行状态。
{{< /note >}}
@@ -1396,7 +1473,7 @@ Kubernetes marks a Deployment as _progressing_ when one of the following tasks i
执行下面的任务期间，Kubernetes 标记 Deployment 为 _进行中（Progressing）_：
+当上线过程进入“Progressing”状态时，Deployment 控制器会向 Deployment 的
+`.status.conditions` 中添加包含下面属性的状况条目：
+
+* `type: Progressing`
+* `status: "True"`
+* `reason: NewReplicaSetCreated` | `reason: FoundNewReplicaSet` | `reason: ReplicaSetUpdated`
+
@@ -1430,6 +1518,25 @@ updates you've requested have been completed.
* 与 Deployment 关联的所有副本都可用。
* 未运行 Deployment 的旧副本。
+
+当上线过程进入“Complete”状态时，Deployment 控制器会向 Deployment 的
+`.status.conditions` 中添加包含下面属性的状况条目：
+
+* `type: Progressing`
+* `status: "True"`
+* `reason: NewReplicaSetAvailable`
+
+
+这一 `Progressing` 状况的状态值会持续为 `"True"`，直至新的上线动作被触发。
+即使副本的可用状态发生变化（进而影响 `Available` 状况），`Progressing` 状况的值也不会变化。
+
+
输出类似于：
```
@@ -1511,35 +1627,46 @@ deployment.apps/nginx-deployment patched
Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following
attributes to the Deployment's `.status.conditions`:
-->
-超过截止时间后，Deployment 控制器将添加具有以下属性的 DeploymentCondition 到
+超过截止时间后，Deployment 控制器将添加具有以下属性的 Deployment 状况到
Deployment 的 `.status.conditions` 中：
* Type=Progressing
* Status=False
* Reason=ProgressDeadlineExceeded
+
+这一状况也可能会比较早地失败，因而其状态值被设置为 `"False"`，
+其原因为 `ReplicaSetCreateError`。
+一旦 Deployment 上线完成，就不再考虑其期限。
+
参考
-[Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)
+[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)
获取更多状态状况相关的信息。
+{{< note >}}
-{{< note >}}
除了报告 `Reason=ProgressDeadlineExceeded` 状态之外，Kubernetes 对已停止的
Deployment 不执行任何操作。更高级别的编排器可以利用这一设计并相应地采取行动。
例如，将 Deployment 回滚到其以前的版本。
+{{< /note >}}
-如果你暂停了某个 Deployment，Kubernetes 不再根据指定的截止时间检查 Deployment 进展。
+{{< note >}}
+
+如果你暂停了某个 Deployment 上线，Kubernetes 不再根据指定的截止时间检查 Deployment 进展。
你可以在上线过程中间安全地暂停 Deployment 再恢复其执行，这样做不会导致超出最后时限的问题。
{{< /note >}}
@@ -1638,18 +1765,18 @@ Conditions:
```
-`Type=Available` 加上 `Status=True` 意味着 Deployment 具有最低可用性。
+`type: Available` 加上 `status: True` 意味着 Deployment 具有最低可用性。
最低可用性由 Deployment 策略中的参数指定。
-`Type=Progressing` 加上 `Status=True` 表示 Deployment 处于上线过程中，并且正在运行，
+`type: Progressing` 加上 `status: True` 表示 Deployment 处于上线过程中，并且正在运行，
或者已成功完成进度，最小所需新副本处于可用。
请参阅对应状况的 Reason 了解相关细节。
-在我们的案例中 `Reason=NewReplicaSetAvailable` 表示 Deployment 已完成。
+在我们的案例中 `reason: NewReplicaSetAvailable` 表示 Deployment 已完成。
### 对失败 Deployment 的操作 {#operating-on-a-failed-deployment}
@@ -1709,11 +1836,11 @@ it is 10.
Deployment 的多少个旧有 ReplicaSet。其余的 ReplicaSet 将在后台被垃圾回收。
默认情况下，此值为 10。
+{{< note >}}
-{{< note >}}
显式将此字段设置为 0 将导致 Deployment 的所有历史记录被清空，因此 Deployment 将无法回滚。
{{< /note >}}
@@ -1726,23 +1853,23 @@ can create multiple Deployments, one for each release, following the canary patt
-->
## 金丝雀部署 {#canary-deployment}
-如果要使用 Deployment 向用户子集或服务器子集上线版本，则可以遵循
-[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
+如果要使用 Deployment 向用户子集或服务器子集上线版本，
+则可以遵循[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
所描述的金丝雀模式，创建多个 Deployment，每个版本一个。
## 编写 Deployment 规约 {#writing-a-deployment-spec}
同其他 Kubernetes 配置一样， Deployment 需要 `apiVersion`，`kind` 和 `metadata` 字段。
-有关配置文件的其他信息，请参考
-[部署 Deployment ](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、配置容器和
-[使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/)等相关文档。
+有关配置文件的其他信息，请参考[部署 Deployment](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、
+配置容器和[使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/)等相关文档。
`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。
它和 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的语法规则完全相同。
@@ -1794,6 +1921,34 @@ allowed, which is the default if not specified.
`.spec.replicas` 是指定所需 Pod 的可选字段。它的默认值是1。
+
+如果你对某个 Deployment 执行了手动扩缩操作（例如，通过
+`kubectl scale deployment deployment --replicas=X`），
+之后基于清单对 Deployment 执行了更新操作（例如通过运行
+`kubectl apply -f deployment.yaml`），那么通过应用清单而完成的更新会覆盖之前手动扩缩所作的变更。
+
+
+如果一个 [HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
+（或者其他执行水平扩缩操作的类似 API）在管理 Deployment 的扩缩，
+则不要设置 `.spec.replicas`。
+
+
+恰恰相反，应该允许 Kubernetes
+{{< glossary_tooltip text="控制面" term_id="control-plane" >}}来自动管理
+`.spec.replicas` 字段。
+
在 API `apps/v1`版本中，`.spec.selector` 和 `.metadata.labels` 如果没有设置的话，
不会被默认设置为 `.spec.template.metadata.labels`，所以需要明确进行设置。
@@ -1825,14 +1980,14 @@ Pods with `.spec.template` if the number of Pods is less than the desired number
的总数超过 `.spec.replicas` 的设置时，Deployment 会终结之。
如果 Pods 总数未达到期望值，Deployment 会基于 `.spec.template` 创建新的 Pod。
+{{< note >}}
-{{< note >}}
-你不应直接创建、或者通过创建另一个 Deployment，或者创建类似 ReplicaSet
-或 ReplicationController 这类控制器来创建标签与此选择算符匹配的 Pod。
+你不应直接创建与此选择算符匹配的 Pod，也不应通过创建另一个 Deployment 或者类似于
+ReplicaSet 或 ReplicationController 这类控制器来创建标签与此选择算符匹配的 Pod。
如果这样做，第一个 Deployment 会认为它创建了这些 Pod。
Kubernetes 不会阻止你这么做。
{{< /note >}}
@@ -1864,6 +2019,23 @@ All existing Pods are killed before new ones are created when `.spec.strategy.ty
如果 `.spec.strategy.type==Recreate`，在创建新 Pods 之前，所有现有的 Pods 会被杀死。
+{{< note >}}
+
+这只会确保为了升级而创建新 Pod 之前其他 Pod 都已终止。如果你升级一个 Deployment，
+所有旧版本的 Pod 都会立即被终止。控制器等待这些 Pod 被成功移除之后，
+才会创建新版本的 Pod。如果你手动删除一个 Pod，其生命周期是由 ReplicaSet 来控制的，
+后者会立即创建一个替换 Pod（即使旧的 Pod 仍然处于 Terminating 状态）。
+如果你需要一种“最多 n 个”的 Pod 个数保证，你需要考虑使用
+[StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)。
+{{< /note >}}
+
`.spec.strategy.rollingUpdate.maxUnavailable` 是一个可选字段，用来指定
-更新过程中不可用的 Pod 的个数上限。该值可以是绝对数字（例如，5），也可以是
-所需 Pods 的百分比（例如，10%）。百分比值会转换成绝对数并去除小数部分。
+更新过程中不可用的 Pod 的个数上限。该值可以是绝对数字（例如，5），也可以是所需
+Pods 的百分比（例如，10%）。百分比值会转换成绝对数并去除小数部分。
如果 `.spec.strategy.rollingUpdate.maxSurge` 为 0，则此值不能为 0。
默认值为 25%。
@@ -1901,8 +2073,8 @@ down further, followed by scaling up the new ReplicaSet, ensuring that the total
at all times during the update is at least 70% of the desired Pods.
-->
例如，当此值设置为 30% 时，滚动更新开始时会立即将旧 ReplicaSet 缩容到期望 Pod 个数的70%。
-新 Pod 准备就绪后，可以继续缩容旧有的 ReplicaSet，然后对新的 ReplicaSet 扩容，确保在更新期间
-可用的 Pods 总数在任何时候都至少为所需的 Pod 个数的 70%。
+新 Pod 准备就绪后，可以继续缩容旧有的 ReplicaSet，然后对新的 ReplicaSet 扩容，
+确保在更新期间可用的 Pods 总数在任何时候都至少为所需的 Pod 个数的 70%。
##### 最大峰值 {#max-surge}
-`.spec.strategy.rollingUpdate.maxSurge` 是一个可选字段，用来指定可以创建的超出
-期望 Pod 个数的 Pod 数量。此值可以是绝对数（例如，5）或所需 Pods 的百分比（例如，10%）。
+`.spec.strategy.rollingUpdate.maxSurge` 是一个可选字段，用来指定可以创建的超出期望
+Pod 个数的 Pod 数量。此值可以是绝对数（例如，5）或所需 Pods 的百分比（例如，10%）。
如果 `MaxUnavailable` 为 0，则此值不能为 0。百分比值会通过向上取整转换为绝对数。
此字段的默认值为 25%。
@@ -1934,8 +2106,8 @@ total number of Pods running at any time during the update is at most 130% of de
`.spec.progressDeadlineSeconds` is an optional field that specifies the number of seconds you want
to wait for your Deployment to progress before the system reports back that the Deployment has
-[failed progressing](#failed-deployment) - surfaced as a condition with `Type=Progressing`, `Status=False`.
-and `Reason=ProgressDeadlineExceeded` in the status of the resource. The Deployment controller will keep
+[failed progressing](#failed-deployment) - surfaced as a condition with `type: Progressing`, `status: False`.
+and `reason: ProgressDeadlineExceeded` in the status of the resource. The Deployment controller will keep
retrying the Deployment. In the future, once automatic rollback will be implemented, the Deployment
controller will roll back a Deployment as soon as it observes such a condition.
-->
@@ -1943,8 +2115,8 @@ controller will roll back a Deployment as soon as it observes such a condition.
`.spec.progressDeadlineSeconds` 是一个可选字段，用于指定系统在报告 Deployment
[进展失败](#failed-deployment) 之前等待 Deployment 取得进展的秒数。
-这类报告会在资源状态中体现为 `Type=Progressing`、`Status=False`、
-`Reason=ProgressDeadlineExceeded`。Deployment 控制器将持续重试 Deployment。
+这类报告会在资源状态中体现为 `type: Progressing`、`status: False`、
+`reason: ProgressDeadlineExceeded`。Deployment 控制器将持续重试 Deployment。
将来，一旦实现了自动回滚，Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。
### 最短就绪时间 {#min-ready-seconds}
-`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间，
+`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod
+在没有任意容器崩溃情况下的最小就绪时间，
只有超出这个时间 Pod 才被视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。
-要了解何时 Pod 被视为就绪，可参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
+要了解何时 Pod 被视为就绪，
+可参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
+* 了解 [Pod](/zh/docs/concepts/workloads/pods)。
+* [使用 Deployment 运行一个无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。
+* `Deployment` 是 Kubernetes REST API 中的一个顶层资源。
+ 阅读 {{< api-reference page="workload-resources/deployment-v1" >}}
+ 对象定义，以了解 Deployment 的 API 细节。
+* 阅读 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)
+ 了解如何使用它来在可能出现干扰的情况下管理应用的可用性。
+
From e0302f46f2d1f9a386fa6646f548caae37da47a5 Mon Sep 17 00:00:00 2001
From: Qiming Teng
Date: Sun, 10 Apr 2022 18:27:36 +0800
Subject: [PATCH 073/167] [zh] Resync nodes page
---
.../zh/docs/concepts/architecture/nodes.md | 570 ++++++++++++------
1 file changed, 390 insertions(+), 180 deletions(-)
diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md
index 11fbc9294b..68ffb345b1 100644
--- a/content/zh/docs/concepts/architecture/nodes.md
+++ b/content/zh/docs/concepts/architecture/nodes.md
@@ -52,21 +52,20 @@ There are two main ways to have Nodes added to the {{< glossary_tooltip text="AP
1. The kubelet on a node self-registers to the control plane
2. You, or another human user, manually add a Node object
-After you create a Node object, or the kubelet on a node self-registers, the
-control plane checks whether the new Node object is valid. For example, if you
-try to create a Node from the following JSON manifest:
+After you create a Node {{< glossary_tooltip text="object" term_id="object" >}},
+or the kubelet on a node self-registers, the control plane checks whether the new Node object is
+valid. For example, if you try to create a Node from the following JSON manifest:
-->
## 管理 {#management}
-向 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver"
->}}添加节点的方式主要有两种：
+向 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}添加节点的方式主要有两种：
1. 节点上的 `kubelet` 向控制面执行自注册；
2. 你，或者别的什么人，手动添加一个 Node 对象。
-在你创建了 Node 对象或者节点上的 `kubelet` 执行了自注册操作之后，
-控制面会检查新的 Node 对象是否合法。例如，如果你使用下面的 JSON
-对象来创建 Node 对象：
+在你创建了 Node {{< glossary_tooltip text="object" term_id="object" >}}或者节点上的
+`kubelet` 执行了自注册操作之后，控制面会检查新的 Node 对象是否合法。
+例如，如果你尝试使用下面的 JSON 对象来创建 Node 对象：
```json
{
@@ -93,13 +92,14 @@ Kubernetes 会在内部创建一个 Node 对象作为节点的表示。Kubernete
如果节点是健康的（即所有必要的服务都在运行中），则该节点可以用来运行 Pod。
否则，直到该节点变为健康之前，所有的集群活动都会忽略该节点。
+{{< note >}}
-{{< note >}}
Kubernetes 会一直保存着非法节点对应的对象，并持续检查该节点是否已经
变得健康。
你，或者某个{{< glossary_tooltip term_id="controller" text="控制器">}}必需显式地
@@ -113,6 +113,27 @@ The name of a Node object must be a valid
Node 对象的名称必须是合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+
+### 节点名称唯一性 {#node-name-uniqueness}
+
+节点的[名称](/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。
+没有两个 Node 可以同时使用相同的名称。 Kubernetes 还假定名字相同的资源是同一个对象。
+就 Node 而言，隐式假定使用相同名称的实例会具有相同的状态（例如网络配置、根磁盘内容）
+和类似节点标签这类属性。这可能在节点被更改但其名称未变时导致系统状态不一致。
+如果某个 Node 需要被替换或者大量变更，需要从 API 服务器移除现有的 Node 对象，
+之后再在更新之后重新将其加入。
+
- - `--kubeconfig` - 用于向 API 服务器表明身份的凭据路径。
- - `--cloud-provider` - 与某{{< glossary_tooltip text="云驱动" term_id="cloud-provider" >}}
- 进行通信以读取与自身相关的元数据的方式。
- - `--register-node` - 自动向 API 服务注册。
- - `--register-with-taints` - 使用所给的污点列表（逗号分隔的 `=:`）注册节点。
- 当 `register-node` 为 false 时无效。
- - `--node-ip` - 节点 IP 地址。
- - `--node-labels` - 在集群中注册节点时要添加的
- {{< glossary_tooltip text="标签" term_id="label" >}}。
- （参见 [NodeRestriction 准入控制插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。
- - `--node-status-update-frequency` - 指定 kubelet 向控制面发送状态的频率。
+- `--kubeconfig` - 用于向 API 服务器执行身份认证所用的凭据的路径。
+- `--cloud-provider` - 与某{{< glossary_tooltip text="云驱动" term_id="cloud-provider" >}}
+ 进行通信以读取与自身相关的元数据的方式。
+- `--register-node` - 自动向 API 服务注册。
+- `--register-with-taints` - 使用所给的{{< glossary_tooltip text="污点" term_id="taint" >}}列表
+ （逗号分隔的 `=:`）注册节点。当 `register-node` 为 false 时无效。
+- `--node-ip` - 节点 IP 地址。
+- `--node-labels` - 在集群中注册节点时要添加的{{< glossary_tooltip text="标签" term_id="label" >}}。
+ （参见 [NodeRestriction 准入控制插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。
+- `--node-status-update-frequency` - 指定 kubelet 向控制面发送状态的频率。
-启用[节点授权模式](/zh/docs/reference/access-authn-authz/node/)和
+启用[Node 鉴权模式](/zh/docs/reference/access-authn-authz/node/)和
[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
时，仅授权 `kubelet` 创建或修改其自己的节点资源。
+{{< note >}}
+
+正如[节点名称唯一性](#node-name-uniqueness)一节所述，当 Node 的配置需要被更新时，
+一种好的做法是重新向 API 服务器注册该节点。例如，如果 kubelet 重启时其 `--node-labels`
+是新的值集，但同一个 Node 名称已经被使用，则所作变更不会起作用，
+因为节点标签是在 Node 注册时完成的。
+
+
+如果在 kubelet 重启期间 Node 配置发生了变化，已经被调度到某 Node 上的 Pod
+可能会出现行为不正常或者出现其他问题，例如，已经运行的 Pod
+可能通过污点机制设置了与 Node 上新设置的标签相排斥的规则，也有一些其他 Pod，
+本来与此 Pod 之间存在不兼容的问题，也会因为新的标签设置而被调到到同一节点。
+节点重新注册操作可以确保节点上所有 Pod 都被排空并被正确地重新调度。
+{{< /note >}}
+
-你可以结合使用节点上的标签和 Pod 上的选择算符来控制调度。
+你可以结合使用 Node 上的标签和 Pod 上的选择算符来控制调度。
例如，你可以限制某 Pod 只能在符合要求的节点子集上运行。
-如果标记节点为不可调度（unschedulable），将阻止新 Pod 调度到该节点之上，但不会
-影响任何已经在其上的 Pod。
+如果标记节点为不可调度（unschedulable），将阻止新 Pod 调度到该 Node 之上，
+但不会影响任何已经在其上的 Pod。
这是重启节点或者执行其他维护操作之前的一个有用的准备步骤。
-要标记一个节点为不可调度，执行以下命令：
+要标记一个 Node 为不可调度，执行以下命令：
```shell
kubectl cordon $NODENAME
```
+
更多细节参考[安全腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。
+{{< note >}}
-{{< note >}}
被 {{< glossary_tooltip term_id="daemonset" text="DaemonSet" >}} 控制器创建的 Pod
能够容忍节点的不可调度属性。
-DaemonSet 通常提供节点本地的服务，即使节点上的负载应用已经被腾空，这些服务也仍需
-运行在节点之上。
+DaemonSet 通常提供节点本地的服务，即使节点上的负载应用已经被腾空，
+这些服务也仍需运行在节点之上。
{{< /note >}}
-* HostName：由节点的内核设置。可以通过 kubelet 的 `--hostname-override` 参数覆盖。
+* HostName：由节点的内核报告。可以通过 kubelet 的 `--hostname-override` 参数覆盖。
* ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。
* InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。
@@ -301,14 +350,14 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` |
{{< /table >}}
+{{< note >}}
-{{< note >}}
-如果使用命令行工具来打印已保护（Cordoned）节点的细节，其中的 Condition 字段可能
-包括 `SchedulingDisabled`。`SchedulingDisabled` 不是 Kubernetes API 中定义的
+如果使用命令行工具来打印已保护（Cordoned）节点的细节，其中的 Condition 字段可能包括
+`SchedulingDisabled`。`SchedulingDisabled` 不是 Kubernetes API 中定义的
Condition，被保护起来的节点在其规约中被标记为不可调度（Unschedulable）。
{{< /note >}}
@@ -340,16 +389,20 @@ than the `pod-eviction-timeout` (an argument passed to the
{{< glossary_tooltip text="API-initiated eviction" term_id="api-eviction" >}}
for all Pods assigned to that node. The default eviction timeout duration is
**five minutes**.
+-->
+如果 Ready 状况的 `status` 处于 `Unknown` 或者 `False` 状态的时间超过了
+`pod-eviction-timeout` 值（一个传递给
+{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
+的参数），[节点控制器](#node-controller) 会对节点上的所有 Pod 触发
+{{< glossary_tooltip text="API-发起的驱逐" term_id="api-eviction" >}}。
+默认的逐出超时时长为 **5 分钟**。
+
+
-如果 Ready 条件的 `status` 处于 `Unknown` 或者 `False` 状态的时间超过了 `pod-eviction-timeout` 值，
-（一个传递给 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} 的参数），
-[节点控制器](#node-controller) 会对节点上的所有 Pod 触发
-{{< glossary_tooltip text="API-发起的驱逐" term_id="api-eviction" >}}。
-默认的逐出超时时长为 **5 分钟**。
某些情况下，当节点不可达时，API 服务器不能和其上的 kubelet 通信。
删除 Pod 的决定不能传达给 kubelet，直到它重新建立和 API 服务器的连接为止。
与此同时，被计划删除的 Pod 可能会继续在游离的节点上运行。
@@ -370,15 +423,24 @@ names.
从 Kubernetes 删除节点对象将导致 API 服务器删除节点上所有运行的 Pod 对象并释放它们的名字。
-节点生命周期控制器会自动创建代表状况的
+当节点上出现问题时，Kubernetes 控制面会自动创建与影响节点的状况对应的
[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
-当调度器将 Pod 指派给某节点时，会考虑节点上的污点。
-Pod 则可以通过容忍度（Toleration）表达所能容忍的污点。
+调度器在将 Pod 指派到某 Node 时会考虑 Node 上的污点设置。
+Pod 也可以设置{{< glossary_tooltip text="容忍度" term_id="toleration" >}}，
+以便能够在设置了特定污点的 Node 上运行。
+
+
+进一步的细节可参阅[根据状况为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)。
-### 容量与可分配 {#capacity}
+### 容量（Capacity）与可分配（Allocatable） {#capacity}
-描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。
+这两个值描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。
-### 信息 {#info}
+### 信息（Info） {#info}
-描述节点的一般信息，如内核版本、Kubernetes 版本（`kubelet` 和 `kube-proxy` 版本）、
+Info 指的是节点的一般信息，如内核版本、Kubernetes 版本（`kubelet` 和 `kube-proxy` 版本）、
容器运行时详细信息，以及 节点使用的操作系统。
`kubelet` 从节点收集这些信息并将其发布到 Kubernetes API。
+## 心跳 {#heartbeats}
+Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性，并在检测到故障时采取行动。
+对于节点，有两种形式的心跳:
+
+
+* 更新节点的 `.status`
+* `kube-node-lease` {{}}中的
+ [Lease（租约）](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)对象。
+ 每个节点都有一个关联的 Lease 对象。
+
+与 Node 的 `.status` 更新相比，Lease 是一种轻量级资源。
+使用 Lease 来表达心跳在大型集群中可以减少这些更新对性能的影响。
+kubelet 负责创建和更新节点的 `.status`，以及更新它们对应的 Lease。
+
+
-## 心跳 {#heartbeats}
-Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性，并在检测到故障时采取行动。
-
-对于节点，有两种形式的心跳:
-
-* 更新节点的 `.status`
-* [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 对象
- 在 `kube-node-lease` {{}}中。
- 每个节点都有一个关联的 Lease 对象。
-
-与 Node 的 `.status` 更新相比，`Lease` 是一种轻量级资源。
-使用 `Leases` 心跳在大型集群中可以减少这些更新对性能的影响。
-
-kubelet 负责创建和更新节点的 `.status`，以及更新它们对应的 `Lease`。
-
-- 当状态发生变化时，或者在配置的时间间隔内没有更新事件时，kubelet 会更新 `.status`。
- `.status` 更新的默认间隔为 5 分钟（比不可达节点的 40 秒默认超时时间长很多）。
-- `kubelet` 会每 10 秒（默认更新间隔时间）创建并更新其 `Lease` 对象。
- `Lease` 更新独立于 `NodeStatus` 更新而发生。
- 如果 `Lease` 的更新操作失败，`kubelet` 会采用指数回退机制，从 200 毫秒开始
- 重试，最长重试间隔为 7 秒钟。
+- 当节点状态发生变化时，或者在配置的时间间隔内没有更新事件时，kubelet 会更新 `.status`。
+ `.status` 更新的默认间隔为 5 分钟（比节点不可达事件的 40 秒默认超时时间长很多）。
+- `kubelet` 会创建并每 10 秒（默认更新间隔时间）更新 Lease 对象。
+ Lease 的更新独立于 Node 的 `.status` 更新而发生。
+ 如果 Lease 的更新操作失败，kubelet 会采用指数回退机制，从 200 毫秒开始重试，
+ 最长重试间隔为 7 秒钟。
## 节点控制器 {#node-controller}
-节点{{< glossary_tooltip text="控制器" term_id="controller" >}}是
-Kubernetes 控制面组件，管理节点的方方面面。
+节点{{< glossary_tooltip text="控制器" term_id="controller" >}}是 Kubernetes 控制面组件，
+管理节点的方方面面。
节点控制器在节点的生命周期中扮演多个角色。
第一个是当节点注册时为它分配一个 CIDR 区段（如果启用了 CIDR 分配）。
@@ -505,6 +569,7 @@ controller deletes the node from its list of nodes.
-第三个是监控节点的健康状况。 节点控制器是负责：
-- 在节点节点不可达的情况下，在 Node 的 `.status` 中更新 `NodeReady` 状况。
- 在这种情况下，节点控制器将 `NodeReady` 状况更新为 `ConditionUnknown` 。
-- 如果节点仍然无法访问：对于不可达节点上的所有 Pod触发
+第三个是监控节点的健康状况。节点控制器负责：
+
+- 在节点不可达的情况下，在 Node 的 `.status` 中更新 NodeReady 状况。
+ 在这种情况下，节点控制器将 NodeReady 状况更新为 `Unknown` 。
+- 如果节点仍然无法访问：对于不可达节点上的所有 Pod 触发
[API-发起的逐出](/zh/docs/concepts/scheduling-eviction/api-eviction/)。
- 默认情况下，节点控制器 在将节点标记为 `ConditionUnknown` 后等待 5 分钟 提交第一个驱逐请求。
+ 默认情况下，节点控制器在将节点标记为 `Unknown` 后等待 5 分钟提交第一个驱逐请求。
节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。
@@ -542,29 +608,33 @@ The node eviction behavior changes when a node in a given availability zone
becomes unhealthy. The node controller checks what percentage of nodes in the zone
are unhealthy (NodeReady condition is `ConditionUnknown` or `ConditionFalse`) at
the same time:
+-->
+当一个可用区域（Availability Zone）中的节点变为不健康时，节点的驱逐行为将发生改变。
+节点控制器会同时检查可用区域中不健康（NodeReady 状况为 `Unknown` 或 `False`）
+的节点的百分比：
+
+
+- 如果不健康节点的比例超过 `--unhealthy-zone-threshold` （默认为 0.55），
+ 驱逐速率将会降低。
+- 如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个节点 - 默认为 50），
+ 驱逐操作将会停止。
+- 否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。
+
-当一个可用区域（Availability Zone）中的节点变为不健康时，节点的驱逐行为将发生改变。
-节点控制器会同时检查可用区域中不健康（NodeReady 状况为 `ConditionUnknown` 或 `ConditionFalse`）
-的节点的百分比：
-- 如果不健康节点的比例超过 `--unhealthy-zone-threshold` （默认为 0.55），
-驱逐速率将会降低。
-- 如果集群较小（意即小于等于 `--large-cluster-size-threshold`
-个节点 - 默认为 50），驱逐操作将会停止。
-- 否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。
-
-在单个可用区域实施这些策略的原因是当一个可用区域可能从控制面脱离时其它可用区域
-可能仍然保持连接。
+在逐个可用区域中实施这些策略的原因是，
+当一个可用区域可能从控制面脱离时其它可用区域可能仍然保持连接。
如果你的集群没有跨越云服务商的多个可用区域，那（整个集群）就只有一个可用区域。
节点控制器还负责驱逐运行在拥有 `NoExecute` 污点的节点上的 Pod，
除非这些 Pod 能够容忍此污点。
-节点控制器还负责根据节点故障（例如节点不可访问或没有就绪）为其添加
-{{< glossary_tooltip text="污点" term_id="taint" >}}。
+节点控制器还负责根据节点故障（例如节点不可访问或没有就绪）
+为其添加{{< glossary_tooltip text="污点" term_id="taint" >}}。
这意味着调度器不会将 Pod 调度到不健康的节点上。
-Kubernetes {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}保证节点上
-有足够的资源供其上的所有 Pod 使用。它会检查节点上所有容器的请求的总和不会超过节点的容量。
+Kubernetes {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}
+保证节点上有足够的资源供其上的所有 Pod 使用。
+它会检查节点上所有容器的请求的总和不会超过节点的容量。
总的请求包括由 kubelet 启动的所有容器，但不包括由容器运行时直接启动的容器，
也不包括不受 `kubelet` 控制的其他进程。
+{{< note >}}
-{{< note >}}
-如果要为非 Pod 进程显式保留资源。请参考
-[为系统守护进程预留资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。
+如果要为非 Pod 进程显式保留资源。
+请参考[为系统守护进程预留资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。
{{< /note >}}
如果启用了 `TopologyManager` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
`kubelet` 可以在作出资源分配决策时使用拓扑提示。
-参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
-了解详细信息。
+参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)了解详细信息。
kubelet 会尝试检测节点系统关闭事件并终止在节点上运行的 Pods。
-在节点终止期间，kubelet 保证 Pod 遵从常规的 [Pod 终止流程](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
+在节点终止期间，kubelet 保证 Pod 遵从常规的
+[Pod 终止流程](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
体面节点关闭特性依赖于 systemd，因为它要利用
-[systemd 抑制器锁](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)
+[systemd 抑制器锁](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)机制，
在给定的期限内延迟节点关闭。
体面节点关闭特性受 `GracefulNodeShutdown`
-[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)
-控制，在 1.21 版本中是默认启用的。
+[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)控制，
+在 1.21 版本中是默认启用的。
注意，默认情况下，下面描述的两个配置选项，`ShutdownGracePeriod` 和
-`ShutdownGracePeriodCriticalPods` 都是被设置为 0 的，因此不会激活
-体面节点关闭功能。
+`ShutdownGracePeriodCriticalPods` 都是被设置为 0 的，因此不会激活体面节点关闭功能。
要激活此功能特性，这两个 kubelet 配置选项要适当配置，并设置为非零值。
-在体面关闭节点过程中，kubelet 分两个阶段来终止 Pods：
+在体面关闭节点过程中，kubelet 分两个阶段来终止 Pod：
1. 终止在节点上运行的常规 Pod。
2. 终止在节点上运行的[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
@@ -723,11 +795,10 @@ Graceful Node Shutdown feature is configured with two [`KubeletConfiguration`](/
[`KubeletConfiguration`](/zh/docs/tasks/administer-cluster/kubelet-config-file/) 选项：
* `ShutdownGracePeriod`：
- * 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod 还是
- [关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
+ * 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod
+ 还是[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
* `ShutdownGracePeriodCriticalPods`：
- * 在节点关闭期间指定用于终止
- [关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
+ * 在节点关闭期间指定用于终止[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
的持续时间。该值应小于 `ShutdownGracePeriod`。
-
{{< note >}}
-当 Pod 在正常节点关闭期间被驱逐时，它们会被标记为 `failed`。
-运行 `kubectl get pods` 将被驱逐的 pod 的状态显示为 `Shutdown`。
-并且 `kubectl describe pod` 表示 pod 因节点关闭而被驱逐：
+当 Pod 在正常节点关闭期间被驱逐时，它们会被标记为已经失败（Failed）。
+运行 `kubectl get pods` 时，被驱逐的 Pod 的状态显示为 `Shutdown`。
+并且 `kubectl describe pod` 表示 Pod 因节点关闭而被驱逐：
```
-Status: Failed
-Reason: Shutdown
-Message: Node is shutting, evicting pods
+Reason: Terminated
+Message: Pod was terminated in response to imminent node shutdown.
```
-
-`Failed` 的 pod 对象将被保留，直到被明确删除或
-[由 GC 清理](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)。
-与突然的节点终止相比这是一种行为变化。
{{< /note >}}
+
+### 基于 Pod 优先级的体面节点关闭 {#pod-priority-graceful-node-shutdown}
+
+{{< feature-state state="alpha" for_k8s_version="v1.23" >}}
+
+
+为了在体面节点关闭期间提供更多的灵活性，尤其是处理关闭期间的 Pod 排序问题，
+体面节点关闭机制能够关注 Pod 的 PriorityClass 设置，前提是你已经在集群中启用了此功能特性。
+此功能特性允许集群管理员基于 Pod
+的[优先级类（Priority Class）](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)
+显式地定义体面节点关闭期间 Pod 的处理顺序。
+
+
+前文所述的[体面节点关闭](#graceful-node-shutdown)特性能够分两个阶段关闭 Pod，
+首先关闭的是非关键的 Pod，之后再处理关键 Pod。
+如果需要显式地以更细粒度定义关闭期间 Pod 的处理顺序，需要一定的灵活度，
+这时可以使用基于 Pod 优先级的体面关闭机制。
+
+
+当体面节点关闭能够处理 Pod 优先级时，体面节点关闭的处理可以分为多个阶段，
+每个阶段关闭特定优先级类的 Pod。kubelet 可以被配置为按确切的阶段处理 Pod，
+且每个阶段可以独立设置关闭时间。
+
+
+假设集群中存在以下自定义的 Pod
+[优先级类](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)。
+
+| Pod 优先级类名称 | Pod 优先级类数值 |
+|-------------------------|------------------------|
+|`custom-class-a` | 100000 |
+|`custom-class-b` | 10000 |
+|`custom-class-c` | 1000 |
+|`regular/unset` | 0 |
+
+
+在 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)中，
+`shutdownGracePeriodByPodPriority` 可能看起来是这样：
+
+| Pod 优先级类数值 | 关闭期限 |
+|------------------------|-----------|
+| 100000 | 10 秒 |
+| 10000 | 180 秒 |
+| 1000 | 120 秒 |
+| 0 | 60 秒 |
+
+
+对应的 kubelet 配置 YAML 将会是：
+
+```yaml
+shutdownGracePeriodByPodPriority:
+ - priority: 100000
+ shutdownGracePeriodSeconds: 10
+ - priority: 10000
+ shutdownGracePeriodSeconds: 180
+ - priority: 1000
+ shutdownGracePeriodSeconds: 120
+ - priority: 0
+ shutdownGracePeriodSeconds: 60
+```
+
+
+上面的表格表明，所有 `priority` 值大于等于 100000 的 Pod 会得到 10 秒钟期限停止，
+所有 `priority` 值介于 10000 和 100000 之间的 Pod 会得到 180 秒钟期限停止，
+所有 `priority` 值介于 1000 和 10000 之间的 Pod 会得到 120 秒钟期限停止，
+所有其他 Pod 将获得 60 秒的时间停止。
+
+用户不需要为所有的优先级类都设置数值。例如，你也可以使用下面这种配置：
+
+| Pod 优先级类数值 | 关闭期限 |
+|------------------------|-----------|
+| 100000 | 300 秒 |
+| 1000 | 120 秒 |
+| 0 | 60 秒 |
+
+
+在上面这个场景中，优先级类为 `custom-class-b` 的 Pod 会与优先级类为 `custom-class-c`
+的 Pod 在关闭时按相同期限处理。
+
+如果在特定的范围内不存在 Pod，则 kubelet 不会等待对应优先级范围的 Pod。
+kubelet 会直接跳到下一个优先级数值范围进行处理。
+
+
+如果此功能特性被启用，但没有提供配置数据，则不会出现排序操作。
+
+使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority` 功能特性，
+并将 kubelet 配置中的 `ShutdownGracePeriodByPodPriority` 设置为期望的配置，
+其中包含 Pod 的优先级类数值以及对应的关闭期限。
+
+
+kubelet 子系统中会生成 `graceful_shutdown_start_time_seconds` 和
+`graceful_shutdown_end_time_seconds` 度量指标以便监视节点关闭行为。
+
## 交换内存管理 {#swap-memory}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
-在 Kubernetes 1.22 之前，节点不支持使用交换内存，并且
-默认情况下，如果在节点上检测到交换内存配置，kubelet 将无法启动。 在 1.22
-以后，可以在每个节点的基础上启用交换内存支持。
+
+在 Kubernetes 1.22 之前，节点不支持使用交换内存，并且默认情况下，
+如果在节点上检测到交换内存配置，kubelet 将无法启动。
+在 1.22 以后，可以逐个节点地启用交换内存支持。
+
要在节点上启用交换内存，必须启用kubelet 的 `NodeSwap` 特性门控，
- 同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn`
+同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn`
[配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
-设置为false。
+设置为 false。
-用户还可以选择配置 `memorySwap.swapBehavior` 以指定节点使用交换内存的方式。 例如:
+
+用户还可以选择配置 `memorySwap.swapBehavior` 以指定节点使用交换内存的方式。例如:
```yaml
memorySwap:
@@ -818,41 +1026,43 @@ The available configuration options for `swapBehavior` are:
use. Workloads on the node not managed by Kubernetes can still swap.
- `UnlimitedSwap`: Kubernetes workloads can use as much swap memory as they
request, up to the system limit.
+-->
+可用的 `swapBehavior` 的配置选项有：
+- `LimitedSwap`：Kubernetes 工作负载的交换内存会受限制。
+ 不受 Kubernetes 管理的节点上的工作负载仍然可以交换。
+- `UnlimitedSwap`：Kubernetes 工作负载可以使用尽可能多的交换内存请求，
+ 一直到达到系统限制为止。
+
+
+如果启用了特性门控但是未指定 `memorySwap` 的配置，默认情况下 kubelet 将使用
+`LimitedSwap` 设置。
+`LimitedSwap` 这种设置的行为取决于节点运行的是 v1 还是 v2 的控制组（也就是 `cgroups`）：
+
+
+- **cgroupsv1:** Kubernetes 工作负载可以使用内存和交换，上限为 Pod 的内存限制值（如果设置了的话）。
+- **cgroupsv2:** Kubernetes 工作负载不能使用交换内存。
+
-已有的 `swapBehavior` 的配置选项有：
-
-- `LimitedSwap`：Kubernetes 工作负载的交换内存会受限制。
- 不受 Kubernetes 管理的节点上的工作负载仍然可以交换。
-- `UnlimitedSwap`：Kubernetes 工作负载可以使用尽可能多的交换内存
- 请求，一直到系统限制。
-
-如果启用了特性门控但是未指定 `memorySwap` 的配置，默认情况下 kubelet 将使用
-`LimitedSwap` 设置。
-
-`LimitedSwap` 设置的行为还取决于节点运行的是 v1 还是 v2 的控制组（也就是 `cgroups`）：
-
-- **cgroupsv1:** Kubernetes 工作负载可以使用内存和
- 交换，达到 pod 的内存限制（如果设置）。
-- **cgroupsv2:** Kubernetes 工作负载不能使用交换内存。
-
-如需更多信息以及协助测试和提供反馈，请
-参见 [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) 及其
-[设计方案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)。
+如需更多信息以及协助测试和提供反馈，请参见
+[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400)
+及其[设计提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)。
## {{% heading "whatsnext" %}}
@@ -863,10 +1073,10 @@ see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
section of the architecture design document.
* Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
-->
-* 了解有关节点[组件](/zh/docs/concepts/overview/components/#node-components)。
+* 进一步了解节点[组件](/zh/docs/concepts/overview/components/#node-components)。
* 阅读 [Node 的 API 定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。
* 阅读架构设计文档中有关
- [节点](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
+ [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
的章节。
* 了解[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
From 82e8574fc94fbaf996b955fedf7d17e5f8c55523 Mon Sep 17 00:00:00 2001
From: Mengjiao Liu
Date: Fri, 8 Apr 2022 19:32:14 +0800
Subject: [PATCH 074/167] [zh]Synchronize default-storage-class-prereqs.md
files and improve translations
---
content/zh/includes/default-storage-class-prereqs.md | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/content/zh/includes/default-storage-class-prereqs.md b/content/zh/includes/default-storage-class-prereqs.md
index 2ebaa45228..63a27a0d40 100644
--- a/content/zh/includes/default-storage-class-prereqs.md
+++ b/content/zh/includes/default-storage-class-prereqs.md
@@ -1,9 +1,12 @@
-您需要有一个带有默认[StorageClass](/docs/concepts/storage/storage-classes/)的动态持续卷供应程序，或者自己[静态的提供持久卷](/docs/user-guide/persistent-volumes/#provisioning)来满足这里使用的[持久卷请求](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)。
+你需要有一个带有默认 [StorageClass](/zh/docs/concepts/storage/storage-classes/)的
+[动态 PersistentVolume 供应程序](/zh/docs/concepts/storage/dynamic-provisioning/)，
+或者自己[静态的提供 PersistentVolume](/zh/docs/concepts/storage/persistent-volumes/#provisioning)
+来满足这里使用的 [PersistentVolumeClaim](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
From a21e006ebe16288b34243a27b4f534e420143f08 Mon Sep 17 00:00:00 2001
From: Mitesh Jain <47820816+miteshskj@users.noreply.github.com>
Date: Mon, 11 Apr 2022 20:47:44 +0530
Subject: [PATCH 075/167] Adding link for client library to client-libraries
page.
---
.../concepts/workloads/controllers/replicationcontroller.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
index 6a40442dc6..b55db484e0 100644
--- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -185,7 +185,7 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Kubectl wi
for it to delete each pod before deleting the ReplicationController itself. If this kubectl
command is interrupted, it can be restarted.
-When using the REST API or Go client library, you need to do the steps explicitly (scale replicas to
+When using the REST API or [client library](/docs/reference/using-api/client-libraries), you need to do the steps explicitly (scale replicas to
0, wait for pod deletions, then delete the ReplicationController).
### Deleting only a ReplicationController
@@ -194,7 +194,7 @@ You can delete a ReplicationController without affecting any of its pods.
Using kubectl, specify the `--cascade=orphan` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete).
-When using the REST API or Go client library, you can delete the ReplicationController object.
+When using the REST API or [client library](/docs/reference/using-api/client-libraries), you can delete the ReplicationController object.
Once the original is deleted, you can create a new ReplicationController to replace it. As long
as the old and new `.spec.selector` are the same, then the new one will adopt the old pods.
From bcc87b7c34546acb7a22ac2ae7968c43674466b2 Mon Sep 17 00:00:00 2001
From: Mitesh Jain <47820816+miteshskj@users.noreply.github.com>
Date: Mon, 11 Apr 2022 20:58:24 +0530
Subject: [PATCH 076/167] Remove stale information about pod dnsConfig.
---
.../concepts/services-networking/dns-pod-service.md | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md
index 4e55d8a3f4..9ca11a3457 100644
--- a/content/en/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/en/docs/concepts/services-networking/dns-pod-service.md
@@ -323,17 +323,6 @@ If the feature gate `ExpandedDNSConfig` is enabled for the kube-apiserver and
the kubelet, it is allowed for Kubernetes to have at most 32 search domains and
a list of search domains of up to 2048 characters.
-### Feature availability
-
-The availability of Pod DNS Config and DNS Policy "`None`" is shown as below.
-
-| k8s version | Feature support |
-| :---------: |:-----------:|
-| 1.14 | Stable |
-| 1.10 | Beta (on by default)|
-| 1.9 | Alpha |
-
-
## {{% heading "whatsnext" %}}
From 71b06a9973bbcc777dd5edadf94eac914862d0e7 Mon Sep 17 00:00:00 2001
From: Ldsdsy
Date: Tue, 12 Apr 2022 10:19:21 +0800
Subject: [PATCH 077/167] translate 2021-09-27-SIG-Node-Spotlight (#32847)
translate 2021-09-27-SIG-Node-Spotlight
translate 2021-09-27-SIG-Node-Spotlight
---
.../2021-09-27-SIG-Node-Spotlight/index.md | 180 ++++++++++++++++++
1 file changed, 180 insertions(+)
create mode 100644 content/zh/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md
diff --git a/content/zh/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md b/content/zh/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md
new file mode 100644
index 0000000000..c5da376b8d
--- /dev/null
+++ b/content/zh/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md
@@ -0,0 +1,180 @@
+---
+layout: blog
+title: "关注 SIG Node"
+date: 2021-09-27
+slug: sig-node-spotlight-2021
+---
+
+**Author:** Dewan Ahmed, Red Hat
+
+
+
+
+## 介绍
+
+在 Kubernetes 中，一个 _Node_ 是你集群中的某台机器。
+[SIG Node](https://github.com/kubernetes/community/tree/master/sig-node) 负责这一非常重要的 Node 组件并支持各种子项目，
+如 Kubelet, Container Runtime Interface (CRI) 以及其他支持 Pod 和主机资源间交互的子项目。
+在这篇文章中，我们总结了和 [Elana Hashman (EH)](https://twitter.com/ehashdn) & [Sergey Kanzhelev (SK)](https://twitter.com/SergeyKanzhelev) 的对话，是他们带领我们了解作为此 SIG 一份子的各个方面，并分享一些关于其他人如何参与的见解。
+
+
+## 我们的对话总结
+
+### 你能告诉我们一些关于 SIG Node 的工作吗？
+
+SK：SIG Node 是一个垂直 SIG，负责支持 Pod 和主机资源之间受控互动的组件。我们管理被调度到节点上的 Pod 的生命周期。
+这个 SIG 的重点是支持广泛的工作负载类型，包括具有硬件特性或性能敏感要求的工作负载。同时保持节点上 Pod 之间的隔离边界，以及 Pod 和主机的隔离边界。
+这个 SIG 维护了相当多的组件，并有许多外部依赖（如容器运行时间或操作系统功能），这使得我们处理起来十分复杂。但我们战胜了这种复杂度，旨在不断提高节点的可靠性。
+
+
+### 你能再解释一下 “SIG Node 是一种垂直 SIG” 的含义吗？
+
+EH：有两种 SIG：横向和垂直。横向 SIG 关注 Kubernetes 中每个组件的特定功能：例如，SIG Security 考虑 Kubernetes 中每个组件的安全方面，或者 SIG Instrumentation 关注 Kubernetes 中每个组件的日志、度量、跟踪和事件。
+这样的 SIG 并不太会拥有大量的代码。
+
+相反，垂直 SIG 拥有一个单一的组件，并负责批准和合并该代码库的补丁。
+SIG Node 拥有 "Node" 的垂直性，与 kubelet 和它的生命周期有关。这包括 kubelet 本身的代码，以及节点控制器、容器运行时接口和相关的子项目，比如节点问题检测器。
+
+
+### CI 子项目是如何开始的？这是专门针对 SIG Node 的吗？它对 SIG 有什么帮助？
+
+SK：该子项目是在其中一个版本因关键测试的大量测试失败而受阻后开始跟进的。
+这些测试并不是一下子就开始下降的，而是持续的缺乏关注导致了测试质量的缓慢下降。
+SIG Node 一直将质量和可靠性放在首位，组建这个子项目是强调这一优先事项的一种方式。
+
+
+### 作为 issue 和 PR 数量第三大的 SIG，你们 SIG 是如何兼顾这么多工作的？
+
+EH：这归功于有组织性。当我在 2021 年 1 月增加对 SIG 的贡献时，我发现自己被大量的 PR 和 issue 淹没了，不知道该从哪里开始。
+我们已经在 CI 子项目板上跟踪与测试有关的 issue 和 PR 请求，但这缺少了很多 bug 修复和功能工作。
+因此，我开始为我们剩余的 PR 建立一个分流板，这使我能够根据状态和采取的行动对其进行分类，并为其他贡献者记录它的用途。
+在过去的两个版本中，我们关闭或合并了超过 500 个 issue 和 PR。Kubernetes devstats 显示，我们的速度因此而大大提升。
+
+6月，我们进行了第一次 bug 清除活动，以解决针对 SIG Node 的积压问题，确保它们被正确归类。
+在这次 48 小时的全球活动中，我们关闭了 130 多个问题，但截至发稿时，我们仍有 333 个问题没有解决。
+
+### 为什么新的和现有的贡献者应该考虑加入 Node 兴趣小组呢？
+
+SK：作为 SIG Node 的贡献者会带给你有意义且有用的技能和认可度。
+了解 Kubelet 的内部结构有助于构建更好的应用程序，调整和优化这些应用程序，并在 issue 排查上获得优势。
+如果你是一个新手贡献者，SIG Node 为你提供了基础知识，这是理解其他 Kubernetes 组件的设计方式的关键。
+现在的贡献者可能会受益于许多功能都需要 SIG Node 的这种或那种变化。所以成为 SIG Node 的贡献者有助于更快地建立其他 SIG 的功能。
+
+SIG Node 维护着许多组件，其中许多组件都依赖于外部项目或操作系统功能。这使得入职过程相当冗长和苛刻。
+但如果你愿意接受挑战，总有一个地方适合你，也有一群人支持你。
+
+### 你是如何帮助新手贡献者开始工作的？
+
+EH：在 SIG Node 的起步工作可能是令人生畏的，因为有太多的工作要做，我们的 SIG 会议非常大，而且很难找到一个开始的地方。
+
+我总是鼓励新手贡献者在他们已经有一些投入的方向上更进一步。
+在 SIG Node 中，这可能意味着自愿帮助修复一个只影响到你个人的 bug，或者按优先级去分流你关心的 bug。
+
+为了尽快了解任何开源代码库，你可以采取两种策略：从深入探索一个特定的问题开始，然后根据需要扩展你的知识边缘，或者单纯地尽可能多的审查 issues 和变更请求，以了解更高层次的组件工作方式。
+最终，如果你想成为一名 Node reviewer 或 approver，两件事是不可避免的。
+
+[Davanum Srinivas](https://twitter.com/dims) 和我各自举办了一次小组辅导，以帮助教导新手贡献者成为 Node reviewer 的技能，如果有兴趣，我们可以努力寻找一个导师来举办另一次会议。
+我也鼓励新手贡献者参加我们的 Node CI 子项目会议：它的听众较少，而且我们不记录分流会议，所以它可以是一个比较温和的方式来开始 SIG 之旅。
+
+### 有什么特别的技能者是你想招募的吗？对 SIG 可用性的贡献者可能会学到什么技能？
+
+SK：SIG Node 在大相径庭的领域从事许多工作流。所有这些领域都是系统级的。
+对于典型的代码贡献，你需要对建立和善用低级别的 API 以及编写高性能和可靠的组件有热情。
+作为一个贡献者，你将学习如何调试和排除故障，剖析和监控这些组件，以及由这些组件运行的用户工作负载。
+通常情况下，由于节点正在运行生产工作负载，所以对节点的访问是有限的，甚至是没有的。
+
+另一种贡献方式是帮助记录 SIG Node 的功能。这种类型的贡献需要对功能有深刻的理解，并有能力用简单的术语解释它们。
+
+最后，我们一直在寻找关于如何最好地运行你的工作负载的反馈。来解释一下它的具体情况，以及 SIG Node 组件中的哪些功能可能有助于更好地运行它。
+
+### 你在哪些方面得到了积极的反馈，以及 SIG Node 的下一步计划是什么？
+
+EH：在过去的一年里，SIG Node 采用了一些新的流程来帮助管理我们的功能开发和 Kubernetes 增强提议，其他 SIG 也向我们寻求在管理大型工作负载方面的灵感。
+我希望这是一个我们可以继续领导并进一步迭代的领域。
+
+现在，我们在新功能和废弃功能之间保持了很好的平衡。
+废弃未使用或难以维护的功能有助于我们控制技术债务和维护负荷，例子包括 dockershim 和 DynamicKubeletConfiguration 的废弃。
+新功能将在终端用户的集群中释放更多的功能，包括令人兴奋的功能，如支持 cgroups v2、交换内存、优雅的节点关闭和设备管理策略。
+
+### 最后你有什么想法/资源要分享吗？
+
+SK/EH：进入任何开源社区都需要时间和努力。一开始 SIG Node 可能会因为参与者的数量、工作量和项目范围而让你不知所措。但这是完全值得的。
+请加入我们这个热情的社区! [SIG Node GitHub Repo]（https://github.com/kubernetes/community/tree/master/sig-node）包含许多有用的资源，包括 Slack、邮件列表和其他联系信息。
+
+## 总结
+
+SIG Node 举办了一场 [KubeCon + CloudNativeCon Europe 2021 talk](https://www.youtube.com/watch?v=z5aY4e2RENA)，对他们强大的 SIG 进行了介绍和深入探讨。
+加入 SIG 的会议，了解最新的研究成果，未来一年的计划是什么，以及如何作为贡献者参与到上游的 Node 团队中!
\ No newline at end of file
From 6a375baa5ebdcfa95b1db5f11c0ad9230694abd8 Mon Sep 17 00:00:00 2001
From: Qiming Teng
Date: Sun, 10 Apr 2022 13:25:14 +0800
Subject: [PATCH 078/167] [zh] Resync assign pod to node
The whole page was rewritten. This is a full resync.
---
.../scheduling-eviction/assign-pod-node.md | 1009 ++++++++---------
.../pods/pod-with-affinity-anti-affinity.yaml | 32 +
2 files changed, 533 insertions(+), 508 deletions(-)
create mode 100644 content/zh/examples/pods/pod-with-affinity-anti-affinity.yaml
diff --git a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
index 60ee606313..b97cdc4159 100644
--- a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -1,5 +1,5 @@
---
-title: 将 Pod 分配给节点
+title: 将 Pod 指派给节点
content_type: concept
weight: 20
---
@@ -23,327 +23,314 @@ There are several ways to do this, and the recommended approaches all use
[label selectors](/docs/concepts/overview/working-with-objects/labels/) to facilitate the selection.
Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
(e.g. spread your pods across nodes so as not place the pod on a node with insufficient free resources, etc.)
-but there are some circumstances where you may want more control on a node where a pod lands, for example to ensure
-that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different
+However, there are some circumstances where you may want to control which node
+the Pod deploys to, for example, to ensure that a Pod ends up on a node with an SSD attached to it, or to co-locate pods from two different
services that communicate a lot into the same availability zone.
-->
-你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的
-{{< glossary_tooltip text="节点" term_id="node" >}} 上运行。
+你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}}
+只能在特定的{{< glossary_tooltip text="节点" term_id="node" >}}上运行。
有几种方法可以实现这点，推荐的方法都是用
[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)来进行选择。
通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上，
而不是将 Pod 放置在可用资源不足的节点上等等）。但在某些情况下，你可能需要进一步控制
-Pod 停靠的节点，例如，确保 Pod 最终落在连接了 SSD 的机器上，或者将来自两个不同的服务
-且有大量通信的 Pods 被放置在同一个可用区。
+Pod 被部署到的节点。例如，确保 Pod 最终落在连接了 SSD 的机器上，
+或者将来自两个不同的服务且有大量通信的 Pods 被放置在同一个可用区。
+
+你可以使用下列方法中的任何一种来选择 Kubernetes 对特定 Pod 的调度：
+
+* 与[节点标签](#built-in-node-labels)匹配的 [nodeSelector](#nodeSelector)
+* [亲和性与反亲和性](#affinity-and-anti-affinity)
+* [nodeName](#nodename) 字段
+
+
+## 节点标签 {#built-in-node-labels}
+
+与很多其他 Kubernetes 对象类似，节点也有[标签](/zh/docs/concepts/overview/working-with-objects/labels/)。
+你可以[手动地添加标签](/zh/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node)。
+Kubernetes 也会为集群中所有节点添加一些标准的标签。
+参见[常用的标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)以了解常见的节点标签。
+
+{{< note >}}
+
+这些标签的取值是取决于云提供商的，并且是无法在可靠性上给出承诺的。
+例如，`kubernetes.io/hostname` 的取值在某些环境中可能与节点名称相同，
+而在其他环境中会取不同的值。
+{{< /note >}}
+
+
+## 节点隔离/限制 {#node-isolation-restriction}
+
+通过为节点添加标签，你可以准备让 Pod 调度到特定节点或节点组上。
+你可以使用这个功能来确保特定的 Pod 只能运行在具有一定隔离性，安全性或监管属性的节点上。
+
+
+如果使用标签来实现节点隔离，建议选择节点上的
+{{}}
+无法修改的标签键。
+这可以防止受感染的节点在自身上设置这些标签，进而影响调度器将工作负载调度到受感染的节点。
+
+
+[`NodeRestriction` 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)防止
+kubelet 使用 `node-restriction.kubernetes.io/` 前缀设置或修改标签。
+
+要使用该标签前缀进行节点隔离：
+
+
+1. 确保你在使用[节点鉴权](/zh/docs/reference/access-authn-authz/node/)机制并且已经启用了
+ [NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。
+2. 将带有 `node-restriction.kubernetes.io/` 前缀的标签添加到 Node 对象，
+ 然后在[节点选择器](#nodeSelector)中使用这些标签。
+ 例如，`example.com.node-restriction.kubernetes.io/fips=true` 或
+ `example.com.node-restriction.kubernetes.io/pci-dss=true`。
+
## nodeSelector
-
-`nodeSelector` 是节点选择约束的最简单推荐形式。`nodeSelector` 是 PodSpec 的一个字段。
-它包含键值对的映射。为了使 pod 可以在某个节点上运行，该节点的标签中
-必须包含这里的每个键值对（它也可以具有其他标签）。
-最常见的用法的是一对键值对。
+`nodeSelector` 是节点选择约束的最简单推荐形式。你可以将 `nodeSelector` 字段添加到
+Pod 的规约中设置你希望目标节点所具有的[节点标签](#built-in-node-labels)。
+Kubernetes 只会将 Pod 调度到拥有你所指定的每个标签的节点上。
-让我们来看一个使用 `nodeSelector` 的例子。
-
-
-### 步骤零：先决条件
-
-本示例假设你已基本了解 Kubernetes 的 Pod 并且已经[建立一个 Kubernetes 集群](/zh/docs/setup/)。
-
-
-### 步骤一：添加标签到节点 {#attach-labels-to-node}
-
-执行 `kubectl get nodes` 命令获取集群的节点名称。
-选择一个你要增加标签的节点，然后执行
-`kubectl label nodes =`
-命令将标签添加到你所选择的节点上。
-例如，如果你的节点名称为 'kubernetes-foo-node-1.c.a-robinson.internal'
-并且想要的标签是 'disktype=ssd'，则可以执行
-`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd` 命令。
-
-
-你可以通过重新运行 `kubectl get nodes --show-labels`，
-查看节点当前具有了所指定的标签来验证它是否有效。
-你也可以使用 `kubectl describe node "nodename"` 命令查看指定节点的标签完整列表。
-
-
-### 步骤二：添加 nodeSelector 字段到 Pod 配置中
-
-选择任何一个你想运行的 Pod 的配置文件，并且在其中添加一个 nodeSelector 部分。
-例如，如果下面是我的 pod 配置：
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: nginx
- labels:
- env: test
-spec:
- containers:
- - name: nginx
- image: nginx
-```
-
-
-然后像下面这样添加 nodeSelector：
-
-{{< codenew file="pods/pod-nginx.yaml" >}}
-
-
-当你之后运行 `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml` 命令，
-Pod 将会调度到将标签添加到的节点上。
-你可以通过运行 `kubectl get pods -o wide` 并查看分配给 pod 的 “NODE” 来验证其是否有效。
-
-
-## 插曲：内置的节点标签 {#built-in-node-labels}
-
-除了你[添加](#step-one-attach-label-to-the-node)的标签外，节点还预制了一组标准标签。
-参见这些[常用的标签，注解以及污点](/zh/docs/reference/labels-annotations-taints/)：
-
-* [`kubernetes.io/hostname`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
-* [`failure-domain.beta.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
-* [`failure-domain.beta.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
-* [`topology.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-* [`topology.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-* [`beta.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
-* [`node.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
-* [`kubernetes.io/os`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
-* [`kubernetes.io/arch`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
-
-{{< note >}}
-
-这些标签的值是特定于云供应商的，因此不能保证可靠。
-例如，`kubernetes.io/hostname` 的值在某些环境中可能与节点名称相同，
-但在其他环境中可能是一个不同的值。
-{{< /note >}}
-
-
-## 节点隔离/限制 {#node-isolation-restriction}
-
-向 Node 对象添加标签可以将 pod 定位到特定的节点或节点组。
-这可以用来确保指定的 Pod 只能运行在具有一定隔离性，安全性或监管属性的节点上。
-当为此目的使用标签时，强烈建议选择节点上的 kubelet 进程无法修改的标签键。
-这可以防止受感染的节点使用其 kubelet 凭据在自己的 Node 对象上设置这些标签，
-并影响调度器将工作负载调度到受感染的节点。
-
-
-`NodeRestriction` 准入插件防止 kubelet 使用 `node-restriction.kubernetes.io/`
-前缀设置或修改标签。要使用该标签前缀进行节点隔离：
-
-
-1. 确保你在使用[节点授权](/zh/docs/reference/access-authn-authz/node/)并且已经 _启用_
- [NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。
-2. 将 `node-restriction.kubernetes.io/` 前缀下的标签添加到 Node 对象，
- 然后在节点选择器中使用这些标签。
- 例如，`example.com.node-restriction.kubernetes.io/fips=true` 或
- `example.com.node-restriction.kubernetes.io/pci-dss=true`。
+进一步的信息可参见[将 Pod 指派给节点](/zh/docs/tasks/configure-pod-container/assign-pods-nodes)。
-## 亲和性与反亲和性
+## 亲和性与反亲和性 {#affinity-and-anti-affinity}
-`nodeSelector` 提供了一种非常简单的方法来将 Pod 约束到具有特定标签的节点上。
-亲和性/反亲和性功能极大地扩展了你可以表达约束的类型。关键的增强点包括：
+`nodeSelector` 提供了一种最简单的方法来将 Pod 约束到具有特定标签的节点上。
+亲和性和反亲和性扩展了你可以定义的约束类型。使用亲和性与反亲和性的一些好处有：
-1. 语言表达能力更强（不仅仅是“对完全匹配规则的 AND”）
-2. 你可以发现规则是“软需求”/“偏好”，而不是硬性要求，因此，
- 如果调度器无法满足该要求，仍然调度该 Pod
-3. 你可以使用节点上（或其他拓扑域中）的 Pod 的标签来约束，而不是使用
- 节点本身的标签，来允许哪些 pod 可以或者不可以被放置在一起。
-
-
-亲和性功能包含两种类型的亲和性，即“节点亲和性”和“Pod 间亲和性/反亲和性”。
-节点亲和性就像现有的 `nodeSelector`（但具有上面列出的前两个好处），然而
-Pod 间亲和性/反亲和性约束 Pod 标签而不是节点标签（在上面列出的第三项中描述，
-除了具有上面列出的第一和第二属性）。
+* 亲和性、反亲和性语言的表达能力更强。`nodeSelector` 只能选择拥有所有指定标签的节点。
+ 亲和性、反亲和性为你提供对选择逻辑的更强控制能力。
+* 你可以标明某规则是“软需求”或者“偏好”，这样调度器在无法找到匹配节点时仍然调度该 Pod。
+* 你可以使用节点上（或其他拓扑域中）运行的其他 Pod 的标签来实施调度约束，
+ 而不是只能使用节点本身的标签。这个能力让你能够定义规则允许哪些 Pod 可以被放置在一起。
### 节点亲和性 {#node-affinity}
-节点亲和性概念上类似于 `nodeSelector`，它使你可以根据节点上的标签来约束
-Pod 可以调度到哪些节点。
+节点亲和性概念上类似于 `nodeSelector`，
+它使你可以根据节点上的标签来约束 Pod 可以调度到哪些节点上。
+节点亲和性有两种：
-目前有两种类型的节点亲和性，分别为 `requiredDuringSchedulingIgnoredDuringExecution` 和
-`preferredDuringSchedulingIgnoredDuringExecution`。
-你可以视它们为“硬需求”和“软需求”，意思是，前者指定了将 Pod 调度到一个节点上
-*必须*满足的规则（就像 `nodeSelector` 但使用更具表现力的语法），
-后者指定调度器将尝试执行但不能保证的*偏好*。
-名称的“IgnoredDuringExecution”部分意味着，类似于 `nodeSelector` 的工作原理，
-如果节点的标签在运行时发生变更，从而不再满足 Pod 上的亲和性规则，那么 Pod
-将仍然继续在该节点上运行。
-将来我们计划提供 `requiredDuringSchedulingRequiredDuringExecution`，
-它将与 `requiredDuringSchedulingIgnoredDuringExecution` 完全相同，
-只是它会将 Pod 从不再满足 Pod 的节点亲和性要求的节点上驱逐。
+* `requiredDuringSchedulingIgnoredDuringExecution`：
+ 调度器只有在规则被满足的时候才能执行调度。此功能类似于 `nodeSelector`，
+ 但其语法表达能力更强。
+* `preferredDuringSchedulingIgnoredDuringExecution`：
+ 调度器会尝试寻找满足对应规则的节点。如果找不到匹配的节点，调度器仍然会调度该 Pod。
+
+{{}}
+
+在上述类型中，`IgnoredDuringExecution` 意味着如果节点标签在 Kubernetes
+调度 Pod 时发生了变更，Pod 仍将继续运行。
+{{}}
-因此，`requiredDuringSchedulingIgnoredDuringExecution` 的示例将是
-“仅将 Pod 运行在具有 Intel CPU 的节点上”，而
-`preferredDuringSchedulingIgnoredDuringExecution` 的示例为
-“尝试将这组 Pod 运行在 XYZ 故障区域，如果这不可能的话，则允许一些
-Pod 在其他地方运行”。
+You can specify node affinities using the `.spec.affinity.nodeAffinity` field in
+your Pod spec.
-
-节点亲和性通过 PodSpec 的 `affinity` 字段下的 `nodeAffinity` 字段进行指定。
-
-
-下面是一个使用节点亲和性的 Pod 的实例：
+你可以使用 Pod 规约中的 `.spec.affinity.nodeAffinity` 字段来设置节点亲和性。
+例如，考虑下面的 Pod 规约：
{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
-此节点亲和性规则表示，Pod 只能放置在具有标签键 `kubernetes.io/e2e-az-name`
-且标签值为 `e2e-az1` 或 `e2e-az2` 的节点上。
-另外，在满足这些标准的节点中，具有标签键为 `another-node-label-key`
-且标签值为 `another-node-label-value` 的节点应该优先使用。
+在这一示例中，所应用的规则如下：
+
+* 节点必须包含键名为 `kubernetes.io/os` 的标签，并且其取值为 `linux`。
+* 节点 **最好** 具有键名为 `another-node-label-key` 且取值为
+ `another-node-label-value` 的标签。
-你可以在上面的例子中看到 `In` 操作符的使用。新的节点亲和性语法支持下面的操作符：
-`In`，`NotIn`，`Exists`，`DoesNotExist`，`Gt`，`Lt`。
-你可以使用 `NotIn` 和 `DoesNotExist` 来实现节点反亲和性行为，或者使用
-[节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)
-将 Pod 从特定节点中驱逐。
+你可以使用 `operator` 字段来为 Kubernetes 设置在解释规则时要使用的逻辑操作符。
+你可以使用 `In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt` 和 `Lt` 之一作为操作符。
-如果你同时指定了 `nodeSelector` 和 `nodeAffinity`，*两者*必须都要满足，
+`NotIn` 和 `DoesNotExist` 可用来实现节点反亲和性行为。
+你也可以使用[节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)
+将 Pod 从特定节点上驱逐。
+
+{{< note >}}
+
+如果你同时指定了 `nodeSelector` 和 `nodeAffinity`，**两者** 必须都要满足，
才能将 Pod 调度到候选节点上。
-如果你指定了多个与 `nodeAffinity` 类型关联的 `nodeSelectorTerms`，则
-**如果其中一个** `nodeSelectorTerms` 满足的话，pod将可以调度到节点上。
+
+如果你指定了多个与 `nodeAffinity` 类型关联的 `nodeSelectorTerms`，
+只要其中一个 `nodeSelectorTerms` 满足的话，Pod 就可以被调度到节点上。
-
-如果你指定了多个与 `nodeSelectorTerms` 关联的 `matchExpressions`，则
-**只有当所有** `matchExpressions` 满足的话，Pod 才会可以调度到节点上。
-
-如果你修改或删除了 pod 所调度到的节点的标签，Pod 不会被删除。
-换句话说，亲和性选择只在 Pod 调度期间有效。
+如果你指定了多个与同一 `nodeSelectorTerms` 关联的 `matchExpressions`，
+则只有当所有 `matchExpressions` 都满足时 Pod 才可以被调度到节点上。
+{{< /note >}}
-`preferredDuringSchedulingIgnoredDuringExecution` 中的 `weight` 字段值的
-范围是 1-100。
-对于每个符合所有调度要求（资源请求、RequiredDuringScheduling 亲和性表达式等）
-的节点，调度器将遍历该字段的元素来计算总和，并且如果节点匹配对应的
-MatchExpressions，则添加“权重”到总和。
-然后将这个评分与该节点的其他优先级函数的评分进行组合。
-总分最高的节点是最优选的。
+参阅[使用节点亲和性来为 Pod 指派节点](/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)，
+以了解进一步的信息。
+
+
+#### 节点亲和性权重 {#node-affinity-weight}
+
+你可以为 `preferredDuringSchedulingIgnoredDuringExecution` 亲和性类型的每个实例设置
+`weight` 字段，其取值范围是 1 到 100。
+当调度器找到能够满足 Pod 的其他调度请求的节点时，调度器会遍历节点满足的所有的偏好性规则，
+并将对应表达式的 `weight` 值加和。
+
+
+最终的加和值会添加到该节点的其他优先级函数的评分之上。
+在调度器为 Pod 作出调度决定时，总分最高的节点的优先级也最高。
+
+例如，考虑下面的 Pod 规约：
+
+{{}}
+
+
+如果存在两个候选节点，都满足 `requiredDuringSchedulingIgnoredDuringExecution` 规则，
+其中一个节点具有标签 `label-1:key-1`，另一个节点具有标签 `label-2:key-2`，
+调度器会考察各个节点的 `weight` 取值，并将该权重值添加到节点的其他得分值之上，
+
+{{< note >}}
+
+如果你希望 Kubernetes 能够成功地调度此例中的 Pod，你必须拥有打了
+`kubernetes.io/os=linux` 标签的节点。
+{{< /note >}}
在配置多个[调度方案](/zh/docs/reference/scheduling/config/#multiple-profiles)时，
-你可以将某个方案与节点亲和性关联起来，如果某个调度方案仅适用于某组
-特殊的节点时，这样做是很有用的。
+你可以将某个方案与节点亲和性关联起来，如果某个调度方案仅适用于某组特殊的节点时，
+这样做是很有用的。
要实现这点，可以在[调度器配置](/zh/docs/reference/scheduling/config/)中为
-[`NodeAffinity` 插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)
-添加 `addedAffinity` 参数。
-例如：
+[`NodeAffinity` 插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)的
+`args` 字段添加 `addedAffinity`。例如：
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
@@ -389,54 +375,78 @@ profiles:
这里的 `addedAffinity` 除遵从 Pod 规约中设置的节点亲和性之外，还
适用于将 `.spec.schedulerName` 设置为 `foo-scheduler`。
+换言之，为了匹配 Pod，节点需要满足 `addedAffinity` 和 Pod 的 `.spec.NodeAffinity`。
+由于 `addedAffinity` 对最终用户不可见，其行为可能对用户而言是出乎意料的。
+应该使用与调度方案名称有明确关联的节点标签。
+
{{< note >}}
+
DaemonSet 控制器[为 DaemonSet 创建 Pods](/zh/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)，
-但该控制器不理会调度方案。因此，建议你保留一个调度方案，例如
-`default-scheduler`，不要在其中设置 `addedAffinity`。
-这样，DaemonSet 的 Pod 模板将会使用此调度器名称。
-否则，DaemonSet 控制器所创建的某些 Pods 可能持续处于不可调度状态。
+但该控制器不理会调度方案。
+DaemonSet 控制器创建 Pod 时，默认的 Kubernetes 调度器负责放置 Pod，
+并遵从 DaemonSet 控制器中奢侈的 `nodeAffinity` 规则。
{{< /note >}}
### pod 间亲和性与反亲和性 {#inter-pod-affinity-and-anti-affinity}
-Pod 间亲和性与反亲和性使你可以 *基于已经在节点上运行的 Pod 的标签* 来约束
+Pod 间亲和性与反亲和性使你可以基于已经在节点上运行的 **Pod** 的标签来约束
Pod 可以调度到的节点，而不是基于节点上的标签。
-规则的格式为“如果 X 节点上已经运行了一个或多个 满足规则 Y 的 Pod，
-则这个 Pod 应该（或者在反亲和性的情况下不应该）运行在 X 节点”。
-Y 表示一个具有可选的关联命令空间列表的 LabelSelector；
-与节点不同，因为 Pod 是命名空间限定的（因此 Pod 上的标签也是命名空间限定的），
-因此作用于 Pod 标签的标签选择算符必须指定选择算符应用在哪个命名空间。
-从概念上讲，X 是一个拓扑域，如节点、机架、云供应商可用区、云供应商地理区域等。
-你可以使用 `topologyKey` 来表示它，`topologyKey` 是节点标签的键以便系统
-用来表示这样的拓扑域。
-请参阅上面[插曲：内置的节点标签](#built-in-node-labels)部分中列出的标签键。
+
+
+Pod 间亲和性与反亲和性的规则格式为“如果 X 上已经运行了一个或多个满足规则 Y 的 Pod，
+则这个 Pod 应该（或者在反亲和性的情况下不应该）运行在 X 上”。
+这里的 X 可以是节点、机架、云提供商可用区或地理区域或类似的拓扑域，
+Y 则是 Kubernetes 尝试满足的规则。
+
+
+你通过[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)
+的形式来表达规则（Y），并可根据需要指定选关联的名字空间列表。
+Pod 在 Kubernetes 中是名字空间作用域的对象，因此 Pod 的标签也隐式地具有名字空间属性。
+针对 Pod 标签的所有标签选择算符都要指定名字空间，Kubernetes
+会在指定的名字空间内寻找标签。
+
+
+你会通过 `topologyKey` 来表达拓扑域（X）的概念，其取值是系统用来标示域的节点标签键。
+相关示例可参见[常用标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)。
{{< note >}}
-Pod 间亲和性与反亲和性需要大量的处理，这可能会显著减慢大规模集群中的调度。
-我们不建议在超过数百个节点的集群中使用它们。
+Pod 间亲和性和反亲和性都需要相当的计算量，因此会在大规模集群中显著降低调度速度。
+我们不建议在包含数百个节点的集群中使用这类设置。
{{< /note >}}
{{< note >}}
-Pod 反亲和性需要对节点进行一致的标记，即集群中的每个节点必须具有适当的标签能够匹配
-`topologyKey`。如果某些或所有节点缺少指定的 `topologyKey` 标签，可能会导致意外行为。
+Pod 反亲和性需要节点上存在一致性的标签。换言之，
+集群中每个节点都必须拥有与 `topologyKey` 匹配的标签。
+如果某些或者所有节点上不存在所指定的 `topologyKey` 标签，调度行为可能与预期的不同。
{{< /note >}}
-与节点亲和性一样，当前有两种类型的 Pod 亲和性与反亲和性，即
-`requiredDuringSchedulingIgnoredDuringExecution` 和
-`preferredDuringSchedulingIgnoredDuringExecution`，分别表示“硬性”与“软性”要求。
-请参阅前面节点亲和性部分中的描述。
-`requiredDuringSchedulingIgnoredDuringExecution` 亲和性的一个示例是
-“将服务 A 和服务 B 的 Pod 放置在同一区域，因为它们之间进行大量交流”，而
-`preferredDuringSchedulingIgnoredDuringExecution` 反亲和性的示例将是
-“将此服务的 pod 跨区域分布”（硬性要求是说不通的，因为你可能拥有的
-Pod 数多于区域数）。
+#### Pod 间亲和性与反亲和性的类型
+
+与[节点亲和性](#node-affinity)类似，Pod 的亲和性与反亲和性也有两种类型：
+
+* `requiredDuringSchedulingIgnoredDuringExecution`
+* `preferredDuringSchedulingIgnoredDuringExecution`
-Pod 间亲和性通过 PodSpec 中 `affinity` 字段下的 `podAffinity` 字段进行指定。
-而 Pod 间反亲和性通过 PodSpec 中 `affinity` 字段下的 `podAntiAffinity` 字段进行指定。
+例如，你可以使用 `requiredDuringSchedulingIgnoredDuringExecution` 亲和性来告诉调度器，
+将两个服务的 Pod 放到同一个云提供商可用区内，因为它们彼此之间通信非常频繁。
+类似地，你可以使用 `preferredDuringSchedulingIgnoredDuringExecution`
+反亲和性来将同一服务的多个 Pod 分布到多个云提供商可用区中。
-### Pod 使用 pod 亲和性 的示例：
+要使用 Pod 间亲和性，可以使用 Pod 规约中的 `.affinity.podAffinity` 字段。
+对于 Pod 间反亲和性，可以使用 Pod 规约中的 `.affinity.podAntiAffinity` 字段。
+
+
+#### Pod 亲和性示例 {#an-example-of-a-pod-that-uses-pod-affinity}
+
+考虑下面的 Pod 规约：
{{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
+本示例定义了一条 Pod 亲和性规则和一条 Pod 反亲和性规则。Pod 亲和性规则配置为
+`requiredDuringSchedulingIgnoredDuringExecution`，而 Pod 反亲和性配置为
+`preferredDuringSchedulingIgnoredDuringExecution`。
+
+
+亲和性规则表示，仅当节点和至少一个已运行且有 `security=S1` 的标签的
+Pod 处于同一区域时，才可以将该 Pod 调度到节点上。
+更确切的说，调度器必须将 Pod 调度到具有 `topology.kubernetes.io/zone=V`
+标签的节点上，并且集群中至少有一个位于该可用区的节点上运行着带有
+`security=S1` 标签的 Pod。
+
+
+反亲和性规则表示，如果节点处于 Pod 所在的同一可用区且至少一个 Pod 具有
+`security=S2` 标签，则该 Pod 不应被调度到该节点上。
+更确切地说， 如果同一可用区中存在其他运行着带有 `security=S2` 标签的 Pod 节点，
+并且节点具有标签 `topology.kubernetes.io/zone=R`，Pod 不能被调度到该节点上。
+
+
-在这个 Pod 的亲和性配置定义了一条 Pod 亲和性规则和一条 Pod 反亲和性规则。
-在此示例中，`podAffinity` 配置为 `requiredDuringSchedulingIgnoredDuringExecution`，
-然而 `podAntiAffinity` 配置为 `preferredDuringSchedulingIgnoredDuringExecution`。
-Pod 亲和性规则表示，仅当节点和至少一个已运行且有键为“security”且值为“S1”的标签
-的 Pod 处于同一区域时，才可以将该 Pod 调度到节点上。
-（更确切的说，如果节点 N 具有带有键 `topology.kubernetes.io/zone` 和某个值 V 的标签，
-则 Pod 有资格在节点 N 上运行，以便集群中至少有一个节点具有键
-`topology.kubernetes.io/zone` 和值为 V 的节点正在运行具有键“security”和值
-“S1”的标签的 pod。）
-Pod 反亲和性规则表示，如果节点处于 Pod 所在的同一可用区且具有键“security”和值“S2”的标签，
-则该 pod 不应将其调度到该节点上。
-（如果 `topologyKey` 为 `topology.kubernetes.io/zone`，则意味着当节点和具有键
-“security”和值“S2”的标签的 Pod 处于相同的区域，Pod 不能被调度到该节点上。）
查阅[设计文档](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
-以获取 Pod 亲和性与反亲和性的更多样例，包括
-`requiredDuringSchedulingIgnoredDuringExecution`
-和 `preferredDuringSchedulingIgnoredDuringExecution` 两种配置。
+以了解 Pod 亲和性与反亲和性的更多示例。
-Pod 亲和性与反亲和性的合法操作符有 `In`，`NotIn`，`Exists`，`DoesNotExist`。
+你可以针对 Pod 间亲和性与反亲和性为其 `operator` 字段使用 `In`、`NotIn`、`Exists`、
+`DoesNotExist` 等值。
-原则上，`topologyKey` 可以是任何合法的标签键。
-然而，出于性能和安全原因，topologyKey 受到一些限制：
+原则上，`topologyKey` 可以是任何合法的标签键。出于性能和安全原因，`topologyKey`
+有一些限制：
-1. 对于 Pod 亲和性而言，在 `requiredDuringSchedulingIgnoredDuringExecution`
- 和 `preferredDuringSchedulingIgnoredDuringExecution` 中，`topologyKey` 不允许为空。
-2. 对于 Pod 反亲和性而言，`requiredDuringSchedulingIgnoredDuringExecution`
- 和 `preferredDuringSchedulingIgnoredDuringExecution` 中，`topologyKey`
- 都不可以为空。
-3. 对于 `requiredDuringSchedulingIgnoredDuringExecution` 要求的 Pod 反亲和性，
- 准入控制器 `LimitPodHardAntiAffinityTopology` 被引入以确保 `topologyKey`
- 只能是 `kubernetes.io/hostname`。如果你希望 `topologyKey` 也可用于其他定制
- 拓扑逻辑，你可以更改准入控制器或者禁用之。
-4. 除上述情况外，`topologyKey` 可以是任何合法的标签键。
+* 对于 Pod 亲和性而言，在 `requiredDuringSchedulingIgnoredDuringExecution`
+ 和 `preferredDuringSchedulingIgnoredDuringExecution` 中，`topologyKey`
+ 不允许为空。
+* 对于 `requiredDuringSchedulingIgnoredDuringExecution` 要求的 Pod 反亲和性，
+ 准入控制器 `LimitPodHardAntiAffinityTopology` 要求 `topologyKey` 只能是
+ `kubernetes.io/hostname`。如果你希望使用其他定制拓扑逻辑，
+ 你可以更改准入控制器或者禁用之。
-除了 `labelSelector` 和 `topologyKey`，你也可以指定表示命名空间的
-`namespaces` 队列，`labelSelector` 也应该匹配它
-（这个与 `labelSelector` 和 `topologyKey` 的定义位于相同的级别）。
-如果忽略或者为空，则默认为 Pod 亲和性/反亲和性的定义所在的命名空间。
-
-
-所有与 `requiredDuringSchedulingIgnoredDuringExecution` 亲和性与反亲和性
-关联的 `matchExpressions` 必须满足，才能将 pod 调度到节点上。
+除了 `labelSelector` 和 `topologyKey`，你也可以指定 `labelSelector`
+要匹配的命名空间列表，方法是在 `labelSelector` 和 `topologyKey`
+所在层同一层次上设置 `namespaces`。
+如果 `namespaces` 被忽略或者为空，则默认为 Pod 亲和性/反亲和性的定义所在的命名空间。
-#### 名字空间选择算符
+#### 名字空间选择算符 {#namespace-selector}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
用户也可以使用 `namespaceSelector` 选择匹配的名字空间，`namespaceSelector`
是对名字空间集合进行标签查询的机制。
亲和性条件会应用到 `namespaceSelector` 所选择的名字空间和 `namespaces` 字段中
所列举的名字空间之上。
-注意，空的 `namespaceSelector`（{}）会匹配所有名字空间，而 null 或者空的
+注意，空的 `namespaceSelector`（`{}`）会匹配所有名字空间，而 null 或者空的
`namespaces` 列表以及 null 值 `namespaceSelector` 意味着“当前 Pod 的名字空间”。
+{{< note >}}
此功能特性是 Beta 版本的，默认是被启用的。你可以通过针对 kube-apiserver 和
-kube-scheduler 设置
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+kube-scheduler 设置[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
`PodAffinityNamespaceSelector` 来禁用此特性。
+{{< /note >}}
#### 更实际的用例
-Pod 间亲和性与反亲和性在与更高级别的集合（例如 ReplicaSets、StatefulSets、
-Deployments 等）一起使用时，它们可能更加有用。
-可以轻松配置一组应位于相同定义拓扑（例如，节点）中的工作负载。
+Pod 间亲和性与反亲和性在与更高级别的集合（例如 ReplicaSet、StatefulSet、
+Deployment 等）一起使用时，它们可能更加有用。
+这些规则使得你可以配置一组工作负载，使其位于相同定义拓扑（例如，节点）中。
-##### 始终放置在相同节点上
-
-在三节点集群中，一个 web 应用程序具有内存缓存，例如 redis。
-我们希望 web 服务器与缓存尽可能放置在同一节点上。
-
-
-下面是一个简单 redis Deployment 的 YAML 代码段，它有三个副本和选择器标签 `app=store`。
-Deployment 配置了 `PodAntiAffinity`，用来确保调度器不会将所有副本调度到同一节点上。
+在下面的 Redis 缓存 Deployment 示例中，副本上设置了标签 `app=store`。
+`podAntiAffinity` 规则告诉调度器避免将多个带有 `app=store` 标签的副本部署到同一节点上。
+因此，每个独立节点上会创建一个缓存实例。
```yaml
apiVersion: apps/v1
@@ -662,11 +686,14 @@ spec:
```
-下面 webserver Deployment 的 YAML 代码段中配置了 `podAntiAffinity` 和 `podAffinity`。
-这将通知调度器将 web-server 的所有副本与具有 `app=store` 选择器标签的 Pod 放置在一起。
-同时这还确保了不会有两个 web 服务器的副本被调度到同一节点上。
+下面的 Deployment 用来提供 Web 服务器服务，会创建带有标签 `app=web-store` 的副本。
+Pod 亲和性规则告诉调度器将副本放到运行有标签包含 `app=store` Pod 的节点上。
+Pod 反亲和性规则告诉调度器不要在同一节点上放置多个 `app=web-store` 的服务器。
```yaml
apiVersion: apps/v1
@@ -708,9 +735,11 @@ spec:
```
-如果我们创建了上面的两个 Deployment，我们的三节点集群将如下表所示。
+创建前面两个 Deployment 会产生如下的集群布局，每个 Web 服务器与一个缓存实例并置，
+并分别运行在三个独立的节点上。
| node-1 | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
@@ -718,81 +747,51 @@ If we create the above two deployments, our three node cluster should look like
| *cache-1* | *cache-2* | *cache-3* |
-如你所见，`web-server` 的三个副本都按照预期那样自动放置在同一位置。
-
-```
-kubectl get pods -o wide
-```
+参阅 [ZooKeeper 教程](/zh/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
+了解一个 StatefulSet 的示例，该 StatefulSet 配置了反亲和性以实现高可用，
+所使用的是与此例相同的技术。
-输出类似于如下内容：
-
-```
-NAME READY STATUS RESTARTS AGE IP NODE
-redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3
-redis-cache-1450370735-j2j96 1/1 Running 0 8m 10.192.2.2 kube-node-1
-redis-cache-1450370735-z73mh 1/1 Running 0 8m 10.192.3.1 kube-node-2
-web-server-1287567482-5d4dz 1/1 Running 0 7m 10.192.2.3 kube-node-1
-web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4.3 kube-node-3
-web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2
-```
-
-
-##### 永远不放置在相同节点
-
-上面的例子使用 `PodAntiAffinity` 规则和 `topologyKey: "kubernetes.io/hostname"`
-来部署 redis 集群以便在同一主机上没有两个实例。
-参阅 [ZooKeeper 教程](/zh/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)，
-以获取配置反亲和性来达到高可用性的 StatefulSet 的样例（使用了相同的技巧）。
-
## nodeName
-
-`nodeName` 是节点选择约束的最简单方法，但是由于其自身限制，通常不使用它。
-`nodeName` 是 PodSpec 的一个字段。
-如果它不为空，调度器将忽略 Pod，并且给定节点上运行的 kubelet 进程尝试执行该 Pod。
-因此，如果 `nodeName` 在 PodSpec 中指定了，则它优先于上面的节点选择方法。
+## nodeName
+
+`nodeName` 是比亲和性或者 `nodeSelector` 更为直接的形式。`nodeName` 是 Pod
+规约中的一个字段。如果 `nodeName` 字段不为空，调度器会忽略该 Pod，
+而指定节点上的 kubelet 会尝试将 Pod 放到该节点上。
+使用 `nodeName` 规则的优先级会高于使用 `nodeSelector` 或亲和性与非亲和性的规则。
-使用 `nodeName` 来选择节点的一些限制：
+使用 `nodeName` 来选择节点的方式有一些局限性：
-- 如果指定的节点不存在，
-- 如果指定的节点没有资源来容纳 Pod，Pod 将会调度失败并且其原因将显示为，
- 比如 OutOfmemory 或 OutOfcpu。
-- 云环境中的节点名称并非总是可预测或稳定的。
+- 如果所指代的节点不存在，则 Pod 无法运行，而且在某些情况下可能会被自动删除。
+- 如果所指代的节点无法提供用来运行 Pod 所需的资源，Pod 会失败，
+ 而其失败原因中会给出是否因为内存或 CPU 不足而造成无法运行。
+- 在云环境中的节点名称并不总是可预测的，也不总是稳定的。
-下面的是使用 `nodeName` 字段的 Pod 配置文件的例子：
+下面是一个使用 `nodeName` 字段的 Pod 规约示例：
```yaml
apiVersion: v1
@@ -807,32 +806,26 @@ spec:
```
-上面的 pod 将运行在 kube-01 节点上。
+上面的 Pod 只能运行在节点 `kube-01` 之上。
## {{% heading "whatsnext" %}}
-[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)
-允许节点*排斥*一组 Pod。
+* 进一步阅读[污点与容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)文档。
+* 阅读[节点亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
+ 和[Pod 间亲和性与反亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
+ 的设计文档。
+* 了解[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)如何参与节点层面资源分配决定。
+* 了解如何使用 [nodeSelector](/zh/docs/tasks/configure-pod-container/assign-pods-nodes/)。
+* 了解如何使用[亲和性和反亲和性](/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)。
-
-[节点亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)与
-[pod 间亲和性/反亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
-的设计文档包含这些功能的其他背景信息。
-
-
-一旦 Pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。
-[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)
-可以参与到节点级别的资源分配决定中。
diff --git a/content/zh/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/zh/examples/pods/pod-with-affinity-anti-affinity.yaml
new file mode 100644
index 0000000000..a7d14b2d6f
--- /dev/null
+++ b/content/zh/examples/pods/pod-with-affinity-anti-affinity.yaml
@@ -0,0 +1,32 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: with-affinity-anti-affinity
+spec:
+ affinity:
+ nodeAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ nodeSelectorTerms:
+ - matchExpressions:
+ - key: kubernetes.io/os
+ operator: In
+ values:
+ - linux
+ preferredDuringSchedulingIgnoredDuringExecution:
+ - weight: 1
+ preference:
+ matchExpressions:
+ - key: label-1
+ operator: In
+ values:
+ - key-1
+ - weight: 50
+ preference:
+ matchExpressions:
+ - key: label-2
+ operator: In
+ values:
+ - key-2
+ containers:
+ - name: with-node-affinity
+ image: k8s.gcr.io/pause:2.0
\ No newline at end of file
From 812dafd7efa04ade1d497cff525d2b555bfdbb3b Mon Sep 17 00:00:00 2001
From: Mengjiao Liu
Date: Tue, 12 Apr 2022 12:05:40 +0800
Subject: [PATCH 079/167] Fix mysql-configmap.yaml error
---
content/en/examples/application/mysql/mysql-configmap.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/content/en/examples/application/mysql/mysql-configmap.yaml b/content/en/examples/application/mysql/mysql-configmap.yaml
index 519334bc82..6aa5bfe4e5 100644
--- a/content/en/examples/application/mysql/mysql-configmap.yaml
+++ b/content/en/examples/application/mysql/mysql-configmap.yaml
@@ -9,8 +9,10 @@ data:
# Apply this config only on the primary.
[mysqld]
log-bin
+ datadir=/var/lib/mysql/mysql
replica.cnf: |
# Apply this config only on replicas.
[mysqld]
super-read-only
+ datadir=/var/lib/mysql/mysql
From 70cabe4a5bffa188c5d7176a1fc87e3ba0dde916 Mon Sep 17 00:00:00 2001
From: Mengjiao Liu
Date: Tue, 12 Apr 2022 14:57:13 +0800
Subject: [PATCH 080/167] [zh] Sync mysql-configmap.yaml
---
.../zh/examples/application/mysql/mysql-configmap.yaml | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/content/zh/examples/application/mysql/mysql-configmap.yaml b/content/zh/examples/application/mysql/mysql-configmap.yaml
index 46d34e422c..6aa5bfe4e5 100644
--- a/content/zh/examples/application/mysql/mysql-configmap.yaml
+++ b/content/zh/examples/application/mysql/mysql-configmap.yaml
@@ -5,12 +5,14 @@ metadata:
labels:
app: mysql
data:
- master.cnf: |
- # Apply this config only on the master.
+ primary.cnf: |
+ # Apply this config only on the primary.
[mysqld]
log-bin
- slave.cnf: |
- # Apply this config only on slaves.
+ datadir=/var/lib/mysql/mysql
+ replica.cnf: |
+ # Apply this config only on replicas.
[mysqld]
super-read-only
+ datadir=/var/lib/mysql/mysql
From 224b80dbc473dd973e7c7344f4718cd98e568908 Mon Sep 17 00:00:00 2001
From: Mengjiao Liu
Date: Tue, 12 Apr 2022 15:08:27 +0800
Subject: [PATCH 081/167] [ja]Sync mysql-configmap.yaml
---
.../ja/examples/application/mysql/mysql-configmap.yaml | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/content/ja/examples/application/mysql/mysql-configmap.yaml b/content/ja/examples/application/mysql/mysql-configmap.yaml
index 46d34e422c..6aa5bfe4e5 100644
--- a/content/ja/examples/application/mysql/mysql-configmap.yaml
+++ b/content/ja/examples/application/mysql/mysql-configmap.yaml
@@ -5,12 +5,14 @@ metadata:
labels:
app: mysql
data:
- master.cnf: |
- # Apply this config only on the master.
+ primary.cnf: |
+ # Apply this config only on the primary.
[mysqld]
log-bin
- slave.cnf: |
- # Apply this config only on slaves.
+ datadir=/var/lib/mysql/mysql
+ replica.cnf: |
+ # Apply this config only on replicas.
[mysqld]
super-read-only
+ datadir=/var/lib/mysql/mysql
From 7e0a2162d71bc9ab716246991adabaa56bf5ded4 Mon Sep 17 00:00:00 2001
From: Mengjiao Liu
Date: Tue, 12 Apr 2022 16:46:38 +0800
Subject: [PATCH 082/167] Fix missing links
---
content/en/docs/concepts/security/pod-security-standards.md | 2 +-
.../debug-application-cluster/resource-metrics-pipeline.md | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md
index b8c2c2771f..393468ac74 100644
--- a/content/en/docs/concepts/security/pod-security-standards.md
+++ b/content/en/docs/concepts/security/pod-security-standards.md
@@ -478,7 +478,7 @@ in the Pod manifest, and represent parameters to the container runtime.
Security profiles are control plane mechanisms to enforce specific settings in the Security Context,
as well as other related parameters outside the Security Context. As of July 2021,
-[Pod Security Policies](/docs/concepts/profile/pod-security-profile/) are deprecated in favor of the
+[Pod Security Policies](/docs/concepts/security/pod-security-policy/) are deprecated in favor of the
built-in [Pod Security Admission Controller](/docs/concepts/security/pod-security-admission/).
{{% thirdparty-content %}}
diff --git a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
index 12a692b2f4..77d72e3649 100644
--- a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+++ b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
@@ -194,7 +194,7 @@ both Linux and Windows kernels). The time window used to calculate CPU is shown
in Metrics API.
To learn more about how Kubernetes allocates and measures CPU resources, see
-[meaning of CPU](/docs/concepts/configuration/manage-resources-container/#meaning-of-cpu).
+[meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu).
### Memory
@@ -209,7 +209,7 @@ anonymous memory associated with the container in question. The working set metr
includes some cached (file-backed) memory, because the host OS cannot always reclaim pages.
To learn more about how Kubernetes allocates and measures memory resources, see
-[meaning of memory](/docs/concepts/configuration/manage-resources-container/#meaning-of-memory).
+[meaning of memory](/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory).
## Metrics Server
From 479a59943886a08ea8a1809d4838de73480604a6 Mon Sep 17 00:00:00 2001
From: Qiming Teng
Date: Wed, 9 Mar 2022 20:42:22 +0800
Subject: [PATCH 083/167] [zh] Resync feature gates
---
.../feature-gates.md | 783 +++++++++++-------
1 file changed, 488 insertions(+), 295 deletions(-)
diff --git a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
index 9cee580e00..fdd88a3ad6 100644
--- a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
@@ -45,7 +45,8 @@ on each Kubernetes component.
Each Kubernetes component lets you enable or disable a set of feature gates that
are relevant to that component.
Use `-h` flag to see a full set of feature gates for all components.
-To set feature gates for a component, such as kubelet, use the `--feature-gates` flag assigned to a list of feature pairs:
+To set feature gates for a component, such as kubelet, use the `--feature-gates`
+flag assigned to a list of feature pairs:
-->
每个 Kubernetes 组件都支持启用或禁用与该组件相关的一组特性门控。
使用 `-h` 参数来查看所有组件支持的完整特性门控。
@@ -101,7 +102,7 @@ different Kubernetes components.
|---------|---------|-------|---------------|---------------|
| `APIListChunking` | `false` | Alpha | 1.8 | 1.8 |
| `APIListChunking` | `true` | Beta | 1.9 | |
-| `APIPriorityAndFairness` | `false` | Alpha | 1.17 | 1.19 |
+| `APIPriorityAndFairness` | `false` | Alpha | 1.18 | 1.19 |
| `APIPriorityAndFairness` | `true` | Beta | 1.20 | |
| `APIResponseCompression` | `false` | Alpha | 1.7 | 1.15 |
| `APIResponseCompression` | `true` | Beta | 1.16 | |
@@ -113,50 +114,58 @@ different Kubernetes components.
| `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | |
| `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
| `CPUManager` | `true` | Beta | 1.10 | |
-| `CPUManagerPolicyOptions` | `false` | Alpha | 1.22 | |
+| `CPUManagerPolicyAlphaOptions` | `false` | Alpha | 1.23 | |
+| `CPUManagerPolicyBetaOptions` | `true` | Beta | 1.23 | |
+| `CPUManagerPolicyOptions` | `false` | Alpha | 1.22 | 1.22 |
+| `CPUManagerPolicyOptions` | `true` | Beta | 1.23 | |
| `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 |
| `CSIInlineVolume` | `true` | Beta | 1.16 | - |
| `CSIMigration` | `false` | Alpha | 1.14 | 1.16 |
| `CSIMigration` | `true` | Beta | 1.17 | |
-| `CSIMigrationAWS` | `false` | Alpha | 1.14 | |
-| `CSIMigrationAWS` | `false` | Beta | 1.17 | |
+| `CSIMigrationAWS` | `false` | Alpha | 1.14 | 1.16 |
+| `CSIMigrationAWS` | `false` | Beta | 1.17 | 1.22 |
+| `CSIMigrationAWS` | `true` | Beta | 1.23 | |
| `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | 1.18 |
-| `CSIMigrationAzureDisk` | `false` | Beta | 1.19 | |
+| `CSIMigrationAzureDisk` | `false` | Beta | 1.19 | 1.22 |
+| `CSIMigrationAzureDisk` | `true` | Beta | 1.23 | |
| `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | 1.19 |
| `CSIMigrationAzureFile` | `false` | Beta | 1.21 | |
| `CSIMigrationGCE` | `false` | Alpha | 1.14 | 1.16 |
-| `CSIMigrationGCE` | `false` | Beta | 1.17 | |
+| `CSIMigrationGCE` | `false` | Beta | 1.17 | 1.22 |
+| `CSIMigrationGCE` | `true` | Beta | 1.23 | |
| `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | 1.17 |
| `CSIMigrationOpenStack` | `true` | Beta | 1.18 | |
| `CSIMigrationvSphere` | `false` | Beta | 1.19 | |
+| `CSIMigrationPortworx` | `false` | Alpha | 1.23 | |
+| `csiMigrationRBD` | `false` | Alpha | 1.23 | |
| `CSIStorageCapacity` | `false` | Alpha | 1.19 | 1.20 |
| `CSIStorageCapacity` | `true` | Beta | 1.21 | |
-| `CSIVolumeFSGroupPolicy` | `false` | Alpha | 1.19 | 1.19 |
-| `CSIVolumeFSGroupPolicy` | `true` | Beta | 1.20 | |
| `CSIVolumeHealth` | `false` | Alpha | 1.21 | |
| `CSRDuration` | `true` | Beta | 1.22 | |
-| `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | 1.19 |
-| `ConfigurableFSGroupPolicy` | `true` | Beta | 1.20 | |
| `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | 1.21 |
| `ControllerManagerLeaderMigration` | `true` | Beta | 1.22 | |
| `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
+| `CustomResourceValidationExpressions` | `false` | Alpha | 1.23 | |
| `DaemonSetUpdateSurge` | `false` | Alpha | 1.21 | 1.21 |
| `DaemonSetUpdateSurge` | `true` | Beta | 1.22 | |
| `DefaultPodTopologySpread` | `false` | Alpha | 1.19 | 1.19 |
| `DefaultPodTopologySpread` | `true` | Beta | 1.20 | |
-| `DelegateFSGroupToCSIDriver` | `false` | Alpha | 1.22 | |
+| `DelegateFSGroupToCSIDriver` | `false` | Alpha | 1.22 | 1.22 |
+| `DelegateFSGroupToCSIDriver` | `true` | Beta | 1.23 | |
| `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 |
| `DevicePlugins` | `true` | Beta | 1.10 | |
| `DisableAcceleratorUsageMetrics` | `false` | Alpha | 1.19 | 1.19 |
| `DisableAcceleratorUsageMetrics` | `true` | Beta | 1.20 | |
| `DisableCloudProviders` | `false` | Alpha | 1.22 | |
+| `DisableKubeletCloudCredentialProviders` | `false` | Alpha | 1.23 | |
| `DownwardAPIHugePages` | `false` | Alpha | 1.20 | 1.20 |
| `DownwardAPIHugePages` | `false` | Beta | 1.21 | |
| `EfficientWatchResumption` | `false` | Alpha | 1.20 | 1.20 |
| `EfficientWatchResumption` | `true` | Beta | 1.21 | |
| `EndpointSliceTerminatingCondition` | `false` | Alpha | 1.20 | 1.21 |
| `EndpointSliceTerminatingCondition` | `true` | Beta | 1.22 | |
-| `EphemeralContainers` | `false` | Alpha | 1.16 | |
+| `EphemeralContainers` | `false` | Alpha | 1.16 | 1.22 |
+| `EphemeralContainers` | `true` | Beta | 1.23 | |
| `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 |
| `ExpandCSIVolumes` | `true` | Beta | 1.16 | |
| `ExpandedDNSConfig` | `false` | Alpha | 1.22 | |
@@ -165,28 +174,34 @@ different Kubernetes components.
| `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 |
| `ExpandPersistentVolumes` | `true` | Beta | 1.11 | |
| `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
-| `GenericEphemeralVolume` | `false` | Alpha | 1.19 | 1.20 |
-| `GenericEphemeralVolume` | `true` | Beta | 1.21 | |
| `GracefulNodeShutdown` | `false` | Alpha | 1.20 | 1.20 |
| `GracefulNodeShutdown` | `true` | Beta | 1.21 | |
+| `GracefulNodeShutdownBasedOnPodPriority` | `false` | Alpha | 1.23 | |
+| `GRPCContainerProbe` | `false` | Alpha | 1.23 | |
+| `HonorPVReclaimPolicy` | `false` | Alpha | 1.23 | |
| `HPAContainerMetrics` | `false` | Alpha | 1.20 | |
| `HPAScaleToZero` | `false` | Alpha | 1.16 | |
+| `IdentifyPodOS` | `false` | Alpha | 1.23 | |
| `IndexedJob` | `false` | Alpha | 1.21 | 1.21 |
| `IndexedJob` | `true` | Beta | 1.22 | |
-| `IngressClassNamespacedParams` | `false` | Alpha | 1.21 | 1.21 |
-| `IngressClassNamespacedParams` | `true` | Beta | 1.22 | |
| `InTreePluginAWSUnregister` | `false` | Alpha | 1.21 | |
| `InTreePluginAzureDiskUnregister` | `false` | Alpha | 1.21 | |
| `InTreePluginAzureFileUnregister` | `false` | Alpha | 1.21 | |
| `InTreePluginGCEUnregister` | `false` | Alpha | 1.21 | |
| `InTreePluginOpenStackUnregister` | `false` | Alpha | 1.21 | |
+| `InTreePluginPortworxUnregister` | `false` | Alpha | 1.23 | |
+| `InTreePluginRBDUnregister` | `false` | Alpha | 1.23 | |
| `InTreePluginvSphereUnregister` | `false` | Alpha | 1.21 | |
-| `IPv6DualStack` | `false` | Alpha | 1.15 | 1.20 |
-| `IPv6DualStack` | `true` | Beta | 1.21 | |
-| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | |
+| `JobMutableNodeSchedulingDirectives` | `true` | Beta | 1.23 | |
+| `JobReadyPods` | `false` | Alpha | 1.23 | |
+| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | 1.22 |
+| `JobTrackingWithFinalizers` | `true` | Beta | 1.23 | |
| `KubeletCredentialProviders` | `false` | Alpha | 1.20 | |
| `KubeletInUserNamespace` | `false` | Alpha | 1.22 | |
-| `KubeletPodResourcesGetAllocatable` | `false` | Alpha | 1.21 | |
+| `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
+| `KubeletPodResources` | `true` | Beta | 1.15 | |
+| `KubeletPodResourcesGetAllocatable` | `false` | Alpha | 1.21 | 1.22 |
+| `KubeletPodResourcesGetAllocatable` | `false` | Beta | 1.23 | |
| `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
| `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | |
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
@@ -201,13 +216,17 @@ different Kubernetes components.
| `NodeSwap` | `false` | Alpha | 1.22 | |
| `NonPreemptingPriority` | `false` | Alpha | 1.15 | 1.18 |
| `NonPreemptingPriority` | `true` | Beta | 1.19 | |
-| `PodDeletionCost` | `false` | Alpha | 1.21 | 1.21 |
-| `PodDeletionCost` | `true` | Beta | 1.22 | |
+| `OpenAPIEnums` | `false` | Alpha | 1.23 | |
+| `OpenAPIV3` | `false` | Alpha | 1.23 | |
+| `PodAndContainerStatsFromCRI` | `false` | Alpha | 1.23 | |
| `PodAffinityNamespaceSelector` | `false` | Alpha | 1.21 | 1.21 |
| `PodAffinityNamespaceSelector` | `true` | Beta | 1.22 | |
+| `PodDeletionCost` | `false` | Alpha | 1.21 | 1.21 |
+| `PodDeletionCost` | `true` | Beta | 1.22 | |
| `PodOverhead` | `false` | Alpha | 1.16 | 1.17 |
| `PodOverhead` | `true` | Beta | 1.18 | |
-| `PodSecurity` | `false` | Alpha | 1.22 | |
+| `PodSecurity` | `false` | Alpha | 1.22 | 1.22 |
+| `PodSecurity` | `true` | Beta | 1.23 | |
| `PreferNominatedNode` | `false` | Alpha | 1.21 | 1.21 |
| `PreferNominatedNode` | `true` | Beta | 1.22 | |
| `ProbeTerminationGracePeriod` | `false` | Alpha | 1.21 | 1.21 |
@@ -216,6 +235,7 @@ different Kubernetes components.
| `ProxyTerminatingEndpoints` | `false` | Alpha | 1.22 | |
| `QOSReserved` | `false` | Alpha | 1.11 | |
| `ReadWriteOncePod` | `false` | Alpha | 1.22 | |
+| `RecoverVolumeExpansionFailure` | `false` | Alpha | 1.23 | |
| `RemainingItemCount` | `false` | Alpha | 1.15 | 1.15 |
| `RemainingItemCount` | `true` | Beta | 1.16 | |
| `RemoveSelfLink` | `false` | Alpha | 1.16 | 1.19 |
@@ -231,22 +251,24 @@ different Kubernetes components.
| `ServiceLoadBalancerClass` | `true` | Beta | 1.22 | |
| `SizeMemoryBackedVolumes` | `false` | Alpha | 1.20 | 1.21 |
| `SizeMemoryBackedVolumes` | `true` | Beta | 1.22 | |
-| `StatefulSetMinReadySeconds` | `false` | Alpha | 1.22 | |
+| `StatefulSetAutoDeletePVC` | `false` | Alpha | 1.22 | |
+| `StatefulSetMinReadySeconds` | `false` | Alpha | 1.22 | 1.22 |
+| `StatefulSetMinReadySeconds` | `true` | Beta | 1.23 | |
| `StorageVersionAPI` | `false` | Alpha | 1.20 | |
| `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
| `StorageVersionHash` | `true` | Beta | 1.15 | |
| `SuspendJob` | `false` | Alpha | 1.21 | 1.21 |
| `SuspendJob` | `true` | Beta | 1.22 | |
-| `TTLAfterFinished` | `false` | Alpha | 1.12 | 1.20 |
-| `TTLAfterFinished` | `true` | Beta | 1.21 | |
-| `TopologyAwareHints` | `false` | Alpha | 1.21 | |
+| `TopologyAwareHints` | `false` | Alpha | 1.21 | 1.22 |
+| `TopologyAwareHints` | `false` | Beta | 1.23 | |
| `TopologyManager` | `false` | Alpha | 1.16 | 1.17 |
| `TopologyManager` | `true` | Beta | 1.18 | |
| `VolumeCapacityPriority` | `false` | Alpha | 1.21 | - |
| `WinDSR` | `false` | Alpha | 1.14 | |
| `WinOverlay` | `false` | Alpha | 1.14 | 1.19 |
| `WinOverlay` | `true` | Beta | 1.20 | |
-| `WindowsHostProcessContainers` | `false` | Alpha | 1.22 | |
+| `WindowsHostProcessContainers` | `false` | Alpha | 1.22 | 1.22 |
+| `WindowsHostProcessContainers` | `false` | Beta | 1.23 | |
{{< /table >}}
-- `Accelerators`：使用 Docker 时启用 Nvidia GPU 支持。
+- `Accelerators`：使用 Docker Engine 时启用 Nvidia GPU 支持。这一特性不再提供。
+ 关于替代方案，请参阅[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。
- `AdvancedAuditing`：启用[高级审计功能](/zh/docs/tasks/debug-application-cluster/audit/#advanced-audit)。
- `AffinityInAnnotations`：启用 [Pod 亲和或反亲和](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)。
- `AllowExtTrafficLocalEndpoints`：启用服务用于将外部请求路由到节点本地终端。
- `AllowInsecureBackendProxy`：允许用户在执行 Pod 日志访问请求时跳过 TLS 验证。
- `AnyVolumeDataSource`: 允许使用任何自定义的资源来做作为
{{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}} 中的 `DataSource`.
-- `AppArmor`：使用 Docker 时，在 Linux 节点上启用基于 AppArmor 机制的强制访问控制。
- 请参见 [AppArmor 教程](/zh/docs/tutorials/clusters/apparmor/) 获取详细信息。
+- `AppArmor`：在 Linux 节点上为 Pod 启用基于 AppArmor 机制的强制访问控制。
+ 请参见 [AppArmor 教程](/zh/docs/tutorials/security/apparmor/) 获取详细信息。
- `AttachVolumeLimit`：启用卷插件用于报告可连接到节点的卷数限制。有关更多详细信息，请参阅
@@ -705,7 +742,26 @@ Each feature gate is designed for enabling/disabling a specific feature:
+- `CPUManager`：启用容器级别的 CPU 亲和性支持，有关更多详细信息，请参见
+ [CPU 管理策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/)。
+- `CPUManagerPolicyAlphaOptions`：允许对 CPUManager 策略进行微调，针对试验性的、
+ alpha 质量级别的选项。
+ 此特性门控用来保护一组质量级别为 alpha 的 CPUManager 选项。
+ 此特性门控永远不会被升级为 beta 或者稳定版本。
+- `CPUManagerPolicyBetaOptions`：允许对 CPUManager 策略进行微调，针对试验性的、
+ beta 质量级别的选项。
+ 此特性门控用来保护一组质量级别为 beta 的 CPUManager 选项。
+ 此特性门控永远不会被升级为稳定版本。
+- `CPUManagerPolicyOptions`: 允许微调 CPU 管理策略。
+
-- `CPUManager`：启用容器级别的 CPU 亲和性支持，有关更多详细信息，请参见
- [CPU 管理策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/)。
- `CRIContainerLogRotation`：为 CRI 容器运行时启用容器日志轮换。日志文件的默认最大大小为
10MB，缺省情况下，一个容器允许的最大日志文件数为5。这些值可以在kubelet配置中配置。
更多细节请参见 [日志架构](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)。
-- `CPUManagerPolicyOptions`: 允许微调 CPU 管理策略。
- `CSIBlockVolume`：启用外部 CSI 卷驱动程序用于支持块存储。有关更多详细信息，请参见
[`csi` 原始块卷支持](/zh/docs/concepts/storage/volumes/#csi-raw-block-volume-support)。
- `CSIDriverRegistry`：在 csi.storage.k8s.io 中启用与 CSIDriver API 对象有关的所有逻辑。
@@ -732,8 +785,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
+- `CSIMigrationAWS`：确保填充和转换逻辑能够将卷操作从 AWS-EBS 内嵌插件路由到 EBS CSI 插件。
+ 如果节点禁用了此特性门控或者未安装和配置 EBS CSI 插件，支持回退到内嵌 EBS 插件
+ 来执行卷挂载操作。不支持回退到这些插件来执行卷制备操作，因为需要安装并配置 CSI 插件。
+- `CSIMigrationAWSComplete`：停止在 kubelet 和卷控制器中注册 EBS 内嵌插件，
+ 并启用填充和转换逻辑将卷操作从 AWS-EBS 内嵌插件路由到 EBS CSI 插件。
+ 这需要启用 CSIMigration 和 CSIMigrationAWS 特性标志，并在集群中的所有节点上安装和配置
+ EBS CSI 插件。该特性标志已被废弃，取而代之的是 `InTreePluginAWSUnregister` ，
+ 后者会阻止注册 EBS 内嵌插件。
+
-- `CSIMigrationAWS`：确保填充和转换逻辑能够将卷操作从 AWS-EBS 内嵌插件路由到 EBS CSI 插件。
- 如果节点未安装和配置 EBS CSI 插件，则支持回退到内嵌 EBS 插件。
- 这需要启用 CSIMigration 特性标志。
-- `CSIMigrationAWSComplete`：停止在 kubelet 和卷控制器中注册 EBS 内嵌插件，
- 并启用 shims 和转换逻辑将卷操作从AWS-EBS 内嵌插件路由到 EBS CSI 插件。
- 这需要启用 CSIMigration 和 CSIMigrationAWS 特性标志，并在集群中的所有节点上安装和配置
- EBS CSI 插件。该特性标志已被废弃，取而代之的是 `InTreePluginAWSUnregister` ，这会阻止注册 EBS 内嵌插件。
-- `CSIMigrationAzureDisk`：确保填充和转换逻辑能够将卷操作从 Azure 磁盘内嵌插件路由到
- Azure 磁盘 CSI 插件。如果节点未安装和配置 AzureDisk CSI 插件，
- 支持回退到内建 AzureDisk 插件。这需要启用 CSIMigration 特性标志。
+- `CSIMigrationAzureDisk`：确保填充和转换逻辑能够将卷操作从 AzureDisk 内嵌插件路由到
+ Azure 磁盘 CSI 插件。对于禁用了此特性的节点或者没有安装并配置 AzureDisk CSI
+ 插件的节点，支持回退到内嵌（in-tree）AzureDisk 插件来执行磁盘挂载操作。
+ 不支持回退到内嵌插件来执行磁盘制备操作，因为对应的 CSI 插件必须已安装且正确配置。
+ 此特性需要启用 CSIMigration 特性标志。
- `CSIMigrationAzureDiskComplete`：停止在 kubelet 和卷控制器中注册 Azure 磁盘内嵌插件，
并启用 shims 和转换逻辑以将卷操作从 Azure 磁盘内嵌插件路由到 AzureDisk CSI 插件。
这需要启用 CSIMigration 和 CSIMigrationAzureDisk 特性标志，
@@ -773,9 +835,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
-- `CSIMigrationAzureFile`：确保封装和转换逻辑能够将卷操作从 Azure 文件内嵌插件路由到
- Azure 文件 CSI 插件。如果节点未安装和配置 AzureFile CSI 插件，
- 支持回退到内嵌 AzureFile 插件。这需要启用 CSIMigration 特性标志。
+- `CSIMigrationAzureFile`：确保封装和转换逻辑能够将卷操作从 AzureFile 内嵌插件路由到
+ AzureFile CSI 插件。对于禁用了此特性的节点或者没有安装并配置 AzureFile CSI
+ 插件的节点，支持回退到内嵌（in-tree）AzureFile 插件来执行卷挂载操作。
+ 不支持回退到内嵌插件来执行卷制备操作，因为对应的 CSI 插件必须已安装且正确配置。
+ 此特性需要启用 CSIMigration 特性标志。
- `CSIMigrationAzureFileComplete`：停止在 kubelet 和卷控制器中注册 Azure-File 内嵌插件，
并启用 shims 和转换逻辑以将卷操作从 Azure-File 内嵌插件路由到 AzureFile CSI 插件。
这需要启用 CSIMigration 和 CSIMigrationAzureFile 特性标志，
@@ -795,8 +861,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
-- `CSIMigrationGCE`：启用 shims 和转换逻辑，将卷操作从 GCE-PD 内嵌插件路由到
- PD CSI 插件。如果节点未安装和配置 PD CSI 插件，支持回退到内嵌 GCE 插件。
- 这需要启用 CSIMigration 特性标志。
+- `CSIMigrationGCE`：启用填充和转换逻辑，将卷操作从 GCE-PD 内嵌插件路由到
+ PD CSI 插件。对于禁用了此特性的节点或者没有安装并配置 PD CSI 插件的节点，
+ 支持回退到内嵌（in-tree）GCE 插件来执行挂载操作。
+ 不支持回退到内嵌插件来执行制备操作，因为对应的 CSI 插件必须已安装且正确配置。
+ 此特性需要启用 CSIMigration 特性标志。
- `CSIMigrationGCEComplete`：停止在 kubelet 和卷控制器中注册 GCE-PD 内嵌插件，
并启用 shims 和转换逻辑以将卷操作从 GCE-PD 内嵌插件路由到 PD CSI 插件。
这需要启用 CSIMigration 和 CSIMigrationGCE 特性标志，并在集群中的所有节点上
安装和配置 PD CSI 插件。该特性标志已被废弃，取而代之的是
能防止注册内嵌 GCE PD 插件的 `InTreePluginGCEUnregister` 特性标志。
+- `csiMigrationRBD`：启用填充和转换逻辑，将卷操作从 RBD 的内嵌插件路由到 Ceph RBD
+ CSI 插件。此特性要求 CSIMigration 和 csiMigrationRBD 特性标志均被启用，
+ 且集群中安装并配置了 Ceph CSI 插件。此标志已被弃用，以鼓励使用
+ `InTreePluginRBDUnregister` 特性标志。后者会禁止注册内嵌的 RBD 插件。
+
- `CSIMigrationOpenStack`：确保填充和转换逻辑能够将卷操作从 Cinder 内嵌插件路由到
- Cinder CSI 插件。如果节点未安装和配置 Cinder CSI 插件，支持回退到内嵌 Cinder 插件。
- 这需要启用 CSIMigration 特性标志。
+ Cinder CSI 插件。对于禁用了此特性的节点或者没有安装并配置 Cinder CSI 插件的节点，
+ 支持回退到内嵌（in-tree）Cinder 插件来执行挂载操作。
+ 不支持回退到内嵌插件来执行制备操作，因为对应的 CSI 插件必须已安装且正确配置。
+ 此磁特性需要启用 CSIMigration 特性标志。
- `CSIMigrationOpenStackComplete`：停止在 kubelet 和卷控制器中注册 Cinder 内嵌插件，
- 并启用 shims 和转换逻辑将卷操作从 Cinder 内嵌插件路由到 Cinder CSI 插件。
+ 并启用填充和转换逻辑将卷操作从 Cinder 内嵌插件路由到 Cinder CSI 插件。
这需要启用 CSIMigration 和 CSIMigrationOpenStack 特性标志，并在集群中的所有节点上
- 安装和配置 Cinder CSI 插件。该特性标志已被废弃，取而代之的是
- 能防止注册内嵌 openstack cinder 插件的 `InTreePluginOpenStackUnregister` 特性标志。
+ 安装和配置 Cinder CSI 插件。该特性标志已被弃用，取而代之的是
+ 能防止注册内嵌 OpenStack Cinder 插件的 `InTreePluginOpenStackUnregister` 特性标志。
- `CSIMigrationvSphere`: 允许封装和转换逻辑将卷操作从 vSphere 内嵌插件路由到
- vSphere CSI 插件。如果节点未安装和配置 vSphere CSI 插件，则支持回退到
- vSphere 内嵌插件。这需要启用 CSIMigration 特性标志。
+ vSphere CSI 插件。如果节点禁用了此特性门控或者未安装和配置 vSphere CSI 插件，
+ 则支持回退到 vSphere 内嵌插件来执行挂载操作。
+ 不支持回退到内嵌插件来执行制备操作，因为对应的 CSI 插件必须已安装且正确配置。
+ 这需要启用 CSIMigration 特性标志。
- `CSIMigrationvSphereComplete`: 停止在 kubelet 和卷控制器中注册 vSphere 内嵌插件，
- 并启用 shims 和转换逻辑以将卷操作从 vSphere 内嵌插件路由到 vSphere CSI 插件。
+ 并启用填充和转换逻辑以将卷操作从 vSphere 内嵌插件路由到 vSphere CSI 插件。
这需要启用 CSIMigration 和 CSIMigrationvSphere 特性标志，并在集群中的所有节点上
安装和配置 vSphere CSI 插件。该特性标志已被废弃，取而代之的是
能防止注册内嵌 vsphere 插件的 `InTreePluginvSphereUnregister` 特性标志。
+- `CSIMigrationPortworx`：启用填充和转换逻辑，将卷操作从 Portworx 内嵌插件路由到
+ Portworx CSI 插件。需要在集群中安装并配置 Portworx CSI 插件，并针对 kube-controller-manager
+ 和 kubelet 配置启用特性门控 `CSIMigrationPortworx=true`。
+
-- `CSIVolumeFSGroupPolicy`: 允许 CSIDrivers 使用 `fsGroupPolicy` 字段.
+- `CSIVolumeFSGroupPolicy`：允许 CSIDrivers 使用 `fsGroupPolicy` 字段.
该字段能控制由 CSIDriver 创建的卷在挂载这些卷时是否支持卷所有权和权限修改。
-- `CSIVolumeHealth`: 启用对节点上的 CSI volume 运行状况监控的支持
-- `CSRDuration`: 允许客户端来通过请求 Kubernetes CSR API 签署的证书的持续时间。
+- `CSIVolumeHealth`：启用对节点上的 CSI volume 运行状况监控的支持
+- `CSRDuration`：允许客户端来通过请求 Kubernetes CSR API 签署的证书的持续时间。
- `ConfigurableFSGroupPolicy`：在 Pod 中挂载卷时，允许用户为 fsGroup
配置卷访问权限和属主变更策略。请参见
[为 Pod 配置卷访问权限和属主变更策略](/zh/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)。
-- `ControllerManagerLeaderMigration`: 为 `kube-controller-manager` 和 `cloud-controller-manager`
- 开启 leader 迁移功能。
+- `ControllerManagerLeaderMigration`：为 `kube-controller-manager` 和 `cloud-controller-manager`
+ 开启领导者迁移功能。
- `CronJobControllerV2`：使用 {{< glossary_tooltip text="CronJob" term_id="cronjob" >}}
控制器的一种替代实现。否则，系统会选择同一控制器的 v1 版本。
+- `CustomCPUCFSQuotaPeriod`：使节点能够更改
+ [kubelet 配置](/zh/docs/tasks/administer-cluster/kubelet-config-file/)
+ 中的 `cpuCFSQuotaPeriod`。
+- `CustomResourceValidationExpressions`：启用 CRD 中的表达式语言合法性检查，
+ 基于 `x-kubernetes-validations` 扩展中所书写的合法性检查规则来验证定制资源。
+- `CustomPodDNS`：允许使用 Pod 的 `dnsConfig` 属性自定义其 DNS 设置。
+ 更多详细信息，请参见
+ [Pod 的 DNS 配置](/zh/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)。
+
-- `CustomCPUCFSQuotaPeriod`：使节点能够更改
- [kubelet 配置](/zh/docs/tasks/administer-cluster/kubelet-config-file/).
- 中的 `cpuCFSQuotaPeriod`。
-- `CustomPodDNS`：允许使用 Pod 的 `dnsConfig` 属性自定义其 DNS 设置。
- 更多详细信息，请参见
- [Pod 的 DNS 配置](/zh/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)。
- `CustomResourceDefaulting`：为 CRD 启用在其 OpenAPI v3 验证模式中提供默认值的支持。
- `CustomResourcePublishOpenAPI`：启用 CRD OpenAPI 规范的发布。
- `CustomResourceSubresources`：对于用
@@ -938,6 +1046,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
[CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
创建的资源启用基于 Webhook 的转换。
- `DaemonSetUpdateSurge`: 使 DaemonSet 工作负载在每个节点的更新期间保持可用性。
+ 参阅[对 DaemonSet 执行滚动更新](/zh/docs/tasks/manage-daemon/update-daemon-set/)。
- `DefaultPodTopologySpread`: 启用 `PodTopologySpread` 调度插件来完成
[默认的调度传播](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
@@ -963,18 +1064,31 @@ Each feature gate is designed for enabling/disabling a specific feature:
NodePublishVolume CSI 调用传递 `fsGroup` ，将应用 `fsGroup` 从 Pod 的
`securityContext` 的角色委托给驱动。
- `DevicePlugins`：在节点上启用基于
- [设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)的
- 资源制备。
+ [设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
+ 的资源制备。
- `DisableAcceleratorUsageMetrics`：
[禁用 kubelet 收集加速器指标](/zh/docs/concepts/cluster-administration/system-metrics/#disable-accelerator-metrics).
-- `DisableCloudProviders`: 禁用 `kube-apiserver`，
- `kube-controller-manager` 和 `kubelet` 组件的 `--cloud-provider` 标志相关
- 的所有功能。
+
+- `DisableCloudProviders`: 禁用 `kube-apiserver`，`kube-controller-manager` 和
+ `kubelet` 组件的 `--cloud-provider` 标志相关的所有功能。
+- `DisableKubeletCloudCredentialProviders`：禁用 kubelet 中为拉取镜像内置的凭据机制，
+ 该凭据用于向某云提供商的容器镜像仓库执行身份认证。
- `DownwardAPIHugePages`：允许在
[下行（Downward）API](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information)
中使用巨页信息。
- `DryRun`：启用在服务器端对请求进行
- [彩排（Dry Run）](/zh/docs/reference/using-api/api-concepts/#dry-run)，
+ [试运行（Dry Run）](/zh/docs/reference/using-api/api-concepts/#dry-run)，
以便测试验证、合并和修改，同时避免提交更改。
- `DynamicAuditing`：在 v1.19 版本前用于启用动态审计。
- `EnableEquivalenceClassCache`：调度 Pod 时，使 scheduler 缓存节点的等效项。
- `EndpointSlice`：启用 EndpointSlice 以实现可扩缩性和可扩展性更好的网络端点。
- 参阅[启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。
+ 参阅[启用 EndpointSlice](/zh/docs/concepts/services-networking/endpoint-slices/)。
- `EndpointSliceNodeName`：允许使用 EndpointSlice 的 `nodeName` 字段。
- `EndpointSliceProxying`：启用此特性门控时，Linux 上运行的 kube-proxy 会使用
- EndpointSlices 而不是 Endpoints 作为其主要数据源，从而使得可扩缩性和性能
- 提升成为可能。参阅
- [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。
+ EndpointSlices 而不是 Endpoints 作为其主要数据源，从而使得可扩缩性和性能提升成为可能。
+ 参阅[启用 EndpointSlice](/zh/docs/concepts/services-networking/endpoint-slices/)。
- `EndpointSliceTerminatingCondition`：允许使用 EndpointSlice 的 `terminating` 和
`serving` 状况字段。
- `ExpandCSIVolumes`: 启用扩展 CSI 卷。
- `ExpandedDNSConfig`: 在 kubelet 和 kube-apiserver 上启用后，
- 允许更多的 DNS 搜索域和搜索域列表。 参阅
+ 允许使用更多的 DNS 搜索域和搜索域列表。此功能特性需要容器运行时
+ （Containerd：v1.5.6 或更高，CRI-O：v1.22 或更高）的支持。参阅
[扩展 DNS 配置](/zh/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration).
- `ExpandInUsePersistentVolumes`：启用扩充使用中的 PVC 的尺寸。请查阅
[调整使用中的 PersistentVolumeClaim 的大小](/zh/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)。
@@ -1089,16 +1204,29 @@ Each feature gate is designed for enabling/disabling a specific feature:
这适用于使用其他主机名字空间、主机安装的容器，或具有特权或使用特定的非名字空间功能
（例如 MKNODE、SYS_MODULE 等）的容器。
如果在 Docker 守护程序中启用了用户名字空间重新映射，则启用此选项。
-- `ExternalPolicyForExternalIP`： 修复 ExternalPolicyForExternalIP 没有应用于 Service ExternalIPs 的 bug。
+- `ExternalPolicyForExternalIP`： 修复 ExternalPolicyForExternalIP 没有应用于
+ Service ExternalIPs 的缺陷。
- `GCERegionalPersistentDisk`：在 GCE 上启用带地理区域信息的 PD 特性。
- `GenericEphemeralVolume`：启用支持临时的内联卷，这些卷支持普通卷
- （可以由第三方存储供应商提供、存储容量跟踪、从快照还原等等）的所有功能。请参见
- [临时卷](/zh/docs/concepts/storage/ephemeral-volumes/)。
+ （可以由第三方存储供应商提供、存储容量跟踪、从快照还原等等）的所有功能。
+ 请参见[临时卷](/zh/docs/concepts/storage/ephemeral-volumes/)。
- `GracefulNodeShutdown`：在 kubelet 中启用体面地关闭节点的支持。
- 在系统关闭时，kubelet 会尝试监测该事件并体面地终止节点上运行的 Pods。参阅
- [体面地关闭节点](/zh/docs/concepts/architecture/nodes/#graceful-node-shutdown)
+ 在系统关闭时，kubelet 会尝试监测该事件并体面地终止节点上运行的 Pods。
+ 参阅[体面地关闭节点](/zh/docs/concepts/architecture/nodes/#graceful-node-shutdown)
以了解更多细节。
+- `GracefulNodeShutdownBasedOnPodPriority`：允许 kubelet 在体面终止节点时检查
+ Pod 的优先级。
+- `GRPCContainerProbe`：为 LivenessProbe、ReadinessProbe、StartupProbe 启用 gRPC 探针。
+ 参阅[配置活跃态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)。
+- `HonorPVReclaimPolicy`：无论 PV 和 PVC 的删除顺序如何，当持久卷申领的策略为 `Delete`
+ 时，确保这种策略得到处理。
+
- `HPAContainerMetrics`：允许 `HorizontalPodAutoscaler` 基于目标 Pods 中各容器
的度量值来执行扩缩操作。
@@ -1116,11 +1247,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
[巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。
- `HugePageStorageMediumSize`：启用支持多种大小的预分配
[巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。
-
+- `HyperVContainer`：为 Windows 容器启用
+ [Hyper-V 隔离](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)。
+- `IdentifyPodOS`：允许设置 Pod 的 OS 字段。这一设置有助于在 API 服务器准入期间确定性地辨识
+ Pod 的 OS。在 Kubernetes {{< skew currentVersion >}} 中，`pod.spec.os.name` 可选的值包括
+ `windows` 和 `linux`。
+- `ImmutableEphemeralVolumes`：允许将各个 Secret 和 ConfigMap 标记为不可变更的，
+ 以提高安全性和性能。
+- `InTreePluginAWSUnregister`: 在 kubelet 和卷控制器上关闭注册 aws-ebs 内嵌插件。
+- `InTreePluginAzureDiskUnregister`: 在 kubelet 和卷控制器上关闭注册 azuredisk 内嵌插件。
+- `InTreePluginAzureFileUnregister`: 在 kubelet 和卷控制器上关闭注册 azurefile 内嵌插件。
+
+- `InTreePluginGCEUnregister`: 在 kubelet 和卷控制器上关闭注册 gce-pd 内嵌插件。
+- `InTreePluginOpenStackUnregister`: 在 kubelet 和卷控制器上关闭注册 OpenStack cinder 内嵌插件。
+- `InTreePluginPortworxUnregister`: 在 kubelet 和卷控制器上关闭注册 Portworx 内嵌插件。
+- `InTreePluginRBDUnregister`: 在 kubelet 和卷控制器上关闭注册 RBD 内嵌插件。
+
+- `InTreePluginvSphereUnregister`: 在 kubelet 和卷控制器上关闭注册 vSphere 内嵌插件。
+- `IndexedJob`：允许 [Job](/zh/docs/concepts/workloads/controllers/job/)
+ 控制器根据完成索引来管理 Pod 完成。
+- `IngressClassNamespacedParams`：允许在 `IngressClass` 资源中引用命名空间范围的参数。
+ 该特性增加了两个字段 —— `scope`、`namespace` 到 `IngressClass.spec.parameters`。
+- `Initializers`： 使用 Initializers 准入插件允许异步协调对象创建。
+
+- `IPv6DualStack`：启用[双协议栈](/zh/docs/concepts/services-networking/dual-stack/)
+ 以支持 IPv6。
+- `JobMutableNodeSchedulingDirectives`：允许在 [Job](/docs/concepts/workloads/controllers/job)
+ 的 Pod 模板中更新节点调度指令。
+- `JobReadyPods`：允许跟踪[状况](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)为
+ `Ready` 的 Pod 的个数。`Ready` 的 Pod 记录在
+ [Job](/zh/docs/concepts/workloads/controllers/job) 对象的
+ [status](/docs/reference/kubernetes-api/workload-resources/job-v1/#JobStatus) 字段中。
+
+- `JobTrackingWithFinalizers`: 启用跟踪 [Job](/zh/docs/concepts/workloads/controllers/job)
+ 完成情况，而不是永远从集群剩余 Pod 来获取信息判断完成情况。Job 控制器使用
+ Pod finalizers 和 Job 状态中的一个字段来跟踪已完成的 Pod 以计算完成。
+- `KubeletConfigFile`：启用从使用配置文件指定的文件中加载 kubelet 配置。
+ 有关更多详细信息，请参见
+ [通过配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file/)。
+
-- `HyperVContainer`：为 Windows 容器启用
- [Hyper-V 隔离](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)。
-- `ImmutableEphemeralVolumes`：允许将各个 Secret 和 ConfigMap 标记为不可变更的，
- 以提高安全性和性能。
-- `InTreePluginAWSUnregister`: 在 kubelet 和 卷控制器上关闭注册 aws-ebs 内嵌插件。
-- `InTreePluginAzureDiskUnregister`: 在 kubelet 和 卷控制器上关闭注册 azuredisk 内嵌插件。
-- `InTreePluginAzureFileUnregister`: 在 kubelet 和 卷控制器上关闭注册 azurefile 内嵌插件。
-- `InTreePluginGCEUnregister`: 在 kubelet 和 卷控制器上关闭注册 gce-pd 内嵌插件。
-- `InTreePluginOpenStackUnregister`: 在 kubelet 和 卷控制器上关闭注册 OpenStack cinder 内嵌插件。
-- `InTreePluginvSphereUnregister`: 在 kubelet 和 卷控制器上关闭注册 vSphere 内嵌插件。
-- `IndexedJob`：允许 [Job](/zh/docs/concepts/workloads/controllers/job/) 控制器按每个完成的索引去管理 Pod 完成。
-- `IngressClassNamespacedParams`：允许引用命名空间范围的参数引用 `IngressClass`资源。该特性增加了两个字段 —— `Scope` 和 `Namespace` 到 `IngressClass.spec.parameters`。
-- `Initializers`： 使用 Initializers 准入插件允许异步协调对象创建。
-- `IPv6DualStack`：启用 [双协议栈](/zh/docs/concepts/services-networking/dual-stack/)
- 以支持 IPv6。
-- `JobTrackingWithFinalizers`: 启用跟踪 [Job](/zh/docs/concepts/workloads/controllers/job)
- 完成情况，而不是永远从集群剩余 pod 来获取信息判断完成情况。Job 控制器使
- 用 Pod finalizers 和 Job 状态中的一个字段来跟踪已完成的 Pod 以计算完成。
-- `KubeletConfigFile`：启用从使用配置文件指定的文件中加载 kubelet 配置。
- 有关更多详细信息，请参见
- [通过配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file/)。
-- `KubeletCredentialProviders`：允许使用 kubelet exec 凭据提供程序来设置
- 镜像拉取凭据。
-- `KubeletInUserNamespace`: 支持在 {{}} 里运行 kubelet 。
- 请参见 [使用非 Root 用户来运行 Kubernetes 节点组件](/zh/docs/tasks/administer-cluster/kubelet-in-userns/).
-- `KubeletPluginsWatcher`：启用基于探针的插件监视应用程序，使 kubelet 能够发现
- 类似 [CSI 卷驱动程序](/zh/docs/concepts/storage/volumes/#csi)这类插件。
+- `KubeletCredentialProviders`：允许使用 kubelet exec 凭据提供程序来设置镜像拉取凭据。
+- `KubeletInUserNamespace`: 支持在{{}}
+ 里运行 kubelet 。
+ 请参见[使用非 Root 用户来运行 Kubernetes 节点组件](/zh/docs/tasks/administer-cluster/kubelet-in-userns/)。
+- `KubeletPluginsWatcher`：启用基于探针的插件监视应用程序，使 kubelet 能够发现类似
+ [CSI 卷驱动程序](/zh/docs/concepts/storage/volumes/#csi)这类插件。
-- `KubeletPodResources`：启用 kubelet 上 Pod 资源 GRPC 端点。更多详细信息，请参见
- [支持设备监控](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)。
-- `KubeletPodResourcesGetAllocatable`：启用 kubelet 的 pod 资源
- 的 `GetAllocatableResources` 功能。
- 该 API 增强了[资源分配报告]（/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources）
+- `KubeletPodResources`：启用 kubelet 上 Pod 资源 GRPC 端点。更多详细信息，
+ 请参见[支持设备监控](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)。
+- `KubeletPodResourcesGetAllocatable`：启用 kubelet 的 pod 资源的
+ `GetAllocatableResources` 功能。
+ 该 API 增强了[资源分配报告](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources)
包含有关可分配资源的信息，使客户端能够正确跟踪节点上的可用计算资源。
-- `LegacyNodeRoleBehavior`：禁用此门控时，服务负载均衡器中和节点干扰中的原先行为
- 会忽略 `node-role.kubernetes.io/master` 标签，使用 `NodeDisruptionExclusion` 和
+- `LegacyNodeRoleBehavior`：禁用此门控时，服务负载均衡器中和节点干扰中的原先行为会忽略
+ `node-role.kubernetes.io/master` 标签，使用 `NodeDisruptionExclusion` 和
`ServiceNodeExclusion` 对应特性所提供的标签。
+- `LocalStorageCapacityIsolation`：允许使用
+ [本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)
+ 以及 [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)的 `sizeLimit` 属性。
+- `LocalStorageCapacityIsolationFSQuotaMonitoring`：如果
+ [本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)启用了
+ `LocalStorageCapacityIsolation`，并且
+ [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)的后备文件系统支持项目配额，
+ 并且启用了这些配额，将使用项目配额来监视
+ [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)的存储消耗而不是遍历文件系统，
+ 以此获得更好的性能和准确性。
+
-- `LocalStorageCapacityIsolation`：允许使用
- [本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)
- 以及 [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir) 的 `sizeLimit` 属性。
-- `LocalStorageCapacityIsolationFSQuotaMonitoring`：如果
- [本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)
- 启用了 `LocalStorageCapacityIsolation`，并且
- [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)
- 的后备文件系统支持项目配额，并且启用了这些配额，将使用项目配额来监视
- [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)的存储消耗
- 而不是遍历文件系统，以此获得更好的性能和准确性。
-- `LogarithmicScaleDown`：启用 Pod 的半随机（semi-random）选择，控制器将根据 Pod 时间戳的对数桶按比例缩小去驱逐 Pod。
+- `LogarithmicScaleDown`：启用 Pod 的半随机（semi-random）选择，控制器将根据 Pod
+ 时间戳的对数桶按比例缩小去驱逐 Pod。
- `MemoryManager`: 允许基于 NUMA 拓扑为容器设置内存亲和性。
- `MemoryQoS`: 使用 cgroup v2 内存控制器在 pod / 容器上启用内存保护和使用限制。
-- `MixedProtocolLBService`：允许在同一 `LoadBalancer` 类型的 Service 实例中使用不同
- 的协议。
+- `MixedProtocolLBService`：允许在同一 `LoadBalancer` 类型的 Service 实例中使用不同的协议。
- `MountContainers`：允许使用主机上的工具容器作为卷挂载程序。
+- `MountPropagation`：启用将一个容器安装的共享卷共享到其他容器或 Pod。
+ 更多详细信息，请参见[挂载传播](/zh/docs/concepts/storage/volumes/#mount-propagation)。
+- `NamespaceDefaultLabelName`：配置 API 服务器以在所有名字空间上设置一个不可变的
+ {{< glossary_tooltip text="标签" term_id="label" >}} `kubernetes.io/metadata.name`，
+ 也包括名字空间。
+- `NodeDisruptionExclusion`：启用节点标签 `node.kubernetes.io/exclude-disruption`，
+ 以防止在可用区发生故障期间驱逐节点。
+- `NodeLease`：启用新的 Lease（租期）API 以报告节点心跳，可用作节点运行状况信号。
+
+- `NodeSwap`: 启用 kubelet 为节点上的 Kubernetes 工作负载分配交换内存的能力。
+ 必须将 `KubeletConfiguration.failSwapOn` 设置为 false 的情况下才能使用。
+ 更多详细信息，请参见[交换内存](/zh/docs/concepts/architecture/nodes/#swap-memory)。
+- `NonPreemptingPriority`：为 PriorityClass 和 Pod 启用 `preemptionPolicy` 选项。
+- `OpenAPIEnums`：允许在从 API 服务器返回的 spec 中填充 OpenAPI 模式的 "enum" 字段。
+- `OpenAPIV3`：允许 API 服务器发布 OpenAPI V3。
+- `PVCProtection`：启用防止仍被某 Pod 使用的 PVC 被删除的特性。
+
-- `MountPropagation`：启用将一个容器安装的共享卷共享到其他容器或 Pod。
- 更多详细信息，请参见[挂载传播](/zh/docs/concepts/storage/volumes/#mount-propagation)。
-- `NamespaceDefaultLabelName`：配置 API 服务器以在所有名字空间上设置一个不可变的 {{< glossary_tooltip text="label" term_id="label" >}}
- `kubernetes.io/metadata.name`，也包括名字空间。
-- `NodeDisruptionExclusion`：启用节点标签 `node.kubernetes.io/exclude-disruption`，
- 以防止在可用区发生故障期间驱逐节点。
-- `NodeLease`：启用新的 Lease（租期）API 以报告节点心跳，可用作节点运行状况信号。
-- `NodeSwap`: 启用 kubelet 为节点上的 Kubernetes 工作负载分配交换内存的能力。
- 必须将 `KubeletConfiguration.failSwapOn` 设置为 false 的情况下才能使用。
- 更多详细信息，请参见 [交换内存](/zh/docs/concepts/architecture/nodes/#swap-memory)。
-- `NonPreemptingPriority`：为 PriorityClass 和 Pod 启用 `preemptionPolicy` 选项。
-- `PVCProtection`：启用防止仍被某 Pod 使用的 PVC 被删除的特性。
-- `PodDeletionCost`：启用 [Pod 删除成本](/zh/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost) 功能。
+- `PodDeletionCost`：启用 [Pod 删除成本](/zh/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)功能。
该功能使用户可以影响 ReplicaSet 的降序顺序。
- `PersistentLocalVolumes`：允许在 Pod 中使用 `local（本地）` 卷类型。
如果请求 `local` 卷，则必须指定 Pod 亲和性属性。
- `PodDisruptionBudget`：启用 [PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/) 特性。
- `PodAffinityNamespaceSelector`：启用 [Pod 亲和性名称空间选择器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#namespace-selector)
- 和 [CrossNamespacePodAffinity](/zh/docs/concepts/policy/resource-quotas/#cross-namespace-pod-affinity-quota) 资源配额功能。
+ 和 [CrossNamespacePodAffinity](/zh/docs/concepts/policy/resource-quotas/#cross-namespace-pod-affinity-quota)
+ 资源配额功能。
- `PodOverhead`：启用 [PodOverhead](/zh/docs/concepts/scheduling-eviction/pod-overhead/)
特性以考虑 Pod 开销。
+- `PodPriority`：启用根据[优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
+ 的 Pod 调度和抢占。
+- `PodReadinessGates`：启用 `podReadinessGate` 字段的设置以扩展 Pod 准备状态评估。
+ 有关更多详细信息，请参见
+ [Pod 就绪状态判别](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。
+- `PodSecurity`: 开启 `PodSecurity` 准入控制插件。
+- `PodShareProcessNamespace`：在 Pod 中启用 `shareProcessNamespace` 的设置，
+ 以便在 Pod 中运行的容器之间共享同一进程名字空间。更多详细信息，请参见
+ [在 Pod 中的容器间共享同一进程名字空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)。
+- `PreferNominatedNode`: 这个标志告诉调度器在循环遍历集群中的所有其他节点之前，
+ 是否首先检查指定的节点。
+
-- `PodPriority`：根据 [优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
- 启用 Pod 的调度和抢占。
-- `PodReadinessGates`：启用 `podReadinessGate` 字段的设置以扩展 Pod 准备状态评估。
- 有关更多详细信息，请参见
- [Pod 就绪状态判别](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。
-- `PodSecurity`: 开启 `PodSecurity` 准入控制插件。
-- `PodShareProcessNamespace`：在 Pod 中启用 `shareProcessNamespace` 的设置，
- 以便在 Pod 中运行的容器之间共享同一进程名字空间。更多详细信息，请参见
- [在 Pod 中的容器间共享同一进程名字空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)。
-- `PreferNominatedNode`: 这个标志告诉调度器在循环遍历集群中的所有其他节点
- 之前，是否首先检查指定的节点。
- `ProbeTerminationGracePeriod`：在 Pod 上 启用
[设置探测器级别 `terminationGracePeriodSeconds`](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds)。
- 有关更多信息，请参见 [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)。
-- `ProcMountType`：允许容器通过设置 SecurityContext 的 `procMount` 字段来控制
- 对 proc 文件系统的挂载方式。
+ 有关更多信息，请参见[改进提案](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)。
+- `ProcMountType`：允许容器通过设置 SecurityContext 的 `procMount` 字段来控制对
+ proc 文件系统的挂载方式。
- `ProxyTerminatingEndpoints`: 当 `ExternalTrafficPolicy=Local` 时，
允许 kube-proxy 来处理终止过程中的端点。
- `QOSReserved`：允许在 QoS 级别进行资源预留，以防止处于较低 QoS 级别的 Pod
突发进入处于较高 QoS 级别的请求资源（目前仅适用于内存）。
- `ReadWriteOncePod`: 允许使用 `ReadWriteOncePod` 访问模式的 PersistentVolume。
-- `RemainingItemCount`：允许 API 服务器在
- [分块列表请求](/zh/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)
- 的响应中显示剩余条目的个数。
+- `RecoverVolumeExpansionFailure`：允许用户编辑其 PVC 来缩小其尺寸，
+ 从而从之前卷扩容发生的失败中恢复。更多细节可参见
+ [从卷扩容失效中恢复](/zh/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes)。
+- `RemainingItemCount`：允许 API 服务器在
+ [分块列表请求](/zh/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)
+ 的响应中显示剩余条目的个数。
+- `RemoveSelfLink`：将 ObjectMeta 和 ListMeta 中的 `selfLink` 字段废弃并删除。
+- `RequestManagement`：允许在每个 API 服务器上通过优先级和公平性管理请求并发性。
+ 自 1.17 以来已被 `APIPriorityAndFairness` 替代。
+
-- `RemoveSelfLink`：将 ObjectMeta 和 ListMeta 中的 `selfLink` 字段废弃并删除。
-- `RequestManagement`：允许在每个 API 服务器上通过优先级和公平性管理请求并发性。
- 自 1.17 以来已被 `APIPriorityAndFairness` 弃用。
- `ResourceLimitsPriorityFunction`：启用某调度器优先级函数，
该函数将最低得分 1 指派给至少满足输入 Pod 的 CPU 和内存限制之一的节点，
目的是打破得分相同的节点之间的关联。
- `ResourceQuotaScopeSelectors`：启用资源配额范围选择器。
- `RootCAConfigMap`：配置 `kube-controller-manager`，使之发布一个名为 `kube-root-ca.crt`
- 的 {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}，到
- 所有名字空间中。该 ConfigMap 包含用来验证与 kube-apiserver 之间连接的
- CA 证书包。参阅
- [绑定服务账户令牌](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)
+ 的 {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}，
+ 到所有名字空间中。该 ConfigMap 包含用来验证与 kube-apiserver 之间连接的 CA 证书包。
+ 参阅[绑定服务账户令牌](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)
以了解更多细节。
- `RotateKubeletClientCertificate`：在 kubelet 上启用客户端 TLS 证书的轮换。
更多详细信息，请参见
@@ -1392,17 +1574,28 @@ Each feature gate is designed for enabling/disabling a specific feature:
更多详细信息，请参见
[kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。
- `RunAsGroup`：启用对容器初始化过程中设置的主要组 ID 的控制。
-- `RuntimeClass`：启用 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)
- 特性用于选择容器运行时配置。
-- `ScheduleDaemonSetPods`：启用 DaemonSet Pods 由默认调度程序而不是
- DaemonSet 控制器进行调度。
+- `RuntimeClass`：启用 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)
+ 特性用于选择容器运行时配置。
+- `ScheduleDaemonSetPods`：启用 DaemonSet Pods 由默认调度程序而不是
+ DaemonSet 控制器进行调度。
+- `SCTPSupport`：在 Pod、Service、Endpoints、NetworkPolicy 定义中允许将 'SCTP'
+ 用作 `protocol` 值。
+- `SeccompDefault`: 允许将所有工作负载的默认 seccomp 配置文件为 `RuntimeDefault`。
+ seccomp 配置在 Pod 或者容器的 `securityContext` 字段中指定。
+- `SelectorIndex`: 允许使用 API 服务器的 watch 缓存中基于标签和字段的索引来加速 list 操作。
+
-- `SCTPSupport`：在 Pod、Service、Endpoints、NetworkPolicy 定义中
- 允许将 _SCTP_ 用作 `protocol` 值。
-- `SeccompDefault`: 允许将所有工作负载的默认 seccomp 配置文件为 `RuntimeDefault`。
- seccomp 配置在 Pod 或者容器的 `securityContext` 字段中指定。
-- `SelectorIndex`: 允许在 API 服务器 watch 的缓存中基于标签和字段的索引来加速 list 的操作。
- `ServerSideApply`：在 API 服务器上启用
[服务器端应用（SSA）](/zh/docs/reference/using-api/server-side-apply/) 。
- `ServiceAccountIssuerDiscovery`：在 API 服务器中为服务帐户颁发者启用 OIDC 发现端点
@@ -1429,10 +1614,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `ServiceAppProtocol`：为 Service 和 Endpoints 启用 `appProtocol` 字段。
- `ServiceInternalTrafficPolicy`：为服务启用 `internalTrafficPolicy` 字段。
- `ServiceLBNodePortControl`：为服务启用 `allocateLoadBalancerNodePorts` 字段。
- `ServiceLoadBalancerClass`: 为服务启用 `loadBalancerClass` 字段。
- 有关更多信息，请参见 [负载均衡器类的定义 implementation](/zh/docs/concepts/services-networking/service/#load-balancer-class)。
-- `ServiceLoadBalancerFinalizer`：为服务负载均衡启用终结器（finalizers）保护。
+- `ServiceLoadBalancerClass`: 为服务启用 `loadBalancerClass` 字段。
+ 有关更多信息，请参见[指定负载均衡器实现类](/zh/docs/concepts/services-networking/service/#load-balancer-class)。
+- `ServiceLoadBalancerFinalizer`：为服务负载均衡启用终结器（finalizers）保护。
+- `ServiceNodeExclusion`：启用从云提供商创建的负载均衡中排除节点。
+ 如果节点标记有 `node.kubernetes.io/exclude-from-external-load-balancers`，
+ 标签，则可以排除该节点。
+- `ServiceTopology`：启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。
+ 有关更多详细信息，请参见[服务拓扑](/zh/docs/concepts/services-networking/service-topology/)。
+
-- `ServiceNodeExclusion`：启用从云提供商创建的负载均衡中排除节点。
- 如果节点标记有 `node.kubernetes.io/exclude-from-external-load-balancers`，
- 标签，则可以排除该节点。
-- `ServiceTopology`：启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。
- 有关更多详细信息，请参见
- [服务拓扑](/zh/docs/concepts/services-networking/service-topology/)。
-- `SetHostnameAsFQDN`：启用将全限定域名（FQDN）设置为 Pod 主机名的功能。
- 请参见[为 Pod 设置 `setHostnameAsFQDN` 字段](/zh/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)。
-- `SizeMemoryBackedVolumes`：允许 kubelet 检查基于内存制备的卷的尺寸约束
- （目前主要针对 `emptyDir` 卷）。
-
+- `SetHostnameAsFQDN`：启用将全限定域名（FQDN）设置为 Pod 主机名的功能。
+ 请参见[为 Pod 设置 `setHostnameAsFQDN` 字段](/zh/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)。
+- `SizeMemoryBackedVolumes`：允许 kubelet 检查基于内存制备的卷的尺寸约束
+ （目前主要针对 `emptyDir` 卷）。
+- `StartupProbe`：在 kubelet 中启用
+ [启动探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)。
+- `StatefulSetMinReadySeconds`: 允许 StatefulSet 控制器采纳 `minReadySeconds` 设置。
+
-- `StartupProbe`：在 kubelet 中启用
- [启动探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)。
-- `StatefulSetMinReadySeconds`: 允许 StatefulSet 控制器采纳 `minReadySeconds` 设置。
- `StorageObjectInUseProtection`：如果仍在使用 PersistentVolume 或
PersistentVolumeClaim 对象，则将其删除操作推迟。
- `StorageVersionAPI`: 启用
@@ -1492,28 +1681,31 @@ Each feature gate is designed for enabling/disabling a specific feature:
will be reserved for the system as a whole and for Kubernetes system daemons
respectively.
- `SupportPodPidsLimit`: Enable the support to limiting PIDs in Pods.
+-->
+- `SupportIPVSProxyMode`：启用使用 IPVS 提供集群内服务负载平衡。更多详细信息，请参见
+ [服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)。
+- `SupportNodePidsLimit`：启用支持，限制节点上的 PID 用量。
+ `--system-reserved` 和 `--kube-reserved` 中的参数 `pid=<数值>` 可以分别用来
+ 设定为整个系统所预留的进程 ID 个数和为 Kubernetes 系统守护进程预留的进程 ID 个数。
+- `SupportPodPidsLimit`：启用支持限制 Pod 中的进程 PID。
+
-- `SupportIPVSProxyMode`：启用使用 IPVS 提供内服务负载平衡。更多详细信息，请参见
- [服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)。
-- `SupportNodePidsLimit`：启用支持，限制节点上的 PID 用量。
- `--system-reserved` 和 `--kube-reserved` 中的参数 `pid=<数值>` 可以分别用来
- 设定为整个系统所预留的进程 ID 个数和为 Kubernetes 系统守护进程预留的进程
- ID 个数。
-- `SupportPodPidsLimit`：启用支持限制 Pod 中的进程 PID。
-- `SuspendJob`： 启用支持以暂停和恢复作业。 更多详细信息，请参见
- [Jobs 文档](zh//docs/concepts/workloads/controllers/job/)。
-- `Sysctls`：允许为每个 Pod 设置的名字空间内核参数（sysctls）。
- 更多详细信息，请参见 [sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/)。
-
+- `SuspendJob`： 启用支持以暂停和恢复作业。 更多详细信息，请参见
+ [Jobs 文档](/zh/docs/concepts/workloads/controllers/job/)。
+- `Sysctls`：允许为每个 Pod 设置的名字空间内核参数（sysctls）。
+ 更多详细信息，请参见 [sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/)。
+- `TTLAfterFinished`：资源完成执行后，允许
+ [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)清理资源。
+
-- `TTLAfterFinished`：资源完成执行后，允许
- [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)清理资源。
- `TaintBasedEvictions`：根据节点上的污点和 Pod 上的容忍度启用从节点驱逐 Pod 的特性。
更多详细信息可参见[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
- `TaintNodesByCondition`：根据[节点状况](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)
@@ -1541,14 +1724,25 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `TokenRequestProjection`：启用通过
[`projected` 卷](/zh/docs/concepts/storage/volumes/#projected)
将服务帐户令牌注入到 Pod 中的特性。
-- `TopologyAwareHints`： 在 EndpointSlices 中启用基于拓扑提示的拓扑感知路由。
- 更多详细信息可参见[Topology Aware Hints](/zh/docs/concepts/services-networking/topology-aware-hints/)
-- `TopologyManager`：启用一种机制来协调 Kubernetes 不同组件的细粒度硬件资源分配。
- 详见[控制节点上的拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)。
+- `TopologyAwareHints`： 在 EndpointSlices 中启用基于拓扑提示的拓扑感知路由。
+ 更多详细信息可参见[拓扑感知提示](/zh/docs/concepts/services-networking/topology-aware-hints/)。
+- `TopologyManager`：启用一种机制来协调 Kubernetes 不同组件的细粒度硬件资源分配。
+ 详见[控制节点上的拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)。
+- `ValidateProxyRedirects`： 这个标志控制 API 服务器是否应该验证只跟随到相同的主机的重定向。
+ 仅在启用 `StreamingProxyRedirects` 标志时被使用。
+
-- `ValidateProxyRedirects`： 这个标志控制 API 服务器是否应该验证只跟随到相同的主机的重定向。
- 仅在启用 `StreamingProxyRedirects` 标志时被使用。
- `VolumeCapacityPriority`: 基于可用 PV 容量的拓扑，启用对不同节点的优先级支持。
- `VolumePVCDataSource`：启用对将现有 PVC 指定数据源的支持。
- `VolumeScheduling`：启用卷拓扑感知调度，并使 PersistentVolumeClaim（PVC）
@@ -1575,10 +1767,17 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `WatchBookmark`: Enable support for watch bookmark events.
- `WinDSR`: Allows kube-proxy to create DSR loadbalancers for Windows.
- `WinOverlay`: Allows kube-proxy to run in overlay mode for Windows.
+-->
+- `VolumeSubpathEnvExpansion`：启用 `subPathExpr` 字段用于在 `subPath` 中展开环境变量。
+- `WarningHeaders`：允许在 API 响应中发送警告头部。
+- `WatchBookmark`：启用对 watch 操作中 bookmark 事件的支持。
+- `WinDSR`：允许 kube-proxy 为 Windows 创建 DSR 负载均衡。
+- `WinOverlay`：允许在 Windows 的覆盖网络模式下运行 kube-proxy 。
+
-- `VolumeSubpathEnvExpansion`：启用 `subPathExpr` 字段用于将环境变量在 `subPath`
- 中展开。
-- `WarningHeaders`：允许在 API 响应中发送警告头部。
-- `WatchBookmark`：启用对 watch 操作中 bookmark 事件的支持。
-- `WinDSR`：允许 kube-proxy 为 Windows 创建 DSR 负载均衡。
-- `WinOverlay`：允许 kube-proxy 在 Windows 的覆盖网络模式下运行。
- `WindowsEndpointSliceProxying`: 当启用时，运行在 Windows 上的 kube-proxy
将使用 EndpointSlices 而不是 Endpoints 作为主要数据源，从而实现可伸缩性和并改进性能。
- 详情请参见[启用端点切片](/zh/docs/tasks/administer-cluster/enabling-endpointslices/).
+ 详情请参见[启用端点切片](/zh/docs/concepts/services-networking/endpoint-slices/).
- `WindowsGMSA`：允许将 GMSA 凭据规范从 Pod 传递到容器运行时。
- `WindowsHostProcessContainers`: 启用对 Windows HostProcess 容器的支持。
- `WindowsRunAsUserName`：提供使用非默认用户在 Windows 容器中运行应用程序的支持。
From 05e987a47bd988313cf9dc1e5ac416261c59aa49 Mon Sep 17 00:00:00 2001
From: Tim Bannister
Date: Thu, 9 Dec 2021 18:55:52 +0000
Subject: [PATCH 084/167] Highlight discussion issue for dockershim deprecation
- Link to k/kubernetes issue 106917
(various places)
- Related rewording to make that extra link work in context
and also:
- Replace alias for dockershim FAQ with a Netlify redirect
Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com>
---
...rd-Container-Runtime-Options-Kubernetes.md | 7 +++-
...-12-02-dont-panic-kubernetes-and-docker.md | 4 +++
.../index.md | 11 ++++--
.../2022-02-17-updated-dockershim-faq.md | 8 +++--
.../migrating-from-dockershim/_index.md | 36 +++++++++++++++----
...k-if-dockershim-deprecation-affects-you.md | 9 ++++-
static/_redirects | 6 +++-
7 files changed, 67 insertions(+), 14 deletions(-)
diff --git a/content/en/blog/_posts/2017-11-00-Containerd-Container-Runtime-Options-Kubernetes.md b/content/en/blog/_posts/2017-11-00-Containerd-Container-Runtime-Options-Kubernetes.md
index 2a105c6396..7bfcebe705 100644
--- a/content/en/blog/_posts/2017-11-00-Containerd-Container-Runtime-Options-Kubernetes.md
+++ b/content/en/blog/_posts/2017-11-00-Containerd-Container-Runtime-Options-Kubernetes.md
@@ -4,7 +4,12 @@ date: 2017-11-02
slug: containerd-container-runtime-options-kubernetes
url: /blog/2017/11/Containerd-Container-Runtime-Options-Kubernetes
---
- **_Editor's note: Today's post is by Lantao Liu, Software Engineer at Google, and Mike Brown, Open Source Developer Advocate at IBM._**
+
+**Authors:** Lantao Liu (Google), and Mike Brown (IBM)
+
+_Update: Kubernetes support for Docker via `dockershim` is now deprecated.
+For more information, read the [deprecation notice](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation).
+You can also discuss the deprecation via a dedicated [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
A _container runtime_ is software that executes containers and manages container images on a node. Today, the most widely known container runtime is [Docker](https://www.docker.com/), but there are other container runtimes in the ecosystem, such as [rkt](https://coreos.com/rkt/), [containerd](https://containerd.io/), and [lxd](https://linuxcontainers.org/lxd/). Docker is by far the most common container runtime used in production Kubernetes environments, but Docker’s smaller offspring, containerd, may prove to be a better option. This post describes using containerd with Kubernetes.
diff --git a/content/en/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/en/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md
index f66391de9e..58a8af7943 100644
--- a/content/en/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md
+++ b/content/en/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md
@@ -7,6 +7,10 @@ slug: dont-panic-kubernetes-and-docker
**Authors:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
+_Update: Kubernetes support for Docker via `dockershim` is now deprecated.
+For more information, read the [deprecation notice](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation).
+You can also discuss the deprecation via a dedicated [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
+
Kubernetes is [deprecating
Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)
as a container runtime after v1.20.
diff --git a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md
index a896d0f8c9..74d2d526be 100644
--- a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md
+++ b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md
@@ -5,13 +5,20 @@ date: 2021-11-12
slug: are-you-ready-for-dockershim-removal
---
-**Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano.
+**Authors:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano.
{{% alert color="info" title="Poll closed" %}}
This poll closed on January 7, 2022.
{{% /alert %}}
-Last year we announced that Dockershim is being deprecated: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/).
+Last year we [announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
+that Kubernetes' dockershim component (which provides a built-in integration for
+Docker Engine) is deprecated.
+
+_Update: There's a [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)
+with more information, and you can also discuss the deprecation via a dedicated
+[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
+
Our current plan is to remove dockershim from the Kubernetes codebase soon.
We are looking for feedback from you whether you are ready for dockershim
removal and to ensure that you are ready when the time comes.
diff --git a/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md
index c8c8b3600c..390f786b67 100644
--- a/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md
+++ b/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md
@@ -1,6 +1,7 @@
---
layout: blog
title: "Updated: Dockershim Removal FAQ"
+linkTitle: "Dockershim Removal FAQ"
date: 2022-02-17
slug: dockershim-faq
aliases: [ '/dockershim' ]
@@ -184,7 +185,7 @@ options are available as you migrate things over.
[documentation]: https://github.com/containerd/cri/blob/master/docs/registry.md
For instructions on how to use containerd and CRI-O with Kubernetes, see the
-Kubernetes documentation on [Container Runtimes]
+Kubernetes documentation on [Container Runtimes].
[Container Runtimes]: /docs/setup/production-environment/container-runtimes/
@@ -192,7 +193,10 @@ Kubernetes documentation on [Container Runtimes]
If you use a vendor-supported Kubernetes distribution, you can ask them about
upgrade plans for their products. For end-user questions, please post them
-to our end user community forum: https://discuss.kubernetes.io/.
+to our end user community forum: https://discuss.kubernetes.io/.
+
+You can discuss the decision to remove dockershim via a dedicated
+[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917).
You can also check out the excellent blog post
[Wait, Docker is deprecated in Kubernetes now?][dep] a more in-depth technical
diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md
index 3066f28e72..3631722a62 100644
--- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md
+++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md
@@ -1,7 +1,8 @@
---
title: "Migrating from dockershim"
weight: 10
-content_type: task
+content_type: task
+no_list: true
---
@@ -14,9 +15,30 @@ in Kubernetes 1.20, there were questions on how this will affect various workloa
installations. Our [Dockershim Removal FAQ](/blog/2022/02/17/dockershim-faq/) is there to help you
to understand the problem better.
-It is recommended to migrate from dockershim to alternative container runtimes.
-Check out [container runtimes](/docs/setup/production-environment/container-runtimes/)
-section to know your options. Make sure to
-[report issues](https://github.com/kubernetes/kubernetes/issues) you encountered
-with the migration. So the issue can be fixed in a timely manner and your cluster would be
-ready for dockershim removal.
+
+
+If you use Docker via dockershim as your container runtime, the Kubernetes project
+recommends that you migrate to an alternative container runtime.
+If you're not sure whether you are using Docker,
+[find out what container runtime is used on a node](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/).
+
+Your cluster might have more than one kind of node, although this is not a common
+configuration.
+
+These tasks will help you to migrate:
+
+* [Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
+* [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/)
+* [Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)
+
+
+## {{% heading "whatsnext" %}}
+
+* Check out [container runtimes](/docs/setup/production-environment/container-runtimes/)
+ to understand your options for a container runtime.
+* There is a
+ [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)
+ to track discussion about the deprecation and removal of dockershim.
+* If you found a defect or other technical concern relating to migrating away from dockershim,
+ you can [report an issue](https://github.com/kubernetes/kubernetes/issues/new/choose)
+ to the Kubernetes project.
diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md
index aea4249294..82139fa716 100644
--- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md
+++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md
@@ -10,7 +10,9 @@ weight: 20
The `dockershim` component of Kubernetes allows to use Docker as a Kubernetes's
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
-Kubernetes' built-in `dockershim` component was deprecated in release v1.20.
+Kubernetes' built-in `dockershim` component was
+[deprecated](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
+in release v1.20.
This page explains how your cluster could be using Docker as a container runtime,
provides details on the role that `dockershim` plays when in use, and shows steps
@@ -88,3 +90,8 @@ You can still pull images or build them using `docker build` command. But images
built or pulled by Docker would not be visible to container runtime and
Kubernetes. They needed to be pushed to some registry to allow them to be used
by Kubernetes.
+
+## {{% heading "whatsnext" %}}
+
+- Read [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) to understand your next steps
+- Read the [dockershim deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article for more information.
diff --git a/static/_redirects b/static/_redirects
index 2f5ce4234a..bb17b4d01a 100644
--- a/static/_redirects
+++ b/static/_redirects
@@ -487,7 +487,6 @@
/editdocs/ /docs/contribute/ 301
/docs/home/editdocs/ /docs/contribute/ 301
-
/docs/admin/accessing-the-api/ /docs/concepts/overview/kubernetes-api/ 301
/docs/admin/admission-controllers/ /docs/reference/access-authn-authz/admission-controllers/ 301
/docs/admin/authentication/ /docs/reference/access-authn-authz/authentication/ 301
@@ -501,9 +500,14 @@
/docs/admin/authorization/webhook/ /docs/reference/access-authn-authz/webhook/ 301
/docs/admin/authorization/ /docs/reference/access-authn-authz/authorization/ 301
/docs/admin/high-availability/building/ /docs/setup/production-environment/tools/kubeadm/high-availability/ 301
+
/code-of-conduct/ /community/code-of-conduct/ 301
/values/ /community/values/ 302
+/dockershim /blog/2022/02/17/dockershim-faq/ 302
+/dockershim/ /blog/2022/02/17/dockershim-faq/ 302
+
+
/docs/setup/release/notes/ /releases/notes/ 302
/docs/setup/release/ /releases/ 301
/docs/setup/version-skew-policy/ /releases/version-skew-policy/ 301
From de066e6a7196f0a67f7ceb8a022f1e6a0731e8ab Mon Sep 17 00:00:00 2001
From: Christopher Negus
Date: Tue, 12 Apr 2022 18:04:09 +0000
Subject: [PATCH 085/167] Responded to review comments
---
data/announcements/scheduled.yaml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/data/announcements/scheduled.yaml b/data/announcements/scheduled.yaml
index 1568b8ee79..0713c4578e 100644
--- a/data/announcements/scheduled.yaml
+++ b/data/announcements/scheduled.yaml
@@ -32,12 +32,12 @@ announcements:
- name: Dockershim removal
startTime: 2022-04-07T00:00:00 # Added in PR: https://github.com/kubernetes/website/pull/32805
- endTime: 2022-05-19T00:00:00 # Expires 2022-05-19
- style: "background: #3d4cb7"
+ endTime: 2022-05-10T00:00:00 # Expires 2022-05-10, but will change text slightly on release date
+ style: "background: #326ce5"
title: "Dockershim removal set for Kubernetes 1.24"
message: |
As of Kubernetes 1.24, Dockershim will no longer be included in Kubernetes.
- Read the [Dockershim Removal FAQ](/blog/2022/02/17/dockershim-faq/) to see what this means to you.
+ Read the [Dockershim Removal FAQ](/dockershim) to see what this means to you.
- name: Kubecon 2020 NA
startTime: 2020-10-26T00:00:00 # Added in https://github.com/kubernetes/website/pull/24714
From 2a15957d13bf9f948ad21ddf18f24effa5fbf35f Mon Sep 17 00:00:00 2001
From: Arhell
Date: Wed, 13 Apr 2022 00:22:05 +0300
Subject: [PATCH 086/167] [id] update proposal link to point to archive
---
.../docs/tasks/administer-cluster/reserve-compute-resources.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/id/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/id/docs/tasks/administer-cluster/reserve-compute-resources.md
index e1ac7b035e..1462a6c87d 100644
--- a/content/id/docs/tasks/administer-cluster/reserve-compute-resources.md
+++ b/content/id/docs/tasks/administer-cluster/reserve-compute-resources.md
@@ -104,7 +104,7 @@ Ini dilakukan dengan menspesifikasikan _parent_ cgroup sebagai nilai dari _flag_
Kami merekomendasikan _daemon_ sistem Kubernetes untuk ditempatkan pada
tingkatan cgroup yang tertinggi (contohnya, `runtime.slice` pada mesin systemd).
Secara ideal, setiap _daemon_ sistem sebaiknya dijalankan pada _child_ cgroup
-di bawah _parent_ ini. Lihat [dokumentasi](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
+di bawah _parent_ ini. Lihat [dokumentasi](https://git.k8s.io/design-proposals-archive/node/node-allocatable.md#recommended-cgroups-setup)
untuk mengetahui rekomendasi hierarki cgroup secara detail.
Catatan: kubelet **tidak membuat** `--kube-reserved-cgroup` jika cgroup
From a582a21cf00c88446a7feda4effd853b108c5c9c Mon Sep 17 00:00:00 2001
From: Chris Short
Date: Tue, 12 Apr 2022 18:42:46 -0400
Subject: [PATCH 087/167] Mention Detector for Docker Socket in dockershim
removal FAQ (#32685)
* Update 2022-02-17-updated-dockershim-faq.md
Adding the new Detector for Docker Socket plugin to the FAQ.
The tool will help folks find Dockershim usage in files on disk as well as running clusters.
* Apply suggestions from code review
Co-authored-by: Nate W. <4453979+nate-double-u@users.noreply.github.com>
* Update 2022-02-17-updated-dockershim-faq.md
Adding period
* Update content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md
Co-authored-by: Rey Lejano
* Update content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md
Co-authored-by: Tim Bannister
Co-authored-by: Nate W. <4453979+nate-double-u@users.noreply.github.com>
Co-authored-by: Rey Lejano
Co-authored-by: Tim Bannister
---
.../en/blog/_posts/2022-02-17-updated-dockershim-faq.md | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md
index 390f786b67..6091090567 100644
--- a/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md
+++ b/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md
@@ -204,6 +204,15 @@ discussion of the changes.
[dep]: https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
+### Is there any tooling that can help me find dockershim in use
+
+Yes! The [Detector for Docker Socket (DDS)][dds] is a kubectl plugin that you can
+install and then use to check your cluster. DDS can detect if active Kubernetes workloads
+are mounting the Docker Engine socket (`docker.sock`) as a volume.
+Find more details and usage patterns in the DDS project's [README][dds].
+
+[dds]: https://github.com/aws-containers/kubectl-detector-for-docker-socket
+
### Can I have a hug?
Yes, we're still giving hugs as requested. 🤗🤗🤗
From 758c357119495a289a2504fde2d1749ab9869466 Mon Sep 17 00:00:00 2001
From: Mengjiao Liu
Date: Wed, 13 Apr 2022 10:42:41 +0800
Subject: [PATCH 088/167] [zh]Fix missing links
---
.../zh/docs/concepts/security/pod-security-standards.md | 2 +-
.../resource-metrics-pipeline.md | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/content/zh/docs/concepts/security/pod-security-standards.md b/content/zh/docs/concepts/security/pod-security-standards.md
index 38f45d6e67..e2e6d7890f 100644
--- a/content/zh/docs/concepts/security/pod-security-standards.md
+++ b/content/zh/docs/concepts/security/pod-security-standards.md
@@ -884,7 +884,7 @@ in the Pod manifest, and represent parameters to the container runtime.
## 度量资源用量 {#measuring-resource-usage}
@@ -284,7 +284,7 @@ CPU 报告为以 cpu 为单位测量的平均核心使用率。在 Kubernetes
用于计算 CPU 的时间窗口显示在 Metrics API 的窗口字段下。
要了解更多关于 Kubernetes 如何分配和测量 CPU 资源的信息，请参阅
-[CPU 的含义](/zh/docs/concepts/configuration/manage-resources-container/#meaning-of-cpu)。
+[CPU 的含义](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)。
### 内存 {#memory}
@@ -313,7 +313,7 @@ Kubernetes 模型中，容器工作集是由容器运行时计算的与相关容
工作集指标通常还包括一些缓存（文件支持）内存，因为主机操作系统不能总是回收页面。
要了解有关 Kubernetes 如何分配和测量内存资源的更多信息，
-请参阅[内存的含义](/zh/docs/concepts/configuration/manage-resources-container/#meaning-of-memory)。
+请参阅[内存的含义](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory)。
+
+アプリケーションログは、アプリケーション内で何が起こっているかを理解するのに役立ちます。ログは、問題のデバッグとクラスターアクティビティの監視に特に役立ちます。最近のほとんどのアプリケーションには、何らかのロギングメカニズムがあります。同様に、コンテナエンジンはロギングをサポートするように設計されています。コンテナ化されたアプリケーションで、最も簡単で最も採用されているロギング方法は、標準出力と標準エラーストリームへの書き込みです。
+
+ただし、コンテナエンジンまたはランタイムによって提供されるネイティブ機能は、たいていの場合、完全なロギングソリューションには十分ではありません。
+
+たとえば、コンテナがクラッシュした場合やPodが削除された場合、またはノードが停止した場合に、アプリケーションのログにアクセスしたい場合があります。
+
+クラスターでは、ノードやPod、またはコンテナに関係なく、ノードに個別のストレージとライフサイクルが必要です。この概念は、_クラスターレベルロギング_ と呼ばれます。
+
+
+
+クラスターレベルロギングのアーキテクチャでは、ログを保存、分析、およびクエリするための個別のバックエンドが必要です。Kubernetesは、ログデータ用のネイティブストレージソリューションを提供していません。代わりに、Kubernetesに統合される多くのロギングソリューションがあります。次のセクションでは、ノードでログを処理および保存する方法について説明します。
+
+## Kubernetesでの基本的なロギング {#basic-logging-in-kubernetes}
+
+この例では、1秒に1回標準出力ストリームにテキストを書き込むコンテナを利用する、`Pod` specificationを使います。
+
+{{< codenew file="debug/counter-pod.yaml" >}}
+
+このPodを実行するには、次のコマンドを使用します:
+
+```shell
+kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
+```
+
+出力は次のようになります:
+
+```console
+pod/counter created
+```
+
+ログを取得するには、以下のように`kubectl logs`コマンドを使用します:
+
+```shell
+kubectl logs counter
+```
+
+出力は次のようになります:
+
+```console
+0: Mon Jan 1 00:00:00 UTC 2001
+1: Mon Jan 1 00:00:01 UTC 2001
+2: Mon Jan 1 00:00:02 UTC 2001
+...
+```
+
+コンテナの以前のインスタンスからログを取得するために、`kubectl logs --previous`を使用できます。Podに複数のコンテナがある場合は、次のように-cフラグでコマンドにコンテナ名を追加することで、アクセスするコンテナのログを指定します。
+
+```console
+kubectl logs counter -c count
+```
+
+詳細については、[`kubectl logs`ドキュメント](/docs/reference/generated/kubectl/kubectl-commands#logs)を参照してください。
+
+## ノードレベルでのロギング {#logging-at-the-node-level}
+
+
+
+コンテナエンジンは、生成された出力を処理して、コンテナ化されたアプリケーションの`stdout`と`stderr`ストリームにリダイレクトします。たとえば、Dockerコンテナエンジンは、これら2つのストリームを[ロギングドライバー](https://docs.docker.com/engine/admin/logging/overview)にリダイレクトします。ロギングドライバーは、JSON形式でファイルに書き込むようにKubernetesで設定されています。
+
+{{< note >}}
+Docker JSONロギングドライバーは、各行を個別のメッセージとして扱います。Dockerロギングドライバーを使用する場合、複数行メッセージを直接サポートすることはできません。ロギングエージェントレベルあるいはそれ以上のレベルで、複数行のメッセージを処理する必要があります。
+{{< /note >}}
+
+デフォルトでは、コンテナが再起動すると、kubeletは1つの終了したコンテナをログとともに保持します。Podがノードから削除されると、対応する全てのコンテナが、ログとともに削除されます。
+
+ノードレベルロギングでの重要な考慮事項は、ノードで使用可能な全てのストレージをログが消費しないように、ログローテーションを実装することです。Kubernetesはログのローテーションを担当しませんが、デプロイツールでそれに対処するソリューションを構築する必要があります。たとえば、`kube-up.sh`スクリプトによってデプロイされたKubernetesクラスターには、1時間ごとに実行するように構成された[`logrotate`](https://linux.die.net/man/8/logrotate)ツールがあります。アプリケーションのログを自動的にローテーションするようにコンテナランタイムを構築することもできます。
+
+例として、[`configure-helper` script](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)に対応するスクリプトである`kube-up.sh`が、どのようにGCPでCOSイメージのロギングを構築しているかについて、詳細な情報を見つけることができます。
+
+**CRIコンテナランタイム**を使用する場合、kubeletはログのローテーションとログディレクトリ構造の管理を担当します。kubeletはこの情報をCRIコンテナランタイムに送信し、ランタイムはコンテナログを指定された場所に書き込みます。2つのkubeletパラメーター、[`container-log-max-size`と`container-log-max-files`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)を[kubelet設定ファイル](/docs/tasks/administer-cluster/kubelet-config-file/)で使うことで、各ログファイルの最大サイズと各コンテナで許可されるファイルの最大数をそれぞれ設定できます。
+
+基本的なロギングの例のように、[`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)を実行すると、ノード上のkubeletがリクエストを処理し、ログファイルから直接読み取ります。kubeletはログファイルの内容を返します。
+
+{{< note >}}
+外部システムがローテーションを実行した場合、またはCRIコンテナランタイムが使用されている場合は、最新のログファイルの内容のみが`kubectl logs`で利用可能になります。例えば、10MBのファイルがある場合、`logrotate`によるローテーションが実行されると、2つのファイルが存在することになります: 1つはサイズが10MBのファイルで、もう1つは空のファイルです。この例では、`kubectl logs`は最新のログファイルの内容、つまり空のレスポンスを返します。
+{{< /note >}}
+
+### システムコンポーネントログ {#system-component-logs}
+
+システムコンポーネントには、コンテナ内で実行されるものとコンテナ内で実行されないものの2種類があります。例えば以下のとおりです。
+
+* Kubernetesスケジューラーとkube-proxyはコンテナ内で実行されます。
+* kubeletとコンテナランタイムはコンテナ内で実行されません。
+
+systemdを搭載したマシンでは、kubeletとコンテナランタイムがjournaldに書き込みます。systemdが存在しない場合、kubeletとコンテナランタイムは`var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナ内のシステムコンポーネントは、デフォルトのロギングメカニズムを迂回して、常に`/var/log`ディレクトリに書き込みます。それらは[`klog`](https://github.com/kubernetes/klog)というロギングライブラリを使用します。これらのコンポーネントのロギングの重大性に関する規則は、[development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)に記載されています。
+
+コンテナログと同様に、`/var/log`ディレクトリ内のシステムコンポーネントログはローテーションする必要があります。`kube-up.sh`スクリプトによって生成されたKubernetesクラスターでは、これらのログは、`logrotate`ツールによって毎日、またはサイズが100MBを超えた時にローテーションされるように設定されています。
+
+## クラスターレベルロギングのアーキテクチャ {#cluster-level-logging-architectures}
+
+Kubernetesはクラスターレベルロギングのネイティブソリューションを提供していませんが、検討可能な一般的なアプローチがいくつかあります。ここにいくつかのオプションを示します:
+
+* 全てのノードで実行されるノードレベルのロギングエージェントを使用します。
+* アプリケーションのPodにログインするための専用のサイドカーコンテナを含めます。
+* アプリケーション内からバックエンドに直接ログを送信します。
+
+### ノードロギングエージェントの使用 {#using-a-node-logging-agent}
+
+
+
+各ノードに _ノードレベルのロギングエージェント_ を含めることで、クラスターレベルロギングを実装できます。ロギングエージェントは、ログを公開したり、ログをバックエンドに送信したりする専用のツールです。通常、ロギングエージェントは、そのノード上の全てのアプリケーションコンテナからのログファイルを含むディレクトリにアクセスできるコンテナです。
+
+ロギングエージェントは全てのノードで実行する必要があるため、エージェントを`DaemonSet`として実行することをおすすめします。
+
+ノードレベルのロギングは、ノードごとに1つのエージェントのみを作成し、ノードで実行されているアプリケーションに変更を加える必要はありません。
+
+コンテナはstdoutとstderrに書き込みますが、合意された形式はありません。ノードレベルのエージェントはこれらのログを収集し、集約のために転送します。
+
+### ロギングエージェントでサイドカーコンテナを使用する {#sidecar-container-with-logging-agent}
+
+サイドカーコンテナは、次のいずれかの方法で使用できます:
+
+* サイドカーコンテナは、アプリケーションログを自身の`stdout`にストリーミングします。
+* サイドカーコンテナは、アプリケーションコンテナからログを取得するように設定されたロギングエージェントを実行します。
+
+#### ストリーミングサイドカーコンテナ {#streaming-sidecar-container}
+
+
+
+サイドカーコンテナに自身の`stdout`や`stderr`ストリームへの書き込みを行わせることで、各ノードですでに実行されているkubeletとロギングエージェントを利用できます。サイドカーコンテナは、ファイル、ソケット、またはjournaldからログを読み取ります。各サイドカーコンテナは、ログを自身の`stdout`または`stderr`ストリームに出力します。
+
+このアプローチにより、`stdout`または`stderr`への書き込みのサポートが不足している場合も含め、アプリケーションのさまざまな部分からいくつかのログストリームを分離できます。ログのリダイレクトの背後にあるロジックは最小限であるため、大きなオーバーヘッドにはなりません。さらに、`stdout`と`stderr`はkubeletによって処理されるため、`kubectl logs`のような組み込みツールを使用できます。
+
+たとえば、Podは単一のコンテナを実行し、コンテナは2つの異なる形式を使用して2つの異なるログファイルに書き込みます。Podの構成ファイルは次のとおりです:
+
+{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
+
+両方のコンポーネントをコンテナの`stdout`ストリームにリダイレクトできたとしても、異なる形式のログエントリを同じログストリームに書き込むことはおすすめしません。代わりに、2つのサイドカーコンテナを作成できます。各サイドカーコンテナは、共有ボリュームから特定のログファイルを追跡し、ログを自身の`stdout`ストリームにリダイレクトできます。
+
+2つのサイドカーコンテナを持つPodの構成ファイルは次のとおりです:
+
+{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
+
+これで、このPodを実行するときに、次のコマンドを実行して、各ログストリームに個別にアクセスできます:
+
+```shell
+kubectl logs counter count-log-1
+```
+
+出力は次のようになります:
+
+```console
+0: Mon Jan 1 00:00:00 UTC 2001
+1: Mon Jan 1 00:00:01 UTC 2001
+2: Mon Jan 1 00:00:02 UTC 2001
+...
+```
+
+```shell
+kubectl logs counter count-log-2
+```
+
+出力は次のようになります:
+
+```console
+Mon Jan 1 00:00:00 UTC 2001 INFO 0
+Mon Jan 1 00:00:01 UTC 2001 INFO 1
+Mon Jan 1 00:00:02 UTC 2001 INFO 2
+...
+```
+
+クラスターにインストールされているノードレベルのエージェントは、それ以上の設定を行わなくても、これらのログストリームを自動的に取得します。必要があれば、ソースコンテナに応じてログをパースするようにエージェントを構成できます。
+
+CPUとメモリーの使用量が少ない(CPUの場合は数ミリコアのオーダー、メモリーの場合は数メガバイトのオーダー)にも関わらず、ログをファイルに書き込んでから`stdout`にストリーミングすると、ディスクの使用量が2倍になる可能性があることに注意してください。単一のファイルに書き込むアプリケーションがある場合は、ストリーミングサイドカーコンテナアプローチを実装するのではなく、`/dev/stdout`を宛先として設定することをおすすめします。
+
+サイドカーコンテナを使用して、アプリケーション自体ではローテーションできないログファイルをローテーションすることもできます。このアプローチの例は、`logrotate`を定期的に実行する小さなコンテナです。しかし、`stdout`と`stderr`を直接使い、ローテーションと保持のポリシーをkubeletに任せることをおすすめします。
+
+#### ロギングエージェントを使用したサイドカーコンテナ {#sidecar-container-with-a-logging-agent}
+
+
+
+ノードレベルロギングのエージェントが、あなたの状況に必要なだけの柔軟性を備えていない場合は、アプリケーションで実行するように特別に構成した別のロギングエージェントを使用してサイドカーコンテナを作成できます。
+
+{{< note >}}
+サイドカーコンテナでロギングエージェントを使用すると、大量のリソースが消費される可能性があります。さらに、これらのログはkubeletによって制御されていないため、`kubectl logs`を使用してこれらのログにアクセスすることができません。
+{{< /note >}}
+
+ロギングエージェントを使用したサイドカーコンテナを実装するために使用できる、2つの構成ファイルを次に示します。最初のファイルには、fluentdを設定するための[`ConfigMap`](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)が含まれています。
+
+{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
+
+{{< note >}}
+fluentdの構成については、[fluentd documentation](https://docs.fluentd.org/)を参照してください。
+{{< /note >}}
+
+2番目のファイルは、fluentdを実行しているサイドカーコンテナを持つPodを示しています。Podは、fluentdが構成データを取得できるボリュームをマウントします。
+
+{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
+
+サンプル構成では、fluentdを任意のロギングエージェントに置き換えて、アプリケーションコンテナ内の任意のソースから読み取ることができます。
+
+### アプリケーションから直接ログを公開する {#exposing-logs-directly-from-the-application}
+
+
+
+すべてのアプリケーションから直接ログを公開または送信するクラスターロギングは、Kubernetesのスコープ外です。
From 0c6d37d1cf9b5bde6b772ff80cbf281ef33c6c10 Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Wed, 13 Apr 2022 15:56:36 +0800
Subject: [PATCH 090/167] [zh] Update replicationcontroller.md
Signed-off-by: xin.li
---
.../workloads/controllers/replicationcontroller.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md b/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
index dbadd4f88d..f83b5d4686 100644
--- a/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -311,7 +311,7 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Kubectl wi
for it to delete each pod before deleting the ReplicationController itself. If this kubectl
command is interrupted, it can be restarted.
-When using the REST API or Go client library, you need to do the steps explicitly (scale replicas to
+When using the REST API or [client library](/docs/reference/using-api/client-libraries), you need to do the steps explicitly (scale replicas to
0, wait for pod deletions, then delete the ReplicationController).
-->
## 使用 ReplicationController {#working-with-replicationcontrollers}
@@ -323,7 +323,7 @@ When using the REST API or Go client library, you need to do the steps explicitl
kubectl 将 ReplicationController 缩放为 0 并等待以便在删除 ReplicationController 本身之前删除每个 Pod。
如果这个 kubectl 命令被中断，可以重新启动它。
-当使用 REST API 或 Go 客户端库时，你需要明确地执行这些步骤（缩放副本为 0、
+当使用 REST API 或[客户端库](/zh/docs/reference/using-api/client-libraries)时，你需要明确地执行这些步骤（缩放副本为 0、
等待 Pod 删除，之后删除 ReplicationController 资源）。
### 只删除 ReplicationController
@@ -341,7 +341,7 @@ When using the REST API or Go client library, simply delete the ReplicationContr
使用 kubectl，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=orphan` 选项。
-当使用 REST API 或 Go 客户端库时，只需删除 ReplicationController 对象。
+当使用 REST API 或客户端库(/zh/docs/reference/using-api/client-libraries)时，只需删除 ReplicationController 对象。
+
+
+
+
+
+`import "k8s.io/apimachinery/pkg/apis/meta/v1"`
+
+
+
+ObjectMeta 是所有持久化资源必须具有的元数据，其中包括用户必须创建的所有对象。
+
+
+
+- **name** (string)
+
+
+ name 在命名空间内必须是唯一的。创建资源时需要，尽管某些资源可能允许客户端请求自动地生成适当的名称。
+ 名称主要用于创建幂等性和配置定义。无法更新。
+ 更多信息：http://kubernetes.io/docs/user-guide/identifiers#names
+
+
+- **generateName** (string)
+
+
+ generateName 是一个可选前缀，由服务器使用，**仅在**未提供 name 字段时生成唯一名称。
+ 如果使用此字段，则返回给客户端的名称将与传递的名称不同。该值还将与唯一的后缀组合。
+ 提供的值与 name 字段具有相同的验证规则，并且可能会根据所需的后缀长度被截断，以使该值在服务器上唯一。
+
+
+ 如果指定了此字段并且生成的名称存在，则服务器将不会返回 409 ——相反，它将返回 201 Created 或 500，
+ 原因是 ServerTimeout 指示在分配的时间内找不到唯一名称，客户端应重试（可选，在 Retry-After 标头中指定的时间之后）。
+
+ 仅在未指定 name 时应用。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#idempotency
+
+- **namespace** (string)
+
+
+ namespace 定义了一个值空间，其中每个名称必须唯一。空命名空间相当于 “default” 命名空间，但 “default” 是规范表示。
+ 并非所有对象都需要限定在命名空间中——这些对象的此字段的值将为空。
+
+ 必须是 DNS_LABEL。无法更新。更多信息：http://kubernetes.io/docs/user-guide/namespaces
+
+- **labels** (map[string]string)
+
+
+ 可用于组织和分类（确定范围和选择）对象的字符串键和值的映射。
+ 可以匹配 ReplicationControllers 和 Service 的选择器。更多信息：http://kubernetes.io/docs/user-guide/labels
+
+- **annotations** (map[string]string)
+
+
+ annotations 是一个非结构化的键值映射，存储在资源中，可以由外部工具设置以存储和检索任意元数据。
+ 它们不可查询，在修改对象时应保留。更多信息：http://kubernetes.io/docs/user-guide/annotations
+
+
+
+### 系统字段 {#System}
+
+
+- **finalizers** ([]string)
+
+
+ 在从注册表中删除对象之前该字段必须为空。
+ 每个条目都是负责的组件的标识符，各组件将从列表中删除自己对应的条目。
+ 如果对象的 deletionTimestamp 非空，则只能删除此列表中的条目。
+ 终结器可以按任何顺序处理和删除。**没有**按照顺序执行，
+ 因为它引入了终结器卡住的重大风险。finalizers 是一个共享字段，
+ 任何有权限的参与者都可以对其进行重新排序。如果按顺序处理终结器列表，
+ 那么这可能导致列表中第一个负责终结器的组件正在等待列表中靠后负责终结器的组件产生的信号（字段值、外部系统或其他），
+ 从而导致死锁。在没有强制排序的情况下，终结者可以在它们之间自由排序，
+ 并且不容易受到列表中排序更改的影响。
+
+- **managedFields** ([]ManagedFieldsEntry)
+
+
+ managedFields 将 workflow-id 和版本映射到由该工作流管理的字段集。
+ 这主要用于内部管理，用户通常不需要设置或理解该字段。
+ 工作流可以是用户名、控制器名或特定应用路径的名称，如 “ci-cd”。
+ 字段集始终存在于修改对象时工作流使用的版本。
+
+
+
+ ManagedFieldsEntry 是一个 workflow-id，一个 FieldSet，也是该字段集适用的资源的组版本。
+
+ - **managedFields.apiVersion** (string)
+
+
+ apiVersion 定义此字段集适用的资源的版本。
+ 格式是 “group/version”，就像顶级 apiVersion 字段一样。
+ 必须跟踪字段集的版本，因为它不能自动转换。
+
+ - **managedFields.fieldsType** (string)
+
+
+ FieldsType 是不同字段格式和版本的鉴别器。
+ 目前只有一个可能的值：“FieldsV1”
+
+ - **managedFields.fieldsV1** (FieldsV1)
+
+
+ FieldsV1 包含类型 “FieldsV1” 中描述的第一个 JSON 版本格式。
+
+
+
+ FieldsV1 以 JSON 格式将一组字段存储在像 Trie 这样的数据结构中。
+
+ 每个键或是 `.` 表示字段本身，并且始终映射到一个空集，
+ 或是一个表示子字段或元素的字符串。该字符串将遵循以下四种格式之一：
+ 1. `f:`，其中 `` 是结构中字段的名称，或映射中的键
+ 2. `v:`，其中 `` 是列表项的精确 json 格式值
+ 3. `i:`，其中 `` 是列表中项目的位置
+ 4. `k:`，其中 `` 是列表项的关键字段到其唯一值的映射
+ 如果一个键映射到一个空的 Fields 值，则该键表示的字段是集合的一部分。
+
+ 确切的格式在 sigs.k8s.io/structured-merge-diff 中定义。
+
+ - **managedFields.manager** (string)
+
+
+ manager 是管理这些字段的工作流的标识符。
+
+ - **managedFields.operation** (string)
+
+
+ operation 是导致创建此 managedFields 表项的操作类型。
+ 此字段的仅有合法值是 “Apply” 和 “Update”。
+
+ - **managedFields.subresource** (string)
+
+
+ subresource 是用于更新该对象的子资源的名称，如果对象是通过主资源更新的，则为空字符串。
+ 该字段的值用于区分管理者，即使他们共享相同的名称。例如，状态更新将不同于使用相同管理者名称的常规更新。
+ 请注意，apiVersion 字段与 subresource 字段无关，它始终对应于主资源的版本。
+
+ - **managedFields.time** (Time)
+
+
+ time 是设置这些字段的时间戳。如果 operation 为 “Apply”，则它应始终为空
+
+
+
+ time 是 time.Time 的包装类，支持正确地序列化为 YAML 和 JSON。
+ 为 time 包提供的许多工厂方法提供了包装类。
+
+
+- **ownerReferences** ([]OwnerReference)
+
+
+ 补丁策略：在键 `uid` 上执行合并操作
+
+ 此对象所依赖的对象列表。如果列表中的所有对象都已被删除，则该对象将被垃圾回收。
+ 如果此对象由控制器管理，则此列表中的条目将指向此控制器，controller 字段设置为 true。
+ 管理控制器不能超过一个。
+
+
+
+
+ OwnerReference 包含足够可以让你识别拥有对象的信息。
+ 拥有对象必须与依赖对象位于同一命名空间中，或者是集群作用域的，因此没有命名空间字段。
+
+ - **ownerReferences.apiVersion** (string)，必选
+
+ 被引用资源的 API 版本。
+
+ - **ownerReferences.kind** (string)，必选
+
+
+ 被引用资源的类别。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
+
+ - **ownerReferences.name** (string)，必选
+
+
+ 被引用资源的名称。更多信息：http://kubernetes.io/docs/user-guide/identifiers#names
+
+ - **ownerReferences.uid** (string)，必选
+
+
+ 被引用资源的 uid。更多信息：http://kubernetes.io/docs/user-guide/identifiers#uids
+
+ - **ownerReferences.blockOwnerDeletion** (boolean)
+
+
+ 如果为 true，**并且**如果所有者具有 “foregroundDeletion” 终结器，
+ 则在删除此引用之前，无法从键值存储中删除所有者。
+ 默认为 false。要设置此字段，用户需要所有者的 “delete” 权限，
+ 否则将返回 422 (Unprocessable Entity)。
+
+ - **ownerReferences.controller** (boolean)
+
+
+ 如果为 true，则此引用指向管理的控制器。
+
+
+### 只读字段 {#Read-only}
+
+
+- **creationTimestamp** (Time)
+
+
+ creationTimestamp 是一个时间戳，表示创建此对象时的服务器时间。
+ 不能保证在单独的操作中按发生前的顺序设置。
+ 客户端不得设置此值。它以 RFC3339 形式表示，并采用 UTC。
+
+ 由系统填充。只读。列表为空。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
+
+
+
+ time 是 time.Time 的包装类，支持正确地序列化为 YAML 和 JSON。
+ 为 time 包提供的许多工厂方法提供了包装类。
+
+- **deletionGracePeriodSeconds** (int64)
+
+
+ 此对象从系统中删除之前允许正常终止的秒数。
+ 仅当设置了 deletionTimestamp 时才设置。
+ 只能缩短。只读。
+
+- **deletionTimestamp** (Time)
+
+
+ deletionTimestamp 是删除此资源的 RFC 3339 日期和时间。
+ 该字段在用户请求优雅删除时由服务器设置，客户端不能直接设置。
+ 一旦 finalizers 列表为空，该资源预计将在此字段中的时间之后被删除
+ （不再从资源列表中可见，并且无法通过名称访问）。
+ 只要 finalizers 列表包含项目，就阻止删除。一旦设置了 deletionTimestamp，
+ 该值可能不会被取消设置或在未来进一步设置，尽管它可能会缩短或在此时间之前可能会删除资源。
+ 例如，用户可能要求在 30 秒内删除一个 Pod。
+ Kubelet 将通过向 Pod 中的容器发送优雅的终止信号来做出反应。
+ 30 秒后，Kubelet 将向容器发送硬终止信号（SIGKILL），
+ 并在清理后从 API 中删除 Pod。在网络存在分区的情况下，
+ 此对象可能在此时间戳之后仍然存在，直到管理员或自动化进程可以确定资源已完全终止。
+ 如果未设置，则未请求优雅删除该对象。
+
+ 请求优雅删除时由系统填充。只读。更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
+
+
+
+ “Time 是 time.Time 的包装类，支持正确地序列化为 YAML 和 JSON。
+ 为 time 包提供的许多工厂方法提供了包装类。”
+
+- **generation** (int64)
+
+
+ 表示期望状态的特定生成的序列号。由系统填充。只读。
+
+- **resourceVersion** (string)
+
+
+ 一个不透明的值，表示此对象的内部版本，客户端可以使用该值来确定对象是否已被更改。
+ 可用于乐观并发、变更检测以及对资源或资源集的监听操作。
+ 客户端必须将这些值视为不透明的，且未更改地传回服务器。
+ 它们可能仅对特定资源或一组资源有效。
+
+ 由系统填充。只读。客户端必须将值视为不透明。
+ 更多信息：https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency
+
+- **selfLink** (string)
+
+
+ selfLink 是表示此对象的 URL。由系统填充。只读。
+
+ **已弃用**。Kubernetes 将在 1.20 版本中停止传播该字段，并计划在 1.21 版本中删除该字段。
+
+- **uid** (string)
+
+
+ UID 是该对象在时间和空间上的唯一值。它通常由服务器在成功创建资源时生成，并且不允许使用 PUT 操作更改。
+
+ 由系统填充。只读。更多信息：http://kubernetes.io/docs/user-guide/identifiers#uids
+
+
+### 忽略字段 {#Ignored}
+
+
+- **clusterName** (string)
+
+
+ 对象所属的集群的名称。这用于区分不同集群中具有相同名称和命名空间的资源。
+ 该字段现在没有在任何地方设置，如果在创建或更新请求中设置，apiserver 将忽略它。
+
+
+
From d3ad42f6691ed80a23da73eef2aff3e5a5eebc0a Mon Sep 17 00:00:00 2001
From: Shannon Kularathna
Date: Tue, 8 Mar 2022 23:30:04 +0000
Subject: [PATCH 092/167] Add info about finding the runtime endpoint
---
.../find-out-runtime-you-use.md | 52 +++++++++++++++++--
1 file changed, 49 insertions(+), 3 deletions(-)
diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md
index 3d2ff7d1ee..dbfe02d9e6 100644
--- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md
+++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md
@@ -32,16 +32,22 @@ kubectl get nodes -o wide
The output is similar to the following. The column `CONTAINER-RUNTIME` outputs
the runtime and its version.
+For Docker Engine, the output is similar to this:
+
```none
-# For dockershim
NAME STATUS VERSION CONTAINER-RUNTIME
node-1 Ready v1.16.15 docker://19.3.1
node-2 Ready v1.16.15 docker://19.3.1
node-3 Ready v1.16.15 docker://19.3.1
```
+If your runtime shows as Docker Engine, you still might not be affected by the
+removal of dockershim in Kubernetes 1.24. [Check the runtime
+endpoint](#which-endpoint) to see if you use dockershim. If you don't use
+dockershim, you aren't affected.
+
+For containerd, the output is similar to this:
```none
-# For containerd
NAME STATUS VERSION CONTAINER-RUNTIME
node-1 Ready v1.19.6 containerd://1.4.1
node-2 Ready v1.19.6 containerd://1.4.1
@@ -49,4 +55,44 @@ node-3 Ready v1.19.6 containerd://1.4.1
```
Find out more information about container runtimes
-on [Container Runtimes](/docs/setup/production-environment/container-runtimes/) page.
+on [Container Runtimes](/docs/setup/production-environment/container-runtimes/)
+page.
+
+## Find out what container runtime endpoint you use {#which-endpoint}
+
+The container runtime talks to the kubelet over a Unix socket using the [CRI
+protocol](/docs/concepts/architecture/cri/), which is based on the gRPC
+framework. The kubelet acts as a client, and the runtime acts as the server.
+In some cases, you might find it useful to know which socket your nodes use. For
+example, with the removal of dockershim in Kubernetes 1.24 and later, you might
+want to know whether you use Docker Engine with dockershim.
+
+{{}}
+If you currently use Docker Engine in your nodes with `cri-dockerd`, you aren't
+affected by the dockershim removal.
+{{}}
+
+You can check which socket you use by checking the kubelet configuration on your
+nodes.
+
+1. Read the starting commands for the kubelet process:
+
+ ```
+ tr \\0 ' ' < /proc/"$(pgrep kubelet)"/cmdline
+ ```
+ If you don't have `tr` or `pgrep`, check the command line for the kubelet
+ process manually.
+
+1. In the output, look for the `--container-runtime` flag and the
+ `--container-runtime-endpoint` flag.
+
+ * If your nodes use Kubernetes v1.23 and earlier and these flags aren't
+ present or if the `--container-runtime` flag is not `remote`,
+ you use the dockershim socket with Docker Engine.
+ * If the `--container-runtime-endpoint` flag is present, check the socket
+ name to find out which runtime you use. For example,
+ `unix:///run/containerd/containerd.sock` is the containerd endpoint.
+
+If you use Docker Engine with the dockershim, [migrate to a different runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/),
+or, if you want to continue using Docker Engine in v1.24 and later, migrate to a
+CRI-compatible adapter like [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
\ No newline at end of file
From e88e05dbb7502d7ab1eefb3cc63b5dfb3e5813f7 Mon Sep 17 00:00:00 2001
From: Tim Bannister
Date: Wed, 13 Apr 2022 17:47:31 +0100
Subject: [PATCH 093/167] Update Docsy to v0.2.0
---
.gitmodules | 1 +
themes/docsy | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/.gitmodules b/.gitmodules
index 38fde49fc9..771ed3fc6b 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,6 +1,7 @@
[submodule "themes/docsy"]
path = themes/docsy
url = https://github.com/google/docsy.git
+ branch = v0.2.0
[submodule "api-ref-generator"]
path = api-ref-generator
url = https://github.com/kubernetes-sigs/reference-docs
diff --git a/themes/docsy b/themes/docsy
index f6a1870918..1c77bb2448 160000
--- a/themes/docsy
+++ b/themes/docsy
@@ -1 +1 @@
-Subproject commit f6a1870918520c83872fc07943a67a1d9d2a998c
+Subproject commit 1c77bb24483946f11c13f882f836a940b55ad019
From 01c3c53b7dbabaaf789acba9662018250adee2e2 Mon Sep 17 00:00:00 2001
From: Sean Wei
Date: Thu, 14 Apr 2022 01:33:53 +0800
Subject: [PATCH 094/167] [en] Fix Markdown format
---
.../en/docs/concepts/scheduling-eviction/assign-pod-node.md | 4 ++--
content/en/docs/reference/access-authn-authz/rbac.md | 2 +-
.../configure-liveness-readiness-startup-probes.md | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
index 44b3c07164..fe86f63501 100644
--- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -120,7 +120,7 @@ your Pod spec.
For example, consider the following Pod spec:
-{{}}
+{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
In this example, the following rules apply:
@@ -167,7 +167,7 @@ scheduling decision for the Pod.
For example, consider the following Pod spec:
-{{}}
+{{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}}
If there are two possible nodes that match the
`requiredDuringSchedulingIgnoredDuringExecution` rule, one with the
diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md
index f17b9ae8dd..ca93444fbc 100644
--- a/content/en/docs/reference/access-authn-authz/rbac.md
+++ b/content/en/docs/reference/access-authn-authz/rbac.md
@@ -31,7 +31,7 @@ kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
The RBAC API declares four kinds of Kubernetes object: _Role_, _ClusterRole_,
_RoleBinding_ and _ClusterRoleBinding_. You can
[describe objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects),
-or amend them, using tools such as `kubectl,` just like any other Kubernetes object.
+or amend them, using tools such as `kubectl`, just like any other Kubernetes object.
{{< caution >}}
These objects, by design, impose access restrictions. If you are making changes
diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
index 6ebfcc2a28..0bc22b5f29 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
@@ -233,7 +233,7 @@ in order to configure checks that rely on gRPC.
Here is an example manifest:
-{{< codenew file="pods/probe/grpc-liveness.yaml">}}
+{{< codenew file="pods/probe/grpc-liveness.yaml" >}}
To use a gRPC probe, `port` must be configured. If the health endpoint is configured
on a non-default service, you must also specify the `service`.
From 56dc4a09988b77c98c5e9b0b0279f8471754bcc8 Mon Sep 17 00:00:00 2001
From: Sean Wei
Date: Thu, 14 Apr 2022 01:40:10 +0800
Subject: [PATCH 095/167] [id] Fix Markdown format
---
.../cluster-administration/certificates.md | 2 +-
.../cluster-administration/flow-control.md | 2 +-
.../cluster-administration/networking.md | 2 +-
.../cluster-administration/system-metrics.md | 4 ++--
.../id/docs/concepts/configuration/overview.md | 16 ++++++++--------
.../compute-storage-net/network-plugins.md | 4 ++--
.../scheduling-eviction/assign-pod-node.md | 2 +-
.../scheduling-eviction/resource-bin-packing.md | 4 ++--
.../concepts/services-networking/dual-stack.md | 2 +-
.../services-networking/service-topology.md | 2 +-
.../id/docs/reference/access-authn-authz/rbac.md | 4 ++--
content/id/docs/reference/glossary/quantity.md | 2 +-
.../docs/reference/setup-tools/kubeadm/_index.md | 2 +-
.../access-application-cluster/access-cluster.md | 2 +-
.../debug-application-introspection.md | 2 +-
.../horizontal-pod-autoscale-walkthrough.md | 2 +-
16 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/content/id/docs/concepts/cluster-administration/certificates.md b/content/id/docs/concepts/cluster-administration/certificates.md
index ee1f91cbeb..8bd5895475 100644
--- a/content/id/docs/concepts/cluster-administration/certificates.md
+++ b/content/id/docs/concepts/cluster-administration/certificates.md
@@ -30,7 +30,7 @@ secara manual melalui `easyrsa`, `openssl` atau `cfssl`.
1. Hasilkan sertifikat dan kunci _server_.
Argumen `--subject-alt-name` digunakan untuk mengatur alamat IP dan nama DNS yang dapat diakses
oleh _server_ API. `MASTER_CLUSTER_IP` biasanya merupakan IP pertama dari CIDR _service cluster_
- yang diset dengan argumen` --service-cluster-ip-range` untuk _server_ API dan
+ yang diset dengan argumen `--service-cluster-ip-range` untuk _server_ API dan
komponen manajer pengontrol. Argumen `--days` digunakan untuk mengatur jumlah hari
masa berlaku sertifikat.
Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` sebagai nama
diff --git a/content/id/docs/concepts/cluster-administration/flow-control.md b/content/id/docs/concepts/cluster-administration/flow-control.md
index 4f6036c0ca..048f6cbd55 100644
--- a/content/id/docs/concepts/cluster-administration/flow-control.md
+++ b/content/id/docs/concepts/cluster-administration/flow-control.md
@@ -263,7 +263,7 @@ perlu memastikan bahwa tidak ada dua FlowSchema yang memiliki `matchingPrecedenc
Sebuah FlowSchema dianggap cocok dengan sebuah permintaan yang diberikan jika setidaknya salah satu dari `rules` nya
ada yang cocok. Sebuah aturan (_rule_) cocok jika setidaknya satu dari `subject` *dan*
-ada salah satu dari `resourceRules` atau` nonResourceRules` (tergantung dari apakah permintaan
+ada salah satu dari `resourceRules` atau `nonResourceRules` (tergantung dari apakah permintaan
yang masuk adalah untuk URL sumber daya atau non-sumber daya) yang cocok dengan permintaan tersebut.
Untuk bagian `name` dalam subjek, dan bagian `verbs`, `apiGroups`, `resources`,
diff --git a/content/id/docs/concepts/cluster-administration/networking.md b/content/id/docs/concepts/cluster-administration/networking.md
index 114f960d49..b300c29e98 100644
--- a/content/id/docs/concepts/cluster-administration/networking.md
+++ b/content/id/docs/concepts/cluster-administration/networking.md
@@ -139,7 +139,7 @@ DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
Jembatan ini dibuat oleh Kubelet (dikontrol oleh _flag_ `--network-plugin=kubenet`) sesuai dengan `.spec.podCIDR` yang dimiliki oleh Node.
-Docker sekarang akan mengalokasikan IP dari blok `cbr-cidr`. Kontainer dapat menjangkau satu sama lain dan Node di atas jembatan` cbr0`. IP-IP tersebut semuanya dapat dirutekan dalam jaringan proyek GCE.
+Docker sekarang akan mengalokasikan IP dari blok `cbr-cidr`. Kontainer dapat menjangkau satu sama lain dan Node di atas jembatan `cbr0`. IP-IP tersebut semuanya dapat dirutekan dalam jaringan proyek GCE.
GCE sendiri tidak tahu apa-apa tentang IP ini, jadi tidak akan NAT untuk lalu lintas internet keluar. Untuk mencapai itu aturan iptables digunakan untuk menyamar (alias SNAT - untuk membuatnya seolah-olah paket berasal dari lalu lintas `Node` itu sendiri) yang terikat untuk IP di luar jaringan proyek GCE (10.0.0.0/8).
diff --git a/content/id/docs/concepts/cluster-administration/system-metrics.md b/content/id/docs/concepts/cluster-administration/system-metrics.md
index f731ccfd77..0c4058c710 100644
--- a/content/id/docs/concepts/cluster-administration/system-metrics.md
+++ b/content/id/docs/concepts/cluster-administration/system-metrics.md
@@ -99,7 +99,7 @@ Opsi `show-hidden-metrics-for-version` menerima input versi yang kamu inginkan u
Opsi tersebut hanya dapat menerima input versi minor sebelumnya sebagai nilai. Semua metrik yang disembunyikan di versi sebelumnya akan dikeluarkan jika admin mengatur versi sebelumnya ke `show-hidden-metrics-for-version`. Versi yang terlalu lama tidak diperbolehkan karena melanggar kebijakan untuk metrik usang.
-Ambil metrik `A` sebagai contoh, di sini diasumsikan bahwa` A` sudah menjadi usang di versi 1.n. Berdasarkan kebijakan metrik usang, kita dapat mencapai kesimpulan berikut:
+Ambil metrik `A` sebagai contoh, di sini diasumsikan bahwa `A` sudah menjadi usang di versi 1.n. Berdasarkan kebijakan metrik usang, kita dapat mencapai kesimpulan berikut:
* Pada rilis `1.n`, metrik menjadi usang, dan dapat dikeluarkan secara bawaan.
* Pada rilis `1.n+1`, metrik disembunyikan secara bawaan dan dapat dikeluarkan dengan baris perintah `show-hidden-metrics-for-version=1.n`.
@@ -155,7 +155,7 @@ kube-scheduler mengidentifikasi [permintaan dan limit](/docs/concepts/configurat
- nama dari sumber daya (misalnya, `cpu`)
- satuan dari sumber daya jika diketahui (misalnya, `cores`)
-Setelah pod selesai (memiliki `restartPolicy` `Never` atau `OnFailure` dan berada dalam fase pod `Succeeded` atau `Failed`, atau telah dihapus dan semua kontainer dalam keadaan Terminated) deret metrik tidak lagi dilaporkan karena penjadwal sekarang sudah dibebaskan untuk menjadwalkan pod lain untuk dijalankan. Metrik yang dibahas pada bagian ini dikenal sebagai `kube_pod_resource_request` dan` kube_pod_resource_limit`.
+Setelah pod selesai (memiliki `restartPolicy` `Never` atau `OnFailure` dan berada dalam fase pod `Succeeded` atau `Failed`, atau telah dihapus dan semua kontainer dalam keadaan Terminated) deret metrik tidak lagi dilaporkan karena penjadwal sekarang sudah dibebaskan untuk menjadwalkan pod lain untuk dijalankan. Metrik yang dibahas pada bagian ini dikenal sebagai `kube_pod_resource_request` dan `kube_pod_resource_limit`.
Metrik diekspos melalui _endpoint_ HTTP `/metrics/resources` dan memerlukan otorisasi yang sama seperti endpoint `/metrics`
pada penjadwal. Kamu harus menggunakan opsi `--show-hidden-metrics-for-version=1.20` untuk mengekspos metrik-metrik stabilitas alfa ini.
diff --git a/content/id/docs/concepts/configuration/overview.md b/content/id/docs/concepts/configuration/overview.md
index cb8f460381..974d5b4a19 100644
--- a/content/id/docs/concepts/configuration/overview.md
+++ b/content/id/docs/concepts/configuration/overview.md
@@ -46,25 +46,25 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar
FOO_SERVICE_PORT=
```
- *Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh` Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini.
+ *Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh `Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini.
- Opsional (meskipun sangat disarankan) [cluster add-on](/id/docs/concepts/cluster-administration/addons/) adalah server DNS.
Server DNS melihat API Kubernetes untuk `Service` baru dan membuat satu set catatan DNS untuk masing-masing. Jika DNS telah diaktifkan di seluruh cluster maka semua `Pods` harus dapat melakukan resolusi nama`Service` secara otomatis.
-- Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <` hostIP`, `hostPort`,` protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan` protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai` hostIP` dan `TCP` sebagai default` protokol`.
+- Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <`hostIP`, `hostPort`, `protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan `protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai `hostIP` dan `TCP` sebagai default `protokol`.
Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/id/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/id/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`.
-- Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti` hostPort`.
+- Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti `hostPort`.
- Gunakan [headless Services](/id/docs/concepts/services-networking/service/#headless-
-services) (yang memiliki `ClusterIP` dari` None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing.
+services) (yang memiliki `ClusterIP` dari `None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing.
## Menggunakan label
-- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
+- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen `phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/id/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
@@ -103,11 +103,11 @@ Semantik caching dari penyedia gambar yang mendasarinya membuat bahkan `imagePul
## Menggunakan kubectl
-- Gunakan `kubectl apply -f `. Ini mencari konfigurasi Kubernetes di semua file `.yaml`,` .yml`, dan `.json` di` `dan meneruskannya ke` apply`.
+- Gunakan `kubectl apply -f `. Ini mencari konfigurasi Kubernetes di semua file `.yaml`, `.yml`, dan `.json` di `` dan meneruskannya ke `apply`.
-- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
+- Gunakan label selector untuk operasi `get` dan `delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
-- Gunakan `kubectl run` dan` kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh.
+- Gunakan `kubectl run` dan `kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh.
diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
index f54e285549..1c3bb469ae 100644
--- a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
@@ -28,7 +28,7 @@ Kubelet memiliki _plugin_ jaringan bawaan tunggal, dan jaringan bawaan umum untu
## Persyaratan _Plugin_ Jaringan
-Selain menyediakan [antarmuka `NetworkPlugin`](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) untuk mengonfigurasi dan membersihkan jaringan Pod, _plugin_ ini mungkin juga memerlukan dukungan khusus untuk kube-proxy. Proksi _iptables_ jelas tergantung pada _iptables_, dan _plugin_ ini mungkin perlu memastikan bahwa lalu lintas kontainer tersedia untuk _iptables_. Misalnya, jika plugin menghubungkan kontainer ke _bridge_ Linux, _plugin_ harus mengatur nilai sysctl `net/bridge/bridge-nf-call-iptables` menjadi ` 1` untuk memastikan bahwa proksi _iptables_ berfungsi dengan benar. Jika _plugin_ ini tidak menggunakan _bridge_ Linux (melainkan sesuatu seperti Open vSwitch atau mekanisme lainnya), _plugin_ ini harus memastikan lalu lintas kontainer dialihkan secara tepat untuk proksi.
+Selain menyediakan [antarmuka `NetworkPlugin`](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) untuk mengonfigurasi dan membersihkan jaringan Pod, _plugin_ ini mungkin juga memerlukan dukungan khusus untuk kube-proxy. Proksi _iptables_ jelas tergantung pada _iptables_, dan _plugin_ ini mungkin perlu memastikan bahwa lalu lintas kontainer tersedia untuk _iptables_. Misalnya, jika plugin menghubungkan kontainer ke _bridge_ Linux, _plugin_ harus mengatur nilai sysctl `net/bridge/bridge-nf-call-iptables` menjadi `1` untuk memastikan bahwa proksi _iptables_ berfungsi dengan benar. Jika _plugin_ ini tidak menggunakan _bridge_ Linux (melainkan sesuatu seperti Open vSwitch atau mekanisme lainnya), _plugin_ ini harus memastikan lalu lintas kontainer dialihkan secara tepat untuk proksi.
Secara bawaan jika tidak ada _plugin_ jaringan Kubelet yang ditentukan, _plugin_ `noop` digunakan, yang menetapkan `net/bridge/bridge-nf-call-iptables=1` untuk memastikan konfigurasi sederhana (seperti Docker dengan sebuah _bridge_) bekerja dengan benar dengan proksi _iptables_.
@@ -148,7 +148,7 @@ Opsi ini disediakan untuk _plugin_ jaringan; Saat ini **hanya kubenet yang mendu
## Ringkasan Penggunaan
* `--network-plugin=cni` menetapkan bahwa kita menggunakan _plugin_ jaringan `cni` dengan _binary-binary plugin_ CNI aktual yang terletak di `--cni-bin-dir` (nilai bawaannya `/opt/cni/bin`) dan konfigurasi _plugin_ CNI yang terletak di `--cni-conf-dir` (nilai bawaannya `/etc/cni/net.d`).
-* `--network-plugin=kubenet` menentukan bahwa kita menggunakan _plugin_ jaringan` kubenet` dengan `bridge` CNI dan _plugin-plugin_ `host-local` yang terletak di `/opt/cni/bin` atau `cni-bin-dir`.
+* `--network-plugin=kubenet` menentukan bahwa kita menggunakan _plugin_ jaringan `kubenet` dengan `bridge` CNI dan _plugin-plugin_ `host-local` yang terletak di `/opt/cni/bin` atau `cni-bin-dir`.
* `--network-plugin-mtu=9001` menentukan MTU yang akan digunakan, saat ini hanya digunakan oleh _plugin_ jaringan `kubenet`.
diff --git a/content/id/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/id/docs/concepts/scheduling-eviction/assign-pod-node.md
index f8654f4276..4f0f838db5 100644
--- a/content/id/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/id/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -279,7 +279,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3
##### Tidak akan pernah ditempatkan bersamaan dalam node yang sama
-Contoh di atas menggunakan aturan `PodAntiAffinity` dengan` topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy klaster redis sehingga tidak ada dua instance terletak pada hos yang sama.
+Contoh di atas menggunakan aturan `PodAntiAffinity` dengan `topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy klaster redis sehingga tidak ada dua instance terletak pada hos yang sama.
Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) untuk contoh dari konfigurasi StatefulSet dengan anti-afinitas untuk ketersediaan tinggi, menggunakan teknik yang sama.
Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
diff --git a/content/id/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/id/docs/concepts/scheduling-eviction/resource-bin-packing.md
index 0f5b92784a..7cf64b6696 100644
--- a/content/id/docs/concepts/scheduling-eviction/resource-bin-packing.md
+++ b/content/id/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -28,7 +28,7 @@ permintaan terhadap kapasitas. Hal ini memungkinkan pengguna untuk _bin pack_
sumber daya tambahan dengan menggunakan parameter yang sesuai untuk meningkatkan
pemanfaatan sumber daya yang langka dalam klaster yang besar. Perilaku
`RequestedToCapacityRatioResourceAllocation` dari fungsi prioritas dapat
-dikontrol melalui pilihan konfigurasi yang disebut ` RequestToCapacityRatioArguments`.
+dikontrol melalui pilihan konfigurasi yang disebut `RequestToCapacityRatioArguments`.
Argumen ini terdiri dari dua parameter yaitu `shape` dan `resources`. Shape
memungkinkan pengguna untuk menyempurnakan fungsi menjadi yang paling tidak
diminta atau paling banyak diminta berdasarkan nilai `utilization` dan `score`.
@@ -36,7 +36,7 @@ Sumber daya terdiri dari `name` yang menentukan sumber daya mana yang dipertimba
selama penilaian dan `weight` yang menentukan bobot masing-masing sumber daya.
Di bawah ini adalah contoh konfigurasi yang menetapkan `requestedToCapacityRatioArguments`
-pada perilaku _bin packing_ untuk sumber daya tambahan` intel.com/foo` dan `intel.com/bar`
+pada perilaku _bin packing_ untuk sumber daya tambahan `intel.com/foo` dan `intel.com/bar`
```json
{
diff --git a/content/id/docs/concepts/services-networking/dual-stack.md b/content/id/docs/concepts/services-networking/dual-stack.md
index 6714a00cde..52e892f4f4 100644
--- a/content/id/docs/concepts/services-networking/dual-stack.md
+++ b/content/id/docs/concepts/services-networking/dual-stack.md
@@ -113,7 +113,7 @@ yang dikonfigurasi untuk Service ini.
### Tipe _LoadBalancer_
Penyedia layanan _cloud_ yang mendukung IPv6 untuk pengaturan beban eksternal,
-Mengatur bagian `type` menjadi` LoadBalancer` sebagai tambahan terhadap mengatur bagian
+Mengatur bagian `type` menjadi `LoadBalancer` sebagai tambahan terhadap mengatur bagian
`ipFamily` menjadi `IPv6` menyediakan sebuah _cloud load balancer_ untuk Service kamu.
## Lalu lintas _egress_
diff --git a/content/id/docs/concepts/services-networking/service-topology.md b/content/id/docs/concepts/services-networking/service-topology.md
index 05abffa323..6ad889b995 100644
--- a/content/id/docs/concepts/services-networking/service-topology.md
+++ b/content/id/docs/concepts/services-networking/service-topology.md
@@ -26,7 +26,7 @@ _availability zone_ yang sama.
## Pengantar
-Secara bawaan lalu lintas jaringan yang dikirim ke `ClusterIP` atau` NodePort` dari Service
+Secara bawaan lalu lintas jaringan yang dikirim ke `ClusterIP` atau `NodePort` dari Service
dapat dialihkan ke alamat _backend_ untuk Service tersebut. Sejak Kubernetes 1.7
dimungkinkan untuk merutekan lalu lintas jaringan "eksternal" ke Pod yang berjalan di
Node yang menerima lalu lintas jaringan, tetapi fitur ini tidak didukung untuk `ClusterIP` dari
diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md
index 45be8d9b4f..438b53abf8 100644
--- a/content/id/docs/reference/access-authn-authz/rbac.md
+++ b/content/id/docs/reference/access-authn-authz/rbac.md
@@ -248,7 +248,7 @@ rules:
Kamu juga dapat merujuk ke sumber daya dengan nama untuk permintaan tertentu melalui daftar `resourceNames`.
Ketika nama dicantumkan, permintaan dapat dibatasi untuk setiap objek sumber daya.
-Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan `get` atau` update` pada sebuah
+Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan `get` atau `update` pada sebuah
{{< glossary_tooltip term_id="ConfigMap" >}} bernama `my-configmap`:
```yaml
@@ -268,7 +268,7 @@ rules:
```
{{< note >}}
-Kamu tidak dapat membatasi permintaan `create` atau` deletecollection` dengan nama sumber daya. Untuk `create`,
+Kamu tidak dapat membatasi permintaan `create` atau `deletecollection` dengan nama sumber daya. Untuk `create`,
keterbatasan ini dikarenakan nama objek tidak diketahui pada waktu otorisasi.
{{< /note >}}
diff --git a/content/id/docs/reference/glossary/quantity.md b/content/id/docs/reference/glossary/quantity.md
index 7369fc20dc..fc2cd1290e 100644
--- a/content/id/docs/reference/glossary/quantity.md
+++ b/content/id/docs/reference/glossary/quantity.md
@@ -15,7 +15,7 @@ Representasi bilangan bulat dari bilangan kecil atau besar menggunakan sufiks SI
Kuantitas adalah representasi dari bilangan kecil atau besar menggunakan notasi bilangan bulat kompak dengan sufiks SI. Bilangan pecahan direpresentasikan dengan satuan mili, sedangkan bilangan besar direpresentasikan dengan satuan kilo, mega, atau giga.
-Misalnya, angka `1,5` direpresentasikan sebagai` 1500m`, sedangkan angka `1000` dapat direpresentasikan sebagai `1k`, dan `1000000` sebagai `1M`. Kamu juga dapat menentukan sufiks notasi biner; angka 2048 dapat ditulis sebagai `2Ki`.
+Misalnya, angka `1,5` direpresentasikan sebagai `1500m`, sedangkan angka `1000` dapat direpresentasikan sebagai `1k`, dan `1000000` sebagai `1M`. Kamu juga dapat menentukan sufiks notasi biner; angka 2048 dapat ditulis sebagai `2Ki`.
Satuan desimal yang diterima (pangkat 10) adalah `m` (mili), `k` (kilo, sengaja huruf kecil), `M` (mega), `G` (giga), `T` (tera), `P` (peta), `E` (exa).
diff --git a/content/id/docs/reference/setup-tools/kubeadm/_index.md b/content/id/docs/reference/setup-tools/kubeadm/_index.md
index 25fbca1cca..979c9cc1a7 100644
--- a/content/id/docs/reference/setup-tools/kubeadm/_index.md
+++ b/content/id/docs/reference/setup-tools/kubeadm/_index.md
@@ -8,7 +8,7 @@ card:
weight: 40
---
-
Kubeadm adalah fitur yang dibuat untuk menyediakan `kubeadm init` dan` kubeadm join` sebagai praktik terbaik dengan "jalur cepat" untuk membuat klaster Kubernetes.
+Kubeadm adalah fitur yang dibuat untuk menyediakan `kubeadm init` dan `kubeadm join` sebagai praktik terbaik dengan "jalur cepat" untuk membuat klaster Kubernetes.
kubeadm melakukan tindakan yang diperlukan untuk membuat klaster minimum yang layak untuk aktif dan berjalan. Secara desain, ini hanya memperdulikan tentang *bootstrap*, bukan tentang mesin *provisioning*. Demikian pula, dengan instalasi berbagai *addon* atau tambahan yang bagus untuk dimiliki, seperti Dasbor Kubernetes, solusi pemantauan, dan tambahan khusus cloud, tidak termasuk dalam cakupan.
diff --git a/content/id/docs/tasks/access-application-cluster/access-cluster.md b/content/id/docs/tasks/access-application-cluster/access-cluster.md
index 6a575ad8f1..bba413951c 100644
--- a/content/id/docs/tasks/access-application-cluster/access-cluster.md
+++ b/content/id/docs/tasks/access-application-cluster/access-cluster.md
@@ -207,7 +207,7 @@ Dalam banyak kasus, IP Node, IP Pod, dan beberapa IP Service pada sebuah klaster
Kamu memiliki beberapa opsi untuk menghubungi Node, Pod, dan Service dari luar klaster:
- Mengakses Service melalui IP publik.
- - Gunakan Service dengan tipe `NodePort` atau` LoadBalancer` untuk membuat Service dapat dijangkau di luar klaster. Lihat dokumentasi [Service](/docs/user-guide/services) dan perintah [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose).
+ - Gunakan Service dengan tipe `NodePort` atau `LoadBalancer` untuk membuat Service dapat dijangkau di luar klaster. Lihat dokumentasi [Service](/docs/user-guide/services) dan perintah [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose).
- Bergantung pada lingkungan klaster kamu, hal ini mungkin hanya mengekspos Service ke jaringan perusahaan kamu, atau mungkin mengeksposnya ke internet. Pikirkan apakah Service yang diekspos aman atau tidak. Apakah layanan di balik Service tersebut melakukan autentikasinya sendiri?
- Tempatkan Pod di belakang Service. Untuk mengakses satu Pod tertentu dari sekumpulan replika, misalnya untuk pengawakutuan (_debugging_), letakkan label unik di Pod dan buat Service baru yang memilih label ini.
- Pada kebanyakan kasus, pengembang aplikasi tidak perlu langsung mengakses Node melalui IP Node mereka.
diff --git a/content/id/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/id/docs/tasks/debug-application-cluster/debug-application-introspection.md
index 96b7a05e07..746c46f045 100644
--- a/content/id/docs/tasks/debug-application-cluster/debug-application-introspection.md
+++ b/content/id/docs/tasks/debug-application-cluster/debug-application-introspection.md
@@ -268,7 +268,7 @@ status:
## Contoh: Men-_debug_ Node yang mati/tidak terjangkau (_down/unreachable_)
-Terkadang saat men-_debug_ melihat status sebuah Node akan sangat berguna - misalnya, karena kamu telah melihat perilaku aneh dari sebuah Pod yang sedang berjalan pada Node tersebut, atau untuk mencari tahu mengapa sebuah Pod tidak dapat dijadwalkan ke dalam Node tersebut. Seperti pada Pod, kamu dapat menggunakan perintah `kubectl description node` dan` kubectl get node -o yaml` untuk mengambil informasi mendetil tentang Node. Misalnya, disini kamu akan melihat jika sebuah Node sedang mati (terputus dari jaringan, atau kubelet mati dan tidak mau restart, dll.). Perhatikan peristiwa yang menunjukkan Node tersebut NotReady, dan juga perhatikan bahwa Pod tidak lagi berjalan (mereka akan dikeluarkan setelah lima menit berstatus NotReady).
+Terkadang saat men-_debug_ melihat status sebuah Node akan sangat berguna - misalnya, karena kamu telah melihat perilaku aneh dari sebuah Pod yang sedang berjalan pada Node tersebut, atau untuk mencari tahu mengapa sebuah Pod tidak dapat dijadwalkan ke dalam Node tersebut. Seperti pada Pod, kamu dapat menggunakan perintah `kubectl description node` dan `kubectl get node -o yaml` untuk mengambil informasi mendetil tentang Node. Misalnya, disini kamu akan melihat jika sebuah Node sedang mati (terputus dari jaringan, atau kubelet mati dan tidak mau restart, dll.). Perhatikan peristiwa yang menunjukkan Node tersebut NotReady, dan juga perhatikan bahwa Pod tidak lagi berjalan (mereka akan dikeluarkan setelah lima menit berstatus NotReady).
```shell
kubectl get nodes
diff --git a/content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 442e3178ec..7a23efa6ff 100644
--- a/content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -426,7 +426,7 @@ pengambilan metrik. Terakhir, kondisi terakhir, `ScalingLimited`, menunjukkan ba
## Lampiran: Kuantitas
-Semua metrik di HorizontalPodAutoscaler dan metrik API ditentukan menggunakan notasi bilangan bulat khusus yang dikenal di Kubernetes sebagai {{< glossary_tooltip term_id="quantity" text="kuantitas">}}. Misalnya, kuantitas `10500m` akan ditulis sebagai `10.5` dalam notasi desimal. Metrik API akan menampilkan bilangan bulat tanpa sufiks jika memungkinkan, dan secara umum akan mengembalikan kuantitas dalam satuan mili. Ini berarti kamu mungkin melihat nilai metrik berfluktuasi antara `1` dan `1500m`, atau `1` dan` 1,5` ketika ditulis dalam notasi desimal.
+Semua metrik di HorizontalPodAutoscaler dan metrik API ditentukan menggunakan notasi bilangan bulat khusus yang dikenal di Kubernetes sebagai {{< glossary_tooltip term_id="quantity" text="kuantitas">}}. Misalnya, kuantitas `10500m` akan ditulis sebagai `10.5` dalam notasi desimal. Metrik API akan menampilkan bilangan bulat tanpa sufiks jika memungkinkan, dan secara umum akan mengembalikan kuantitas dalam satuan mili. Ini berarti kamu mungkin melihat nilai metrik berfluktuasi antara `1` dan `1500m`, atau `1` dan `1,5` ketika ditulis dalam notasi desimal.
## Lampiran: Skenario lain yang memungkinkan
From 7c221a3688ef8a58938a56d45fa6e3d5cf8e2893 Mon Sep 17 00:00:00 2001
From: Sean Wei
Date: Thu, 14 Apr 2022 01:41:28 +0800
Subject: [PATCH 096/167] [fr] Fix Markdown format
---
.../fr/docs/concepts/architecture/nodes.md | 2 +-
.../concepts/services-networking/ingress.md | 6 ++---
.../concepts/services-networking/service.md | 6 ++---
.../generate-ref-docs/kubernetes-api.md | 4 +--
content/fr/docs/setup/custom-cloud/kops.md | 4 +--
.../tools/kubeadm/create-cluster-kubeadm.md | 26 +++++++++----------
.../tools/kubeadm/ha-topology.md | 6 ++---
.../tools/kubeadm/install-kubeadm.md | 2 +-
.../tools/kubeadm/kubelet-integration.md | 2 +-
.../tools/kubeadm/troubleshooting-kubeadm.md | 22 ++++++++--------
10 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/content/fr/docs/concepts/architecture/nodes.md b/content/fr/docs/concepts/architecture/nodes.md
index f493fe5b17..8fba205053 100644
--- a/content/fr/docs/concepts/architecture/nodes.md
+++ b/content/fr/docs/concepts/architecture/nodes.md
@@ -157,7 +157,7 @@ Dans la plupart des cas, le contrôleur de noeud limite le taux d’expulsion à
Le comportement d'éviction de noeud change lorsqu'un noeud d'une zone de disponibilité donnée devient défaillant.
Le contrôleur de nœud vérifie quel pourcentage de nœuds de la zone est défaillant (la condition NodeReady est ConditionUnknown ou ConditionFalse) en même temps.
-Si la fraction de nœuds défaillant est au moins `--unhealthy-zone-threshold` (valeur par défaut de 0,55), le taux d'expulsion est réduit: si le cluster est petit (c'est-à-dire inférieur ou égal à ` --large-cluster-size-threshold` noeuds - valeur par défaut 50) puis les expulsions sont arrêtées, sinon le taux d'expulsion est réduit à `--secondary-node-eviction-rate` (valeur par défaut de 0,01) par seconde.
+Si la fraction de nœuds défaillant est au moins `--unhealthy-zone-threshold` (valeur par défaut de 0,55), le taux d'expulsion est réduit: si le cluster est petit (c'est-à-dire inférieur ou égal à `--large-cluster-size-threshold` noeuds - valeur par défaut 50) puis les expulsions sont arrêtées, sinon le taux d'expulsion est réduit à `--secondary-node-eviction-rate` (valeur par défaut de 0,01) par seconde.
Ces stratégies sont implémentées par zone de disponibilité car une zone de disponibilité peut être partitionnée à partir du master, tandis que les autres restent connectées.
Si votre cluster ne s'étend pas sur plusieurs zones de disponibilité de fournisseur de cloud, il n'existe qu'une seule zone de disponibilité (la totalité du cluster).
diff --git a/content/fr/docs/concepts/services-networking/ingress.md b/content/fr/docs/concepts/services-networking/ingress.md
index 2699864484..d8b489aa51 100644
--- a/content/fr/docs/concepts/services-networking/ingress.md
+++ b/content/fr/docs/concepts/services-networking/ingress.md
@@ -91,7 +91,7 @@ spec:
number: 80
```
-Comme pour toutes les autres ressources Kubernetes, un Ingress (une entrée) a besoin des champs `apiVersion`,` kind` et `metadata`.
+Comme pour toutes les autres ressources Kubernetes, un Ingress (une entrée) a besoin des champs `apiVersion`, `kind` et `metadata`.
Pour des informations générales sur l'utilisation des fichiers de configuration, voir [déployer des applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configurer des conteneurs](/docs/tasks/configure-pod-container/configure-pod-configmap/), [gestion des ressources](/docs/concepts/cluster-administration/manage-deployment/).
Ingress utilise fréquemment des annotations pour configurer certaines options en fonction du contrôleur Ingress, dont un exemple
est l'annotation [rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
@@ -223,7 +223,7 @@ Events:
Normal ADD 22s loadbalancer-controller default/test
```
-Le contrôleur d’Ingress fournit une implémentation spécifique aux load-balancers qui satisfait l'Ingress, tant que les services (`s1`,` s2`) existent.
+Le contrôleur d’Ingress fournit une implémentation spécifique aux load-balancers qui satisfait l'Ingress, tant que les services (`s1`, `s2`) existent.
Lorsque cela est fait, vous pouvez voir l’adresse du load-balancer sur le champ d'adresse.
{{< note >}}
@@ -272,7 +272,7 @@ spec:
number: 80
```
-Si vous créez une ressource Ingress sans aucun hôte défini dans les règles, tout trafic Web à destination de l'adresse IP de votre contrôleur d'Ingress peut être mis en correspondance sans qu'un hôte virtuel basé sur le nom ne soit requis. Par exemple, la ressource Ingress suivante acheminera le trafic demandé pour `first.bar.com` au `service1` `second.foo.com` au `service2`, et à tout trafic à l'adresse IP sans nom d'hôte défini dans la demande (c'est-à-dire sans en-tête de requête présenté) au `service3`.
+Si vous créez une ressource Ingress sans aucun hôte défini dans les règles, tout trafic Web à destination de l'adresse IP de votre contrôleur d'Ingress peut être mis en correspondance sans qu'un hôte virtuel basé sur le nom ne soit requis. Par exemple, la ressource Ingress suivante acheminera le trafic demandé pour `first.bar.com` au `service1`, `second.foo.com` au `service2`, et à tout trafic à l'adresse IP sans nom d'hôte défini dans la demande (c'est-à-dire sans en-tête de requête présenté) au `service3`.
```yaml
apiVersion: networking.k8s.io/v1
diff --git a/content/fr/docs/concepts/services-networking/service.md b/content/fr/docs/concepts/services-networking/service.md
index f1cec8633f..9d8484b18e 100644
--- a/content/fr/docs/concepts/services-networking/service.md
+++ b/content/fr/docs/concepts/services-networking/service.md
@@ -209,7 +209,7 @@ Cela signifie que vous évitez d'envoyer du trafic via kube-proxy vers un pod co
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
-En mode `ipvs`, kube-proxy surveille les Services et Endpoints Kubernetes. kube-proxy appelle l'interface` netlink` pour créer les règles IPVS en conséquence et synchronise périodiquement les règles IPVS avec les Services et Endpoints Kubernetes.
+En mode `ipvs`, kube-proxy surveille les Services et Endpoints Kubernetes. kube-proxy appelle l'interface `netlink` pour créer les règles IPVS en conséquence et synchronise périodiquement les règles IPVS avec les Services et Endpoints Kubernetes.
Cette boucle de contrôle garantit que l'état IPVS correspond à l'état souhaité.
Lors de l'accès à un service, IPVS dirige le trafic vers l'un des pods backend.
@@ -364,11 +364,11 @@ Les valeurs de `Type` et leurs comportements sont:
Le choix de cette valeur rend le service uniquement accessible à partir du cluster.
Il s'agit du `ServiceType` par défaut.
* [`NodePort`](#type-nodeport): Expose le service sur l'IP de chaque nœud sur un port statique (le `NodePort`).
- Un service `ClusterIP`, vers lequel le service` NodePort` est automatiquement créé.
+ Un service `ClusterIP`, vers lequel le service `NodePort` est automatiquement créé.
Vous pourrez contacter le service `NodePort`, depuis l'extérieur du cluster, en demandant `: `.
* [`LoadBalancer`](#loadbalancer): Expose le service en externe à l'aide de l'équilibreur de charge d'un fournisseur de cloud.
Les services `NodePort` et `ClusterIP`, vers lesquels les itinéraires de l'équilibreur de charge externe, sont automatiquement créés.
- * [`ExternalName`](#externalname): Mappe le service au contenu du champ `externalName` (par exemple` foo.bar.example.com`), en renvoyant un enregistrement `CNAME` avec sa valeur.
+ * [`ExternalName`](#externalname): Mappe le service au contenu du champ `externalName` (par exemple `foo.bar.example.com`), en renvoyant un enregistrement `CNAME` avec sa valeur.
Aucun proxy d'aucune sorte n'est mis en place.
{{< note >}}
Vous avez besoin de CoreDNS version 1.7 ou supérieure pour utiliser le type `ExternalName`.
diff --git a/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md
index cdb91bb27a..b039d19c8b 100644
--- a/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md
+++ b/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md
@@ -122,7 +122,7 @@ On branch master
### Valider votre fichier édité
-Exécutez `git add` et ` git commit` pour valider les modifications que vous avez apportées jusqu'à présent.
+Exécutez `git add` et `git commit` pour valider les modifications que vous avez apportées jusqu'à présent.
Dans l'étape suivante, vous ferez un deuxième commit.
Il est important de séparer vos modifications en deux commits.
@@ -152,7 +152,7 @@ Voir le contenu de `api/openapi-spec/swagger.json` pour vous assurer que la faut
Par exemple, vous pouvez exécuter `git diff -a api/openapi-spec/swagger.json`.
Ceci est important, car `swagger.json` sera l’entrée de la seconde étape du processus de génération de doc.
-Exécutez `git add` et ` git commit` pour valider vos modifications.
+Exécutez `git add` et `git commit` pour valider vos modifications.
Vous avez maintenant deux validations: une avec le fichier `types.go` édité et une avec les spécifications OpenAPI générées et les fichiers associés.
Gardez ces deux commits séparés.
C'est-à-dire, ne faites pas un squash de vos commits.
diff --git a/content/fr/docs/setup/custom-cloud/kops.md b/content/fr/docs/setup/custom-cloud/kops.md
index 297ce01b73..fa2f5acfbe 100644
--- a/content/fr/docs/setup/custom-cloud/kops.md
+++ b/content/fr/docs/setup/custom-cloud/kops.md
@@ -132,7 +132,7 @@ mais aussi `dev.example.com` ou même `example.com`. kops fonctionne avec n'impo
Supposons que vous utilisiez `dev.example.com` comme zone hébergée. Vous créeriez cette zone hébergée en utilisant la [méthode normal](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), ou avec une ligne de commande telle que `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
Vous devrez ensuite configurer vos enregistrements NS dans le domaine parent afin que vous puissiez résoudre dans ce domaine.
-Vous créeriez donc des enregistrements NS dans le domaine `example.com` pour` dev`.
+Vous créeriez donc des enregistrements NS dans le domaine `example.com` pour `dev`.
S'il s'agit d'un nom de domaine racine, vous devrez configurer les enregistrements NS chez votre hébergeur de nom de domaine (là où vous avez acheté votre nom de domaine `example.com`).
Cette étape est délicate, soyez vigilants (c’est la première cause de problèmes !). Vous pouvez vérifier que
@@ -195,7 +195,7 @@ Il applique les modifications que vous avez apportées à la configuration sur v
Par exemple, après un `kops edit ig nodes`, puis un `kops update cluster --yes` pour appliquer votre configuration, parfois, vous devrez également exécuter un `kops rolling-update cluster` pour déployer la configuration immédiatement.
-Sans l'argument `--yes`,` kops update cluster` vous montrera un aperçu de ce qu’il va faire. C'est pratique
+Sans l'argument `--yes`, `kops update cluster` vous montrera un aperçu de ce qu’il va faire. C'est pratique
pour les clusters de production !
### Explorer d'autres composants additionnels (add-ons)
diff --git a/content/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index f25ac905be..9983bde03c 100644
--- a/content/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -243,7 +243,7 @@ Alternativement, si vous êtes `root`, vous pouvez exécuter:
export KUBECONFIG=/etc/kubernetes/admin.conf
```
-Faites un enregistrement du retour de la commande `kubeadm join` que` kubeadm init` génère. Vous avez
+Faites un enregistrement du retour de la commande `kubeadm join` que `kubeadm init` génère. Vous avez
besoin de cette commande pour [joindre des noeuds à votre cluster](#join-nodes).
Le jeton est utilisé pour l'authentification mutuelle entre le master et les nœuds qui veulent le rejoindre.
@@ -284,7 +284,7 @@ car cela pourrait entraîner des problèmes.
Si vous constatez une collision entre le réseau de pod de votre plug-in de réseau et certains
de vos réseaux hôtes,
vous devriez penser à un remplacement de CIDR approprié et l'utiliser lors de `kubeadm init` avec
-` --pod-network-cidr` et en remplacement du YAML de votre plugin réseau.
+ `--pod-network-cidr` et en remplacement du YAML de votre plugin réseau.
Vous pouvez installer un add-on réseau de pod avec la commande suivante:
```bash
@@ -304,8 +304,8 @@ Pour plus d'informations sur l'utilisation de Calico, voir
[Installation de Calico pour les netpols ( network policies ) et le réseau](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), ainsi que d'autres resources liées à ce sujet.
Pour que Calico fonctionne correctement, vous devez passer `--pod-network-cidr = 192.168.0.0 / 16`
-à` kubeadm init` ou mettre à jour le fichier `calico.yml` pour qu'il corresponde à votre réseau de Pod.
-Notez que Calico fonctionne uniquement sur `amd64`,` arm64`, `ppc64le` et` s390x`.
+à `kubeadm init` ou mettre à jour le fichier `calico.yml` pour qu'il corresponde à votre réseau de Pod.
+Notez que Calico fonctionne uniquement sur `amd64`, `arm64`, `ppc64le` et `s390x`.
```shell
kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
@@ -317,7 +317,7 @@ Canal utilise Calico pour les netpols et Flannel pour la mise en réseau. Report
documentation Calico pour obtenir le [guide de démarrage officiel](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/flannel).
Pour que Canal fonctionne correctement, `--pod-network-cidr = 10.244.0.0 / 16` doit être passé à
-` kubeadm init`. Notez que Canal ne fonctionne que sur `amd64`.
+`kubeadm init`. Notez que Canal ne fonctionne que sur `amd64`.
```shell
kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml
@@ -353,14 +353,14 @@ cilium-drxkl 1/1 Running 0 18m
{{% /tab %}}
{{% tab name="Flannel" %}}
-Pour que `flannel` fonctionne correctement, vous devez passer` --pod-network-cidr = 10.244.0.0 / 16` à `kubeadm init`.
+Pour que `flannel` fonctionne correctement, vous devez passer `--pod-network-cidr = 10.244.0.0 / 16` à `kubeadm init`.
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant
-` sysctl net.bridge.bridge-nf-call-iptables = 1`
+ `sysctl net.bridge.bridge-nf-call-iptables = 1`
passez le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI
fonctionnent, pour plus d'informations
allez voir [ici](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
-Notez que `flannel` fonctionne sur` amd64`, `arm`,` arm64`, `ppc64le` et` s390x` sous Linux.
+Notez que `flannel` fonctionne sur `amd64`, `arm`, `arm64`, `ppc64le` et `s390x` sous Linux.
Windows (`amd64`) est annoncé comme supporté dans la v0.11.0 mais son utilisation n’est pas
documentée.
@@ -378,7 +378,7 @@ Ceci est nécessaire pour que certains plugins CNI fonctionnent, pour plus d'inf
s'il vous plaît allez voir [ici](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
Kube-router s'appuie sur kube-controller-manager pour allouer le pod CIDR aux nœuds. Par conséquent,
-utilisez `kubeadm init` avec l'option` --pod-network-cidr`.
+utilisez `kubeadm init` avec l'option `--pod-network-cidr`.
Kube-router fournit un réseau de pod, une stratégie réseau et un proxy de service basé sur un
IP Virtual Server (IPVS) / Linux Virtual Server (LVS) hautement performant.
@@ -388,7 +388,7 @@ veuillez consulter le [guide d'installation](https://github.com/cloudnativelabs/
{{% /tab %}}
{{% tab name="Romana" %}}
-Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à` 1` en exécutant
+Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à `1` en exécutant
`sysctl net.bridge.bridge-nf-call-iptables = 1`
Cette commande indiquera de passer le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI fonctionnent,
pour plus d'informations
@@ -404,13 +404,13 @@ kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containe
{{% /tab %}}
{{% tab name="Weave Net" %}}
-Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant` sysctl net.bridge.bridge-nf-call-iptables = 1`
+Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant `sysctl net.bridge.bridge-nf-call-iptables = 1`
Cette commande indiquera de passer le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI fonctionnent, pour plus d'informations
s'il vous plaît allez voir [ici](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
Le guide de configuration officiel de Weave Net est [ici](https://www.weave.works/docs/net/latest/kube-addon/).
-Weave Net fonctionne sur `amd64`,` arm`, `arm64` et` ppc64le` sans aucune action supplémentaire requise.
+Weave Net fonctionne sur `amd64`, `arm`, `arm64` et `ppc64le` sans aucune action supplémentaire requise.
Weave Net paramètre le mode hairpin par défaut. Cela permet aux pods de se connecter via leur adresse IP de service
s'ils ne connaissent pas leur Pod IP.
@@ -597,7 +597,7 @@ Si vous souhaitez réinitialiser les tables IPVS, vous devez exécuter la comman
ipvsadm -C
```
-Si vous souhaitez recommencer Il suffit de lancer `kubeadm init` ou` kubeadm join` avec les
+Si vous souhaitez recommencer Il suffit de lancer `kubeadm init` ou `kubeadm join` avec les
arguments appropriés.
Plus d'options et d'informations sur la
[`commande de réinitialisation de kubeadm`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/).
diff --git a/content/fr/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/fr/docs/setup/production-environment/tools/kubeadm/ha-topology.md
index fbc9d14c0c..d2e8d9fde8 100644
--- a/content/fr/docs/setup/production-environment/tools/kubeadm/ha-topology.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/ha-topology.md
@@ -27,7 +27,7 @@ Un cluster HA empilé est une [topologie réseau](https://fr.wikipedia.org/wiki/
où le cluster de stockage de données distribuées est fourni par etcd et est superposé au
cluster formé par les noeuds gérés par kubeadm qui exécute les composants du control plane.
-Chaque nœud du control plane exécute une instance de `kube-apiserver`,` kube-scheduler` et
+Chaque nœud du control plane exécute une instance de `kube-apiserver`, `kube-scheduler` et
`kube-controller-manager`.
Le `kube-apiserver` est exposé aux nœuds à l'aide d'un loadbalancer.
@@ -47,7 +47,7 @@ Par conséquent, vous devez exécuter au moins trois nœuds de control plane emp
en haute disponibilité.
C'est la topologie par défaut dans kubeadm. Un membre etcd local est créé automatiquement
-sur les noeuds du control plane en utilisant `kubeadm init` et` kubeadm join --experimental-control-plane`.
+sur les noeuds du control plane en utilisant `kubeadm init` et `kubeadm join --experimental-control-plane`.
Schéma de la [Topologie etcd empilée](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
@@ -59,7 +59,7 @@ distribuées fourni par etcd est externe au cluster formé par les nœuds qui ex
du control plane.
Comme la topologie etcd empilée, chaque nœud du control plane d'une topologie etcd externe exécute
-une instance de `kube-apiserver`,` kube-scheduler` et `kube-controller-manager`. Et le `kube-apiserver`
+une instance de `kube-apiserver`, `kube-scheduler` et `kube-controller-manager`. Et le `kube-apiserver`
est exposé aux nœuds workers à l’aide d’un load-balancer. Cependant, les membres etcd s'exécutent sur
des hôtes distincts et chaque hôte etcd communique avec le `kube-apiserver` de chaque nœud du control plane.
diff --git a/content/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index 20b44143e2..a45ed1f7db 100644
--- a/content/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -250,7 +250,7 @@ ARCH="amd64"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
```
-Installez `kubeadm`,` kubelet`, `kubectl` et ajoutez un service systemd` kubelet`:
+Installez `kubeadm`, `kubelet`, `kubectl` et ajoutez un service systemd `kubelet`:
RELEASE_VERSION="v0.6.0"
diff --git a/content/fr/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/fr/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
index 05f4839c05..9317f482f9 100644
--- a/content/fr/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
@@ -38,7 +38,7 @@ utilisant kubeadm, plutôt que de gérer manuellement la configuration des kubel
### Propagation de la configuration niveau cluster à chaque kubelet {#propagating-cluster-level-configuration-to-each-kubelet}
Vous pouvez fournir à la kubelet les valeurs par défaut à utiliser par les commandes `kubeadm init` et
-` kubeadm join`. Des exemples intéressants incluent l’utilisation d’un runtime CRI différent ou la
+ `kubeadm join`. Des exemples intéressants incluent l’utilisation d’un runtime CRI différent ou la
définition du sous-réseau par défaut utilisé par les services.
Si vous souhaitez que vos services utilisent le sous-réseau `10.96.0.0 / 12` par défaut pour les
diff --git a/content/fr/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/fr/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index bf9b0d69cb..79ead91bb3 100644
--- a/content/fr/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/fr/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -102,26 +102,26 @@ L'inspection des journaux de Docker peut également être utile:
journalctl -ul docker
```
-## Pods dans l'état `RunContainerError`,` CrashLoopBackOff` ou `Error`
+## Pods dans l'état `RunContainerError`, `CrashLoopBackOff` ou `Error`
Juste après `kubeadm init`, il ne devrait pas y avoir de pods dans ces états.
- S'il existe des pods dans l'un de ces états _juste après_ `kubeadm init`, veuillez ouvrir un
issue dans le dépôt de Kubeadm. `coredns` (ou` kube-dns`) devrait être dans l'état `Pending`
jusqu'à ce que vous ayez déployé la solution réseau.
-- Si vous voyez des pods dans les états `RunContainerError`,` CrashLoopBackOff` ou `Error`
+- Si vous voyez des pods dans les états `RunContainerError`, `CrashLoopBackOff` ou `Error`
après le déploiement de la solution réseau et que rien ne se passe pour `coredns` (ou` kube-dns`),
il est très probable que la solution Pod Network que vous avez installée est en quelque sorte
endommagée. Vous devrez peut-être lui accorder plus de privilèges RBAC ou utiliser une version
plus récente. S'il vous plaît créez une issue dans le dépôt du fournisseur de réseau de Pod.
- Si vous installez une version de Docker antérieure à 1.12.1, supprimez l'option `MountFlags = slave`
- lors du démarrage de `dockerd` avec` systemd` et redémarrez `docker`. Vous pouvez voir les options
+ lors du démarrage de `dockerd` avec `systemd` et redémarrez `docker`. Vous pouvez voir les options
de montage dans `/usr/lib/systemd/system/docker.service`.
Les options de montage peuvent interférer avec les volumes montés par Kubernetes et mettre les
- pods dans l'état`CrashLoopBackOff`. L'erreur se produit lorsque Kubernetes ne trouve pas les fichiers
+ pods dans l'état `CrashLoopBackOff`. L'erreur se produit lorsque Kubernetes ne trouve pas les fichiers
`var/run/secrets/kubernetes.io/serviceaccount`.
-## `coredns` (ou` kube-dns`) est bloqué dans l'état `Pending`
+## `coredns` (ou `kube-dns`) est bloqué dans l'état `Pending`
Ceci est **prévu** et fait partie du design. kubeadm est agnostique vis-à-vis du fournisseur
de réseau, ainsi l'administrateur devrait [installer la solution réseau pod](/docs/concepts/cluster-administration/addons/)
@@ -132,7 +132,7 @@ D'où l' état `Pending` avant la mise en place du réseau.
Les fonctionnalités `HostPort` et `HostIP` sont disponibles en fonction de votre fournisseur
de réseau de pod. Veuillez contacter l’auteur de la solution de réseau de Pod pour savoir si
-Les fonctionnalités `HostPort` et` HostIP` sont disponibles.
+Les fonctionnalités `HostPort` et `HostIP` sont disponibles.
Les fournisseurs de CNI Calico, Canal, et Flannel supportent HostPort.
@@ -151,7 +151,7 @@ Si votre fournisseur de réseau ne prend pas en charge le plug-in portmap CNI, v
- Si vous utilisez VirtualBox (directement ou via Vagrant), vous devrez vous assurez que
`hostname -i` renvoie une adresse IP routable. Par défaut la première interface est connectée
-à un réseau d’`hôte uniquement` non routable. En contournement vous pouvez modifier`/etc/hosts`,
+à un réseau d’ `hôte uniquement` non routable. En contournement vous pouvez modifier `/etc/hosts`,
jetez un œil à ce [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11) par exemple.
## Erreurs de certificats TLS
@@ -198,7 +198,7 @@ pour que la deuxième interface soit choisie.
## IP non publique utilisée pour les conteneurs
-Dans certaines situations, les commandes `kubectl logs` et` kubectl run` peuvent
+Dans certaines situations, les commandes `kubectl logs` et `kubectl run` peuvent
renvoyer les erreurs suivantes dans un cluster par ailleurs fonctionnel:
```sh
@@ -211,9 +211,9 @@ avec d’autres adresses IP même sous-réseau, éventuellement à cause d'une p
par le fournisseur de la machine.
- Digital Ocean attribue une adresse IP publique à `eth0` ainsi qu’une adresse privée à
utiliser en interne comme IP d'ancrage pour leur fonction IP flottante, mais `kubelet` choisira cette
-dernière comme` InternalIP` du noeud au lieu du public.
+dernière comme `InternalIP` du noeud au lieu du public.
- Utilisez `ip addr show` pour verifier ce scénario au lieu de` ifconfig` car `ifconfig` n'affichera pas
+ Utilisez `ip addr show` pour verifier ce scénario au lieu de `ifconfig` car `ifconfig` n'affichera pas
l'alias de l'adresse IP incriminée. Sinon, une API spécifique à Digital Ocean
permet de rechercher l'adresse IP d'ancrage à partir du droplet:
@@ -253,7 +253,7 @@ Pod de CoreDNS déployé dans Kubernetes détecte une boucle. [Un certain nombre
sont disponibles pour éviter que Kubernetes ne tente de redémarrer le pod CoreDNS chaque fois que CoreDNS détecte une boucle et s'arrête.
{{< warning >}}
-Désactiver SELinux ou paramètrer `allowPrivilegeEscalation` sur` true` peut compromettre
+Désactiver SELinux ou paramètrer `allowPrivilegeEscalation` sur `true` peut compromettre
la sécurité de votre cluster.
{{< /warning >}}
From 4d06efb2b82eb88ef5359a782bf5cdf304120698 Mon Sep 17 00:00:00 2001
From: Sean Wei
Date: Thu, 14 Apr 2022 01:41:45 +0800
Subject: [PATCH 097/167] [it] Fix Markdown format
---
content/it/docs/concepts/architecture/nodes.md | 10 +++++-----
.../cluster-administration/certificates.md | 2 +-
.../cluster-administration/cloud-providers.md | 12 ++++++------
.../cluster-administration/federation.md | 4 ++--
.../kubelet-garbage-collection.md | 12 ++++++------
.../concepts/cluster-administration/logging.md | 16 ++++++++--------
.../manage-deployment.md | 18 +++++++++---------
.../cluster-administration/networking.md | 6 +++---
8 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/content/it/docs/concepts/architecture/nodes.md b/content/it/docs/concepts/architecture/nodes.md
index c3c58be9d4..8bb62bb297 100644
--- a/content/it/docs/concepts/architecture/nodes.md
+++ b/content/it/docs/concepts/architecture/nodes.md
@@ -41,13 +41,13 @@ L'utilizzo di questi campi varia a seconda del provider cloud o della configuraz
### Condition
-l campo `conditions` descrive lo stato di tutti i nodi` Running`.
+l campo `conditions` descrive lo stato di tutti i nodi `Running`.
| Condizione del nodo | Descrizione |
| ---------------- | ------------- |
| `OutOfDisk` | `True` se lo spazio disponibile sul nodo non è sufficiente per aggiungere nuovi pod, altrimenti` False` |
-| `Pronto` | `True` se il nodo è integro e pronto ad accettare i pod,` False` se il nodo non è integro e non accetta i pod e `Sconosciuto` se il controller del nodo non è stato ascoltato dal nodo nell'ultimo` nodo-monitor -grace-periodo` (il valore predefinito è 40 secondi) |
+| `Pronto` | `True` se il nodo è integro e pronto ad accettare i pod, `False` se il nodo non è integro e non accetta i pod e `Sconosciuto` se il controller del nodo non è stato ascoltato dal nodo nell'ultimo` nodo-monitor -grace-periodo` (il valore predefinito è 40 secondi) |
| `MemoryPressure` | `Vero` se la pressione esiste sulla memoria del nodo, ovvero se la memoria del nodo è bassa; altrimenti `False` |
| `PIDPressure` | `True` se la pressione esiste sui processi, ovvero se ci sono troppi processi sul nodo; altrimenti `False` |
| `DiskPressure` | `True` se esiste una pressione sulla dimensione del disco, ovvero se la capacità del disco è bassa; altrimenti `False` |
@@ -64,12 +64,12 @@ La condizione del nodo è rappresentata come un oggetto JSON. Ad esempio, la seg
]
```
-Se lo stato della condizione Ready rimane `Unknown` o` False` per un tempo superiore a `pod-eviction-timeout`, viene passato un argomento al [gestore-kube-controller](/docs/admin/kube-controller-manager/) e tutti i pod sul nodo sono programmati per la cancellazione dal controller del nodo. La durata predefinita del timeout di sfratto è di ** cinque minuti **. In alcuni casi, quando il nodo non è raggiungibile, l'apiserver non è in grado di comunicare con kubelet sul nodo. La decisione di eliminare i pod non può essere comunicata al kubelet fino a quando non viene ristabilita la comunicazione con l'apiserver. Nel frattempo, i pod che sono programmati per la cancellazione possono continuare a funzionare sul nodo partizionato.
+Se lo stato della condizione Ready rimane `Unknown` o `False` per un tempo superiore a `pod-eviction-timeout`, viene passato un argomento al [gestore-kube-controller](/docs/admin/kube-controller-manager/) e tutti i pod sul nodo sono programmati per la cancellazione dal controller del nodo. La durata predefinita del timeout di sfratto è di ** cinque minuti **. In alcuni casi, quando il nodo non è raggiungibile, l'apiserver non è in grado di comunicare con kubelet sul nodo. La decisione di eliminare i pod non può essere comunicata al kubelet fino a quando non viene ristabilita la comunicazione con l'apiserver. Nel frattempo, i pod che sono programmati per la cancellazione possono continuare a funzionare sul nodo partizionato.
Nelle versioni di Kubernetes precedenti alla 1.5, il controllore del nodo [forzerebbe la cancellazione](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
questi pod non raggiungibili dall'apiserver. Tuttavia, in 1.5 e versioni successive, il controller del nodo non impone l'eliminazione dei pod finché non lo è
confermato che hanno smesso di funzionare nel cluster. Puoi vedere i pod che potrebbero essere in esecuzione su un nodo irraggiungibile
-lo stato `Terminating` o` Unknown`. Nei casi in cui Kubernetes non può dedurre dall'infrastruttura sottostante se ha un nodo
+lo stato `Terminating` o `Unknown`. Nei casi in cui Kubernetes non può dedurre dall'infrastruttura sottostante se ha un nodo
lasciato permanentemente un cluster, potrebbe essere necessario che l'amministratore del cluster elimini manualmente l'oggetto nodo. Cancellare l'oggetto nodo da
Kubernetes fa sì che tutti gli oggetti Pod in esecuzione sul nodo vengano eliminati dal server apis e libera i loro nomi.
@@ -227,7 +227,7 @@ Per l'autoregistrazione, il kubelet viene avviato con le seguenti opzioni:
- `--kubeconfig` - Percorso delle credenziali per autenticarsi sull'apiserver.
- `--cloud-provider` - Come parlare con un provider cloud per leggere i metadati su se stesso.
- `--register-node` - Si registra automaticamente con il server API.
- - `--register-with-taints` - Registra il nodo con la lista data di taints (separati da virgola` = : `). No-op se `register-node` è falso.
+ - `--register-with-taints` - Registra il nodo con la lista data di taints (separati da virgola ` = : `). No-op se `register-node` è falso.
- `--node-ip` - Indirizzo IP del nodo.
- `--node-labels` - Etichette da aggiungere quando si registra il nodo nel cluster (vedere le restrizioni dell'etichetta applicate dal [plugin di accesso NodeRestriction](/docs/reference/access-authn-authz/admission-controller/#noderestriction) in 1.13+).
- `--node-status-update-frequency` - Specifica la frequenza con cui kubelet invia lo stato del nodo al master
diff --git a/content/it/docs/concepts/cluster-administration/certificates.md b/content/it/docs/concepts/cluster-administration/certificates.md
index a05a982ccb..7e938447ba 100644
--- a/content/it/docs/concepts/cluster-administration/certificates.md
+++ b/content/it/docs/concepts/cluster-administration/certificates.md
@@ -9,7 +9,7 @@ weight: 20
Quando si utilizza l'autenticazione del certificato client, è possibile generare certificati
-manualmente tramite `easyrsa`,` openssl` o `cfssl`.
+manualmente tramite `easyrsa`, `openssl` o `cfssl`.
diff --git a/content/it/docs/concepts/cluster-administration/cloud-providers.md b/content/it/docs/concepts/cluster-administration/cloud-providers.md
index 78e1f38bd2..8c409061e1 100644
--- a/content/it/docs/concepts/cluster-administration/cloud-providers.md
+++ b/content/it/docs/concepts/cluster-administration/cloud-providers.md
@@ -47,7 +47,7 @@ controllerManager:
mountPath: "/etc/kubernetes/cloud.conf"
```
-I provider cloud in-tree in genere richiedono sia `--cloud-provider` e` --cloud-config` specificati nelle righe di
+I provider cloud in-tree in genere richiedono sia `--cloud-provider` e `--cloud-config` specificati nelle righe di
comando per [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/)
e il [Kubelet](/docs/admin/kubelet/). Anche il contenuto del file specificato in `--cloud-config` per ciascun provider
è documentato di seguito.
@@ -91,8 +91,8 @@ spec:
* `service.beta.kubernetes.io / aws-load-balancer-access-log-enabled`: utilizzato sul servizio per abilitare o disabilitare i log di accesso.
* `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-name`: usato per specificare il nome del bucket di log degli accessi s3.
* `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-prefix`: utilizzato per specificare il prefisso del bucket del registro di accesso s3.
-* `service.beta.kubernetes.io / aws-load-balancer-additional-resource-tags`: utilizzato sul servizio per specificare un elenco separato da virgole di coppie chiave-valore che verranno registrate come tag aggiuntivi nel ELB. Ad esempio: "Key1 = Val1, Key2 = Val2, KeyNoVal1 =, KeyNoVal2" `.
-* `service.beta.kubernetes.io / aws-load-balancer-backend-protocol`: utilizzato sul servizio per specificare il protocollo parlato dal backend (pod) dietro un listener. Se `http` (predefinito) o` https`, viene creato un listener HTTPS che termina la connessione e analizza le intestazioni. Se impostato su `ssl` o` tcp`, viene utilizzato un listener SSL "raw". Se impostato su `http` e` aws-load-balancer-ssl-cert` non viene utilizzato, viene utilizzato un listener HTTP.
+* `service.beta.kubernetes.io / aws-load-balancer-additional-resource-tags`: utilizzato sul servizio per specificare un elenco separato da virgole di coppie chiave-valore che verranno registrate come tag aggiuntivi nel ELB. Ad esempio: `"Key1 = Val1, Key2 = Val2, KeyNoVal1 =, KeyNoVal2"`.
+* `service.beta.kubernetes.io / aws-load-balancer-backend-protocol`: utilizzato sul servizio per specificare il protocollo parlato dal backend (pod) dietro un listener. Se `http` (predefinito) o `https`, viene creato un listener HTTPS che termina la connessione e analizza le intestazioni. Se impostato su `ssl` o `tcp`, viene utilizzato un listener SSL "raw". Se impostato su `http` e `aws-load-balancer-ssl-cert` non viene utilizzato, viene utilizzato un listener HTTP.
* `service.beta.kubernetes.io / aws-load-balancer-ssl-cert`: utilizzato nel servizio per richiedere un listener sicuro. Il valore è un certificato ARN valido. Per ulteriori informazioni, vedere [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN è un ARN certificato IAM o CM, ad es. `ARN: AWS: ACM: US-est-1: 123456789012: certificato / 12345678-1234-1234-1234-123456789012`.
* `service.beta.kubernetes.io / aws-load-balancer-connection-draining-enabled`: utilizzato sul servizio per abilitare o disabilitare il drenaggio della connessione.
* `service.beta.kubernetes.io / aws-load-balancer-connection-draining-timeout`: utilizzato sul servizio per specificare un timeout di drenaggio della connessione.
@@ -125,7 +125,7 @@ corrispondere al nome VM di CloudStack.
Il provider cloud GCE utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il primo segmento del nome del nodo
Kubernetes deve corrispondere al nome dell'istanza GCE (ad esempio, un nodo denominato `kubernetes-node-2.c.my-proj.internal`
-deve corrispondere a un'istanza denominata` kubernetes-node-2`) .
+deve corrispondere a un'istanza denominata `kubernetes-node-2`) .
## OpenStack
Questa sezione descrive tutte le possibili configurazioni che possono
@@ -243,7 +243,7 @@ file:
il bilanciamento del carico.
* `lb-method` (Opzionale): utilizzato per specificare l'algoritmo in base al quale verrà caricato il carico
distribuito tra i membri del pool di bilanciamento del carico. Il valore può essere
- `ROUND_ROBIN`,` LEAST_CONNECTIONS` o `SOURCE_IP`. Il comportamento predefinito se
+ `ROUND_ROBIN`, `LEAST_CONNECTIONS` o `SOURCE_IP`. Il comportamento predefinito se
nessuno è specificato è `ROUND_ROBIN`.
* `lb-provider` (Opzionale): utilizzato per specificare il provider del servizio di bilanciamento del carico.
Se non specificato, sarà il servizio provider predefinito configurato in neutron
@@ -272,7 +272,7 @@ Queste opzioni di configurazione per il provider OpenStack riguardano lo storage
e dovrebbe apparire nella sezione `[BlockStorage]` del file `cloud.conf`:
* `bs-version` (Opzionale): usato per sovrascrivere il rilevamento automatico delle versioni. Valido
- i valori sono `v1`,` v2`, `v3` e` auto`. Quando `auto` è specificato automatico
+ i valori sono `v1`, `v2`, `v3` e `auto`. Quando `auto` è specificato automatico
il rilevamento selezionerà la versione supportata più alta esposta dal sottostante
Cloud OpenStack. Il valore predefinito se nessuno è fornito è `auto`.
* `trust-device-path` (Opzionale): Nella maggior parte degli scenari i nomi dei dispositivi a blocchi
diff --git a/content/it/docs/concepts/cluster-administration/federation.md b/content/it/docs/concepts/cluster-administration/federation.md
index 7f4bdb5998..48816b40f9 100644
--- a/content/it/docs/concepts/cluster-administration/federation.md
+++ b/content/it/docs/concepts/cluster-administration/federation.md
@@ -162,9 +162,9 @@ In secondo luogo, decidi quanti cluster dovrebbero essere disponibili allo stess
il numero che può essere non disponibile `U`. Se non sei sicuro, allora 1 è una buona scelta.
Se è possibile bilanciare il carico per indirizzare il traffico verso qualsiasi regione in caso di guasto di un cluster, allora
-avete bisogno almeno dei grossi `R` o` U + 1`. Se non lo è (ad esempio, vuoi garantire una bassa latenza per tutti
+avete bisogno almeno dei grossi `R` o `U + 1`. Se non lo è (ad esempio, vuoi garantire una bassa latenza per tutti
utenti in caso di guasto di un cluster), quindi è necessario disporre di cluster `R * (U + 1)`
-(`U + 1` in ciascuna delle regioni` R`). In ogni caso, prova a mettere ciascun cluster in una zona diversa.
+(`U + 1` in ciascuna delle regioni `R`). In ogni caso, prova a mettere ciascun cluster in una zona diversa.
Infine, se uno qualsiasi dei tuoi cluster richiederebbe più del numero massimo consigliato di nodi per un cluster Kubernetes, allora
potresti aver bisogno di più cluster. Kubernetes v1.3 supporta cluster di dimensioni fino a 1000 nodi. Supporta Kubernetes v1.8
diff --git a/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md
index 10e0af08cc..da7d469101 100644
--- a/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md
+++ b/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md
@@ -23,12 +23,12 @@ Kubernetes gestisce il ciclo di vita di tutte le immagini tramite imageManager,
di consulente.
La politica per la raccolta dei rifiuti delle immagini prende in considerazione due fattori:
-`HighThresholdPercent` e` LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
+`HighThresholdPercent` e `LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
attiverà la garbage collection. La garbage collection cancellerà le immagini utilizzate meno di recente fino al minimo
soglia è stata soddisfatta.
La politica per la raccolta dei rifiuti delle immagini prende in considerazione due fattori:
-`HighThresholdPercent` e` LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
+`HighThresholdPercent` e `LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
attiverà la garbage collection. La garbage collection cancellerà le immagini utilizzate meno di recente fino al minimo
soglia è stata soddisfatta.
@@ -44,8 +44,8 @@ Kubelet agirà su contenitori non identificati, cancellati o al di fuori dei lim
precedentemente menzionate. I contenitori più vecchi saranno generalmente rimossi per primi. `MaxPerPodContainer`
e `MaxContainer` possono potenzialmente entrare in conflitto l'uno con l'altro in situazioni in cui il mantenimento del
numero massimo di contenitori per pod (`MaxPerPodContainer`) non rientra nell'intervallo consentito di contenitori morti
-globali (` MaxContainers`). `MaxPerPodContainer` verrebbe regolato in questa situazione: uno scenario peggiore sarebbe
-quello di eseguire il downgrade di` MaxPerPodContainer` su 1 e rimuovere i contenitori più vecchi. Inoltre, i
+globali (`MaxContainers`). `MaxPerPodContainer` verrebbe regolato in questa situazione: uno scenario peggiore sarebbe
+quello di eseguire il downgrade di `MaxPerPodContainer` su 1 e rimuovere i contenitori più vecchi. Inoltre, i
contenitori di proprietà dei pod che sono stati cancellati vengono rimossi una volta che sono più vecchi di "MinAge".
I contenitori che non sono gestiti da Kubelet non sono soggetti alla garbage collection del contenitore.
@@ -83,12 +83,12 @@ Compreso:
| Bandiera esistente | Nuova bandiera | Motivazione
| ------------- | -------- | --------- |
-| `--image-gc-high-threshold` | `--eviction-hard` o` --eviction-soft` | i segnali di sfratto esistenti possono innescare la garbage collection delle immagini |
+| `--image-gc-high-threshold` | `--eviction-hard` o `--eviction-soft` | i segnali di sfratto esistenti possono innescare la garbage collection delle immagini |
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | i reclami di sfratto ottengono lo stesso comportamento |
| `--maximum-dead-containers` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
| `--maximum-dead-containers-per-container` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
| `--minimum-container-ttl-duration` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
-| `--low-diskspace-threshold-mb` | `--eviction-hard` o` eviction-soft` | lo sfratto generalizza le soglie del disco ad altre risorse |
+| `--low-diskspace-threshold-mb` | `--eviction-hard` o `eviction-soft` | lo sfratto generalizza le soglie del disco ad altre risorse |
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | lo sfratto generalizza la transizione della pressione del disco verso altre risorse |
diff --git a/content/it/docs/concepts/cluster-administration/logging.md b/content/it/docs/concepts/cluster-administration/logging.md
index 601dfcf365..931eb1c2cb 100644
--- a/content/it/docs/concepts/cluster-administration/logging.md
+++ b/content/it/docs/concepts/cluster-administration/logging.md
@@ -47,7 +47,7 @@ $ kubectl logs counter
...
```
-You can use `kubectl logs` to retrieve logsPuoi usare `kubectl logs` per recuperare i log da una precedente istanziazione di un contenitore con il flag` --previous`, nel caso in cui il contenitore si sia arrestato in modo anomalo. Se il pod ha più contenitori, è necessario specificare i registri del contenitore a cui si desidera accedere aggiungendo un nome contenitore al comando. Vedi la documentazione [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) per maggiori dettagli. from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
+You can use `kubectl logs` to retrieve logsPuoi usare `kubectl logs` per recuperare i log da una precedente istanziazione di un contenitore con il flag `--previous`, nel caso in cui il contenitore si sia arrestato in modo anomalo. Se il pod ha più contenitori, è necessario specificare i registri del contenitore a cui si desidera accedere aggiungendo un nome contenitore al comando. Vedi la documentazione [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) per maggiori dettagli. from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
## Logging at the node level
@@ -105,7 +105,7 @@ bypassando il meccanismo di registrazione predefinito. Usano il [klog] [klog]
biblioteca di registrazione. È possibile trovare le convenzioni per la gravità della registrazione per quelli
componenti nel [documento di sviluppo sulla registrazione](https://git.k8s.io/community/contributors/devel/logging.md).
-Analogamente ai log del contenitore, i log dei componenti di sistema sono in /var/log`
+Analogamente ai log del contenitore, i log dei componenti di sistema sono in `/var/log`
la directory dovrebbe essere ruotata. Nei cluster di Kubernetes allevati da
lo script `kube-up.sh`, quei log sono configurati per essere ruotati da
lo strumento `logrotate` al giorno o una volta che la dimensione supera i 100 MB.
@@ -143,7 +143,7 @@ Puoi utilizzare un contenitore sidecar in uno dei seguenti modi:
-Facendo scorrere i propri contenitori sidecar sul proprio `stdout` e` stderr`
+Facendo scorrere i propri contenitori sidecar sul proprio `stdout` e `stderr`
flussi, è possibile sfruttare il kubelet e l'agente di registrazione che
già eseguito su ciascun nodo. I contenitori del sidecar leggono i log da un file, un socket,
o il diario. Ogni singolo contenitore sidecar stampa il log nel proprio `stdout`
@@ -151,16 +151,16 @@ o flusso `stderr`.
Questo approccio consente di separare diversi flussi di log da diversi
parti della tua applicazione, alcune delle quali possono mancare di supporto
-per scrivere su `stdout` o` stderr`. La logica dietro il reindirizzamento dei registri
+per scrivere su `stdout` o `stderr`. La logica dietro il reindirizzamento dei registri
è minimo, quindi non è un sovraccarico significativo. Inoltre, perché
-`stdout` e` stderr` sono gestiti da kubelet, puoi usare gli strumenti integrati
+`stdout` e `stderr` sono gestiti da kubelet, puoi usare gli strumenti integrati
come `log di kubectl`.
Considera il seguente esempio. Un pod esegue un singolo contenitore e il contenitore
scrive su due file di registro diversi, utilizzando due formati diversi. Ecco un
file di configurazione per il pod:
-{{}}
+{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
Sarebbe un disastro avere voci di registro di diversi formati nello stesso registro
stream, anche se si è riusciti a reindirizzare entrambi i componenti al flusso `stdout` di
@@ -170,7 +170,7 @@ i registri al proprio flusso `stdout`.
Ecco un file di configurazione per un pod con due contenitori sidecar:
-{{}}
+{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
Ora quando si esegue questo pod, è possibile accedere separatamente a ciascun flusso di log
eseguendo i seguenti comandi:
@@ -205,7 +205,7 @@ approccio contenitore.
I contenitori del sidecar possono anche essere usati per ruotare i file di log che non possono essere
ruotato dall'applicazione stessa. [Un esempio](https://github.com/samsung-cnct/logrotate)
di questo approccio è un piccolo contenitore che esegue periodicamente logrotate.
-Tuttavia, si raccomanda di usare `stdout` e` stderr` direttamente e lasciare la rotazione
+Tuttavia, si raccomanda di usare `stdout` e `stderr` direttamente e lasciare la rotazione
e politiche di conservazione al kubelet.
diff --git a/content/it/docs/concepts/cluster-administration/manage-deployment.md b/content/it/docs/concepts/cluster-administration/manage-deployment.md
index 24b2a76390..4d68765214 100644
--- a/content/it/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/it/docs/concepts/cluster-administration/manage-deployment.md
@@ -89,7 +89,7 @@ my-nginx-svc LoadBalancer 10.0.0.208 80/TCP 0s
```
Con i suddetti comandi, prima creiamo le risorse sotto `examples/application/nginx/` e stampiamo le risorse create con il formato di output `-o name`
-(stampa ogni risorsa come risorsa / nome). Quindi `grep` solo il" servizio ", e poi lo stampiamo con` kubectl get`.
+(stampa ogni risorsa come risorsa / nome). Quindi `grep` solo il" servizio ", e poi lo stampiamo con `kubectl get`.
Se si organizzano le risorse su più sottodirectory all'interno di una particolare directory, è possibile eseguire ricorsivamente anche le operazioni nelle sottodirectory, specificando `--recursive` o` -R` accanto al flag `--filename, -f`.
@@ -112,7 +112,7 @@ $ kubectl create -f project/k8s/development
error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)
```
-Invece, specifica il flag `--recursive` o` -R` con il flag `--filename, -f` come tale:
+Invece, specifica il flag `--recursive` o `-R` con il flag `--filename, -f` come tale:
```shell
$ kubectl create -f project/k8s/development --recursive
@@ -121,7 +121,7 @@ deployment.apps/my-deployment created
persistentvolumeclaim/my-pvc created
```
-Il flag `--recursive` funziona con qualsiasi operazione che accetta il flag` --filename, -f` come: `kubectl {crea, ottieni, cancella, descrivi, implementa} ecc .`
+Il flag `--recursive` funziona con qualsiasi operazione che accetta il flag `--filename, -f` come: `kubectl {crea, ottieni, cancella, descrivi, implementa} ecc .`
Il flag `--recursive` funziona anche quando sono forniti più argomenti` -f`:
@@ -195,7 +195,7 @@ modo che la nuova versione possa ricevere il traffico di produzione in tempo rea
Ad esempio, puoi usare un'etichetta `track` per differenziare le diverse versioni.
-La versione stabile e primaria avrebbe un'etichetta `track` con valore come` stable`:
+La versione stabile e primaria avrebbe un'etichetta `track` con valore come `stable`:
```yaml
name: frontend
@@ -210,7 +210,7 @@ La versione stabile e primaria avrebbe un'etichetta `track` con valore come` sta
```
e quindi puoi creare una nuova versione del frontend del guestbook che porta l'etichetta `track` con un valore diverso
-(ad esempio` canary`), in modo che due gruppi di pod non si sovrappongano:
+(ad esempio `canary`), in modo che due gruppi di pod non si sovrappongano:
```yaml
name: frontend-canary
@@ -266,7 +266,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
```
questo produce tutti i pod "app = nginx", con un'ulteriore colonna di etichette del livello dei pod (specificata
-con `-L` o` --label-columns`).
+con `-L` o `--label-columns`).
Per ulteriori informazioni, consultare [labels](/docs/concepts/overview/working-with-objects/labels/) e
[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
@@ -353,7 +353,7 @@ non è in grado di rilevare l'eliminazione delle proprietà impostate al momento
motivo, non li rimuoverà.
Tutte le chiamate successive a `kubectl apply`, e altri comandi che modificano la configurazione, come `kubectl replace`
-e `kubectl edit`, aggiorneranno l'annotazione, consentendo le successive chiamate a` kubectl apply` per rilevare ed
+e `kubectl edit`, aggiorneranno l'annotazione, consentendo le successive chiamate a `kubectl apply` per rilevare ed
eseguire cancellazioni usando un tre via diff.
{{< note >}}
@@ -368,7 +368,7 @@ In alternativa, puoi anche aggiornare le risorse con `kubectl edit`:
$ kubectl edit deployment/my-nginx
```
-Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la
+Questo equivale a prima `get` la risorsa, modificarla nell'editor di testo e quindi `apply` la risorsa con la
versione aggiornata:
```shell
@@ -381,7 +381,7 @@ $ rm /tmp/nginx.yaml
```
Questo ti permette di fare più cambiamenti significativi più facilmente. Nota che puoi specificare l'editor con le
-variabili di ambiente `EDITOR` o` KUBE_EDITOR`.
+variabili di ambiente `EDITOR` o `KUBE_EDITOR`.
Per ulteriori informazioni, consultare il documento [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit).
diff --git a/content/it/docs/concepts/cluster-administration/networking.md b/content/it/docs/concepts/cluster-administration/networking.md
index af99f91735..cf895a1845 100644
--- a/content/it/docs/concepts/cluster-administration/networking.md
+++ b/content/it/docs/concepts/cluster-administration/networking.md
@@ -59,7 +59,7 @@ parla con altre macchine virtuali nel tuo progetto. Questo è lo stesso modello
Gli indirizzi IP di Kubernetes esistono nello scope `Pod` - contenitori all'interno di un 'Pod`
condividere i loro spazi dei nomi di rete, compreso il loro indirizzo IP. Ciò significa che
-i contenitori all'interno di un `Pod` possono raggiungere tutti gli altri porti su` localhost`. Questo
+i contenitori all'interno di un `Pod` possono raggiungere tutti gli altri porti su `localhost`. Questo
significa anche che i contenitori all'interno di un 'Pod` devono coordinare l'utilizzo della porta, ma questo
non è diverso dai processi in una VM. Questo è chiamato il modello "IP-per-pod".
@@ -195,10 +195,10 @@ Docker è avviato con:
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
```
-Questo bridge è creato da Kubelet (controllato da `--network-plugin = kubenet` flag) in base al `Nodo` .spec.podCIDR`.
+Questo bridge è creato da Kubelet (controllato da `--network-plugin = kubenet` flag) in base al Nodo `.spec.podCIDR`.
Docker ora assegna gli IP dal blocco `cbr-cidr`. I contenitori possono raggiungere l'un l'altro e `Nodi` sul
-ponte` cbr0`. Questi IP sono tutti instradabili all'interno della rete del progetto GCE.
+ponte `cbr0`. Questi IP sono tutti instradabili all'interno della rete del progetto GCE.
GCE non sa nulla di questi IP, quindi non lo farà loro per il traffico internet in uscita. Per ottenere ciò viene
utilizzata una regola iptables masquerade (aka SNAT - per far sembrare che i pacchetti provengano dal `Node` stesso)
From e2375cc16469d595836cc87f275509ff40450b00 Mon Sep 17 00:00:00 2001
From: Sean Wei
Date: Thu, 14 Apr 2022 01:42:27 +0800
Subject: [PATCH 098/167] [es] Fix Markdown format
---
.../concepts/configuration/manage-resources-containers.md | 6 +++---
.../docs/concepts/containers/container-lifecycle-hooks.md | 4 ++--
content/es/docs/concepts/workloads/pods/pod.md | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/content/es/docs/concepts/configuration/manage-resources-containers.md b/content/es/docs/concepts/configuration/manage-resources-containers.md
index 55e17c405f..9630d271ba 100644
--- a/content/es/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/es/docs/concepts/configuration/manage-resources-containers.md
@@ -564,8 +564,8 @@ El {{< glossary_tooltip text="planificador" term_id="kube-scheduler" >}} se enca
la cantidad disponible sea asignada simultáneamente a los Pods.
El servidor de API restringe las cantidades de recursos extendidos a números enteros.
-Ejemplos de cantidades _validas_ son `3`,` 3000m` y `3Ki`. Ejemplos de
-_cantidades no válidas_ son `0.5` y` 1500m`.
+Ejemplos de cantidades _validas_ son `3`, `3000m` y `3Ki`. Ejemplos de
+_cantidades no válidas_ son `0.5` y `1500m`.
{{< note >}}
Los recursos extendidos reemplazan los Recursos Integrales Opacos.
@@ -630,7 +630,7 @@ está pendiente con un mensaje de este tipo, hay varias cosas para probar:
- Añadir más nodos al clúster.
- Terminar Pods innecesarios para hacer hueco a los Pods en estado pendiente.
- Compruebe que el Pod no sea más grande que todos los nodos. Por ejemplo, si todos los
- los nodos tienen una capacidad de `cpu: 1`, entonces un Pod con una solicitud de` cpu: 1.1`
+ los nodos tienen una capacidad de `cpu: 1`, entonces un Pod con una solicitud de `cpu: 1.1`
nunca se programará.
Puedes comprobar las capacidades del nodo y cantidad utilizada con el comando
diff --git a/content/es/docs/concepts/containers/container-lifecycle-hooks.md b/content/es/docs/concepts/containers/container-lifecycle-hooks.md
index 18cee92897..4471282d23 100644
--- a/content/es/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/es/docs/concepts/containers/container-lifecycle-hooks.md
@@ -64,7 +64,7 @@ el contenedor no puede alcanzar el estado de `running` (en ejecución).
El comportamiento es similar para un hook `PreStop`.
Si el hook se cuelga durante la ejecución,
la fase del Pod permanece en un estado de `terminating` (finalizando) y se cancela después del `terminationGracePeriodSeconds` (finalización después del periodo de gracia) del pod en cuestión.
-Si un hook `PostStart` o` PreStop` falla, se mata el contenedor.
+Si un hook `PostStart` o `PreStop` falla, se mata el contenedor.
Los usuarios deben hacer que sus controladores de hooks sean lo más livianos posible.
Hay casos, sin embargo, que los comandos de larga ejecución tienen sentido,
@@ -74,7 +74,7 @@ como cuando se guarda el estado antes de detener un contenedor.
La entrega de un hook está destinada a ser enviada *al menos una vez*,
lo que significa que un hook puede ser llamado varias veces para cualquier evento dado,
-tanto para `PostStart` como para ` PreStop`.
+tanto para `PostStart` como para `PreStop`.
Depende de la implementación del hook manejar esto correctamente.
En general, solo se realizan entregas individuales.
diff --git a/content/es/docs/concepts/workloads/pods/pod.md b/content/es/docs/concepts/workloads/pods/pod.md
index 825ffbc016..b97a9f82a6 100644
--- a/content/es/docs/concepts/workloads/pods/pod.md
+++ b/content/es/docs/concepts/workloads/pods/pod.md
@@ -129,7 +129,7 @@ Un ejemplo del ciclo de terminación de un Pod:
1. El Kubelet terminará de eliminar el Pod en el servidor API configurando el período de gracia 0 (eliminación inmediata). El Pod desaparece de la API y ya no es visible desde el cliente.
Por defecto, todas las eliminaciones se realizan correctamente en 30 segundos. El comando `kubectl delete` admite la opción` --grace-period = `que permite al usuario anular el valor predeterminado y especificar su propio valor. El valor `0` [forzar eliminación](/es/docs/concepts/workloads/pods/pod/#forzar-destrucción-de-pods) del Pod.
-Debe especificar un indicador adicional `--force` junto con` --grace-period = 0` para realizar eliminaciones forzadas.
+Debe especificar un indicador adicional `--force` junto con `--grace-period = 0` para realizar eliminaciones forzadas.
### Forzar destrucción de Pods
From 872f2eecab51771dac24d858b440da6aa991cf3a Mon Sep 17 00:00:00 2001
From: Sean Wei
Date: Thu, 14 Apr 2022 01:42:34 +0800
Subject: [PATCH 099/167] [pt-br] Fix Markdown format
---
.../pt-br/docs/concepts/cluster-administration/certificates.md | 2 +-
content/pt-br/docs/concepts/containers/images.md | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/content/pt-br/docs/concepts/cluster-administration/certificates.md b/content/pt-br/docs/concepts/cluster-administration/certificates.md
index c75051304c..660471eb3d 100644
--- a/content/pt-br/docs/concepts/cluster-administration/certificates.md
+++ b/content/pt-br/docs/concepts/cluster-administration/certificates.md
@@ -164,7 +164,7 @@ Por fim, adicione os mesmos parâmetros nos parâmetros iniciais do Servidor de
"OU": ""
}]
}
-1. Gere a chave CA (`ca-key.pem`) e o certificado (` ca.pem`):
+1. Gere a chave CA (`ca-key.pem`) e o certificado (`ca.pem`):
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
1. Crie um arquivo de configuração JSON para gerar chaves e certificados para o Servidor de API, por exemplo, `server-csr.json`. Certifique-se de substituir os valores entre colchetes angulares por valores reais que você deseja usar. O `MASTER_CLUSTER_IP` é o IP do serviço do cluster para o servidor da API, conforme descrito na subseção anterior. O exemplo abaixo também assume que você está usando `cluster.local` como DNS de domínio padrão
diff --git a/content/pt-br/docs/concepts/containers/images.md b/content/pt-br/docs/concepts/containers/images.md
index 6f8b81dd7c..605f1dd982 100644
--- a/content/pt-br/docs/concepts/containers/images.md
+++ b/content/pt-br/docs/concepts/containers/images.md
@@ -88,7 +88,7 @@ Essa abordagem é adequada se você puder controlar a configuração do nó.
{{< note >}}
O Kubernetes padrão é compatível apenas com as seções `auths` e` HttpHeaders` na configuração do Docker.
-Auxiliares de credencial do Docker (`credHelpers` ou` credsStore`) não são suportados.
+Auxiliares de credencial do Docker (`credHelpers` ou `credsStore`) não são suportados.
{{< /note >}}
Docker armazena chaves de registros privados no arquivo `$HOME/.dockercfg` ou `$HOME/.docker/config.json`. Se você colocar o mesmo arquivo na lista de caminhos de pesquisa abaixo, o kubelet o usa como provedor de credenciais ao obter imagens.
From a1741bcee9b44fd8fa2c4d1fd079a6718ec165f7 Mon Sep 17 00:00:00 2001
From: Sean Wei
Date: Thu, 14 Apr 2022 01:43:08 +0800
Subject: [PATCH 100/167] [de] Fix Markdown format
---
content/de/docs/concepts/workloads/pods/_index.md | 2 +-
content/de/docs/reference/kubectl/cheatsheet.md | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md
index 956190e6c7..eb3dcd971f 100644
--- a/content/de/docs/concepts/workloads/pods/_index.md
+++ b/content/de/docs/concepts/workloads/pods/_index.md
@@ -248,7 +248,7 @@ einige Einschränkungen:
Eintrag zur Liste `metadata.finalizers` hinzugefügt werden.
- Pod-Updates dürfen keine Felder ändern, die Ausnahmen sind
`spec.containers[*].image`,
- `spec.initContainers[*].image`,` spec.activeDeadlineSeconds` oder
+ `spec.initContainers[*].image`, `spec.activeDeadlineSeconds` oder
`spec.tolerations`. Für `spec.tolerations` kannnst du nur neue Einträge
hinzufügen.
- Für `spec.activeDeadlineSeconds` sind nur zwei Änderungen erlaubt:
diff --git a/content/de/docs/reference/kubectl/cheatsheet.md b/content/de/docs/reference/kubectl/cheatsheet.md
index bce7eeefb3..d2472b1c2a 100644
--- a/content/de/docs/reference/kubectl/cheatsheet.md
+++ b/content/de/docs/reference/kubectl/cheatsheet.md
@@ -322,7 +322,7 @@ Ausgabeformat | Beschreibung
### Kubectl Ausgabe Ausführlichkeit und Debugging
-Die Ausführlichkeit von Kubectl wird mit den Flags `-v` oder `--v ` gesteuert, gefolgt von einer Ganzzahl, die die Protokollebene darstellt. Allgemeine Protokollierungskonventionen für Kubernetes und die zugehörigen Protokollebenen werden [hier](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) beschrieben.
+Die Ausführlichkeit von Kubectl wird mit den Flags `-v` oder `--v` gesteuert, gefolgt von einer Ganzzahl, die die Protokollebene darstellt. Allgemeine Protokollierungskonventionen für Kubernetes und die zugehörigen Protokollebenen werden [hier](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) beschrieben.
Ausführlichkeit | Beschreibung
--------------| -----------
From ac9368c9bade89154365cfa668320c06f3c77469 Mon Sep 17 00:00:00 2001
From: Tim Allclair
Date: Wed, 13 Apr 2022 16:53:01 -0700
Subject: [PATCH 101/167] [de] Clean up various broken links
---
content/de/docs/concepts/cluster-administration/addons.md | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/content/de/docs/concepts/cluster-administration/addons.md b/content/de/docs/concepts/cluster-administration/addons.md
index eb07120623..60a54b9ef1 100644
--- a/content/de/docs/concepts/cluster-administration/addons.md
+++ b/content/de/docs/concepts/cluster-administration/addons.md
@@ -24,14 +24,14 @@ Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenf
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) vereint Flannel und Calico um Networking- und Network-Policies bereitzustellen.
* [Cilium](https://github.com/cilium/cilium) ist ein L3 Network- and Network-Policy-Plugin welches das transparent HTTP/API/L7-Policies durchsetzen kann. Sowohl Routing- als auch Overlay/Encapsulation-Modes werden uterstützt. Außerdem kann Cilium auf andere CNI-Plugins aufsetzen.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) ermöglicht das nahtlose Verbinden von Kubernetes mit einer Reihe an CNI-Plugins wie z.B. Calico, Canal, Flannel, Romana, oder Weave.
-* [Contiv](http://contiv.github.io) bietet konfigurierbares Networking (Native L3 auf BGP, Overlay mit vxlan, Klassisches L2, Cisco-SDN/ACI) für verschiedene Anwendungszwecke und auch umfangreiches Policy-Framework. Das Contiv-Projekt ist vollständig [Open Source](http://github.com/contiv). Der [installer](http://github.com/contiv/install) bietet sowohl kubeadm als auch nicht-kubeadm basierte Installationen.
+* [Contiv](https://contivpp.io/) bietet konfigurierbares Networking (Native L3 auf BGP, Overlay mit vxlan, Klassisches L2, Cisco-SDN/ACI) für verschiedene Anwendungszwecke und auch umfangreiches Policy-Framework. Das Contiv-Projekt ist vollständig [Open Source](http://github.com/contiv). Der [installer](http://github.com/contiv/install) bietet sowohl kubeadm als auch nicht-kubeadm basierte Installationen.
* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basierend auf [Tungsten Fabric](https://tungsten.io), ist eine Open Source, multi-Cloud Netzwerkvirtualisierungs- und Policy-Management Plattform. Contrail und Tungsten Fabric sind mit Orechstratoren wie z.B. Kubernetes, OpenShift, OpenStack und Mesos integriert und bieten Isolationsmodi für Virtuelle Maschinen, Container (bzw. Pods) und Bare Metal workloads.
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann.
* [Knitter](https://github.com/ZTE/Knitter/) ist eine Network-Lösung die Mehrfach-Network in Kubernetes ermöglicht.
* Multus ist ein Multi-Plugin für Mehrfachnetzwerk-Unterstützung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusätzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstützen.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) bietet eine Integration zwischen VMware NSX-T und einem Orchestator wie z.B. Kubernetes. Außerdem bietet es eine Integration zwischen NSX-T und Containerbasierten CaaS/PaaS-Plattformen wie z.B. Pivotal Container Service (PKS) und OpenShift.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) ist eine SDN-Plattform die Policy-Basiertes Networking zwischen Kubernetes Pods und nicht-Kubernetes Umgebungen inklusive Sichtbarkeit und Security-Monitoring bereitstellt.
-* [Romana](http://romana.io) ist eine Layer 3 Network-Lösung für Pod-Netzwerke welche auch die [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) unterstützt. Details zur Installation als kubeadm Add-On sind [hier](https://github.com/romana/romana/tree/master/containerize) verfügbar.
+* [Romana](https://github.com/romana/romana) ist eine Layer 3 Network-Lösung für Pod-Netzwerke welche auch die [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) unterstützt. Details zur Installation als kubeadm Add-On sind [hier](https://github.com/romana/romana/tree/master/containerize) verfügbar.
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) bietet Networking and Network-Policies und arbeitet auf beiden Seiten der Network-Partition ohne auf eine externe Datenbank angwiesen zu sein.
## Service-Discovery
@@ -52,5 +52,3 @@ Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenf
Es gibt einige weitere Add-Ons die in dem abgekündigten [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)-Verzeichnis dokumentiert sind.
Add-Ons die ordentlich gewartet werden dürfen gerne hier aufgezählt werden. Wir freuen uns auf PRs!
-
-
From 5da572c9158969245a0d8616e31eaa2968eb07cd Mon Sep 17 00:00:00 2001
From: Tim Allclair
Date: Wed, 13 Apr 2022 16:56:52 -0700
Subject: [PATCH 102/167] [it] Clean up various broken links
---
.../it/docs/concepts/cluster-administration/addons.md | 6 ++----
.../docs/concepts/cluster-administration/networking.md | 10 ++++------
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/content/it/docs/concepts/cluster-administration/addons.md b/content/it/docs/concepts/cluster-administration/addons.md
index 5c2568ac60..aed6cdf756 100644
--- a/content/it/docs/concepts/cluster-administration/addons.md
+++ b/content/it/docs/concepts/cluster-administration/addons.md
@@ -25,13 +25,13 @@ I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unisce Flannel e Calico, fornendo i criteri di rete e di rete.
* [Cilium](https://github.com/cilium/cilium) è un plug-in di criteri di rete e di rete L3 in grado di applicare in modo trasparente le politiche HTTP / API / L7. Sono supportate entrambe le modalità di routing e overlay / incapsulamento.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave.
-* [Contiv](http://contiv.github.io) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source](http://github.com/contiv). Il [programma di installazione](http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm.
+* [Contiv](https://contivpp.io/) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source](http://github.com/contiv). Il [programma di installazione](http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm.
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) è un provider di reti sovrapposte che può essere utilizzato con Kubernetes.
* [Knitter](https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes.
* Multus è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1/docs/kubernetes-1-installation.rst) è una piattaforma SDN che fornisce una rete basata su policy tra i pod di Kubernetes e non Kubernetes con visibilità e monitoraggio della sicurezza.
-* [Romana](http://romana.io) è una soluzione di rete Layer 3 per pod network che supporta anche [API NetworkPolicy](/docs/concepts/services-networking/network-policies/). Dettagli di installazione del componente aggiuntivo di Kubeadm disponibili [qui](https://github.com/romana/romana/tree/master/containerize).
+* [Romana](https://github.com/romana/romana) è una soluzione di rete Layer 3 per pod network che supporta anche [API NetworkPolicy](/docs/concepts/services-networking/network-policies/). Dettagli di installazione del componente aggiuntivo di Kubeadm disponibili [qui](https://github.com/romana/romana/tree/master/containerize).
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) fornisce i criteri di rete e di rete, continuerà a funzionare su entrambi i lati di una partizione di rete e non richiede un database esterno.
## Service Discovery
@@ -48,5 +48,3 @@ I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine
qui ci sono molti altri componenti aggiuntivi documentati nella directory deprecata [cluster / addons](https://git.k8s.io/kubernetes/cluster/addons).
Quelli ben mantenuti dovrebbero essere collegati qui.
-
-
diff --git a/content/it/docs/concepts/cluster-administration/networking.md b/content/it/docs/concepts/cluster-administration/networking.md
index cf895a1845..ddb129009f 100644
--- a/content/it/docs/concepts/cluster-administration/networking.md
+++ b/content/it/docs/concepts/cluster-administration/networking.md
@@ -127,7 +127,7 @@ di [avere simultaneamente accesso a diverse implementazioni](https://github.com/
del [modello di rete Kubernetes](https://git.k8s.io/website/docs/concepts/cluster-administration/networking.md#kubernetes-model) in runtime.
Ciò include qualsiasi implementazione che funziona come un [plugin CNI](https://github.com/containernetworking/cni#3rd-party-plugins),
come [Flannel](https://github.com/coreos/flannel#flanella), [Calico](http://docs.projectcalico.org/),
-[Romana](http://romana.io), [Weave-net](https://www.weave.works/products/tessere-net/).
+[Romana](https://github.com/romana/romana), [Weave-net](https://www.weave.works/products/tessere-net/).
CNI-Genie supporta anche [assegnando più indirizzi IP a un pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-indirizzi-per-pod), ciascuno da un diverso plugin CNI.
@@ -153,7 +153,7 @@ complessità della rete richiesta per implementare Kubernetes su larga scala all
226/5000
[Contiv](https://github.com/contiv/netplugin) fornisce un networking configurabile (nativo l3 usando BGP,
-overlay usando vxlan, classic l2 o Cisco-SDN / ACI) per vari casi d'uso. [Contiv](http://contiv.io) è tutto aperto.
+overlay usando vxlan, classic l2 o Cisco-SDN / ACI) per vari casi d'uso. [Contiv](https://contivpp.io/) è tutto aperto.
### Contrail / Tungsten Fabric
@@ -255,7 +255,7 @@ Lars Kellogg-Stedman.
### Multus (a Multi Network plugin)
-[Multus](https://github.com/Intel-Corp/multus-cni) è un plugin Multi CNI per supportare la funzionalità Multi
+[Multus](https://github.com/k8snetworkplumbingwg/multus-cni) è un plugin Multi CNI per supportare la funzionalità Multi
Networking in Kubernetes utilizzando oggetti di rete basati su CRD in Kubernetes.
Multus supporta tutti i [plug-in di riferimento](https://github.com/containernetworking/plugins)
@@ -316,7 +316,7 @@ Flannel, alias [canal](https://github.com/tigera/canal) o native GCE, AWS o netw
### Romana
-[Romana](http://romana.io) è una soluzione di automazione della sicurezza e della rete open source che consente di
+[Romana](https://github.com/romana/romana) è una soluzione di automazione della sicurezza e della rete open source che consente di
distribuire Kubernetes senza una rete di overlay. Romana supporta Kubernetes
[Politica di rete](/docs/concepts/services-networking/network-policies/) per fornire isolamento tra gli spazi dei nomi
di rete.
@@ -335,5 +335,3 @@ entrambi i casi, la rete fornisce un indirizzo IP per pod, come è standard per
Il progetto iniziale del modello di rete e la sua logica, e un po 'di futuro i piani sono descritti in maggior
dettaglio nella [progettazione della rete documento](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
-
-
From 0f087d5d7f752d8a8ae5123e2e0d5040486c90a2 Mon Sep 17 00:00:00 2001
From: Tim Allclair
Date: Wed, 13 Apr 2022 17:06:02 -0700
Subject: [PATCH 103/167] [ko] Clean up various broken links
---
content/ko/docs/concepts/cluster-administration/addons.md | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md
index 47dce8be0a..e1d27a1f59 100644
--- a/content/ko/docs/concepts/cluster-administration/addons.md
+++ b/content/ko/docs/concepts/cluster-administration/addons.md
@@ -21,6 +21,7 @@ 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 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다.
+* [Contiv](https://contivpp.io/)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
* [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.
@@ -29,7 +30,7 @@ content_type: concept
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
-* [Romana](https://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
+* [Romana](https://github.com/romana/romana)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
## 서비스 검색
From fbd099a209d1d1c34bb5c9b3bf65e5f3589f164e Mon Sep 17 00:00:00 2001
From: Mitesh Jain <47820816+miteshskj@users.noreply.github.com>
Date: Thu, 14 Apr 2022 06:24:46 +0530
Subject: [PATCH 104/167] Adding more information to Installing kubeadm step.
(#32884)
* Adding more information to Installing kubeadm step.
* Adding more information to installing kubeadm step.
Co-authored-by: Lubomir I. Ivanov
* Remove unnecessary quotes.
Co-authored-by: Lubomir I. Ivanov
---
.../tools/kubeadm/create-cluster-kubeadm.md | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index 1dcc375eef..6baf2e4849 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -70,9 +70,10 @@ Any commands under `kubeadm alpha` are, by definition, supported on an alpha lev
## Instructions
-### Installing kubeadm on your hosts
+### Preparing the hosts
-See ["Installing kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+Install a {{< glossary_tooltip term_id="container-runtime" text="container runtime" >}} and kubeadm on all the hosts.
+For detailed instructions and other prerequisites, see [Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
{{< note >}}
If you have already installed kubeadm, run `apt-get update &&
From 795672d92817f96a691d03d9f5812d7251b9c164 Mon Sep 17 00:00:00 2001
From: Jai Govindani
Date: Thu, 14 Apr 2022 09:24:21 +0700
Subject: [PATCH 105/167] feat(labels-annotations-taints): Add recommended
labels
---
.../labels-annotations-taints/_index.md | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/content/en/docs/reference/labels-annotations-taints/_index.md b/content/en/docs/reference/labels-annotations-taints/_index.md
index c47dd5b03f..d08c6ca90c 100644
--- a/content/en/docs/reference/labels-annotations-taints/_index.md
+++ b/content/en/docs/reference/labels-annotations-taints/_index.md
@@ -15,6 +15,76 @@ This document serves both as a reference to the values and as a coordination poi
## Labels, annotations and taints used on API objects
+### app.kubernetes.io/component
+
+Example: `app.kubernetes.io/component=database`
+
+Used on: All Objects
+
+The component within the architecture.
+
+One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
+
+### app.kubernetes.io/created-by
+
+Example: `app.kubernetes.io/created-by=controller-manager`
+
+Used on: All Objects
+
+The controller/user who created this resource.
+
+One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
+
+### app.kubernetes.io/instance
+
+Example: `app.kubernetes.io/instance=mysql-abcxzy`
+
+Used on: All Objects
+
+A unique name identifying the instance of an application.
+
+One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
+
+### app.kubernetes.io/managed-by
+
+Example: `app.kubernetes.io/managed-by=helm`
+
+Used on: All Objects
+
+The tool being used to manage the operation of an application.
+
+One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
+
+### app.kubernetes.io/name
+
+Example: `app.kubernetes.io/name=mysql`
+
+Used on: All Objects
+
+The name of the application.
+
+One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
+
+### app.kubernetes.io/part-of
+
+Example: `app.kubernetes.io/part-of=wordpress`
+
+Used on: All Objects
+
+The name of a higher level application this one is part of.
+
+One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
+
+### app.kubernetes.io/version
+
+Example: `app.kubernetes.io/version="5.7.21"`
+
+Used on: All Objects
+
+The current version of the application (e.g., a semantic version, revision hash, etc.).
+
+One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
+
### kubernetes.io/arch
Example: `kubernetes.io/arch=amd64`
From 919dd1f4a87f5a30d6fc43329d9bc7ac5c1776c6 Mon Sep 17 00:00:00 2001
From: Mengjiao Liu
Date: Thu, 14 Apr 2022 18:21:52 +0800
Subject: [PATCH 106/167] [zh]Sync debug-running-pod.md
---
.../debug-application-cluster/debug-running-pod.md | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md
index a7746156f7..ccfd8bb18b 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md
@@ -169,7 +169,7 @@ specify the `-i`/`--interactive` argument, `kubectl` will automatically attach
to the console of the Ephemeral Container.
```shell
-kubectl debug -it ephemeral-demo --image=busybox --target=ephemeral-demo
+kubectl debug -it ephemeral-demo --image=busybox:1.28 --target=ephemeral-demo
```
```
@@ -192,7 +192,7 @@ OCI runtime exec failed: exec failed: container_linux.go:346: starting container
如果你指定 `-i` 或者 `--interactive` 参数，`kubectl` 将自动挂接到临时容器的控制台。
```shell
-kubectl debug -it ephemeral-demo --image=busybox --target=ephemeral-demo
+kubectl debug -it ephemeral-demo --image=busybox:1.28 --target=ephemeral-demo
```
```
@@ -298,7 +298,7 @@ this scenario using `kubectl run`:
你可以使用 `kubectl run` 模拟这个场景:
```shell
-kubectl run myapp --image=busybox --restart=Never -- sleep 1d
+kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d
```
#### Pod 停滞在 Waiting 状态
@@ -113,7 +114,7 @@ Again, the information from `kubectl describe ...` should be informative. The m
* 确保镜像名字拼写正确
* 确保镜像已被推送到镜像仓库
-* 用手动命令 `docker pull <镜像>` 试试看镜像是否可拉取
+* 尝试手动是否能拉取镜像。例如，如果你在你的 PC 上使用 Docker，请运行 `docker pull <镜像>`。
-{{< caution >}}
-当多次使用 `--from-env-file` 来从多个数据源创建 ConfigMap 时，仅仅最后一个 env 文件有效。
-{{< /caution >}}
+从 Kubernetes 1.23 版本开始，`kubectl` 支持多次指定 `--from-env-file` 参数来从多个数据源创建 ConfigMap。
```shell
-# 将示例文件下载到 `configure-pod-container/configmap/` 目录
-wget https://k8s.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
-
-# 创建 ConfigMap
kubectl create configmap config-multi-env-files \
--from-env-file=configure-pod-container/configmap/game-env-file.properties \
--from-env-file=configure-pod-container/configmap/ui-env-file.properties
@@ -452,8 +445,11 @@ metadata:
selfLink: /api/v1/namespaces/default/configmaps/config-multi-env-files
uid: 252c4572-eb35-11e7-887b-42010a8002b8
data:
+ allowed: '"true"'
color: purple
+ enemies: aliens
how: fairlyNice
+ lives: "3"
textmode: "true"
```
From 4f70538d4f28b16530b21de308c985b8ea486ef5 Mon Sep 17 00:00:00 2001
From: Mengjiao Liu
Date: Wed, 13 Apr 2022 21:54:17 +0800
Subject: [PATCH 109/167] [zh] Fix change-runtime-containerd.md title display
error
---
.../change-runtime-containerd.md | 72 +++++++++++--------
1 file changed, 42 insertions(+), 30 deletions(-)
diff --git a/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md b/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md
index 0b281a2191..44f4a9f008 100644
--- a/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md
+++ b/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md
@@ -1,6 +1,8 @@
+---
title: 将节点上的容器运行时从 Docker Engine 改为 containerd
weight: 8
content_type: task
+---
本任务给出将容器运行时从 Docker 改为 containerd 所需的步骤。
此任务适用于运行 1.23 或更早版本 Kubernetes 的集群操作人员。
@@ -22,27 +27,32 @@ This task outlines the steps needed to update your container runtime to containe
{{% thirdparty-content %}}
安装 containerd。进一步的信息可参见
[containerd 的安装文档](https://containerd.io/docs/getting-started/)。
-关于一些特定的环境准备工作，请参阅[此页面](/zh/docs/setup/production-environment/container-runtimes/#containerd)。
+关于一些特定的环境准备工作，请遵循 [containerd 指南](/zh/docs/setup/production-environment/container-runtimes/#containerd)。
## 腾空节点 {#drain-the-node}
-```
-# 将 替换为你所要腾空的节点的名称
+```shell
kubectl drain --ignore-daemonsets
```
+将 `` 替换为你所要腾空的节点的名称
+
@@ -56,27 +66,29 @@ systemctl disable docker.service --now
## 安装 Containerd {#install-containerd}
-此[页面](/zh/docs/setup/production-environment/container-runtimes/#containerd)
-包含安装 containerd 的详细步骤。
+遵循此[指南](/zh/docs/setup/production-environment/container-runtimes/#containerd)
+了解安装 containerd 的详细步骤。
{{< tabs name="tab-cri-containerd-installation" >}}
{{% tab name="Linux" %}}
1. 从官方的 Docker 仓库安装 `containerd.io` 包。关于为你所使用的 Linux 发行版来设置
Docker 仓库，以及安装 `containerd.io` 包的详细说明，可参见
[Install Docker Engine](https://docs.docker.com/engine/install/#server)。
2. 配置 containerd：
@@ -86,19 +98,19 @@ Instructions for setting up the Docker repository for your respective Linux dist
```
3. 重启 containerd：
```shell
sudo systemctl restart containerd
```
-
{{% /tab %}}
{{% tab name="Windows (PowerShell)" %}}
启动一个 Powershell 会话，将 `$Version` 设置为期望的版本（例如：`$Version="1.4.3"`），
之后运行下面的命令：
@@ -148,7 +160,9 @@ Start a Powershell session, set `$Version` to the desired version (ex: `$Version
## 配置 kubelet 使用 containerd 作为其容器运行时
@@ -158,21 +172,19 @@ Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtim
对于使用 kubeadm 的用户，可以考虑下面的问题：
`kubeadm` 工具将每个主机的 CRI 套接字保存在该主机对应的 Node 对象的注解中。
+使用 `kubeadm` 的用户应该知道，`kubeadm` 工具将每个主机的 CRI 套接字保存在该主机对应的 Node 对象的注解中。
+要更改这一注解信息，你可以在一台包含 kubeadm `/etc/kubernetes/admin.conf` 文件的机器上执行以下命令：
-
-要更改这一注解信息，你必须执行下面的操作：
-
-在一台包含 `/etc/kubernetes/admin.conf` 文件的机器上，执行
-`kubectl edit no <节点名称>`。
+```shell
+kubectl edit no
+```
@@ -220,7 +232,7 @@ Run `kubectl get nodes -o wide` and containerd appears as the runtime for the no
{{% thirdparty-content %}}
最后，在一切顺利时删除 Docker。
From edb9f05b84400d38eaace5d103dc72c6b6eb1ac0 Mon Sep 17 00:00:00 2001
From: Tim Bannister
Date: Thu, 14 Apr 2022 17:10:39 +0100
Subject: [PATCH 110/167] Work around git directory ownership change check
Add a mitigation for the extra checks that Git added in response to
CVE-2022-24765.
---
Dockerfile | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/Dockerfile b/Dockerfile
index 9e9a6d65b0..a45fa4f0ac 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -27,16 +27,18 @@ RUN mkdir $HOME/src && \
FROM golang:1.16-alpine
RUN apk add --no-cache \
+ runuser \
git \
openssh-client \
rsync \
npm && \
npm install -D autoprefixer postcss-cli
-RUN mkdir -p /usr/local/src && \
- cd /usr/local/src && \
+RUN mkdir -p /var/hugo && \
addgroup -Sg 1000 hugo && \
- adduser -Sg hugo -u 1000 -h /src hugo
+ adduser -Sg hugo -u 1000 -h /var/hugo hugo && \
+ chown -R hugo: /var/hugo && \
+ runuser -u hugo -- git config --global --add safe.directory /src
COPY --from=0 /go/bin/hugo /usr/local/bin/hugo
From 33d6f7a6976aba83da2159dfd3f0236a4390c94f Mon Sep 17 00:00:00 2001
From: Tim Allclair
Date: Thu, 14 Apr 2022 09:47:26 -0700
Subject: [PATCH 111/167] Revert "Delete broken link (contiv.io)"
This reverts commit b0e4e7a03c140abc2b8925ac84a4f15beb732d08.
---
content/en/docs/concepts/cluster-administration/addons.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md
index 89351eb6ab..cb1323ec89 100644
--- a/content/en/docs/concepts/cluster-administration/addons.md
+++ b/content/en/docs/concepts/cluster-administration/addons.md
@@ -21,6 +21,7 @@ This page lists some of the available add-ons and links to their respective inst
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy.
* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported, and it can work on top of other CNI plugins.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
+* [Contiv](https://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes.
* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
From 2dbbadd7d7a06adf508ddb9c61a7a6c7ee9489be Mon Sep 17 00:00:00 2001
From: Tim Allclair
Date: Thu, 14 Apr 2022 09:49:19 -0700
Subject: [PATCH 112/167] Fix contiv link
---
content/en/docs/concepts/cluster-administration/addons.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md
index cb1323ec89..20626f2ff4 100644
--- a/content/en/docs/concepts/cluster-administration/addons.md
+++ b/content/en/docs/concepts/cluster-administration/addons.md
@@ -21,7 +21,7 @@ This page lists some of the available add-ons and links to their respective inst
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy.
* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported, and it can work on top of other CNI plugins.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
-* [Contiv](https://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
+* [Contiv](https://contivpp.io/) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes.
* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
From a7daeaa871a1b5ee051b729bcef28ad29c459196 Mon Sep 17 00:00:00 2001
From: Mengjiao Liu
Date: Thu, 14 Apr 2022 21:02:08 +0800
Subject: [PATCH 113/167] [zh]Sync kustomization.md
---
.../kustomization.md | 22 +++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md
index 2077281f9a..796b20b85b 100644
--- a/content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md
+++ b/content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md
@@ -133,15 +133,28 @@ metadata:
```
要从 env 文件生成 ConfigMap，请在 `configMapGenerator` 中的 `envs` 列表中添加一个条目。
+这也可以用于通过省略 `=` 和值来设置本地环境变量的值。
+
+
+建议谨慎使用本地环境变量填充功能 —— 用补丁覆盖通常更易于维护。
+当无法轻松预测变量的值时，从环境中设置值可能很有用，例如 git SHA。
+
+
下面是一个用来自 `.env` 文件的数据生成 ConfigMap 的例子：
```shell
# 创建一个 .env 文件
+# BAZ 将使用本地环境变量 $BAZ 的取值填充
cat <.env
FOO=Bar
+BAZ
EOF
cat <./kustomization.yaml
@@ -158,7 +171,7 @@ The generated ConfigMap can be examined with the following command:
可以使用以下命令检查生成的 ConfigMap：
```shell
-kubectl kustomize ./
+BAZ=Qux kubectl kustomize ./
```
与 ConfigMaps 一样，生成的 Secrets 可以通过引用 secretGenerator 的名称在部署中使用：
From e8ad3bb411f37abb8b00726664b89b0f1ae2bdfa Mon Sep 17 00:00:00 2001
From: Arhell
Date: Fri, 15 Apr 2022 09:45:02 +0300
Subject: [PATCH 114/167] [id] updated allowedTopologies values format
---
content/id/docs/concepts/storage/storage-classes.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md
index 083620d937..a3684755af 100644
--- a/content/id/docs/concepts/storage/storage-classes.md
+++ b/content/id/docs/concepts/storage/storage-classes.md
@@ -198,8 +198,8 @@ allowedTopologies:
- matchLabelExpressions:
- key: failure-domain.beta.kubernetes.io/zone
values:
- - us-central1-a
- - us-central1-b
+ - us-central-1a
+ - us-central-1b
```
## Parameter-Parameter
From 50615919a251a8c4aa3c2d1f42fd483797e0fad5 Mon Sep 17 00:00:00 2001
From: ydFu
Date: Fri, 15 Apr 2022 14:40:35 +0800
Subject: [PATCH 115/167] [zh] Sync cluster-administration pages for addons.md
* Sync with english version in 'Fix Contiv addon link.' (#32938)
Signed-off-by: ydFu
---
content/zh/docs/concepts/cluster-administration/addons.md | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/content/zh/docs/concepts/cluster-administration/addons.md b/content/zh/docs/concepts/cluster-administration/addons.md
index d12aa56282..dc8303f872 100644
--- a/content/zh/docs/concepts/cluster-administration/addons.md
+++ b/content/zh/docs/concepts/cluster-administration/addons.md
@@ -31,6 +31,7 @@ Add-ons 扩展了 Kubernetes 的功能。
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy.
* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
+* [Contiv](https://contivpp.io/) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes.
* [Knitter](https://github.com/ZTE/Knitter/) is a network solution supporting multiple networking in Kubernetes.
@@ -54,6 +55,10 @@ Add-ons 扩展了 Kubernetes 的功能。
同时支持路由（routing）和覆盖/封装（overlay/encapsulation）模式。
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件，
例如：Flannel、Calico、Canal、Romana 或者 Weave。
+* [Contiv](https://contivpp.io/) 为各种用例和丰富的策略框架提供可配置的网络
+ （使用 BGP 的本机 L3、使用 vxlan 的覆盖、标准 L2 和 Cisco-SDN/ACI）。
+ Contiv 项目完全[开源](https://github.com/contiv)。
+ [安装程序](https://github.com/contiv/install) 提供了基于 kubeadm 和非 kubeadm 的安装选项。
* 基于 [Tungsten Fabric](https://tungsten.io) 的
[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)
是一个开源的多云网络虚拟化和策略管理平台，Contrail 和 Tungsten Fabric 与业务流程系统
From 3e54683ac7da5cd86817bfa49426edfe73060af2 Mon Sep 17 00:00:00 2001
From: zaunist
Date: Tue, 12 Apr 2022 03:45:59 +0800
Subject: [PATCH 116/167] docs: rsync kubelet-in-userns
---
.../administer-cluster/kubelet-in-userns.md | 56 +++++++++++++++++--
1 file changed, 51 insertions(+), 5 deletions(-)
diff --git a/content/zh/docs/tasks/administer-cluster/kubelet-in-userns.md b/content/zh/docs/tasks/administer-cluster/kubelet-in-userns.md
index dea35a94e1..33c23ba810 100644
--- a/content/zh/docs/tasks/administer-cluster/kubelet-in-userns.md
+++ b/content/zh/docs/tasks/administer-cluster/kubelet-in-userns.md
@@ -35,7 +35,7 @@ If you are just looking for how to run a pod as a non-root user, see [SecurityCo
这种技术也叫做 _rootless 模式（Rootless mode）_。
{{< note >}}
-这个文档描述了怎么以非 root 用户身份运行 Kubernetes 节点组件以及 Pod。
+这个文档描述了怎么以非 root 用户身份运行 Kubernetes 节点组件以及 Pod。
如果你只是想了解如何以非 root 身份运行 Pod，请参阅 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/)。
{{< /note >}}
@@ -99,6 +99,51 @@ Rootless Podman is not supported.
+
+
+## 在非特权容器内运行 Kubernetes
+
+{{% thirdparty-content %}}
+
+### sysbox
+
+
+
+[Sysbox](https://github.com/nestybox/sysbox) 是一个开源容器运行时
+(类似于 “runc”），支持在 Linux 用户命名空间隔离的非特权容器内运行系统级工作负载，
+比如 Docker 和 Kubernetes。
+
+
+
+查看 [Sysbox 快速入门指南: Kubernetes-in-Docker](https://github.com/nestybox/sysbox/blob/master/docs/quickstart/kind.md)
+了解更多细节。
+
+
+
+Sysbox 支持在非特权容器内运行 Kubernetes，
+而不需要 Cgroup v2 和 “KubeletInUserNamespace” 特性门控。
+Sysbox 通过在容器内暴露特定的 `/proc` 和 `/sys` 文件系统，
+以及其它一些先进的操作系统虚拟化技术来实现。
+
### 配置 kubelet
@@ -478,7 +523,8 @@ cgroupDriver: "cgroupfs"
`KubeletInUserNamespace` 特性门控从 Kubernetes v1.22 被引入， 标记为 "alpha" 状态。
-通过挂载特制的 proc 文件系统，也可以在不使用这个特性门控的情况下在用户命名空间运行 kubelet，但这不受官方支持。
+通过挂载特制的 proc 文件系统 （比如 [Sysbox](https://github.com/nestybox/sysbox)），
+也可以在不使用这个特性门控的情况下在用户命名空间运行 kubelet，但这不受官方支持。
+
+
+**作者**： Mickey Boxell (Oracle)
+
+随着 Kubernetes 的发展，特性和 API 会定期被重新访问和删除。
+新特性可能会提供替代或改进的方法，来解决现有的问题，从而激励团队移除旧的方法。
+
+
+我们希望确保你了解 Kubernetes 1.24 版本的变化。 该版本将 **弃用** 一些（测试版/beta）API，
+转而支持相同 API 的稳定版本。 Kubernetes 1.24 版本的主要变化是
+[移除 Dockershim](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim)。
+这将在下面讨论，并将在发布时更深入地探讨。
+要提前了解 Kubernetes 1.24 中的更改，请查看正在更新中的
+[CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md)。
+
+
+## 关于 Dockershim {#a-note-about-dockershim}
+
+可以肯定地说，随着 Kubernetes 1.24 的发布，最受关注的删除是 Dockershim。
+Dockershim 在 1.20 版本中已被弃用。 如
+[Kubernetes 1.20 变更日志](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)中所述：
+"Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet
+uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance
+issues in the Kubernetes community."
+随着即将发布的 Kubernetes 1.24，Dockershim 将最终被删除。
+
+
+在文章[别慌: Kubernetes 和 Docker](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/) 中，
+作者简洁地记述了变化的影响，并鼓励用户保持冷静：
+>弃用 Docker 这个底层运行时，转而支持符合为 Kubernetes 创建的容器运行接口
+>Container Runtime Interface (CRI) 的运行时。
+>Docker 构建的镜像，将在你的集群的所有运行时中继续工作，一如既往。
+
+
+已经有一些文档指南，提供了关于从 dockershim 迁移到与 Kubernetes 直接兼容的容器运行时的有用信息。
+你可以在 Kubernetes 文档中的[从 dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)
+页面上找到它们。
+
+
+有关 Kubernetes 为何不再使用 dockershim 的更多信息，
+请参见：[Kubernetes 正在离开 Dockershim](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)
+和[最新的弃用 Dockershim 的常见问题](/zh/blog/2022/02/17/dockershim-faq/)。
+
+查看[你的集群准备好使用 v1.24 了吗？](/blog/2022/03/31/ready-for-dockershim-removal/) 一文，
+了解如何确保你的集群在从 1.23 版本升级到 1.24 版本后继续工作。
+
+
+## Kubernetes API 删除和弃用流程 {#the-Kubernetes-api-removal-and-deprecation-process}
+
+Kubernetes 包含大量随时间演变的组件。在某些情况下，这种演变会导致 API、标志或整个特性被删除。
+为了防止用户面对重大变化，Kubernetes 贡献者采用了一项特性[弃用策略](/zh/docs/reference/using-api/deprecation-policy/)。
+此策略确保仅当同一 API 的较新稳定版本可用并且
+API 具有以下稳定性级别所指示的最短生命周期时，才可能弃用稳定版本 API：
+
+* 正式发布 (GA) 或稳定的 API 版本可能被标记为已弃用，但不得在 Kubernetes 的主版本中删除。
+* 测试版（beta）或预发布 API 版本在弃用后必须支持 3 个版本。
+* Alpha 或实验性 API 版本可能会在任何版本中被删除，恕不另行通知。
+
+
+删除遵循相同的弃用政策，无论 API 是由于 测试版（beta）功能逐渐稳定还是因为该
+API 未被证明是成功的而被删除。
+Kubernetes 将继续确保在删除 API 时提供用来迁移的文档。
+
+
+**弃用的** API 是指那些已标记为在未来 Kubernetes 版本中被删除的 API。
+**删除的** API 是指那些在被弃用后不再可用于当前受支持的 Kubernetes 版本的 API。
+这些删除已被更新的、稳定的/普遍可用的 (GA) API 所取代。
+
+
+## Kubernetes 1.24 的 API 删除、弃用和其他更改 {#api-removals-deprecations-and-other-changes-for-kubernetes-1.24}
+
+* [动态 kubelet 配置](https://github.com/kubernetes/enhancements/issues/281): `DynamicKubeletConfig`
+ 用于启用 kubelet 的动态配置。Kubernetes 1.22 中弃用 `DynamicKubeletConfig` 标志。
+ 在 1.24 版本中，此特性门控将从 kubelet 中移除。请参阅[重新配置 kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/)。
+ 更多详细信息，请参阅[“删除动态 kubelet 配置” 的 KEP](https://github.com/kubernetes/enhancements/issues/281)。
+
+* [动态日志清洗](https://github.com/kubernetes/kubernetes/pull/107207)：实验性的动态日志清洗功能已被弃用，
+ 将在 1.24 版本中被删除。该功能引入了一个日志过滤器，可以应用于所有 Kubernetes 系统组件的日志，
+ 以防止各种类型的敏感信息通过日志泄漏。有关更多信息和替代方法，请参阅
+ [KEP-1753: Kubernetes 系统组件日志清洗](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#deprecation)。
+
+* 树内驱动（In-tree provisioner）向 CSI 卷迁移：这适用于许多树内插件，
+ 包括 [Portworx](https://github.com/kubernetes/enhancements/issues/2589)。
+ 参见[树内存储插件向 CSI 卷迁移的设计文档](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/csi-migration.md#background-and-motivations)
+ 了解更多信息。
+
+* [从 kubelet 中移除 Dockershim](https://github.com/kubernetes/enhancements/issues/2221)：Docker
+ 的容器运行时接口(CRI)（即 Dockershim）目前是 kubelet 代码中内置的容器运行时。 它在 1.20 版本中已被弃用。
+ 从 1.24 版本开始，kubelet 已经移除 dockershim。 查看这篇博客，
+ [了解你需要为 1.24 版本做些什么](/blog/2022/03/31/ready-for-dockershim-removal/)。
+
+* [pod 调度的存储容量追踪](https://github.com/kubernetes/enhancements/issues/1472)：CSIStorageCapacity API
+ 支持通过 CSIStorageCapacity 对象暴露当前可用的存储容量，并增强了使用带有延迟绑定的 CSI 卷的 Pod 的调度。
+ CSIStorageCapacity API 自 1.24 版本起提供稳定版本。升级到稳定版的 API 将弃用 v1beta1 CSIStorageCapacity API。
+ 更多信息请参见 [Pod 调度存储容量约束 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking)。
+
+* [kubeadm 控制面节点上不再存在 `master` 标签](https://github.com/kubernetes/kubernetes/pull/107533)。
+ 对于新集群，控制平面节点将不再添加 'node-role.kubernetes.io/master' 标签，
+ 只会添加 'node-role.kubernetes.io/control-plane' 标签。更多信息请参考
+ [KEP-2067：重命名 kubeadm “master” 标签和污点](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067)。
+
+* [VolumeSnapshot v1beta1 CRD 在 1.24 版本中将被移除](https://github.com/kubernetes/enhancements/issues/177)。
+ Kubernetes 和 [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI)
+ 的卷快照和恢复功能，在 1.20 版本中进入测试版。该功能提供标准化 API 设计 (CRD ) 并为 CSI 卷驱动程序添加了 PV 快照/恢复支持，
+ VolumeSnapshot v1beta1 在 1.21 版本中已被弃用，现在不受支持。更多信息请参考
+ [KEP-177：CSI 快照](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot)和
+ [kubernetes-csi/external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter/releases/tag/v4.1.0)。
+
+## 需要做什么 {#what-to-do}
+
+### 删除 Dockershim {#dockershim-removal}
+如前所述，有一些关于从 [dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)的指南。
+你可以[从查明节点上所使用的容器运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)开始。
+如果你的节点使用 dockershim，则还有其他可能的 Docker Engine 依赖项，
+例如 Pod 或执行 Docker 命令的第三方工具或 Docker 配置文件中的私有注册表。
+你可以按照[检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
+的指南来查看可能的 Docker 引擎依赖项。在升级到 1.24 版本之前， 你决定要么继续使用 Docker Engine 并
+[将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)，
+要么迁移到与 CRI 兼容的运行时。这是[将节点上的容器运行时从 Docker Engine 更改为 containerd](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/) 的指南。
+
+
+### `kubectl convert` {#kubectl-convert}
+
+kubectl 的 [`kubectl convert`](/zh/docs/tasks/tools/included/kubectl-convert-overview/)
+插件有助于解决弃用 API 的迁移问题。该插件方便了不同 API 版本之间清单的转换，
+例如，从弃用的 API 版本到非弃用的 API 版本。关于 API 迁移过程的更多信息可以在
+[已弃用 API 的迁移指南](/docs/reference/using-api/deprecation-guide/)中找到。按照
+[安装 `kubectl convert` 插件](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-convert-plugin)
+文档下载并安装 `kubectl-convert` 二进制文件。
+
+
+### 展望未来 {#looking-ahead}
+
+计划在今年晚些时候发布的 Kubernetes 1.25 和 1.26 版本，将停止提供一些
+Kubernetes API 的 beta 版本，这些 API 当前为稳定版。1.25 版本还将删除 PodSecurityPolicy，
+它已在 Kubernetes 1.21 版本中被弃用，并且不会升级到稳定版。有关详细信息，请参阅
+[PodSecurityPolicy 弃用：过去、现在和未来](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。
+
+
+[Kubernetes 1.25 计划移除的 API 的官方列表](/zh/docs/reference/using-api/deprecation-guide/#v1-25)是：
+
+* The beta CronJob API (batch/v1beta1)
+* The beta EndpointSlice API (discovery.k8s.io/v1beta1)
+* The beta Event API (events.k8s.io/v1beta1)
+* The beta HorizontalPodAutoscaler API (autoscaling/v2beta1)
+* The beta PodDisruptionBudget API (policy/v1beta1)
+* The beta PodSecurityPolicy API (policy/v1beta1)
+* The beta RuntimeClass API (node.k8s.io/v1beta1)
+
+
+[Kubernetes 1.25 计划移除的 API 的官方列表](/zh/docs/reference/using-api/deprecation-guide/#v1-25)是：
+
+* The beta FlowSchema 和 PriorityLevelConfiguration API (flowcontrol.apiserver.k8s.io/v1beta1)
+* The beta HorizontalPodAutoscaler API (autoscaling/v2beta2)
+
+
+### 了解更多 {#want-to-know-more}
+Kubernetes 发行说明中宣告了弃用信息。你可以在以下版本的发行说明中看到待弃用的公告：
+* [Kubernetes 1.21](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md#deprecation)
+* [Kubernetes 1.22](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md#deprecation)
+* [Kubernetes 1.23](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#deprecation)
+* 我们将正式宣布 [Kubernetes 1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#deprecation) 的弃用信息，
+ 作为该版本 CHANGELOG 的一部分。
+
+有关弃用和删除过程的信息，请查看 Kubernetes 官方[弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) 文档。
+
From f8b15c9beaacfd8bc29ca75961159f0dcfde83c5 Mon Sep 17 00:00:00 2001
From: Sean Wei
Date: Fri, 15 Apr 2022 16:47:31 +0800
Subject: [PATCH 118/167] [zh] Fix Markdown format
---
content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md | 2 +-
content/zh/docs/reference/access-authn-authz/rbac.md | 2 +-
.../configure-liveness-readiness-startup-probes.md | 2 +-
.../run-application/run-replicated-stateful-application.md | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
index b97cdc4159..9cac596ae7 100644
--- a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -310,7 +310,7 @@ For example, consider the following Pod spec:
例如，考虑下面的 Pod 规约：
-{{}}
+{{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}}
## API 对象 {#api-overview}
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
index f0c149f13f..f59c530d0a 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
@@ -358,7 +358,7 @@ kubelet 可以配置为使用该协议来执行应用活跃性检查。
下面是一个示例清单：
-{{< codenew file="pods/probe/grpc-liveness.yaml">}}
+{{< codenew file="pods/probe/grpc-liveness.yaml" >}}
-在 `READY` 列中查找 ` 1/2` ：
+在 `READY` 列中查找 `1/2`：
```
NAME READY STATUS RESTARTS AGE
From bcef1ba452aef3e10137d51e2d77f7a5e4f0837e Mon Sep 17 00:00:00 2001
From: Sean Wei
Date: Fri, 15 Apr 2022 20:47:49 +0800
Subject: [PATCH 119/167] Rename non-ASCII filename
---
...d => 2020-09-16-gsoc20-building-operators-for-cluster-addons.md} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename content/en/blog/_posts/{2020-09-16-gsoc‘20 -building-operators-for-cluster-addons.md => 2020-09-16-gsoc20-building-operators-for-cluster-addons.md} (100%)
diff --git a/content/en/blog/_posts/2020-09-16-gsoc‘20 -building-operators-for-cluster-addons.md b/content/en/blog/_posts/2020-09-16-gsoc20-building-operators-for-cluster-addons.md
similarity index 100%
rename from content/en/blog/_posts/2020-09-16-gsoc‘20 -building-operators-for-cluster-addons.md
rename to content/en/blog/_posts/2020-09-16-gsoc20-building-operators-for-cluster-addons.md
From 73ecc2aacf3ced4c42e0dfde41d2490ced58e105 Mon Sep 17 00:00:00 2001
From: Sean Wei
Date: Fri, 15 Apr 2022 20:58:06 +0800
Subject: [PATCH 120/167] Remove space in filename
---
.../_posts/2020-05-21-wsl2-dockerdesktop-k8s.md | 2 +-
...rack.png => wsl2-minikube-install-conntrack.png} | Bin
2 files changed, 1 insertion(+), 1 deletion(-)
rename static/images/blog/2020-05-21-wsl2-dockerdesktop-k8s/{wsl2-minikube-install conntrack.png => wsl2-minikube-install-conntrack.png} (100%)
diff --git a/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md b/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md
index 0a84075aaf..cfc0cc53fc 100644
--- a/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md
+++ b/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md
@@ -360,7 +360,7 @@ So let's fix the issue by installing the missing package:
sudo apt install -y conntrack
```
-
+
Let's try to launch it again:
diff --git a/static/images/blog/2020-05-21-wsl2-dockerdesktop-k8s/wsl2-minikube-install conntrack.png b/static/images/blog/2020-05-21-wsl2-dockerdesktop-k8s/wsl2-minikube-install-conntrack.png
similarity index 100%
rename from static/images/blog/2020-05-21-wsl2-dockerdesktop-k8s/wsl2-minikube-install conntrack.png
rename to static/images/blog/2020-05-21-wsl2-dockerdesktop-k8s/wsl2-minikube-install-conntrack.png
From d82f6d402fdc690f7e2bfaaee3ef795c51c15373 Mon Sep 17 00:00:00 2001
From: Mengjiao Liu
Date: Fri, 15 Apr 2022 19:55:31 +0800
Subject: [PATCH 121/167] [zh]Sync pull-image-private-registry.md
---
.../pull-image-private-registry.md | 100 ++++++++++++++++--
1 file changed, 89 insertions(+), 11 deletions(-)
diff --git a/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md
index c29009533f..662ceef506 100644
--- a/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md
+++ b/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md
@@ -14,11 +14,14 @@ weight: 100
本文介绍如何使用 {{< glossary_tooltip text="Secret" term_id="secret" >}}
从私有的镜像仓库或代码仓库拉取镜像来创建 Pod。
+有很多私有镜像仓库正在使用中。这个任务使用的镜像仓库是
+[Docker Hub](https://www.docker.com/products/docker-hub)
{{% thirdparty-content single="true" %}}
@@ -29,10 +32,13 @@ private container image registry or repository.
-要进行此练习，你需要 `docker` 命令行工具和一个知道密码的
+* 要进行此练习，你需要 `docker` 命令行工具和一个知道密码的
[Docker ID](https://docs.docker.com/docker-id/)。
+* 如果你要使用不同的私有的镜像仓库，你需要有对应镜像仓库的命令行工具和登录信息。
@@ -41,7 +47,7 @@ private container image registry or repository.
On your laptop, you must authenticate with a registry in order to pull a private image:
-->
-## 登录 Docker 镜像仓库
+## 登录 Docker 镜像仓库 {#log-in-to-docker}
在个人电脑上，要想拉取私有镜像必须在镜像仓库上进行身份验证。
@@ -92,15 +98,77 @@ If you use a Docker credentials store, you won't see that `auth` entry but a `cr
{{< /note >}}
+## 创建一个基于现有凭证的 Secret {#registry-secret-existing-credentials}
+
+Kubernetes 集群使用 `kubernetes.io/dockerconfigjson` 类型的
+Secret 来通过镜像仓库的身份验证，进而提取私有镜像。
+
+如果你已经运行了 `docker login` 命令，你可以复制该镜像仓库的凭证到 Kubernetes:
+
+```shell
+kubectl create secret generic regcred \
+ --from-file=.dockerconfigjson= \
+ --type=kubernetes.io/dockerconfigjson
+```
+
+
+如果你需要更多的设置（例如，为新 Secret 设置名字空间或标签），
+则可以在存储 Secret 之前对它进行自定义。
+请务必：
+
+- 将 data 项中的名称设置为 `.dockerconfigjson`
+- 使用 base64 编码方法对 Docker 配置文件进行编码，然后粘贴该字符串的内容，作为字段
+ `data[".dockerconfigjson"]` 的值
+- 将 `type` 设置为 `kubernetes.io/dockerconfigjson`
+
+示例：
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: myregistrykey
+ namespace: awesomeapps
+data:
+ .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
+type: kubernetes.io/dockerconfigjson
+```
+
+
+如果你收到错误消息：`error: no objects passed to create`，
+这可能意味着 base64 编码的字符串是无效的。 如果你收到类似
+`Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`
+的错误消息，则表示数据中的 base64 编码字符串已成功解码，但无法解析为 `.docker/config.json` 文件。
+
+
-## 在集群中创建保存授权令牌的 Secret
-
-Kubernetes 集群使用 `docker-registry` 类型的 Secret 来通过容器仓库的身份验证，进而提取私有映像。
+## 在命令行上提供凭证来创建 Secret {#create-a-secret-by-providing-credentials-on-the-command-line}
创建 Secret，命名为 `regcred`：
@@ -136,12 +204,22 @@ You have successfully set your Docker credentials in the cluster as a Secret cal
这样你就成功地将集群中的 Docker 凭证设置为名为 `regcred` 的 Secret。
+
+{{< note >}}
+在命令行上键入 Secret 可能会将它们存储在你的 shell 历史记录中而不受保护，
+并且这些 Secret 信息也可能在 `kubectl` 运行期间对你 PC 上的其他用户可见。
+{{< /note >}}
+
-## 检查 Secret `regcred`
+## 检查 Secret `regcred` {#inspecting-the-secret-regcred}
要了解你创建的 `regcred` Secret 的内容，可以用 YAML 格式进行查看：
@@ -217,7 +295,7 @@ You have successfully set your Docker credentials as a Secret called `regcred` i
Here is a manifest for an example Pod that needs access to your Docker credentials in `regcred`:
-->
-## 创建一个使用你的 Secret 的 Pod
+## 创建一个使用你的 Secret 的 Pod {#create-a-pod-that-uses-your-secret}
下面是一个 Pod 配置清单示例，该示例中 Pod 需要访问你的 Docker 凭证 `regcred`：
From a9b44a09c64a4aec5bb11b00a25b3ac65d91fb91 Mon Sep 17 00:00:00 2001
From: Arhell
Date: Sat, 16 Apr 2022 00:34:27 +0300
Subject: [PATCH 122/167] [id] fix a nit in the feature-state short code
---
content/id/docs/concepts/workloads/controllers/daemonset.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/id/docs/concepts/workloads/controllers/daemonset.md b/content/id/docs/concepts/workloads/controllers/daemonset.md
index 905a0a193a..c1921a50a1 100644
--- a/content/id/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/id/docs/concepts/workloads/controllers/daemonset.md
@@ -106,7 +106,7 @@ membuat Pod pada semua Node.
### Dijadwalkan oleh _default scheduler_
-{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
+{{< feature-state for_kubernetes_version="1.17" state="stable" >}}
DaemonSet memastikan bahwa semua Node yang memenuhi syarat menjalankan salinan
Pod. Normalnya, Node yang menjalankan Pod dipilih oleh _scheduler_ Kubernetes.
From c808dd1e9e2349e829455a4f485c7ae5d3f6ce90 Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Sat, 16 Apr 2022 15:04:32 +0800
Subject: [PATCH 123/167] [zh] Update runtime-class.md
Signed-off-by: xin.li
---
content/zh/docs/concepts/containers/runtime-class.md | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/content/zh/docs/concepts/containers/runtime-class.md b/content/zh/docs/concepts/containers/runtime-class.md
index a56c163090..63e14b435c 100644
--- a/content/zh/docs/concepts/containers/runtime-class.md
+++ b/content/zh/docs/concepts/containers/runtime-class.md
@@ -213,11 +213,10 @@ handler 需要配置在 runtimes 块中：
```
-更详细信息，请查阅 containerd 配置文档：
-https://github.com/containerd/cri/blob/master/docs/config.md
+更详细信息，请查阅 containerd
+[CRI 插件配置指南](https://github.com/containerd/cri/blob/master/docs/config.md)
#### [cri-o](https://cri-o.io/)
From 2ec3334f6aeb1a10058b8c689623d056e1014e8a Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Sat, 16 Apr 2022 15:10:02 +0800
Subject: [PATCH 124/167] [zh] Update dns-pod-service.md
Signed-off-by: xin.li
---
.../services-networking/dns-pod-service.md | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/content/zh/docs/concepts/services-networking/dns-pod-service.md b/content/zh/docs/concepts/services-networking/dns-pod-service.md
index 82782dfc0b..2b9dfeb36f 100644
--- a/content/zh/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/zh/docs/concepts/services-networking/dns-pod-service.md
@@ -565,21 +565,6 @@ a list of search domains of up to 2048 characters.
如果启用 kube-apiserver 和 kubelet 的特性门控 `ExpandedDNSConfig`，Kubernetes 将可以有最多 32 个
搜索域以及一个最多 2048 个字符的搜索域列表。
-
-### 功能的可用性
-
-Pod DNS 配置和 DNS 策略 "`None`" 的可用版本对应如下所示。
-
-| k8s 版本 | 特性支持 |
-| :---------: |:-----------:|
-| 1.14 | 稳定 |
-| 1.10 | Beta（默认启用） |
-| 1.9 | Alpha |
-
## {{% heading "whatsnext" %}}
+
+
+**作者和采访者：** [Anubhav Vardhan](https://github.com/anubha-v-ardhan) ， [Atharva Shinde](https://github.com/Atharva-Shinde) ， [Avinesh Tripathi](https://github.com/AvineshTripathi) ， [Debabrata Panigrahi](https://github.com/Debanitrkl) ， [Kunal Verma](https://github.com/verma-kunal) ， [Pranshu Srivastava](https://github.com/PranshuSrivastava) ， [Pritish Samal](https://github.com/CIPHERTron) ， [Purneswar Prasad](https://github.com/PurneswarPrasad) ， [Vedant Kakde](https://github.com/vedant-kakde)
+
+
+**编辑：** [Priyanka Saggu](https://psaggu.com)
+
+---
+
+
+大家好 👋
+
+
+欢迎来到亚太地区的“认识我们的贡献者”博文系列第一期。
+
+
+
+在这篇文章中，我们将向您介绍来自印度地区的五位优秀贡献者，他们一直在以各种方式积极地为上游 Kubernetes 项目做贡献，同时也是众多社区倡议的领导者和维护者。
+
+
+💫 *闲话少说，我们开始吧。*
+
+
+## [Arsh Sharma](https://github.com/RinkiyaKeDad)
+
+
+Arsh 目前在 Okteto 公司中担任开发者体验工程师职务。作为一名新的贡献者，他意识到一对一的指导机会让他在开始上游项目中受益匪浅。
+
+
+他目前是 Kubernetes 1.23 版本团队的 CI Signal 经理。他还致力于为 SIG Testing 和 SIG Docs 项目提供贡献，并且在 SIG Architecture 项目中负责 [证书管理器](https://github.com/cert-manager/infrastructure) 工具的开发工作。
+
+
+对于新人来说，Arsh 帮助他们可持续地计划早期贡献。
+
+
+> _我鼓励大家以可持续的方式为社区做贡献。我的意思是，一个人很容易在早期的时候非常有热情，并且承担了很多超出个人实际能力的事情。这通常会导致后期的倦怠。迭代地处理事情会让大家对社区的贡献变得可持续。_
+
+## [Kunal Kushwaha](https://github.com/kunal-kushwaha)
+
+
+Kunal Kushwaha 是 Kubernetes 营销委员会的核心成员。他同时也是 [CNCF 学生计划](https://community.cncf.io/cloud-native-students/) 的创始人之一。他还在 1.22 版本周期中担任通信经理一职。
+
+
+在他的第一年结束时，Kunal 开始为 [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) 项目做贡献。然后，他被推选从事同一项目，此项目是 Google Summer of Code 的一部分。Kunal 在 Google Summer of Code、Google Code-in 等项目中指导过很多人。
+
+
+作为一名开源爱好者，他坚信，社区的多元化参与是非常有益的，因为他引入了新的观念和观点，并尊重自己的伙伴。它曾参与过各种开源项目，他在这些社区中的参与对他作为开发者的发展有很大帮助。
+
+
+
+> _我相信，如果你发现自己在一个了解不多的项目当中，那是件好事，因为现在你可以一边贡献一边学习，社区也会帮助你。它帮助我获得了很多技能，认识了来自世界各地的人，也帮助了他们。你可以在这个过程中学习，自己不一定必须是专家。请重视非代码贡献，因为作为初学者这是一项技能，你可以为组织带来新的视角。_
+
+## [Madhav Jivarajani](https://github.com/MadhavJivrajani)
+
+
+
+Madhav Jivarajani 在 VMware 上游 Kubernetes 稳定性团队工作。他于 2021 年 1 月开始为 Kubernetes 项目做贡献，此后在 SIG Architecture、SIG API Machinery 和 SIG ContribEx（贡献者经验）等项目的几个工作领域做出了重大贡献。
+
+
+在这几个重要项目中，他最近致力于 [设计方案](https://github.com/kubernetes/community/issues/6055) 的存档工作，重构 k8s-infra 存储库下的 ["组"代码库](https://github.com/kubernetes/k8s.io/pull/2713) ，使其具有可模拟性和可测试性，以及改进 [GitHub k8s 机器人](https://github.com/kubernetes/test-infra/issues/23129) 的功能。
+
+
+除了在技术方面的贡献，Madhav 还监督许多旨在帮助新贡献者的项目。他每两周组织一次的“KEP 阅读俱乐部”会议，帮助新人了解添加新功能、摒弃旧功能以及对上游项目进行其他关键更改的过程。他还致力于开发 [Katacoda 场景](https://github.com/kubernetes-sigs/contributor-katacoda) ，以帮助新的贡献者在为 k/k 做贡献的过程更加熟练。目前除了每周与社区成员会面外，他还组织了几个 [新贡献者讲习班（NCW）](https://www.youtube.com/watch?v=FgsXbHBRYIc) 。
+
+
+> _一开始我对 Kubernetes 了解并不多。我加入社区是因为社区超级友好。但让我留下来的不仅仅是人，还有项目本身。我在社区中不会感到不知所措，这是因为我能够在感兴趣的和正在讨论的主题中获得尽可能多的背景和知识。因此，我将继续深入探讨 Kubernetes 及其设计。我是一个系统迷，kubernetes 对我来说绝对是一个金矿。_
+
+
+## [Rajas Kakodkar](https://github.com/rajaskakodkar)
+
+
+Rajas Kakodkar 目前在 VMware 担任技术人员。自 2019 年以来，他一直多方面地从事上游 kubernetes 项目。
+
+
+他现在是 Testing 特别兴趣小组的关键贡献者。他还活跃在 SIG Network 社区。最近，Rajas 为 [NetworkPolicy++](https://docs.google.com/document/d/1AtWQy2fNa4qXRag9cCp5_HsefD7bxKe3ea2RPn8jnSs/) 和 [`kpng`](https://github.com/kubernetes-sigs/kpng) 子项目做出了重大贡献。
+
+
+他遇到的第一个挑战是，他所处的时区与上游项目的日常会议时间不同。不过，社区论坛上的异步交互逐渐解决了这个问题。
+
+
+> _我喜欢为 kubernetes 做出贡献，不仅因为我可以从事尖端技术工作，更重要的是，我可以和优秀的人一起工作，并帮助解决现实问题。_
+
+## [Rajula Vineet Reddy](https://github.com/rajula96reddy)
+
+
+Rajula Vineet Reddy，CERN 的初级工程师，是 SIG ContribEx 项目下营销委员会的成员。在 Kubernetes 1.22 和 1.23 版本周期中，他还担任 SIG Release 的版本经理。
+
+
+在他的一位教授的帮助下，他开始将 kubernetes 项目作为大学项目的一部分。慢慢地，他花费了大量的时间阅读项目的文档、Slack 讨论、GitHub issues 和博客，这有助于他更好地掌握 kubernetes 项目，并激发了他对上游项目做贡献的兴趣。他的主要贡献之一是他在SIG ContribEx上游营销子项目中协助实现了自动化。
+
+
+Rajas 说，参与项目会议和跟踪各种项目角色对于了解社区至关重要。
+
+
+> _我发现社区非常有帮助，而且总是“你得到的回报和你贡献的一样多”。你参与得越多，你就越会了解、学习和贡献新东西。_
+> _“挺身而出”的第一步是艰难的。但在那之后一切都会顺利的。勇敢地参与进来吧。_
+---
+
+
+如果您对我们下一步应该采访谁有任何意见/建议，请在 #sig-contribex 中告知我们。我们很高兴有其他人帮助我们接触社区中更优秀的人。我们将不胜感激。
+
+
+
+我们下期见。最后，祝大家都能快乐地为社区做贡献！👋
+
From 6b5c8a329124c2d8a6c784817ddf1817560de672 Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Sat, 16 Apr 2022 15:15:45 +0800
Subject: [PATCH 126/167] [zh] Update pod-topology-spread-constraints.md
Signed-off-by: xin.li
---
.../workloads/pods/pod-topology-spread-constraints.md | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 42f6677e25..ab91304c04 100644
--- a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -498,7 +498,8 @@ apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- - pluginConfig:
+ - schedulerName: default-scheduler
+ pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints:
@@ -589,7 +590,8 @@ apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- - pluginConfig:
+ - schedulerName: default-scheduler
+ pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints: []
From 2c95aad902d1a8c1b22acac64f95e20af8c031ba Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Sat, 16 Apr 2022 15:20:17 +0800
Subject: [PATCH 127/167] [zh]Update contribute-upstream.md
Signed-off-by: xin.li
---
.../contribute/generate-ref-docs/contribute-upstream.md | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md b/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md
index d16879d7e7..4bf2591aba 100644
--- a/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md
+++ b/content/zh/docs/contribute/generate-ref-docs/contribute-upstream.md
@@ -40,6 +40,8 @@ You need to have these tools installed:
- [Golang](https://golang.org/doc/install) version 1.13+
- [Docker](https://docs.docker.com/engine/installation/)
- [etcd](https://github.com/coreos/etcd/)
+ - [make](https://www.gnu.org/software/make/)
+ - [gcc compiler/linker](https://gcc.gnu.org/)
-->
- 你需要安装以下工具：
@@ -47,6 +49,8 @@ You need to have these tools installed:
- [Golang](https://golang.org/doc/install) 的 1.13 版本或更高
- [Docker](https://docs.docker.com/engine/installation/)
- [etcd](https://github.com/coreos/etcd/)
+ - [make](https://www.gnu.org/software/make/)
+ - [gcc compiler/linker](https://gcc.gnu.org/)
+{{< note >}}
+
-{{< feature-state for_k8s_version="1.12" state="stable" >}}
+要重新配置已创建的集群，请参阅[重新配置 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure)。
+{{< /note >}}
+
+
如果你使用的 Ubuntu 或其他 Linux 发行版，内建支持
[snap](https://snapcraft.io/docs/core/install) 包管理工具，
From 97295ed88fb5bd15e6220444505b17b41e2616b6 Mon Sep 17 00:00:00 2001
From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com>
Date: Sat, 16 Apr 2022 20:33:10 +0900
Subject: [PATCH 138/167] Improvement for
en/docs/reference/glossary/api-eviction.md (#32959)
* fix:add description of PodDisruptionBudgets and hyperlink
* Update api-eviction.md
---
content/en/docs/reference/glossary/api-eviction.md | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/content/en/docs/reference/glossary/api-eviction.md b/content/en/docs/reference/glossary/api-eviction.md
index 69fc9d9b0c..d450f90743 100644
--- a/content/en/docs/reference/glossary/api-eviction.md
+++ b/content/en/docs/reference/glossary/api-eviction.md
@@ -19,4 +19,9 @@ You can request eviction either by directly calling the Eviction API
using a client of the kube-apiserver, like the `kubectl drain` command.
When an `Eviction` object is created, the API server terminates the Pod.
+API-initiated evictions respect your configured [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/)
+and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination).
+
API-initiated eviction is not the same as [node-pressure eviction](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction).
+
+* See [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/) for more information.
From 8dcdc15b04078d219a6e66b995c30693fd6aebf6 Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Sat, 16 Apr 2022 17:22:52 +0800
Subject: [PATCH 139/167] [zh] translate kubeadm-reconfigure.md
Signed-off-by: xin.li
---
.../kubeadm/kubeadm-reconfigure.md | 509 ++++++++++++++++++
1 file changed, 509 insertions(+)
create mode 100644 content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md
diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md
new file mode 100644
index 0000000000..a9af9c080c
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md
@@ -0,0 +1,509 @@
+---
+title: 重新配置 kubeadm 集群
+content_type: task
+weight: 10
+---
+
+
+
+
+kubeadm 不支持自动重新配置部署在托管节点上的组件的方式。
+一种自动化的方法是使用自定义的
+[operator](/zh/docs/concepts/extend-kubernetes/operator/)。
+
+
+要修改组件配置，你必须手动编辑磁盘上关联的集群对象和文件。
+本指南展示了实现 kubeadm 集群重新配置所需执行的正确步骤顺序。
+
+## {{% heading "prerequisites" %}}
+
+
+- 你需要一个使用 kubeadm 部署的集群
+- 拥有管理员凭据（`/etc/kubernetes/admin.conf`）
+ 和从安装了 kubectl 的主机到集群中正在运行的 kube-apiserver 的网络连接
+- 在所有主机上安装文本编辑器
+
+
+
+
+## 重新配置集群
+
+kubeadm 在 ConfigMap 和其他对象中写入了一组集群范围的组件配置选项。
+这些对象必须手动编辑，可以使用命令 `kubectl edit`。
+
+
+`kubectl edit` 命令将打开一个文本编辑器，你可以在其中直接编辑和保存对象。
+你可以使用环境变量 `KUBECONFIG` 和 `KUBE_EDITOR` 来指定 kubectl
+使用的 kubeconfig 文件和首选文本编辑器的位置。
+
+例如：
+```
+KUBECONFIG=/etc/kubernetes/admin.conf KUBE_EDITOR=nano kubectl edit
+```
+
+{{< note >}}
+
+保存对这些集群对象的任何更改后，节点上运行的组件可能不会自动更新。
+以下步骤将指导你如何手动执行该操作。
+{{< /note >}}
+
+{{< warning >}}
+
+
+ConfigMaps 中的组件配置存储为非结构化数据（YAML 字符串）。 这意味着在更新
+ConfigMap 的内容时不会执行验证。 你必须小心遵循特定组件配置的文档化 API 格式，
+并避免引入拼写错误和 YAML 缩进错误。
+{{< /warning >}}
+
+
+### 应用集群配置更改
+
+#### 更新 `ClusterConfiguration`
+
+在集群创建和升级期间，kubeadm 将其
+[`ClusterConfiguration`](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)
+写入 `kube-system` 命名空间中名为 `kubeadm-config` 的 ConfigMap。
+
+要更改 `ClusterConfiguration` 中的特定选项，你可以使用以下命令编辑 ConfigMap：
+
+```shell
+kubectl edit cm -n kube-system kubeadm-config
+```
+
+配置位于 `data.ClusterConfiguration` 键下。
+
+{{< note >}}
+
+`ClusterConfiguration` 包括各种影响单个组件配置的选项， 例如
+kube-apiserver、kube-scheduler、kube-controller-manager、
+CoreDNS、etcd 和 kube-proxy。 对配置的更改必须手动反映在节点组件上。
+{{< /note >}}
+
+
+#### 在控制平面节点上反映 `ClusterConfiguration` 更改
+
+kubeadm 将控制平面组件作为位于 `/etc/kubernetes/manifests`
+目录中的静态 Pod 清单进行管理。
+对 `apiServer`、`controllerManager`、`scheduler` 或 `etcd`键下的
+`ClusterConfiguration` 的任何更改都必须反映在控制平面节点上清单目录中的关联文件中。
+
+
+
+此类更改可能包括:
+- `extraArgs` - 需要更新传递给组件容器的标志列表
+- `extraMounts` - 需要更新组件容器的卷挂载
+- `*SANs` - 需要使用更新的主题备用名称编写新证书
+
+在继续进行这些更改之前，请确保你已备份目录 `/etc/kubernetes/`。
+
+
+
+要编写新证书，你可以使用：
+
+```shell
+kubeadm init phase certs --config
+```
+
+要在 `/etc/kubernetes/manifests` 中编写新的清单文件，你可以使用：
+
+```shell
+kubeadm init phase control-plane --config
+```
+
+
+`` 内容必须与更新后的 `ClusterConfiguration` 匹配。
+`` 值必须是组件的名称。
+
+{{< note >}}
+
+更新 `/etc/kubernetes/manifests` 中的文件将告诉 kubelet 重新启动相应组件的静态 Pod。
+尝试一次对一个节点进行这些更改，以在不停机的情况下离开集群。
+{{< /note >}}
+
+
+### 应用 kubelet 配置更改
+
+#### 更新 `KubeletConfiguration`
+
+在集群创建和升级期间，kubeadm 将其
+[`KubeletConfiguration`](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
+写入 `kube-system` 命名空间中名为 `kubelet-config` 的 ConfigMap。
+你可以使用以下命令编辑 ConfigMap：
+
+```shell
+kubectl edit cm -n kube-system kubelet-config
+```
+
+配置位于 `data.kubelet` 键下。
+
+
+#### 反映 kubelet 的更改
+
+要反映 kubeadm 节点上的更改，你必须执行以下操作：
+
+- 登录到 kubeadm 节点
+- 运行 `kubeadm upgrade node phase kubelet-config` 下载最新的
+ `kubelet-config` ConfigMap 内容到本地文件 `/var/lib/kubelet/config.conf`
+- 编辑文件 `/var/lib/kubelet/kubeadm-flags.env` 以使用标志来应用额外的配置
+- 使用 `systemctl restart kubelet` 重启 kubelet 服务
+
+{{< note >}}
+
+一次执行一个节点的这些更改，以允许正确地重新安排工作负载。
+{{< /note >}}
+
+{{< note >}}
+
+在 `kubeadm upgrade` 期间，kubeadm 从 `kubelet-config` ConfigMap
+下载 `KubeletConfiguration` 并覆盖 `/var/lib/kubelet/config.conf` 的内容。
+这意味着节点本地配置必须通过`/var/lib/kubelet/kubeadm-flags.env`中的标志或在
+kubeadm upgrade` 后手动更新`/var/lib/kubelet/config.conf`的内容来应用，然后重新启动 kubelet。
+{{< /note >}}
+
+
+### 应用 kube-proxy 配置更改
+
+#### 更新 `KubeProxyConfiguration`
+
+在集群创建和升级期间，kubeadm 将其写入
+[`KubeProxyConfiguration`](/zh/docs/reference/config-api/kube-proxy-config.v1alpha1/)
+在名为 `kube-proxy` 的 `kube-system` 命名空间中的 ConfigMap 中。
+
+此 ConfigMap 由 `kube-system` 命名空间中的 `kube-proxy` DaemonSet 使用。
+
+要更改 `KubeProxyConfiguration` 中的特定选项，你可以使用以下命令编辑 ConfigMap：
+
+```shell
+kubectl edit cm -n kube-system kube-proxy
+```
+
+配置位于 `data.config.conf` 键下。
+
+
+#### 反映 kube-proxy 的更改
+
+更新 `kube-proxy` ConfigMap 后，你可以重新启动所有 kube-proxy Pod：
+
+获取 Pod 名称：
+
+```shell
+kubectl get po -n kube-system | grep kube-proxy
+```
+
+使用以下命令删除 Pod：
+
+```shell
+kubectl delete po -n kube-system
+```
+
+将创建使用更新的 ConfigMap 的新 Pod。
+
+{{< note >}}
+
+由于 kubeadm 将 kube-proxy 部署为 DaemonSet，因此不支持特定于节点的配置。
+{{< /note >}}
+
+
+### 应用 CoreDNS 配置更改
+
+#### 更新 CoreDNS 的 Deployment 和 Service
+
+kubeadm 将 CoreDNS 部署为名为 `coredns` 的 Deployment，并使用 Service `kube-dns`，
+两者都在 `kube-system` 命名空间中。
+
+要更新任何 CoreDNS 设置，你可以编辑 Deployment 和 Service：
+
+
+```shell
+kubectl edit deployment -n kube-system coredns
+kubectl edit service -n kube-system kube-dns
+```
+
+
+#### 反映 CoreDNS 的更改
+
+应用 CoreDNS 更改后，你可以删除 CoreDNS Pod。
+
+获取 Pod 名称：
+
+```shell
+kubectl get po -n kube-system | grep coredns
+```
+
+使用以下命令删除 Pod：
+
+```shell
+kubectl delete po -n kube-system
+```
+
+
+将创建具有更新的 CoreDNS 配置的新 Pod。
+
+{{< note >}}
+
+kubeadm 不允许在集群创建和升级期间配置 CoreDNS。
+这意味着如果执行了 `kubeadm upgrade apply`，你对
+CoreDNS 对象的更改将丢失并且必须重新应用。
+{{< /note >}}
+
+
+## 持久化重新配置
+
+在受管节点上执行 `kubeadm upgrade` 期间，kubeadm
+可能会覆盖在创建集群（重新配置）后应用的配置。
+
+
+### 持久化 Node 对象重新配置
+
+kubeadm 在特定 Kubernetes 节点的 Node 对象上写入标签、污点、CRI
+套接字和其他信息。要更改此 Node 对象的任何内容，你可以使用：
+
+```shell
+kubectl edit no
+```
+
+
+在 `kubeadm upgrade` 期间，此类节点的内容可能会被覆盖。
+如果你想在升级后保留对 Node 对象的修改，你可以准备一个
+[kubectl patch](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
+并将其应用到 Node 对象：
+
+```shell
+kubectl patch no --patch-file
+```
+
+
+#### 持久化控制平面组件重新配置
+
+控制平面配置的主要来源是存储在集群中的 `ClusterConfiguration` 对象。
+要扩展静态 Pod 清单配置，可以使用
+[patches](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#patches)。
+
+这些补丁文件必须作为文件保留在控制平面节点上，以确保它们可以被
+`kubeadm upgrade ... --patches ` 使用。
+
+如果对 `ClusterConfiguration` 和磁盘上的静态 Pod 清单进行了重新配置，则必须相应地更新节点特定补丁集。
+
+
+#### 持久化 kubelet 重新配置
+
+对存储在 `/var/lib/kubelet/config.conf` 中的 `KubeletConfiguration`
+所做的任何更改都将在 `kubeadm upgrade` 时因为下载集群范围内的 `kubelet-config`
+ConfigMap 的内容而被覆盖。
+要持久保存 kubelet 节点特定的配置，文件`/var/lib/kubelet/config.conf`
+必须在升级后手动更新，或者文件`/var/lib/kubelet/kubeadm-flags.env` 可以包含标志。
+kubelet 标志会覆盖相关的 `KubeletConfiguration` 选项，但请注意，有些标志已被弃用。
+
+更改 `/var/lib/kubelet/config.conf` 或 `/var/lib/kubelet/kubeadm-flags.env`
+后需要重启 kubelet。
+
+{{% heading "whatsnext" %}}
+
+
+
+- [升级 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)
+- [使用 kubeadm API 自定义组件](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags)
+- [使用 kubeadm 管理证书](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)
\ No newline at end of file
From d4fb60ae2016eedb1057a7c7200858c82168387c Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Sat, 16 Apr 2022 18:00:11 +0800
Subject: [PATCH 140/167] [zh] Sync policy-resources/_index.md
Signed-off-by: xin.li
---
.../reference/kubernetes-api/policy-resources/_index.md | 7 +++++++
1 file changed, 7 insertions(+)
create mode 100644 content/zh/docs/reference/kubernetes-api/policy-resources/_index.md
diff --git a/content/zh/docs/reference/kubernetes-api/policy-resources/_index.md b/content/zh/docs/reference/kubernetes-api/policy-resources/_index.md
new file mode 100644
index 0000000000..71adda0968
--- /dev/null
+++ b/content/zh/docs/reference/kubernetes-api/policy-resources/_index.md
@@ -0,0 +1,7 @@
+---
+title: "策略资源"
+weight: 6
+auto_generated: true
+---
+
+
From 9a90377a14ce3c513d6849396be9750f605bbef4 Mon Sep 17 00:00:00 2001
From: CodyBuilder-dev <52912568+CodyBuilder-dev@users.noreply.github.com>
Date: Sun, 17 Apr 2022 13:53:53 +0900
Subject: [PATCH 141/167] Update object-management.md
---
.../concepts/overview/working-with-objects/object-management.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/ko/docs/concepts/overview/working-with-objects/object-management.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md
index 575def2256..4a0c28315e 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/object-management.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md
@@ -6,7 +6,7 @@ weight: 15
`kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
-몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
+몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요를
제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은
[Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다.
From 9b4516d8fed2c35b05fc0d29da7382dd4aae843b Mon Sep 17 00:00:00 2001
From: song
Date: Thu, 14 Apr 2022 23:35:19 +0800
Subject: [PATCH 142/167] [zh] update outdate setup-konnectivity file
---
.../extend-kubernetes/setup-konnectivity.md | 35 ++++++++-----------
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/content/zh/docs/tasks/extend-kubernetes/setup-konnectivity.md b/content/zh/docs/tasks/extend-kubernetes/setup-konnectivity.md
index 0359639517..1716735ed4 100644
--- a/content/zh/docs/tasks/extend-kubernetes/setup-konnectivity.md
+++ b/content/zh/docs/tasks/extend-kubernetes/setup-konnectivity.md
@@ -13,7 +13,17 @@ Konnectivity 服务为控制平面提供集群通信的 TCP 级别代理。
## {{% heading "prerequisites" %}}
-{{< include "task-tutorial-prereqs.md" >}}
+
+你需要有一个 Kubernetes 集群，并且 kubectl 命令可以与集群通信。
+建议在至少有两个不充当控制平面主机的节点的集群上运行本教程。
+如果你还没有集群，可以使用
+[minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) 创建一个集群。
你需要配置 API 服务器来使用 Konnectivity 服务，并将网络流量定向到集群节点：
-1. 确保 `ServiceAccountTokenVolumeProjection`
- [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
- 被启用。你可以通过为 kube-apiserver 提供以下标志启用
- [服务账号令牌卷保护](/zh/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)：
-
- ```
- --service-account-issuer=api
- --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
- --api-audiences=system:konnectivity-server
- ```
+确保[服务账号令牌卷投射](/zh/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
+特性被启用。该特性自 Kubernetes v1.20 起默认已被启用。
1. 创建一个出站流量配置文件，比如 `admin/konnectivity/egress-selector-configuration.yaml`。
1. 将 API 服务器的 `--egress-selector-config-file` 参数设置为你的 API 服务器的
From 69984b96160ade2ac73e79caa28283e265dd9c0c Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Sun, 17 Apr 2022 21:22:51 +0800
Subject: [PATCH 143/167] [zh] Update network-policies.md
Signed-off-by: xin.li
---
.../services-networking/network-policies.md | 37 +------------------
.../service/networking/networkpolicy.yaml | 35 ++++++++++++++++++
2 files changed, 36 insertions(+), 36 deletions(-)
create mode 100644 content/zh/examples/service/networking/networkpolicy.yaml
diff --git a/content/zh/docs/concepts/services-networking/network-policies.md b/content/zh/docs/concepts/services-networking/network-policies.md
index c49c4b99f1..ff36905777 100644
--- a/content/zh/docs/concepts/services-networking/network-policies.md
+++ b/content/zh/docs/concepts/services-networking/network-policies.md
@@ -121,42 +121,7 @@ An example NetworkPolicy might look like this:
下面是一个 NetworkPolicy 的示例:
-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
- name: test-network-policy
- namespace: default
-spec:
- podSelector:
- matchLabels:
- role: db
- policyTypes:
- - Ingress
- - Egress
- ingress:
- - from:
- - ipBlock:
- cidr: 172.17.0.0/16
- except:
- - 172.17.1.0/24
- - namespaceSelector:
- matchLabels:
- project: myproject
- - podSelector:
- matchLabels:
- role: frontend
- ports:
- - protocol: TCP
- port: 6379
- egress:
- - to:
- - ipBlock:
- cidr: 10.0.0.0/24
- ports:
- - protocol: TCP
- port: 5978
-```
+{{< codenew file="service/networking/networkpolicy.yaml" >}}
-{{< note >}}
如果容器指定了自己的内存限制，但没有指定内存请求，Kubernetes 会自动为它指定与内存限制匹配的内存请求。
同样，如果容器指定了自己的 CPU 限制，但没有指定 CPU 请求，Kubernetes 会自动为它指定与 CPU 限制匹配的 CPU 请求。
{{< /note >}}
@@ -158,7 +158,7 @@ kubectl delete pod qos-demo --namespace=qos-example
A Pod is given a QoS class of Burstable if:
* The Pod does not meet the criteria for QoS class Guaranteed.
-* At least one Container in the Pod has a memory or CPU request.
+* At least one Container in the Pod has a memory or CPU request or limit.
Here is the configuration file for a Pod that has one Container. The Container has a memory limit of 200 MiB
and a memory request of 100 MiB.
@@ -168,7 +168,7 @@ and a memory request of 100 MiB.
如果满足下面条件，将会指定 Pod 的 QoS 类为 Burstable：
* Pod 不符合 Guaranteed QoS 类的标准。
-* Pod 中至少一个容器具有内存或 CPU 请求。
+* Pod 中至少一个容器具有内存或 CPU 的请求或限制。
下面是包含一个容器的 Pod 配置文件。
容器设置了内存限制 200 MiB 和内存请求 100 MiB。
From 53cec5e6d0438478dd5e61acbc626e2362bdff20 Mon Sep 17 00:00:00 2001
From: zaunist
Date: Mon, 18 Apr 2022 15:53:35 +0800
Subject: [PATCH 145/167] docs: Rsync access-cluster-api.md
---
.../administer-cluster/access-cluster-api.md | 52 ++++++++-----------
1 file changed, 22 insertions(+), 30 deletions(-)
diff --git a/content/zh/docs/tasks/administer-cluster/access-cluster-api.md b/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
index 7b1c9bed98..37f80f26af 100644
--- a/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
+++ b/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
@@ -18,7 +18,6 @@ This page shows how to access clusters using the Kubernetes API.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
许多[样例](https://github.com/kubernetes/examples/tree/master/)
-提供了使用 kubectl 的介绍。完整文档请见 [kubectl 手册](/zh/docs/reference/kubectl/overview/)。
+提供了使用 kubectl 的介绍。完整文档请见 [kubectl 手册](/zh/docs/reference/kubectl/)。
-1. 以代理模式运行 kubectl（推荐）。
+1. 以代理模式运行 kubectl（推荐）。
推荐使用此方法，因为它用存储的 apiserver 位置并使用自签名证书验证 API 服务器的标识。
使用这种方法无法进行中间人（MITM）攻击。
2. 另外，你可以直接为 HTTP 客户端提供位置和身份认证。
@@ -160,8 +159,25 @@ export CLUSTER_NAME="some_server_name"
# 指向引用该集群名称的 API 服务器
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
-# 获得令牌
-TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 -d)
+# 创建一个 secret 来保存默认服务账户的令牌
+kubectl apply -f - </dev/null; do
+ echo "waiting for token..." >&2
+ sleep 1
+done
+
+# 获取令牌
+TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
# 使用令牌玩转 API
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
@@ -185,30 +201,6 @@ curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
}
```
-
-使用 `jsonpath` 方式：
-
-```shell
-APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
-TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
-curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
-```
-
-```json
-{
- "kind": "APIVersions",
- "versions": [
- "v1"
- ],
- "serverAddressByClientCIDRs": [
- {
- "clientCIDR": "0.0.0.0/0",
- "serverAddress": "10.0.1.149:443"
- }
- ]
-}
-```
-
-Pod 水平自动扩缩（Horizontal Pod Autoscaler）
-可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment、ReplicaSet 和
-StatefulSet 中的 Pod 数量。
-除了 CPU 利用率，也可以基于其他应程序提供的
-[自定义度量指标](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)
-来执行自动扩缩。
-Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。
+在 Kubernetes 中，_HorizontalPodAutoscaler_ 自动更新工作负载资源
+（例如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或者
+{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}），
+目的是自动扩缩工作负载以满足需求。
-Pod 水平自动扩缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。
-控制器会周期性地调整副本控制器或 Deployment 中的副本数量，以使得类似 Pod 平均 CPU
-利用率、平均内存利用率这类观测到的度量值与用户所设定的目标值匹配。
+水平扩缩意味着对增加的负载的响应是部署更多的 {{< glossary_tooltip text="Pods" term_id="pod" >}}。
+这与 “垂直（Vertical）” 扩缩不同，对于 Kubernetes，
+垂直扩缩意味着将更多资源（例如：内存或 CPU）分配给已经为工作负载运行的 Pod。
+
+如果负载减少，并且 Pod 的数量高于配置的最小值，
+HorizontalPodAutoscaler 会指示工作负载资源（ Deployment、StatefulSet 或其他类似资源）缩减。
+
+
+水平 Pod 自动扩缩不适用于无法扩缩的对象（例如：{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}。）
+
+
+HorizontalPodAutoscaler 被实现为 Kubernetes API 资源和{{< glossary_tooltip text="控制器" term_id="controller" >}}。
+
+资源决定了控制器的行为。在 Kubernetes {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}内运行的水平
+Pod 自动扩缩控制器会定期调整其目标（例如：Deployment）的所需规模，以匹配观察到的指标，
+例如，平均 CPU 利用率、平均内存利用率或你指定的任何其他自定义指标。
+
+
+使用水平 Pod 自动扩缩[演练示例](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)。
-## Pod 水平自动扩缩工作机制
+## HorizontalPodAutoscaler 是如何工作的？ {#how-does-a-horizontalpodautoscaler-work}
-
+{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler 控制 Deployment 及其 ReplicaSet 的规模" class="diagram-medium">}}
-Pod 水平自动扩缩器的实现是一个控制回路，由控制器管理器的 `--horizontal-pod-autoscaler-sync-period` 参数指定周期（默认值为 15 秒）。
+Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路（它不是一个连续的过程）。间隔由
+[`kube-controller-manager`](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
+的 `--horizontal-pod-autoscaler-sync-period` 参数设置（默认间隔为 15 秒）。
-每个周期内，控制器管理器根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。
-控制器管理器可以从资源度量指标 API（按 Pod 统计的资源用量）和自定义度量指标
-API（其他指标）获取度量值。
+在每个时间段内，控制器管理器都会根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。
+控制器管理器找到由 `scaleTargetRef` 定义的目标资源，然后根据目标资源的 `.spec.selector` 标签选择 Pod，
+并从资源指标 API（针对每个 Pod 的资源指标）或自定义指标获取指标 API（适用于所有其他指标）。
* 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个
HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率，
- 控制器获取每个 Pod 中的容器资源使用情况，并计算资源使用率。
- 如果设置了 target 值，将直接使用原始数据（不再计算百分比）。
+ 控制器获取每个 Pod 中的容器[资源使用](/zh/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) 情况，
+ 并计算资源使用率。如果设置了 target 值，将直接使用原始数据（不再计算百分比）。
接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。
-通常情况下，控制器将从一系列的聚合 API（`metrics.k8s.io`、`custom.metrics.k8s.io`
-和 `external.metrics.k8s.io`）中获取度量值。
-`metrics.k8s.io` API 通常由 Metrics 服务器（需要额外启动）提供。
-可以从 [metrics-server](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) 获取更多信息。
-另外，控制器也可以直接从 Heapster 获取指标。
-
-{{< note >}}
-{{< feature-state state="deprecated" for_k8s_version="1.11" >}}
-
-自 Kubernetes 1.11 起，从 Heapster 获取指标特性已废弃。
-{{< /note >}}
+HorizontalPodAutoscaler 的常见用途是将其配置为从{{< glossary_tooltip text="聚合 API" term_id="aggregation-layer" >}}
+（`metrics.k8s.io`、`custom.metrics.k8s.io` 或 `external.metrics.k8s.io`）获取指标。
+`metrics.k8s.io` API 通常由名为 Metrics Server 的插件提供，需要单独启动。有关资源指标的更多信息，
+请参阅 [Metrics Server](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)。
-关于指标 API 更多信息，请参考[度量值指标 API 的支持](#support-for-metrics-apis)。
+[Support for metrics APIs](#support-for-metrics-apis) explains the stability guarantees and support status for these
+different APIs.
-
-自动扩缩控制器使用 scale 子资源访问相应可支持扩缩的控制器（如副本控制器、
-Deployment 和 ReplicaSet）。
-`scale` 是一个可以动态设定副本数量和检查当前状态的接口。
-关于 scale 子资源的更多信息，请参考[这里](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
+对 [Metrics API 的支持](#support-for-metrics-apis)解释了这些不同 API 的稳定性保证和支持状态
+
+HorizontalPodAutoscaler 控制器访问支持扩缩的相应工作负载资源（例如：Deployments 和 StatefulSet）。
+这些资源每个都有一个名为 `scale` 的子资源，该接口允许你动态设置副本的数量并检查它们的每个当前状态。
+有关 Kubernetes API 子资源的一般信息，
+请参阅 [Kubernetes API 概念](/zh/docs/reference/using-api/api-concepts/)。
-例如，当前度量值为 `200m`，目标设定值为 `100m`，那么由于 `200.0/100.0 == 2.0`，
-副本数量将会翻倍。
-如果当前指标为 `50m`，副本数量将会减半，因为`50.0/100.0 == 0.5`。
-如果计算出的扩缩比例接近 1.0
-（根据`--horizontal-pod-autoscaler-tolerance` 参数全局配置的容忍值，默认为 0.1），
-将会放弃本次扩缩。
+例如，如果当前指标值为 `200m`，而期望值为 `100m`，则副本数将加倍，
+因为 `200.0 / 100.0 == 2.0` 如果当前值为 `50m`，则副本数将减半，
+因为 `50.0 / 100.0 == 0.5`。如果比率足够接近 1.0（在全局可配置的容差范围内，默认为 0.1），
+则控制平面会跳过扩缩操作。
如果 HorizontalPodAutoscaler 指定的是 `targetAverageValue` 或 `targetAverageUtilization`，
那么将会把指定 Pod 度量值的平均值做为 `currentMetricValue`。
-然而，在检查容忍度和决定最终扩缩值前，我们仍然会把那些无法获取指标的 Pod 统计进去。
+
+在检查容差并决定最终值之前，控制平面还会考虑是否缺少任何指标，
+以及有多少 Pod [`已就绪`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)。
-所有被标记了删除时间戳（Pod 正在关闭过程中）的 Pod 和失败的 Pod 都会被忽略。
+所有设置了删除时间戳的 Pod（带有删除时间戳的对象正在关闭/移除的过程中）都会被忽略，
+所有失败的 Pod 都会被丢弃。
如果某个 Pod 缺失度量值，它将会被搁置，只在最终确定扩缩数量时再考虑。
-当使用 CPU 指标来扩缩时，任何还未就绪（例如还在初始化）状态的 Pod *或* 最近的指标
-度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。
+当使用 CPU 指标来扩缩时，任何还未就绪（还在初始化，或者可能是不健康的）状态的 Pod **或**
+最近的指标度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。
-由于受技术限制，Pod 水平扩缩控制器无法准确的知道 Pod 什么时候就绪，
-也就无法决定是否暂时搁置该 Pod。
-`--horizontal-pod-autoscaler-initial-readiness-delay` 参数（默认为 30s）用于设置 Pod 准备时间，
-在此时间内的 Pod 统统被认为未就绪。
-`--horizontal-pod-autoscaler-cpu-initialization-period` 参数（默认为5分钟）
-用于设置 Pod 的初始化时间，
-在此时间内的 Pod，CPU 资源度量值将不会被采纳。
+由于技术限制，HorizontalPodAutoscaler 控制器在确定是否保留某些 CPU 指标时无法准确确定 Pod 首次就绪的时间。
+相反，如果 Pod 未准备好并在其启动后的一个可配置的短时间窗口内转换为未准备好，它会认为 Pod “尚未准备好”。
+该值使用 `--horizontal-pod-autoscaler-initial-readiness-delay` 标志配置，默认值为 30 秒。
+一旦 Pod 准备就绪，如果它发生在自启动后较长的、可配置的时间内，它就会认为任何向准备就绪的转换都是第一个。
+该值由 `-horizontal-pod-autoscaler-cpu-initialization-period` 标志配置，默认为 5 分钟。
-如果缺失任何的度量值，我们会更保守地重新计算平均值，
-在需要缩小时假设这些 Pod 消耗了目标值的 100%，
-在需要放大时假设这些 Pod 消耗了 0% 目标值。
-这可以在一定程度上抑制扩缩的幅度。
+如果缺失某些度量值，控制平面会更保守地重新计算平均值，在需要缩小时假设这些 Pod 消耗了目标值的 100%，
+在需要放大时假设这些 Pod 消耗了 0% 目标值。这可以在一定程度上抑制扩缩的幅度。
-此外，如果存在任何尚未就绪的 Pod，我们可以在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩，
-我们保守地假设尚未就绪的 Pod 消耗了期望指标的 0%，从而进一步降低了扩缩的幅度。
+此外，如果存在任何尚未就绪的 Pod，工作负载会在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩，
+控制器保守地假设尚未就绪的 Pod 消耗了期望指标的 0%，从而进一步降低了扩缩的幅度。
-在扩缩方向（缩小或放大）确定后，我们会把未就绪的 Pod 和缺少指标的 Pod 考虑进来再次计算使用率。
-如果新的比率与扩缩方向相反，或者在容忍范围内，则跳过扩缩。
-否则，我们使用新的扩缩比例。
+考虑到尚未准备好的 Pod 和缺失的指标后，控制器会重新计算使用率。
+如果新的比率与扩缩方向相反，或者在容差范围内，则控制器不会执行任何扩缩操作。
+在其他情况下，新比率用于决定对 Pod 数量的任何更改。
-注意，平均利用率的*原始*值会通过 HorizontalPodAutoscaler 的状态体现（
-即使使用了新的使用率，也不考虑未就绪 Pod 和 缺少指标的 Pod)。
+注意，平均利用率的 **原始** 值是通过 HorizontalPodAutoscaler 状态体现的，
+而不考虑尚未准备好的 Pod 或缺少的指标，即使使用新的使用率也是如此。
## API 对象 {#api-object}
-HorizontalPodAutoscaler 是 Kubernetes `autoscaling` API 组的资源。
-在当前稳定版本（`autoscaling/v1`）中只支持基于 CPU 指标的扩缩。
-
-
-API 的 beta 版本（`autoscaling/v2beta2`）引入了基于内存和自定义指标的扩缩。
-在 `autoscaling/v2beta2` 版本中新引入的字段在 `autoscaling/v1` 版本中以注解
-的形式得以保留。
+HorizontalPodAutoscaler 是 Kubernetes `autoscaling` API 组中的 API 资源。
+当前的稳定版本可以在 `autoscaling/v2` API 版本中找到，其中包括对基于内存和自定义指标执行扩缩的支持。
+在使用 `autoscaling/v1` 时，`autoscaling/v2` 中引入的新字段作为注释保留。
创建 HorizontalPodAutoscaler 对象时，需要确保所给的名称是一个合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
有关 API 对象的更多信息，请查阅
-[HorizontalPodAutoscaler 对象设计文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)。
+[HorizontalPodAutoscaler 对象设计文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling)。
-## kubectl 对 Horizontal Pod Autoscaler 的支持
+## 工作量规模的稳定性 {#flapping}
-与其他 API 资源类似，`kubectl` 以标准方式支持 HPA。
-我们可以通过 `kubectl create` 命令创建一个 HPA 对象，
-通过 `kubectl get hpa` 命令来获取所有 HPA 对象，
-通过 `kubectl describe hpa` 命令来查看 HPA 对象的详细信息。
-最后，可以使用 `kubectl delete hpa` 命令删除对象。
-
-
-此外，还有个简便的命令 `kubectl autoscale` 来创建 HPA 对象。
-例如，命令 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` 将会为名
-为 *foo* 的 ReplicationSet 创建一个 HPA 对象，
-目标 CPU 使用率为 `80%`，副本数量配置为 2 到 5 之间。
+在使用 HorizontalPodAutoscaler 管理一组副本的规模时，由于评估的指标的动态特性，
+副本的数量可能会经常波动。这有时被称为 **抖动（thrashing）** 或 **波动（flapping）**。它类似于控制论中的 **滞后（hysteresis）** 概念。
-## 冷却/延迟支持
-
-当使用 Horizontal Pod Autoscaler 管理一组副本扩缩时，
-有可能因为指标动态的变化造成副本数量频繁的变化，有时这被称为
-*抖动（Thrashing）*。
-
-
-从 v1.6 版本起，集群操作员可以调节某些 `kube-controller-manager` 的全局参数来
-缓解这个问题。
-
-
-从 v1.12 开始，算法调整后，扩容操作时的延迟就不必设置了。
-
-
-- `--horizontal-pod-autoscaler-downscale-stabilization`: 设置缩容冷却时间窗口长度。
- 水平 Pod
-扩缩器能够记住过去建议的负载规模，并仅对此时间窗口内的最大规模执行操作。
- 默认值是 5 分钟（`5m0s`）。
-
-
-{{< note >}}
-当调整这些参数时，集群操作员需要明白其可能的影响。
-如果延迟（冷却）时间设置的太长，Horizontal Pod Autoscaler 可能会不能很好的改变负载。
-如果延迟（冷却）时间设置的太短，那么副本数量有可能跟以前一样出现抖动。
-{{< /note >}}
-
-`HorizontalPodAutoscaler` 也支持容器指标源，这时 HPA 可以跟踪记录一组 Pods 中各个容器的
+HorizontalPodAutoscaler API 也支持容器指标源，这时 HPA 可以跟踪记录一组 Pods 中各个容器的
资源用量，进而触发扩缩目标对象的操作。
-容器资源指标的支持使得你可以为特定 Pod 中最重要的容器配置规模缩放阈值。
+容器资源指标的支持使得你可以为特定 Pod 中最重要的容器配置规模扩缩阈值。
例如，如果你有一个 Web 应用和一个执行日志操作的边车容器，你可以基于 Web 应用的
资源用量来执行扩缩，忽略边车容器的存在及其资源用量。
@@ -517,7 +477,7 @@ of the pods then those pods are ignored and the recommendation is recalculated.
for more details about the calculation. To use container resources for autoscaling define a metric
source as follows:
-->
-如果你更改缩放目标对象，令其使用新的、包含一组不同的容器的 Pod 规约，你就需要
+如果你更改扩缩目标对象，令其使用新的、包含一组不同的容器的 Pod 规约，你就需要
修改 HPA 的规约才能基于新添加的容器来执行规模扩缩操作。
如果指标源中指定的容器不存在或者仅存在于部分 Pods 中，那么这些 Pods 会被忽略，
HPA 会重新计算资源用量值。参阅[算法](#algorithm-details)小节进一步了解计算细节。
@@ -563,51 +523,50 @@ the old container name from the HPA specification.
{{< /note >}}
-## 多指标支持 {#support-for-multiple-metrics}
+(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature)
-Kubernetes 1.6 开始支持基于多个度量值进行扩缩。
-你可以使用 `autoscaling/v2beta2` API 来为 Horizontal Pod Autoscaler 指定多个指标。
-Horizontal Pod Autoscaler 会根据每个指标计算，并生成一个扩缩建议。
-幅度最大的扩缩建议会被采纳。
+Provided that you use the `autoscaling/v2` API version, you can configure a HorizontalPodAutoscaler
+to scale based on a custom metric (that is not built in to Kubernetes or any Kubernetes component).
+The HorizontalPodAutoscaler controller then queries for these custom metrics from the Kubernetes
+API.
-
-## 自定义指标支持 {#support-for-custom-metrics}
-
-{{< note >}}
-在 Kubernetes 1.2 增加了支持基于使用特殊注解表达的、特定于具体应用的扩缩能力，
-此能力处于 Alpha 阶段。
-从 Kubernetes 1.6 起，由于新的 autoscaling API 的引入，这些 annotation 就被废弃了。
-虽然收集自定义指标的旧方法仍然可用，Horizontal Pod Autoscaler 调度器将不会再使用这些度量值。
-同时，Horizontal Pod Autoscaler 也不再使用之前用于指定用户自定义指标的注解。
-{{< /note >}}
-
-
-自 Kubernetes 1.6 起，Horizontal Pod Autoscaler 支持使用自定义指标。
-你可以使用 `autoscaling/v2beta2` API 为 Horizontal Pod Autoscaler 指定用户自定义指标。
-Kubernetes 会通过用户自定义指标 API 来获取相应的指标。
-
-
-关于指标 API 的要求，请参阅[对 Metrics API 的支持](#support-for-metrics-apis)。
+## 扩展自定义指标 {#scaling-on-custom-metrics}
+
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}
+
+（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）
+
+如果你使用 `autoscaling/v2` API 版本，则可以将 HorizontalPodAutoscaler
+配置为基于自定义指标（未内置于 Kubernetes 或任何 Kubernetes 组件）进行扩缩。
+HorizontalPodAutoscaler 控制器能够从 Kubernetes API 查询这些自定义指标。
+
+有关要求，请参阅对 [Metrics APIs 的支持](#support-for-metrics-apis)。
+
+
+## 基于多个指标来执行扩缩 {#scaling-on-multiple-metrics}
+
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}
+
+（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）
+
+如果你使用 `autoscaling/v2` API 版本，你可以为 HorizontalPodAutoscaler 指定多个指标以进行扩缩。
+HorizontalPodAutoscaler 控制器评估每个指标，并根据该指标提出一个新的比例。
+HorizontalPodAutoscaler 采用为每个指标推荐的最大比例，
+并将工作负载设置为该大小（前提是这不大于你配置的总体最大值）。
* 启用了 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
@@ -645,24 +601,20 @@ APIs, cluster administrators must ensure that:
* 对于自定义指标，将使用 `custom.metrics.k8s.io` API。
它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。
- 确认你的指标流水线，或者查看[已知方案列表](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)。
- 如果你想自己编写，请从 [boilerplate](https://github.com/kubernetes-sigs/custommetrics-apiserver)开始。
+ 检查你的指标管道以查看是否有可用的 Kubernetes 指标适配器。
* 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。
-* `--horizontal-pod-autoscaler-use-rest-clients` 参数设置为 `true` 或者不设置。
- 如果设置为 false，则会切换到基于 Heapster 的自动扩缩，这个特性已经被弃用了。
-
关于指标来源以及其区别的更多信息，请参阅相关的设计文档，
-[the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md)、
-[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md) 和
-[external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md)。
+[HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md)，
+[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md) 和
+[external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md)。
-## 支持可配置的扩缩 {#support-for-configurable-scaling-behaviour}
+## 可配置的扩缩行为 {#configurable-scaling-behavior}
-从 [v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md)
-开始，`v2beta2` API 允许通过 HPA 的 `behavior` 字段配置扩缩行为。
-在 `behavior` 字段中的 `scaleUp` 和 `scaleDown` 分别指定扩容和缩容行为。
-可以两个方向指定一个稳定窗口，以防止扩缩目标中副本数量的波动。
-类似地，指定扩缩策略可以控制扩缩时副本数的变化率。
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}
+
+（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）
+
+如果你使用 `v2` HorizontalPodAutoscaler API，你可以使用 `behavior` 字段
+（请参阅 [API 参考](/zh/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec)）
+来配置单独的放大和缩小行为。你可以通过在行为字段下设置 `scaleUp` 和/或 `scaleDown` 来指定这些行为。
+
+
+
+你可以指定一个 “稳定窗口” ，以防止扩缩目标的副本计数发生[波动](#flapping)。
+扩缩策略还允许你在扩缩时控制副本的变化率。
### 扩缩策略 {#scaling-policies}
-在 spec 字段的 `behavior` 部分可以指定一个或多个扩缩策略。
-当指定多个策略时，默认选择允许更改最多的策略。
-下面的例子展示了缩容时的行为:
+可以在规约的 `behavior` 部分中指定一个或多个扩缩策略。当指定多个策略时，
+允许最大更改量的策略是默认选择的策略。以下示例显示了缩小时的这种行为：
```yaml
behavior:
@@ -750,35 +711,45 @@ scaling in that direction.
-->
可以指定扩缩方向的 `selectPolicy` 字段来更改策略选择。
通过设置 `Min` 的值，它将选择副本数变化最小的策略。
-将该值设置为 `Disabled` 将完全禁用该方向的缩放。
+将该值设置为 `Disabled` 将完全禁用该方向的扩缩。
### 稳定窗口 {#stabilization-window}
-当用于扩缩的指标持续抖动时，使用稳定窗口来限制副本数上下振动。
-自动扩缩算法使用稳定窗口来考虑过去计算的期望状态，以防止扩缩。
-在下面的例子中，稳定化窗口被指定为 `scaleDown`。
+当用于扩缩的指标不断波动时，稳定窗口用于限制副本计数的[波动](#flapping)。
+自动扩缩算法使用此窗口来推断先前的期望状态并避免对工作负载规模进行不必要的更改。
+
+例如，在以下示例代码段中，为 `scaleDown` 指定了稳定窗口。
```yaml
-scaleDown:
- stabilizationWindowSeconds: 300
+behavior:
+ scaleDown:
+ stabilizationWindowSeconds: 300
```
当指标显示目标应该缩容时，自动扩缩算法查看之前计算的期望状态，并使用指定时间间隔内的最大值。
在上面的例子中，过去 5 分钟的所有期望状态都会被考虑。
+
+这近似于滚动最大值，并避免了扩缩算法频繁删除 Pod 而又触发重新创建等效 Pod。
+
-### 示例：更改缩容稳定窗口
+### 示例：更改缩容稳定窗口 {#example-change-downscale-stabilization-window}
将下面的 behavior 配置添加到 HPA 中，可提供一个 1 分钟的自定义缩容稳定窗口：
@@ -850,7 +821,7 @@ behavior:
To limit the rate at which pods are removed by the HPA to 10% per minute, the
following behavior would be added to the HPA:
-->
-### 示例：限制缩容速率
+### 示例：限制缩容速率 {#example-limit-scale-down-rate}
将下面的 behavior 配置添加到 HPA 中，可限制 Pod 被 HPA 删除速率为每分钟 10%：
@@ -868,8 +839,7 @@ To ensure that no more than 5 Pods are removed per minute, you can add a second
policy with a fixed size of 5, and set `selectPolicy` to minimum. Setting `selectPolicy` to `Min` means
that the autoscaler chooses the policy that affects the smallest number of Pods:
-->
-为了确保每分钟删除的 Pod 数不超过 5 个，可以添加第二个缩容策略，大小固定为 5，
-并将 `selectPolicy` 设置为最小值。
+为了确保每分钟删除的 Pod 数不超过 5 个，可以添加第二个缩容策略，大小固定为 5，并将 `selectPolicy` 设置为最小值。
将 `selectPolicy` 设置为 `Min` 意味着 autoscaler 会选择影响 Pod 数量最小的策略:
```yaml
@@ -892,7 +862,7 @@ The `selectPolicy` value of `Disabled` turns off scaling the given direction.
So to prevent downscaling the following policy would be used:
-->
-### 示例：禁用缩容
+### 示例：禁用缩容 {#example-disable-scale-down}
`selectPolicy` 的值 `Disabled` 会关闭对给定方向的缩容。
因此使用以下策略，将会阻止缩容：
@@ -902,6 +872,30 @@ behavior:
scaleDown:
selectPolicy: Disabled
```
+
+## kubectl 对 HorizontalPodAutoscaler 的支持 {#support-for-horizontalpodautoscaler-in-kubectl}
+
+与每个 API 资源一样，HorizontalPodAutoscaler 都被 `kubectl` 以标准方式支持。
+你可以使用 `kubectl create` 命令创建一个新的自动扩缩器。
+你可以通过 `kubectl get hpa` 列出自动扩缩器或通过 `kubectl describe hpa` 获取详细描述。
+最后，你可以使用 `kubectl delete hpa` 删除自动扩缩器。
+
+
+此外，还有一个特殊的 `kubectl autoscale` 命令用于创建 HorizontalPodAutoscaler 对象。
+例如，执行 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`
+将为 ReplicaSet *foo* 创建一个自动扩缩器，目标 CPU 利用率设置为 `80%`，副本数在 2 到 5 之间。
-## 隐式维护状态禁用
+## 隐式维护状态禁用 {#implicit-maintenance-mode-deactivation}
你可以在不必更改 HPA 配置的情况下隐式地为某个目标禁用 HPA。
如果此目标的期望副本个数被设置为 0，而 HPA 的最小副本个数大于 0，
则 HPA 会停止调整目标（并将其自身的 `ScalingActive` 状况设置为 `false`），
直到你通过手动调整目标的期望副本个数或 HPA 的最小副本个数来重新激活。
+
+
+### 将 Deployment 和 StatefulSet 迁移到水平自动扩缩 {#migrating-deployments-and-statefulsets-to-horizontal-autoscaling}
+
+当启用 HPA 时，建议从它们的{{< glossary_tooltip text="清单" term_id="manifest" >}}中
+删除 Deployment 和/或 StatefulSet 的 `spec.replicas` 的值。
+如果不这样做，则只要应用对该对象的更改，例如通过 `kubectl apply -f deployment.yaml`，
+这将指示 Kubernetes 将当前 Pod 数量扩缩到 `spec.replicas` 键的值。这可能不是所希望的，
+并且当 HPA 处于活动状态时可能会很麻烦。
+
+
+请记住，删除 `spec.replicas` 可能会导致 Pod 计数一次性降级，因为此键的默认值为 1
+（参考 [Deployment Replicas](/zh/docs/concepts/workloads/controllers/deployment#replicas)）。
+更新后，除 1 之外的所有 Pod 都将开始其终止程序。之后的任何部署应用程序都将正常运行，
+并根据需要遵守滚动更新配置。你可以根据修改部署的方式选择以下两种方法之一来避免这种降级：
+
+{{< tabs name="fix_replicas_instructions" >}}
+{{% tab name="客户端 apply 操作（默认行为）" %}}
+
+
+1. `kubectl apply edit-last-applied deployment/`
+2. 在编辑器中，删除 `spec.replicas`。当你保存并退出编辑器时，`kubectl` 会应用更新。
+ 在此步骤中不会更改 Pod 计数。
+3. 你现在可以从清单中删除 `spec.replicas`。如果你使用源代码管理，
+ 还应提交你的更改或采取任何其他步骤来修改源代码，以适应你如何跟踪更新。
+4. 从这里开始，你可以运行 `kubectl apply -f deployment.yaml`
+
+{{% /tab %}}
+{{% tab name="服务器端 apply 操作" %}}
+
+
+使用[服务器端 Apply](/zh/docs/reference/using-api/server-side-apply/) 机制，
+你可以遵循[交出所有权](/zh/docs/reference/using-api/server-side-apply/#transferring-ownership) 说明，
+该指南涵盖了这个确切的用例。
+
+{{% /tab %}}
+{{< /tabs >}}
## {{% heading "whatsnext" %}}
-* 设计文档：[Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md)
-* `kubectl autoscale` 命令：[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
-* 使用示例：[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
+如果你在集群中配置自动扩缩，你可能还需要考虑运行集群级别的自动扩缩器，
+例如 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)。
+
+有关 HorizontalPodAutoscaler 的更多信息：
+
+
+* 阅读水平 Pod 自动扩缩的[演练示例](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)。
+* 阅读 [`kubectl autoscale`](/zh/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 的文档。
+* 如果你想编写自己的自定义指标适配器，
+ 请查看 [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) 以开始使用。
+* 阅读 [API 参考](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/)。
From 36be4cb47a2768c0a8f23a363458586f949ccadd Mon Sep 17 00:00:00 2001
From: howieyuen
Date: Mon, 18 Apr 2022 19:35:31 +0800
Subject: [PATCH 147/167] [zh] translate
zh/docs/reference/config-api/client-authentication.v1beta1
---
.../config-api/client-authentication.v1.md | 9 +-
.../client-authentication.v1beta1.md | 152 ++++++++++++++----
2 files changed, 124 insertions(+), 37 deletions(-)
diff --git a/content/zh/docs/reference/config-api/client-authentication.v1.md b/content/zh/docs/reference/config-api/client-authentication.v1.md
index e3b919b9c4..b1cf6a708b 100644
--- a/content/zh/docs/reference/config-api/client-authentication.v1.md
+++ b/content/zh/docs/reference/config-api/client-authentication.v1.md
@@ -76,6 +76,10 @@ of CertificateAuthority, since CA data will always be passed to the plugin as by
Cluster 中包含允许 exec 插件与 Kubernetes 集群进行通信身份认证时所需
的信息。
+为了确保该结构体包含需要与 Kubernetes 集群进行通信的所有内容（就像通过 Kubeconfig 一样），
+除了证书授权之外，该字段应该映射到 "k8s.io/client-go/tools/clientcmd/api/v1".cluster，
+由于 CA 数据将始终以字节形式传递给插件。
+
| 字段 | 描述 |
|---|
@@ -167,7 +171,7 @@ clusters:
只是针对不同集群会有一些细节上的差异，例如 audience。
此字段使得特定于集群的配置可以直接使用集群信息来设置。
不建议使用此字段来保存 Secret 数据，因为 exec 插件的主要优势之一是不需要在
- kubeconfig 中保存 Secret 数据。
+ kubeconfig 中保存 Secret 数据。
@@ -222,6 +226,7 @@ ExecCredentialSpec 保存传输组件所提供的特定于请求和运行时的
+**出现在：**
- [ExecCredential](#client-authentication-k8s-io-v1-ExecCredential)
@@ -235,7 +240,7 @@ itself should at least be protected via file permissions.
ExecCredentialStatus 中包含传输组件要使用的凭据。
字段 token 和 clientKeyData 都是敏感字段。此数据只能在
客户端与 exec 插件进程之间使用内存来传递。exec 插件本身至少
-应通过文件访问许可来实施保护。
》
+应通过文件访问许可来实施保护。
| 字段 | 描述 |
|---|
diff --git a/content/zh/docs/reference/config-api/client-authentication.v1beta1.md b/content/zh/docs/reference/config-api/client-authentication.v1beta1.md
index e78edd23f6..b683ed5736 100644
--- a/content/zh/docs/reference/config-api/client-authentication.v1beta1.md
+++ b/content/zh/docs/reference/config-api/client-authentication.v1beta1.md
@@ -1,12 +1,22 @@
---
-title: Client Authentication (v1beta1)
+title: 客户端身份认证（Client Authentication）(v1beta1)
content_type: tool-reference
package: client.authentication.k8s.io/v1beta1
auto_generated: true
---
+
+
+
+## 资源类型 {#resource-types}
- [ExecCredential](#client-authentication-k8s-io-v1beta1-ExecCredential)
@@ -20,11 +30,14 @@ auto_generated: true
+
+ExecCredential 由基于 exec 的插件使用，与 HTTP 传输组件沟通凭据信息。
-| Field | Description |
|---|
+| 字段 | 描述 |
|---|
apiVersion
string | client.authentication.k8s.io/v1beta1 |
@@ -33,11 +46,13 @@ HTTP transports.
-spec [Required]
+ |
spec [必需]
ExecCredentialSpec
|
- Spec holds information passed to the plugin by the transport. |
+
+ 字段 spec 包含由 HTTP 传输组件传递给插件的信息。
+
@@ -45,8 +60,10 @@ HTTP transports.
ExecCredentialStatus
- Status is filled in by the plugin and holds the credentials that the transport
-should use to contact the API. |
+
+ 字段 status 由插件填充，包含传输组件与 API 服务器连接时需要提供的凭据。
+
@@ -60,11 +77,13 @@ should use to contact the API.
-**Appears in:**
+
+**出现在：**
- [ExecCredentialSpec](#client-authentication-k8s-io-v1beta1-ExecCredentialSpec)
+
+Cluster 中包含允许 exec 插件与 Kubernetes 集群进行通信身份认证时所需
+的信息。
+
+为了确保该结构体包含需要与 Kubernetes 集群进行通信的所有内容（就像通过 Kubeconfig 一样），
+该字段应该映射到 "k8s.io/client-go/tools/clientcmd/api/v1".cluster，
+除了证书授权之外，由于 CA 数据将始终以字节形式传递给插件。
-| Field | Description |
|---|
+| 字段 | 描述 |
|---|
-server [Required]
+ |
server [必需]
string
|
- Server is the address of the kubernetes cluster (https://hostname:port). |
+
+ 字段 server 是 Kubernetes 集群的地址（https://hostname:port）。
+
@@ -91,9 +119,14 @@ of CertificateAuthority, since CA data will always be passed to the plugin as by
string
+
+ tls-server-name 是用来提供给服务器用作 SNI 解析的，客户端以此检查服务器的证书。
+ 如此字段为空，则使用链接服务器时使用的主机名。
+ |
@@ -101,8 +134,13 @@ used to contact the server is used.
bool
+
+ 设置此字段之后，会令客户端跳过对服务器端证书的合法性检查。
+ 这会使得你的 HTTPS 链接不再安全。
+ |
@@ -110,8 +148,13 @@ This will make your HTTPS connections insecure.
[]byte
+
+ 此字段包含 PEM 编码的证书机构（CA）证书。
+ 如果为空，则使用系统的根证书。
+ |
@@ -119,8 +162,9 @@ If empty, system roots should be used.
string
- ProxyURL is the URL to the proxy to be used for all requests to this
-cluster. |
+
+ 此字段用来设置向集群发送所有请求时要使用的代理服务器。
+
@@ -128,27 +172,40 @@ cluster.
k8s.io/apimachinery/pkg/runtime.RawExtension
+
+ 此字段包含一些额外的、特定于 exec 插件和所连接的集群的数据，
+ 此字段来自于 clientcmd 集群对象的 extensions[client.authentication.k8s.io/exec]
+ 字段：
+
clusters:
- name: my-cluster
cluster:
...
extensions:
- - name: client.authentication.k8s.io/exec # reserved extension name for per cluster exec config
+ - name: client.authentication.k8s.io/exec # 针对每个集群 exec 配置所预留的扩展名称
extension:
- audience: 06e3fbd18de8 # arbitrary config
-
+ audience: 06e3fbd18de8 # 任意配置信息
+
+
+在某些环境中，用户配置可能对很多集群而言都完全一样（即调用同一个 exec 插件），
+只是针对不同集群会有一些细节上的差异，例如 audience。
+此字段使得特定于集群的配置可以直接使用集群信息来设置。
+不建议使用此字段来保存 Secret 数据，因为 exec 插件的主要优势之一是不需要在
+kubeconfig 中保存 Secret 数据。
+ |
@@ -162,16 +219,20 @@ to be stored directly in the kubeconfig.
-**Appears in:**
+
+**出现在：**
- [ExecCredential](#client-authentication-k8s-io-v1beta1-ExecCredential)
+
+ExecCredentialSpec 保存传输组件所提供的特定于请求和运行时的信息。
-| Field | Description |
|---|
+| 字段 | 描述 |
|---|
@@ -180,10 +241,16 @@ the transport.
Cluster
+
+ 此字段中包含的信息使得 exec 插件能够与要访问的 Kubernetes 集群通信。
+ 注意，cluster 字段只有在 exec 驱动的配置中 provideClusterInfo
+ （即：ExecConfig.ProvideClusterInfo）被设置为 true 时才不能为空。
+ |
@@ -197,20 +264,27 @@ ExecConfig.ProvideClusterInfo).
-**Appears in:**
+
+**出现在：**
- [ExecCredential](#client-authentication-k8s-io-v1beta1-ExecCredential)
+
+ExecCredentialStatus 中包含传输组件要使用的凭据。
+
+字段 token 和 clientKeyData 都是敏感字段。
+此数据只能在客户端与 exec 插件进程之间使用内存来传递。
+exec 插件本身至少应通过文件访问许可来实施保护。
-| Field | Description |
|---|
-
+| 字段 | 描述 |
|---|
@@ -218,31 +292,39 @@ itself should at least be protected via file permissions.
meta/v1.Time
- ExpirationTimestamp indicates a time when the provided credentials expire. |
+
+ 给出所提供的凭据到期的时间。
+
-token [Required]
+ |
token [必需]
string
|
- Token is a bearer token used by the client for request authentication. |
+
+ 客户端用做请求身份认证的持有者令牌。
+
-clientCertificateData [Required]
+ |
clientCertificateData [必需]
string
|
- PEM-encoded client TLS certificates (including intermediates, if any). |
+
+ PEM 编码的客户端 TLS 证书（如果有临时证书，也会包含）。
+
-clientKeyData [Required]
+ |
clientKeyData [必需]
string
|
- PEM-encoded private key for the above certificate. |
+
+ 与上述证书对应的、PEM 编码的私钥。
+
From aa0ca9fe41c5917a074aae66e13f53547f6b2a4d Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Mon, 18 Apr 2022 20:45:35 +0800
Subject: [PATCH 148/167] [zh] Update dual-stack-support.md
Signed-off-by: xin.li
---
.../tools/kubeadm/dual-stack-support.md | 23 +++++++++++--------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md b/content/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md
index 38ec9a1dd7..987b392fee 100644
--- a/content/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md
+++ b/content/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md
@@ -81,10 +81,12 @@ kubeadm init --pod-network-cidr=10.244.0.0/16,2001:db8:42:0::/56 --service-cidr=
```
为了更便于理解，参看下面的名为 `kubeadm-config.yaml` 的 kubeadm
-[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)，
+[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)，
该文件用于双协议栈控制面的主控制节点。
```yaml
@@ -138,14 +140,15 @@ The `--apiserver-advertise-address` flag does not support dual-stack.
Before joining a node, make sure that the node has IPv6 routable network interface and allows IPv6 forwarding.
-Here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for joining a worker node to the cluster.
+Here is an example kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/)
+`kubeadm-config.yaml` for joining a worker node to the cluster.
-->
### 向双协议栈集群添加节点 {#join-a-node-to-dual-stack-cluster}
在添加节点之前，请确保该节点具有 IPv6 可路由的网络接口并且启用了 IPv6 转发。
下面的名为 `kubeadm-config.yaml` 的 kubeadm
-[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)
+[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)
示例用于向集群中添加工作节点。
```yaml
@@ -164,10 +167,11 @@ nodeRegistration:
```
下面的名为 `kubeadm-config.yaml` 的 kubeadm
-[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)
+[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)
示例用于向集群中添加另一个控制面节点。
```yaml
@@ -215,13 +219,14 @@ You can deploy a single-stack cluster that has the dual-stack networking feature
{{< /note >}}
为了更便于理解，参看下面的名为 `kubeadm-config.yaml` 的 kubeadm
-[配置文件](/docs/reference/config-api/kubeadm-config.v1beta3/)示例，
+[配置文件](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)示例，
该文件用于单协议栈控制面节点。
-
```yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
From 3a1ecd2138126335ea6d83d002f15d51b9999970 Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Mon, 18 Apr 2022 20:58:30 +0800
Subject: [PATCH 149/167] [zh] Update declare-network-policy.md
Signed-off-by: xin.li
---
.../docs/tasks/administer-cluster/declare-network-policy.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md
index 3d682a4cb8..b5858ba2fc 100644
--- a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md
@@ -108,7 +108,7 @@ You should be able to access the new `nginx` service from other Pods. To access
要从 default 命名空间中的其它s Pod 来访问该服务。可以启动一个 busybox 容器：
```shell
-kubectl run busybox --rm -ti --image=busybox /bin/sh
+kubectl run busybox --rm -ti --image=busybox:1.28 /bin/sh
```
@@ -273,7 +273,7 @@ already be running.
You can view running containers (including static Pods) by running (on the node):
```shell
# Run this command on the node where kubelet is running
-docker ps
+crictl ps
```
The output might be something like:
@@ -287,7 +287,7 @@ The output might be something like:
```shell
# 在 kubelet 运行的节点上执行以下命令
-docker ps
+crictl ps
```
输出可能会像这样：
+```console
+CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
+129fd7d382018 docker.io/library/nginx@sha256:... 11 minutes ago Running web 0 34533c6729106
```
-CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
-f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
-```
+
+
+{{< note >}}
+`crictl` 会输出镜像 URI 和 SHA-256 校验和。 `NAME` 看起来像：
+`docker.io/library/nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31`。
+{{< /note >}}
{{< note >}}
要确保 kubelet 在 API 服务上有创建镜像 Pod 的权限。如果没有，创建请求会被 API 服务拒绝。
-可以看[Pod安全策略](/zh/docs/concepts/policy/pod-security-policy/)。
+可以看 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)和 [Pod 安全策略](/zh/docs/concepts/security/pod-security-policy/)。
{{< /note >}}
-回到 kubelet 运行的节点上，可以手工停止 Docker 容器。
+回到 kubelet 运行的节点上，你可以手动停止容器。
可以看到过了一段时间后 kubelet 会发现容器停止了并且会自动重启 Pod：
```shell
# 在 kubelet 运行的节点上执行以下命令
# 把 ID 换为你的容器的 ID
-docker stop f6d05272b57e
+crictl stop 129fd7d382018
sleep 20
-docker ps
+crictl ps
```
-```
-CONTAINER ID IMAGE COMMAND CREATED ...
-5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
+```console
+CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
+89db4553e1eeb docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106
```
## 动态增加和删除静态 pod
@@ -415,16 +423,17 @@ docker ps
# 在 kubelet 运行的节点上执行以下命令
mv /etc/kubelet.d/static-web.yaml /tmp
sleep 20
-docker ps
+crictl ps
# 可以看到没有 nginx 容器在运行
mv /tmp/static-web.yaml /etc/kubelet.d/
sleep 20
-docker ps
+crictl ps
```
-```
-CONTAINER ID IMAGE COMMAND CREATED ...
-e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
+```console
+CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
+f427638871c35 docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106
```
+
From 291e7ab8733a3e1bc9db532b3fd17f3836a3339f Mon Sep 17 00:00:00 2001
From: HirazawaUi <695097494plus@gmail.com>
Date: Fri, 15 Apr 2022 16:57:18 +0800
Subject: [PATCH 151/167] Update scheduling/config.md
---
.../zh/docs/reference/scheduling/config.md | 615 +++++++++++++-----
1 file changed, 460 insertions(+), 155 deletions(-)
diff --git a/content/zh/docs/reference/scheduling/config.md b/content/zh/docs/reference/scheduling/config.md
index 99c9557e57..93a45419a0 100644
--- a/content/zh/docs/reference/scheduling/config.md
+++ b/content/zh/docs/reference/scheduling/config.md
@@ -22,7 +22,7 @@ file and passing its path as a command line argument.
调度模板（Profile）允许你配置 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
@@ -31,17 +31,19 @@ by implementing one or more of these extension points.
你可以通过运行 `kube-scheduler --config ` 来设置调度模板，
-使用 [KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 结构体。
+使用 KubeSchedulerConfiguration （[v1beta2](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/)
+或者 [v1beta3](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/)） 结构体。
最简单的配置如下：
```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
clientConnection:
kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
@@ -77,62 +79,74 @@ extension points:
调度行为发生在一系列阶段中，这些阶段是通过以下扩展点公开的：
-1. `QueueSort`：这些插件对调度队列中的悬决的 Pod 排序。
+1. `queueSort`：这些插件对调度队列中的悬决的 Pod 排序。
一次只能启用一个队列排序插件。
-2. `PreFilter`：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。
+2. `preFilter`：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。
它们可以将 Pod 标记为不可调度。
-3. `Filter`：这些插件相当于调度策略中的断言（Predicates），用于过滤不能运行 Pod 的节点。
+3. `filter`：这些插件相当于调度策略中的断言（Predicates），用于过滤不能运行 Pod 的节点。
过滤器的调用顺序是可配置的。
如果没有一个节点通过所有过滤器的筛选，Pod 将会被标记为不可调度。
+4. `postFilter`：当无法为 Pod 找到可用节点时，按照这些插件的配置顺序调用他们。
+ 如果任何 `postFilter` 插件将 Pod 标记为“可调度”，则不会调用其余插件。
+
-4. `PreScore`：这是一个信息扩展点，可用于预打分工作。
+5. `preScore`：这是一个信息扩展点，可用于预打分工作。
-5. `Score`：这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。
+6. `score`：这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。
-6. `Reserve`：这是一个信息扩展点，当资源已经预留给 Pod 时，会通知插件。
+7. `reserve`：这是一个信息扩展点，当资源已经预留给 Pod 时，会通知插件。
这些插件还实现了 `Unreserve` 接口，在 `Reserve` 期间或之后出现故障时调用。
-
-7. `Permit`：这些插件可以阻止或延迟 Pod 绑定。
-
-8. `PreBind`：这些插件在 Pod 绑定节点之前执行。
+
+8. `permit`：这些插件可以阻止或延迟 Pod 绑定。
+
+9. `preBind`：这些插件在 Pod 绑定节点之前执行。
-9. `Bind`：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。
+10. `bind`：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。
-10. `PostBind`：这是一个信息扩展点，在 Pod 绑定了节点之后调用。
+11. `postBind`：这是一个信息扩展点，在 Pod 绑定了节点之后调用。
+
+12. `multiPoint`：这是一个仅配置字段，允许同时为所有适用的扩展点启用或禁用插件。
-### 调度插件 {#scheduling-plugin}
-
-
-1. `UnReserve`：这是一个信息扩展点，如果一个 Pod 在预留后被拒绝，并且被 `Permit` 插件搁置，它就会被调用。
-
-
-## 调度插件 {#scheduling-plugins}
+### 调度插件 {#scheduling-plugins}
下面默认启用的插件实现了一个或多个扩展点：
-
-- `SelectorSpread`：对于属于 {{< glossary_tooltip text="Services" term_id="service" >}}、
- {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 和
- {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 的 Pod，偏好跨多个节点部署。
-
- 实现的扩展点：`PreScore`，`Score`。
- `ImageLocality`：选择已经存在 Pod 运行所需容器镜像的节点。
- 实现的扩展点：`Score`。
+ 实现的扩展点：`score`。
- `TaintToleration`：实现了[污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
- 实现的扩展点：`Filter`，`Prescore`，`Score`。
+ 实现的扩展点：`filter`，`prescore`，`score`。
- `NodeName`：检查 Pod 指定的节点名称与当前节点是否匹配。
- 实现的扩展点：`Filter`。
+ 实现的扩展点：`filter`。
- `NodePorts`：检查 Pod 请求的端口在节点上是否可用。
- 实现的扩展点：`PreFilter`，`Filter`。
-
-- `NodePreferAvoidPods`：基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}}
- `scheduler.alpha.kubernetes.io/preferAvoidPods` 打分。
+ 实现的扩展点：`preFilter`，`filter`。
- 实现的扩展点：`Score`。
- `NodeAffinity`：实现了[节点选择器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
和[节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)。
- 实现的扩展点：`Filter`，`Score`.
+ 实现的扩展点：`filter`，`score`.
- `PodTopologySpread`：实现了 [Pod 拓扑分布](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
- 实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。
+ 实现的扩展点：`preFilter`，`filter`，`preScore`，`score`。
- `NodeUnschedulable`：过滤 `.spec.unschedulable` 值为 true 的节点。
- 实现的扩展点：`Filter`。
+ 实现的扩展点：`filter`。
- `NodeResourcesFit`：检查节点是否拥有 Pod 请求的所有资源。
+ 得分可以使用以下三种策略之一：`LeastAllocated`（默认）、`MostAllocated`
+ 和`RequestedToCapacityRatio`。
- 实现的扩展点：`PreFilter`，`Filter`。
+ 实现的扩展点：`preFilter`，`filter`，`score`。
- `NodeResourcesBalancedAllocation`：调度 Pod 时，选择资源使用更为均衡的节点。
- 实现的扩展点：`Score`。
-
-- `NodeResourcesLeastAllocated`：选择资源分配较少的节点。
+ 实现的扩展点：`score`。
- 实现的扩展点：`Score`。
- `VolumeBinding`：检查节点是否有请求的卷，或是否可以绑定请求的卷。
- 实现的扩展点: `PreFilter`、`Filter`、`Reserve`、`PreBind` 和 `Score`。
+ 实现的扩展点: `preFilter`、`filter`、`reserve`、`preBind` 和 `score`。
{{< note >}}
- 当 `VolumeCapacityPriority` 特性被启用时，`Score` 扩展点也被启用。
+ 当 `VolumeCapacityPriority` 特性被启用时，`score` 扩展点也被启用。
它优先考虑可以满足所需卷大小的最小 PV。
{{< /note >}}
- `VolumeRestrictions`：检查挂载到节点上的卷是否满足卷提供程序的限制。
- 实现的扩展点：`Filter`。
+ 实现的扩展点：`filter`。
- `VolumeZone`：检查请求的卷是否在任何区域都满足。
- 实现的扩展点：`Filter`。
+ 实现的扩展点：`filter`。
- `NodeVolumeLimits`：检查该节点是否满足 CSI 卷限制。
- 实现的扩展点：`Filter`。
+ 实现的扩展点：`filter`。
- `EBSLimits`：检查节点是否满足 AWS EBS 卷限制。
- 实现的扩展点：`Filter`。
+ 实现的扩展点：`filter`。
- `GCEPDLimits`：检查该节点是否满足 GCP-PD 卷限制。
- 实现的扩展点：`Filter`。
+ 实现的扩展点：`filter`。
- `AzureDiskLimits`：检查该节点是否满足 Azure 卷限制。
- 实现的扩展点：`Filter`。
+ 实现的扩展点：`filter`。
- `InterPodAffinity`：实现 [Pod 间亲和性与反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)。
- 实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。
+ 实现的扩展点：`preFilter`，`filter`，`preScore`，`score`。
- `PrioritySort`：提供默认的基于优先级的排序。
- 实现的扩展点：`QueueSort`。
+ 实现的扩展点：`queueSort`。
- `DefaultBinder`：提供默认的绑定机制。
- 实现的扩展点：`Bind`。
+ 实现的扩展点：`bind`。
- `DefaultPreemption`：提供默认的抢占机制。
- 实现的扩展点：`PostFilter`。
+ 实现的扩展点：`postFilter`。
你也可以通过组件配置 API 启用以下插件（默认不启用）:
-
-- `NodeResourcesMostAllocated`：选择已分配资源多的节点。
+- `SelectorSpread`：偏向把属于
+ {{< glossary_tooltip text="Services" term_id="service" >}}，
+ {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 和
+ {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 的 Pod 跨节点分布。
- 实现的扩展点：`Score`。
-
-- `RequestedToCapacityRatio`：根据已分配资源的某函数设置选择节点。
+-`CinderLimits`：检查是否可以满足节点的 [OpenStack Cinder](https://docs.openstack.org/cinder/)
+卷限制
- 实现的扩展点：`Score`。
-
-- `CinderVolume`：检查该节点是否满足 OpenStack Cinder 卷限制。
- 实现的扩展点：`Filter`。
-
-- `NodeLabel`：根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}}
- 过滤节点和/或给节点打分。
-
- 实现的扩展点：`Filter`，`Score`。
-
-- `ServiceAffinity`：检查属于某个 {{< glossary_tooltip term_id="service" >}} 的 Pod
- 与配置的标签所定义的节点集是否适配。
- 这个插件还支持将属于某个 Service 的 Pod 分散到各个节点。
-
- 实现的扩展点：`PreFilter`，`Filter`，`Score`。
-
-
### 多配置文件 {#multiple-profiles}
-所有配置文件必须在 QueueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。
+所有配置文件必须在 queueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。
这是因为调度器只有一个保存 pending 状态 Pod 的队列。
{{< /note >}}
+
+
+### 应用于多个扩展点的插件 {#multipoint}
+
+
+从 `kubescheduler.config.k8s.io/v1beta3` 开始，配置文件配置中有一个附加字段 `multiPoint`，它允许跨多个扩展点轻松启用或禁用插件。
+`multiPoint` 配置的目的是简化用户和管理员在使用自定义配置文件时所需的配置。
+
+
+
+考虑一个插件，`MyPlugin`，它实现了 `preScore`、`score`、`preFilter` 和 `filter` 扩展点。
+要为其所有可用的扩展点启用 `MyPlugin`，配置文件配置如下所示：
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: multipoint-scheduler
+ plugins:
+ multiPoint:
+ enabled:
+ - name: MyPlugin
+```
+
+
+
+这相当于为所有扩展点手动启用`MyPlugin`，如下所示：
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: non-multipoint-scheduler
+ plugins:
+ preScore:
+ enabled:
+ - name: MyPlugin
+ score:
+ enabled:
+ - name: MyPlugin
+ preFilter:
+ enabled:
+ - name: MyPlugin
+ filter:
+ enabled:
+ - name: MyPlugin
+```
+
+
+
+在这里使用 `multiPoint` 的一个好处是，如果 `MyPlugin` 将来实现另一个扩展点，`multiPoint` 配置将自动为新扩展启用它。
+
+
+
+可以使用该扩展点的 `disabled` 字段将特定扩展点从 `MultiPoint` 扩展中排除。
+这适用于禁用默认插件、非默认插件或使用通配符 (`'*'`) 来禁用所有插件。
+禁用 `Score` 和 `PreScore` 的一个例子是：
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: non-multipoint-scheduler
+ plugins:
+ multiPoint:
+ enabled:
+ - name: 'MyPlugin'
+ preScore:
+ disabled:
+ - name: '*'
+ score:
+ disabled:
+ - name: '*'
+```
+
+
+
+在 `v1beta3` 中，所有 [默认插件](#scheduling-plugins) 都通过 `MultiPoint` 在内部启用。
+但是，仍然可以使用单独的扩展点来灵活地重新配置默认值（例如排序和分数权重）。
+例如，考虑两个Score插件 `DefaultScore1` 和 `DefaultScore2` ，每个插件的权重为 `1` 。
+它们可以用不同的权重重新排序，如下所示：
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: multipoint-scheduler
+ plugins:
+ score:
+ enabled:
+ - name: 'DefaultScore2'
+ weight: 5
+```
+
+
+
+在这个例子中，没有必要在 `MultiPoint` 中明确指定插件，因为它们是默认插件。
+`Score` 中指定的唯一插件是 `DefaultScore2`。
+这是因为通过特定扩展点设置的插件将始终优先于 `MultiPoint` 插件。
+因此，此代码段实质上重新排序了这两个插件，而无需同时指定它们。
+
+
+
+配置 `MultiPoint` 插件时优先级的一般层次结构如下：
+
+
+1. 特定的扩展点首先运行，它们的设置会覆盖其他地方的设置
+
+
+2. 通过 `MultiPoint` 手动配置的插件及其设置
+
+
+3. 默认插件及其默认设置
+
+
+为了演示上述层次结构，以下示例基于这些插件：
+|插件|扩展点|
+|---|---|
+|`DefaultQueueSort`|`QueueSort`|
+|`CustomQueueSort`|`QueueSort`|
+|`DefaultPlugin1`|`Score`, `Filter`|
+|`DefaultPlugin2`|`Score`|
+|`CustomPlugin1`|`Score`, `Filter`|
+|`CustomPlugin2`|`Score`, `Filter`|
+
+
+这些插件的一个有效示例配置是：
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: multipoint-scheduler
+ plugins:
+ multiPoint:
+ enabled:
+ - name: 'CustomQueueSort'
+ - name: 'CustomPlugin1'
+ weight: 3
+ - name: 'CustomPlugin2'
+ disabled:
+ - name: 'DefaultQueueSort'
+ filter:
+ disabled:
+ - name: 'DefaultPlugin1'
+ score:
+ enabled:
+ - name: 'DefaultPlugin2'
+```
+
+
+请注意，在特定扩展点中重新声明 `MultiPoint` 插件不会出错。
+重新声明被忽略（并记录），因为特定的扩展点优先。
+
+
+
+除了将大部分配置保存在一个位置之外，此示例还做了一些事情：
+
+
+* 启用自定义 `queueSort` 插件并禁用默认插件
+
+* 启用 `CustomPlugin1` 和 `CustomPlugin2`，这将首先为它们的所有扩展点运行
+
+* 禁用 `DefaultPlugin1`，但仅适用于 `filter`
+
+* 重新排序 `DefaultPlugin2` 以在 `score` 中首先运行（甚至在自定义插件之前）
+
+
+在 `v1beta3` 之前的配置版本中，没有 `multiPoint`，上面的代码片段等同于：
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta2
+kind: KubeSchedulerConfiguration
+profiles:
+ - schedulerName: multipoint-scheduler
+ plugins:
+
+ # Disable the default QueueSort plugin
+ queueSort:
+ enabled:
+ - name: 'CustomQueueSort'
+ disabled:
+ - name: 'DefaultQueueSort'
+
+ # Enable custom Filter plugins
+ filter:
+ enabled:
+ - name: 'CustomPlugin1'
+ - name: 'CustomPlugin2'
+ - name: 'DefaultPlugin2'
+ disabled:
+ - name: 'DefaultPlugin1'
+
+ # Enable and reorder custom score plugins
+ score:
+ enabled:
+ - name: 'DefaultPlugin2'
+ weight: 1
+ - name: 'DefaultPlugin1'
+ weight: 3
+```
+
+
+
+虽然这是一个复杂的例子，但它展示了 `MultiPoint` 配置的灵活性以及它与配置扩展点的现有方法的无缝集成。
+
+
+
+## 调度程序配置迁移
+{{< tabs name="tab_with_md" >}}
+{{% tab name="v1beta1 → v1beta2" %}}
+
+* 在 v1beta2 配置版本中，你可以为 `NodeResourcesFit` 插件使用新的 score 扩展。
+ 新的扩展结合了 `NodeResourcesLeastAllocated`、`NodeResourcesMostAllocated` 和 `RequestedToCapacityRatio` 插件的功能。
+ 例如，如果你之前使用了 `NodeResourcesMostAllocated` 插件，
+ 则可以改用 `NodeResourcesFit`（默认启用）并添加一个 `pluginConfig` 和 `scoreStrategy`，类似于：
+
+ ```yaml
+ apiVersion: kubescheduler.config.k8s.io/v1beta2
+ kind: KubeSchedulerConfiguration
+ profiles:
+ - pluginConfig:
+ - args:
+ scoringStrategy:
+ resources:
+ - name: cpu
+ weight: 1
+ type: MostAllocated
+ name: NodeResourcesFit
+ ```
+
+
+* 调度器插件 `NodeLabel` 已弃用；
+ 相反，要使用 [`NodeAffinity`](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
+ 插件（默认启用）来实现类似的行为。
+
+
+* 调度程序插件 `ServiceAffinity` 已弃用；
+ 相反，使用 [`InterPodAffinity`](/zh/doc/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
+ 插件（默认启用）来实现类似的行为。
+
+
+* 调度器插件 `NodePreferAvoidPods` 已弃用；
+ 相反，使用 [节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) 来实现类似的行为。
+
+
+* 在 v1beta2 配置文件中启用的插件优先于该插件的默认配置。
+
+
+* 调度器的健康检查和审计的绑定地址，所配置的 `host` 或 `port` 无效将导致验证失败。
+
+{{% /tab %}}
+
+{{% tab name="v1beta2 → v1beta3" %}}
+
+* 默认增加三个插件的权重：
+ * `InterPodAffinity` 从 1 到 2
+ * `NodeAffinity` 从 1 到 2
+ * `TaintToleration` 从 1 到 3
+{{% /tab %}}
+{{< /tabs >}}
+
## {{% heading "whatsnext" %}}
* 阅读 [kube-scheduler 参考](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
* 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
-* 阅读 [kube-scheduler 配置 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) 参考
-
+* 阅读 [kube-scheduler 配置 (v1beta2)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/) 参考
+* 阅读 [kube-scheduler 配置 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) 参考
From 6f0de11cc38a76bf6675c903c8b47f3e256ecf9f Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Mon, 18 Apr 2022 23:25:13 +0800
Subject: [PATCH 152/167] [zh] Update debug-pod-replication-controller.md
Signed-off-by: xin.li
---
.../determine-reason-pod-failure.md | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
index 19f29d781b..db2bdae03c 100644
--- a/content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+++ b/content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
@@ -99,6 +99,15 @@ the container starts.
```shell
kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
```
+
+
+如果你正在运行多容器 Pod，则可以使用 Go 模板来包含容器的名称。这样，你可以发现哪些容器出现故障:
+
+```shell
+kubectl get pod multi-container-pod -o go-template='{{range .status.containerStatuses}}{{printf "%s:\n%s\n\n" .name .lastState.terminated.message}}{{end}}'
+```
+{{% dockershim-removal %}}
+
You need to install a
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
into each node in the cluster so that Pods can run there. This page outlines
diff --git a/data/i18n/en/en.toml b/data/i18n/en/en.toml
index 1cf54e6a09..e6eb0feced 100644
--- a/data/i18n/en/en.toml
+++ b/data/i18n/en/en.toml
@@ -36,6 +36,9 @@ other = " documentation is no longer actively maintained. The version you are cu
[deprecation_file_warning]
other = "Deprecated"
+[dockershim_message]
+other = """The dockershim code required to run Docker Engine has been removed from the Kubernetes project as of release 1.24. Read the Dockershim Removal FAQ for further details."""
+
[docs_label_browse]
other = "Browse Docs"
diff --git a/layouts/shortcodes/dockershim-removal.html b/layouts/shortcodes/dockershim-removal.html
new file mode 100644
index 0000000000..6ccd07f35e
--- /dev/null
+++ b/layouts/shortcodes/dockershim-removal.html
@@ -0,0 +1,3 @@
+
+ {{ T "note" | safeHTML }} {{ T "dockershim_message" | safeHTML }}
+
From 98d8be323f2c26d542dd872b13f6d05375537146 Mon Sep 17 00:00:00 2001
From: Vitthal Sai
Date: Mon, 18 Apr 2022 23:19:58 +0530
Subject: [PATCH 156/167] Reword dockershim migration recommendation
---
.../administer-cluster/migrating-from-dockershim/_index.md | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md
index 3631722a62..0c3f33bf5d 100644
--- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md
+++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md
@@ -17,8 +17,9 @@ to understand the problem better.
-If you use Docker via dockershim as your container runtime, the Kubernetes project
-recommends that you migrate to an alternative container runtime.
+Dockershim will be removed from Kubernetes following the release of v1.24.
+If you use Docker via dockershim as your container runtime, and wish to upgrade to v1.24,
+it is recommended that you either migrate to another runtime or find an alternative means to obtain Docker Engine support.
If you're not sure whether you are using Docker,
[find out what container runtime is used on a node](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/).
From ee36e095d921ef3aff7373478f7610d7a6ce3d1d Mon Sep 17 00:00:00 2001
From: Christopher Negus
Date: Mon, 18 Apr 2022 22:58:03 +0000
Subject: [PATCH 157/167] Reworded dockershim message
---
data/i18n/en/en.toml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/data/i18n/en/en.toml b/data/i18n/en/en.toml
index e6eb0feced..6c57982f9b 100644
--- a/data/i18n/en/en.toml
+++ b/data/i18n/en/en.toml
@@ -37,7 +37,7 @@ other = " documentation is no longer actively maintained. The version you are cu
other = "Deprecated"
[dockershim_message]
-other = """The dockershim code required to run Docker Engine has been removed from the Kubernetes project as of release 1.24. Read the Dockershim Removal FAQ for further details."""
+other = """Dockershim has been removed from the Kubernetes project as of release 1.24. Read the Dockershim Removal FAQ for further details."""
[docs_label_browse]
other = "Browse Docs"
From ebc817852f8138850a0a01edf910fecd885ad808 Mon Sep 17 00:00:00 2001
From: Christopher Negus
Date: Thu, 14 Apr 2022 22:02:34 +0000
Subject: [PATCH 158/167] Add dockershim shortcode to other files
---
.../production-environment/tools/kubeadm/install-kubeadm.md | 2 +-
.../tools/kubeadm/kubelet-integration.md | 2 ++
.../tasks/administer-cluster/kubeadm/adding-windows-nodes.md | 3 +--
content/en/docs/tasks/network/customize-hosts-file-for-pods.md | 3 +++
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index 917c384766..b7c0fd46ca 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -14,7 +14,7 @@ card:
This page shows how to install the `kubeadm` toolbox.
For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
-
+{{% dockershim-removal %}}
## {{% heading "prerequisites" %}}
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
index 4625299919..1da01fecce 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
@@ -10,6 +10,8 @@ weight: 80
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
+{{% dockershim-removal %}}
+
The lifecycle of the kubeadm CLI tool is decoupled from the
[kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs
on each node within the Kubernetes cluster. The kubeadm CLI tool is executed by the user when Kubernetes is
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index e48550e40b..a5739616bd 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -16,8 +16,7 @@ weight: 30
You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can mix Pods that run on Linux on with Pods that run on Windows. This page shows how to register Windows nodes to your cluster.
-
-
+{{% dockershim-removal %}}
## {{% heading "prerequisites" %}}
{{< version-check >}}
diff --git a/content/en/docs/tasks/network/customize-hosts-file-for-pods.md b/content/en/docs/tasks/network/customize-hosts-file-for-pods.md
index 7eba61fbea..3ed2b0ed6a 100644
--- a/content/en/docs/tasks/network/customize-hosts-file-for-pods.md
+++ b/content/en/docs/tasks/network/customize-hosts-file-for-pods.md
@@ -11,6 +11,9 @@ min-kubernetes-server-version: 1.7
+{{% dockershim-removal %}}
+
+
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.
From fcdf66a1fdbda6c236848a94e8b2dc2c300a9d02 Mon Sep 17 00:00:00 2001
From: Christopher Negus
Date: Mon, 18 Apr 2022 23:32:41 +0000
Subject: [PATCH 159/167] Deleted a blank line
---
.../en/docs/setup/production-environment/container-runtimes.md | 1 -
1 file changed, 1 deletion(-)
diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md
index a75964f477..8c5e744502 100644
--- a/content/en/docs/setup/production-environment/container-runtimes.md
+++ b/content/en/docs/setup/production-environment/container-runtimes.md
@@ -15,7 +15,6 @@ You need to install a
into each node in the cluster so that Pods can run there. This page outlines
what is involved and describes related tasks for setting up nodes.
-
Kubernetes {{< skew currentVersion >}} requires that you use a runtime that
conforms with the
{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI).
From 0a667fcc2d493599fe36d56fd1c47d32e652cb96 Mon Sep 17 00:00:00 2001
From: howieyuen
Date: Mon, 18 Apr 2022 20:55:04 +0800
Subject: [PATCH 160/167] [zh]Sync
content/zh/docs/concepts/containers/images.md
---
content/zh/docs/concepts/containers/images.md | 185 ++----------------
1 file changed, 18 insertions(+), 167 deletions(-)
diff --git a/content/zh/docs/concepts/containers/images.md b/content/zh/docs/concepts/containers/images.md
index b782d01833..12c48ef463 100644
--- a/content/zh/docs/concepts/containers/images.md
+++ b/content/zh/docs/concepts/containers/images.md
@@ -45,8 +45,7 @@ and possibly a port number as well; for example: `fictional.registry.example:104
If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry.
-After the image name part you can add a _tag_ (as also using with commands such
-as `docker` and `podman`).
+After the image name part you can add a _tag_ (in the same way you would when using with commands like `docker` or `podman`).
Tags let you identify different versions of the same series of images.
-->
## 镜像名称 {#image-names}
@@ -57,8 +56,7 @@ Tags let you identify different versions of the same series of images.
如果你不指定仓库的主机名，Kubernetes 认为你在使用 Docker 公共仓库。
-在镜像名称之后，你可以添加一个 _标签（Tag）_ （就像在 `docker` 或 `podman`
-中也在用的那样）。
+在镜像名称之后，你可以添加一个标签（Tag）（与使用 `docker` 或 `podman` 等命令时的方式相同）。
使用标签能让你辨识同一镜像序列中的不同版本。
当使用镜像标签时，如果镜像仓库修改了代码所对应的镜像标签，可能会出现新旧代码混杂在 Pod 中运行的情况。
镜像摘要唯一标识了镜像的特定版本，因此 Kubernetes 每次启动具有指定镜像名称和摘要的容器时，都会运行相同的代码。
-指定一个镜像可以固定你所运行的代码，这样镜像仓库的变化就不会导致版本的混杂。
+通过摘要指定镜像可固定你运行的代码，这样镜像仓库的变化就不会导致版本的混杂。
有一些第三方的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
在创建 Pod（和 Pod 模板）时产生变更，这样运行的工作负载就是根据镜像摘要，而不是标签来定义的。
@@ -346,17 +344,12 @@ These options are explained in more detail below.
### 配置 Node 对私有仓库认证
-如果你在节点上运行的是 Docker，你可以配置 Docker
-容器运行时来向私有容器仓库认证身份。
-
-此方法适用于能够对节点进行配置的场合。
+设置凭据的具体说明取决于你选择使用的容器运行时和仓库。
+你应该参考解决方案的文档来获取最准确的信息。
-Docker 将私有仓库的密钥保存在 `$HOME/.dockercfg` 或 `$HOME/.docker/config.json`
-文件中。如果你将相同的文件放在下面所列的搜索路径中，`kubelet` 会在拉取镜像时将其用作凭据
-数据来源：
-
-
-* `{--root-dir:-/var/lib/kubelet}/config.json`
-* `{kubelet 当前工作目录}/config.json`
-* `${HOME}/.docker/config.json`
-* `/.docker/config.json`
-* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
-* `{kubelet 当前工作目录}/.dockercfg`
-* `${HOME}/.dockercfg`
-* `/.dockercfg`
-
-
-{{< note >}}
-你可能不得不为 `kubelet` 进程显式地设置 `HOME=/root` 环境变量。
-{{< /note >}}
-
-
-推荐采用如下步骤来配置节点以便访问私有仓库。以下示例中，在 PC 或笔记本电脑中操作：
-
-
-1. 针对你要使用的每组凭据，运行 `docker login [服务器]` 命令。这会更新
- 你本地环境中的 `$HOME/.docker/config.json` 文件。
-1. 在编辑器中打开查看 `$HOME/.docker/config.json` 文件，确保其中仅包含你要
- 使用的凭据信息。
-1. 获得节点列表；例如：
-
- - 如果想要节点名称：`nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
-
- - 如果想要节点 IP ，`nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
-
-1. 将本地的 `.docker/config.json` 拷贝到所有节点，放入如上所列的目录之一：
- - 例如，可以试一下：`for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
-
-
-{{< note >}}
-对于产品环境的集群，可以使用配置管理工具来将这些设置应用到
-你所期望的节点上。
-{{< /note >}}
-
-
-创建使用私有镜像的 Pod 来验证。例如：
-
-```shell
-kubectl apply -f - <
-如果一切顺利，那么一段时间后你可以执行：
-```shell
-kubectl logs private-image-test-1
-```
-然后可以看到命令的输出：
-```
-SUCCESS
-```
-
-
-如果你怀疑命令失败了，你可以运行：
-
-```shell
-kubectl describe pods/private-image-test-1 | grep 'Failed'
-```
-
-
-如果命令确实失败，输出类似于：
-
-```
- Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
-```
-
-
-你必须确保集群中所有节点的 `.docker/config.json` 文件内容相同。
-否则，Pod 会能在一些节点上正常运行而无法在另一些节点上启动。
-例如，如果使用节点自动扩缩，那么每个实例模板都需要包含 `.docker/config.json`，
-或者挂载一个包含该文件的驱动器。
-
-在 `.docker/config.json` 中配置了私有仓库密钥后，所有 Pod 都将能读取私有仓库中的镜像。
+有关配置私有容器镜像仓库的示例，请参阅任务
+[从私有镜像库中提取图像](/zh/docs/tasks/configure-pod-container/pull-image-private-registry)。
+该示例使用 Docker Hub 中的私有注册表。
#### 使用 Docker Config 创建 Secret {#creating-a-secret-with-docker-config}
-运行以下命令，将大写字母代替为合适的值：
+你需要知道用于向仓库进行身份验证的用户名、密码和客户端电子邮件地址，以及它的主机名。
+运行以下命令，注意替换适当的大写值：
```shell
-kubectl create secret docker-registry <名称> \
- --docker-server=DOCKER_REGISTRY_SERVER \
- --docker-username=DOCKER_USER \
- --docker-password=DOCKER_PASSWORD \
- --docker-email=DOCKER_EMAIL
+kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
```
+
+
+
+
+## allowWatchBookmarks {#allowWatchBookmarks}
+
+allowWatchBookmarks 字段请求类型为 BOOKMARK 的监视事件。
+没有实现书签的服务器可能会忽略这个标志，并根据服务器的判断发送书签。
+客户端不应该假设书签会在任何特定的时间间隔返回，也不应该假设服务器会在会话期间发送任何书签事件。
+如果当前请求不是 watch 请求，则忽略该字段。
+
+
+## continue {#continue}
+
+当需要从服务器检索更多结果时，应该设置 continue 选项。由于这个值是服务器定义的，
+客户端只能使用先前查询结果中具有相同查询参数的 continue 值(continue值除外)，
+服务器可能拒绝它识别不到的 continue 值。
+如果指定的 continue 值不再有效，无论是由于过期(通常是 5 到 15 分钟)
+还是服务器上的配置更改，服务器将响应 "410 ResourceExpired" 错误和一个 continue 令牌。
+
+如果客户端需要一个一致的列表，它必须在没有 continue 字段的情况下重新发起 list 请求。
+否则，客户端可能会发送另一个带有 410 错误令牌的 list 请求，服务器将响应从下一个键开始的列表，
+但列表数据来自最新的快照，这与之前
+的列表结果不一致。第一个列表请求之后的对象创建，修改，或删除的对象将被包含在响应中，
+只要他们的键是在“下一个键”之后。
+
+当 watch 字段为 true 时，不支持此字段。客户端可以从服务器返回的最后一个 resourceVersion 值开始监视，就不会错过任何修改。
+
+
+## dryRun {#dryRun}
+
+表示不应该持久化所请求的修改。无效或无法识别的 dryRun 指令将导致错误响应，
+并且服务器不再对请求进行进一步处理。有效值为:
+- All: 将处理所有的演练阶段
+
+
+## fieldManager {#fieldManager}
+
+fieldManager 是与进行这些更改的参与者或实体相关联的名称。
+长度小于或128个字符且仅包含可打印字符，如 https://golang.org/pkg/unicode/#IsPrint 所定义。
+
+
+## fieldSelector {#fieldSelector}
+
+根据返回对象的字段限制返回对象列表的选择器。默认为返回所有字段。
+
+
+## force {#force}
+
+Force 将“强制”应用请求。这意味着用户将重新获得他人拥有的冲突领域。
+对于非应用补丁请求，Force 标志必须不设置。
+
+
+## gracePeriodSeconds {#gracePeriodSeconds}
+
+删除对象前的持续时间(秒数)。值必须为非负整数。取值为 0 表示立即删除。
+如果该值为 nil，将使用指定类型的默认宽限期。如果没有指定，默认为每个对象的设置值。0 表示立即删除。
+
+
+## labelSelector {#labelSelector}
+
+通过标签限制返回对象列表的选择器。默认为返回所有对象。
+
+
+## limit {#limit}
+
+limit 是一个列表调用返回的最大响应数。如果有更多的条目，服务器会将列表元数据上的
+'continue' 字段设置为一个值，该值可以用于相同的初始查询来检索下一组结果。
+
+设置 limit 可能会在所有请求的对象被过滤掉的情况下返回少于请求的条目数量(下限为零)，
+并且客户端应该只根据 continue 字段是否存在来确定是否有更多的结果可用。
+服务器可能选择不支持 limit 参数，并将返回所有可用的结果。
+如果指定了 limit 并且 continue 字段为空，客户端可能会认为没有更多的结果可用。
+如果 watch 为 true，则不支持此字段。
+
+服务器保证在使用 continue 时返回的对象将与不带 limit 的列表调用相同，——
+也就是说，在发出第一个请求后所创建、修改或删除的对象将不包含在任何后续的继续请求中。
+
+这有时被称为一致性快照，确保使用 limit 的客户端在分块接收非常大的结果的客户端能够看到所有可能的对象。
+如果对象在分块列表期间被更新，则返回计算第一个列表结果时存在的对象版本。
+
+
+## namespace {#namespace}
+
+
+对象名称和身份验证范围，例如用于团队和项目。
+
+
+## pretty {#pretty}
+
+
+如果设置为 'true' ，那么输出是规范的打印。
+
+
+
+## propagationPolicy {#propagationPolicy}
+
+该字段决定是否以及如何执行垃圾收集。可以设置此字段或 OrphanDependents，但不能同时设置。
+默认策略由 metadata.finalizers 和特定资源的默认策略设置决定。可接受的值是：
+- 'Orphan'：孤立依赖项；
+- 'Background'：允许垃圾回收器后台删除依赖；
+- 'Foreground'：一个级联策略，前台删除所有依赖项。
+
+
+## resourceVersion {#resourceVersion}
+
+resourceVersion 对请求所针对的资源版本设置约束。
+详情请参见 https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions。
+
+默认不设置
+
+
+## resourceVersionMatch {#resourceVersionMatch}
+
+resourceVersionMatch 字段决定如何将 resourceVersion 应用于列表调用。
+强烈建议对设置了 resourceVersion 的列表调用设置 resourceVersion 匹配，
+具体请参见 https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions。
+
+默认不设置
+
+
+
+## timeoutSeconds {#timeoutSeconds}
+
+list/watch 调用的超时秒数。这选项限制调用的持续时间，无论是否有活动。
+
+
+## watch {#watch}
+
+监视对所述资源的更改，并将其这类变更以添加、更新和删除通知流的形式返回。指定 resourceVersion。
+
+
+
+
+
+
From 208ffb99ac9c2cf609bd9b62bb2f07d4cc9eecf9 Mon Sep 17 00:00:00 2001
From: HirazawaUi <695097494plus@gmail.com>
Date: Tue, 19 Apr 2022 15:01:25 +0800
Subject: [PATCH 162/167] Fix the format of scheduling/config.md
---
content/zh/docs/reference/scheduling/config.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/content/zh/docs/reference/scheduling/config.md b/content/zh/docs/reference/scheduling/config.md
index 93a45419a0..cd6c8507ea 100644
--- a/content/zh/docs/reference/scheduling/config.md
+++ b/content/zh/docs/reference/scheduling/config.md
@@ -377,11 +377,11 @@ that are not enabled by default:
实现的扩展点：`preScore`，`score`。
--`CinderLimits`：检查是否可以满足节点的 [OpenStack Cinder](https://docs.openstack.org/cinder/)
+- `CinderLimits`：检查是否可以满足节点的 [OpenStack Cinder](https://docs.openstack.org/cinder/)
卷限制
From 6cd17b446db79158cb0cf8051f9e57e745f7bdd1 Mon Sep 17 00:00:00 2001
From: "wei.wang"
Date: Tue, 19 Apr 2022 15:08:09 +0800
Subject: [PATCH 163/167] update file content/zh/blog/_index.md
---
content/zh/blog/_index.md | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/content/zh/blog/_index.md b/content/zh/blog/_index.md
index 1e61e53bd5..5a7b51631b 100644
--- a/content/zh/blog/_index.md
+++ b/content/zh/blog/_index.md
@@ -8,3 +8,13 @@ menu:
post: >
阅读关于 kubernetes 和容器规范的最新信息,以及获取最新的技术。
---
+
+{{< comment >}}
+
+
+
+有关为博客提供内容的信息，请参见
+https://kubernetes.io/zh/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post
+
+{{< /comment >}}
\ No newline at end of file
From 1c4980445ff0b3d5439564d6fd406f6b57923bf7 Mon Sep 17 00:00:00 2001
From: Zhongmin
Date: Tue, 19 Apr 2022 16:50:06 +0800
Subject: [PATCH 164/167] fix spelling
---
README-zh.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README-zh.md b/README-zh.md
index 1074d60169..700777d7a1 100644
--- a/README-zh.md
+++ b/README-zh.md
@@ -131,7 +131,7 @@ Hugo is shipped in two set of binaries for technical reasons. The current websit
If you run `make serve` on macOS and receive the following error:
-->
-### 对 macOs 上打开太多文件的故障排除
+### 对 macOS 上打开太多文件的故障排除
如果在 macOS 上运行 `make serve` 收到以下错误：
From 53522d88b183073a3b00d1c65e18a73ef13412a0 Mon Sep 17 00:00:00 2001
From: "xin.li"
Date: Tue, 19 Apr 2022 17:13:39 +0800
Subject: [PATCH 165/167] [zh] Sync tools/kubeadm/install-kubeadm.md
Signed-off-by: xin.li
---
.../tools/kubeadm/install-kubeadm.md | 40 +++++++++++--------
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/content/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index 459d74eb07..cc80a3e02a 100644
--- a/content/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -27,6 +27,8 @@ For information on how to create a cluster with kubeadm once you have performed
有关在执行此安装过程后如何使用 kubeadm 创建集群的信息，请参见
[使用 kubeadm 创建集群](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 页面。
+{{% dockershim-removal %}}
+
## {{% heading "prerequisites" %}}
## 检查所需端口{#check-required-ports}
-启用这些[必要的端口](/zh/docs/reference/ports-and-protocols/)后才能使 Kubernetes 的各组件相互通信。可以使用 telnet 来检查端口是否启用，例如：
+启用这些[必要的端口](/zh/docs/reference/ports-and-protocols/)后才能使 Kubernetes 的各组件相互通信。可以使用 netcat 之类的工具来检查端口是否启用，例如：
```shell
-telnet 127.0.0.1 6443
+nc 127.0.0.1 6443
```
-如果同时检测到 Docker 和 containerd，则优先选择 Docker。
+如果同时检测到 Docker Engine 和 containerd，kubeadm 将优先考虑 Docker Engine。
这是必然的，因为 Docker 18.09 附带了 containerd 并且两者都是可以检测到的，
即使你仅安装了 Docker。
-如果检测到其他两个或多个运行时，kubeadm 输出错误信息并退出。
+**如果检测到其他两个或多个运行时，kubeadm 输出错误信息并退出。**
-kubelet 通过内置的 `dockershim` CRI 实现与 Docker 集成。
+kubelet 可以使用已弃用的 dockershim 适配器与 Docker Engine 集成（dockershim 是 kubelet 本身的一部分）。
参阅[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)
以了解更多信息。
@@ -205,13 +207,13 @@ kubelet 通过内置的 `dockershim` CRI 实现与 Docker 集成。
{{% tab name="其它操作系统" %}}
默认情况下， kubeadm 使用 {{< glossary_tooltip term_id="docker" >}} 作为容器运行时。
-kubelet 通过内置的 `dockershim` CRI 实现与 Docker 集成。
+kubelet 可以使用已弃用的 dockershim 适配器与 Docker Engine 集成（dockershim 是 kubelet 本身的一部分）。
参阅[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)
以了解更多信息。
@@ -355,6 +357,9 @@ sudo systemctl enable --now kubelet
You have to do this until SELinux support is improved in the kubelet.
- You can leave SELinux enabled if you know how to configure it but it may require settings that are not supported by kubeadm.
+ - If the `baseurl` fails because your Red Hat-based distribution cannot interpret `basearch`, replace `\$basearch` with your computer's architecture.
+ Type `uname -m` to see that value.
+ For example, the `baseurl` URL for `x86_64` could be: `https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64`.
-->
**请注意：**
@@ -365,6 +370,9 @@ sudo systemctl enable --now kubelet
你必须这么做，直到 kubelet 做出对 SELinux 的支持进行升级为止。
- 如果你知道如何配置 SELinux 则可以将其保持启用状态，但可能需要设定 kubeadm 不支持的部分配置
+- 如果由于该 Red Hat 的发行版无法解析 `basearch` 导致获取 `baseurl` 失败，请将 `\$basearch` 替换为你计算机的架构。
+ 输入 `uname -m` 以查看该值。
+ 例如，`x86_64` 的 `baseurl` URL 可以是：`https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64`。
{{% /tab %}}
{{% tab name="无包管理器的情况" %}}
From 0e6d0b6bab731ee5aed0544df8b41d6cb9d81345 Mon Sep 17 00:00:00 2001
From: "wei.wang"
Date: Tue, 19 Apr 2022 19:21:17 +0800
Subject: [PATCH 166/167] [zh]update file
content/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
---
.../tasks/administer-cluster/kubeadm/adding-windows-nodes.md | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index 4e08ce2c60..7266b0ee4c 100644
--- a/content/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -25,9 +25,10 @@ You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can m
混合使用运行于 Linux 上的 Pod 和运行于 Windows 上的 Pod。
本页面展示如何将 Windows 节点注册到你的集群。
-## {{% heading "prerequisites" %}}
+{{% dockershim-removal %}}
-{{< version-check >}}
+## {{% heading "prerequisites" %}}
+ {{< version-check >}}