diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md
index 7bd4b355b6..de08e48d8c 100644
--- a/content/en/docs/concepts/architecture/nodes.md
+++ b/content/en/docs/concepts/architecture/nodes.md
@@ -11,9 +11,10 @@ weight: 10
Kubernetes runs your workload by placing containers into Pods to run on _Nodes_.
A node may be a virtual or physical machine, depending on the cluster. Each node
-contains the services necessary to run
-{{< glossary_tooltip text="Pods" term_id="pod" >}}, managed by the
-{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
+is managed by the
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}}
+and contains the services necessary to run
+{{< glossary_tooltip text="Pods" term_id="pod" >}}
Typically you have several nodes in a cluster; in a learning or resource-limited
environment, you might have just one.
diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md
index 50ed69ff42..8364b4f81c 100644
--- a/content/en/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md
@@ -91,6 +91,7 @@ Because `kubectl` outputs resource names in the same syntax it accepts, it's eas
```shell
kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service)
+kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service | xargs -i kubectl get {}
```
```shell
diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md
index 58b57a0b04..4d00336a88 100644
--- a/content/en/docs/concepts/configuration/secret.md
+++ b/content/en/docs/concepts/configuration/secret.md
@@ -116,7 +116,7 @@ In this case, `0` means we have just created an empty Secret.
A `kubernetes.io/service-account-token` type of Secret is used to store a
token that identifies a service account. When using this Secret type, you need
to ensure that the `kubernetes.io/service-account.name` annotation is set to an
-existing service account name. An Kubernetes controller fills in some other
+existing service account name. A Kubernetes controller fills in some other
fields such as the `kubernetes.io/service-account.uid` annotation and the
`token` key in the `data` field set to actual token content.
diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md
index cc5ea38b4e..f8475d6284 100644
--- a/content/en/docs/concepts/storage/volumes.md
+++ b/content/en/docs/concepts/storage/volumes.md
@@ -210,8 +210,8 @@ spec:
The `CSIMigration` feature for Cinder, when enabled, redirects all plugin operations
from the existing in-tree plugin to the `cinder.csi.openstack.org` Container
-Storage Interface (CSI) Driver. In order to use this feature, the [Openstack Cinder CSI
-Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md)
+Storage Interface (CSI) Driver. In order to use this feature, the [OpenStack Cinder CSI
+Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)
must be installed on the cluster and the `CSIMigration` and `CSIMigrationOpenStack`
beta features must be enabled.
diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md
index 0cdcbf2f36..3ff113bb63 100644
--- a/content/en/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md
@@ -462,8 +462,6 @@ and the [example of Limit Range](/docs/tasks/administer-cluster/manage-resources
### MutatingAdmissionWebhook {#mutatingadmissionwebhook}
-{{< feature-state for_k8s_version="v1.13" state="beta" >}}
-
This admission controller calls any mutating webhooks which match the request. Matching
webhooks are called in serial; each one may modify the object if it desires.
@@ -474,7 +472,7 @@ If a webhook called by this has side effects (for example, decrementing quota) i
webhooks or validating admission controllers will permit the request to finish.
If you disable the MutatingAdmissionWebhook, you must also disable the
-`MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1`
+`MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1`
group/version via the `--runtime-config` flag (both are on by default in
versions >= 1.9).
@@ -486,8 +484,6 @@ versions >= 1.9).
different when read back.
* Setting originally unset fields is less likely to cause problems than
overwriting fields set in the original request. Avoid doing the latter.
- * This is a beta feature. Future versions of Kubernetes may restrict the types of
- mutations these webhooks can make.
* Future changes to control loops for built-in resources or third-party resources
may break webhooks that work well today. Even when the webhook installation API
is finalized, not all possible webhook behaviors will be guaranteed to be supported
@@ -766,8 +762,6 @@ This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}}
### ValidatingAdmissionWebhook {#validatingadmissionwebhook}
-{{< feature-state for_k8s_version="v1.13" state="beta" >}}
-
This admission controller calls any validating webhooks which match the request. Matching
webhooks are called in parallel; if any of them rejects the request, the request
fails. This admission controller only runs in the validation phase; the webhooks it calls may not
@@ -778,7 +772,7 @@ If a webhook called by this has side effects (for example, decrementing quota) i
webhooks or other validating admission controllers will permit the request to finish.
If you disable the ValidatingAdmissionWebhook, you must also disable the
-`ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1`
+`ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1`
group/version via the `--runtime-config` flag (both are on by default in
versions 1.9 and later).
diff --git a/content/en/docs/reference/glossary/api-group.md b/content/en/docs/reference/glossary/api-group.md
index 6f87e3b041..0eccd9bf6f 100644
--- a/content/en/docs/reference/glossary/api-group.md
+++ b/content/en/docs/reference/glossary/api-group.md
@@ -2,7 +2,7 @@
title: API Group
id: api-group
date: 2019-09-02
-full_link: /docs/concepts/overview/kubernetes-api/#api-groups
+full_link: /docs/concepts/overview/kubernetes-api/#api-groups-and-versioning
short_description: >
A set of related paths in the Kubernetes API.
diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md
index 2ed62c2e2a..79ca330bd5 100644
--- a/content/en/docs/reference/kubectl/cheatsheet.md
+++ b/content/en/docs/reference/kubectl/cheatsheet.md
@@ -195,7 +195,7 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
# Output decoded secrets without external tools
-kubectl get secret ${secret_name} -o go-template='{{range $k,$v := .data}}{{$k}}={{$v|base64decode}}{{"\n"}}{{end}}'
+kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'
# List all Secrets currently in use by a pod
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
@@ -337,7 +337,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
### Resource types
-List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
+List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
```bash
kubectl api-resources
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 9c6acf5560..4d932e3e05 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
@@ -8,7 +8,7 @@ weight: 30
-
Creating a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
+
Using `kubeadm`, you can create a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
`kubeadm` also supports other cluster
lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades.
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 7c44f6e689..90f80db6ca 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
@@ -236,8 +236,8 @@ curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_
Define the directory to download command files
{{< note >}}
-The DOWNLOAD_DIR variable must be set to a writable directory.
-If you are running Flatcar Container Linux, set DOWNLOAD_DIR=/opt/bin.
+The `DOWNLOAD_DIR` variable must be set to a writable directory.
+If you are running Flatcar Container Linux, set `DOWNLOAD_DIR=/opt/bin`.
{{< /note >}}
```bash
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index ded4250787..717ad579d4 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -363,7 +363,7 @@ kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
## `/usr` is mounted read-only on nodes {#usr-mounted-read-only}
-On Linux distributions such as Fedora CoreOS, the directory `/usr` is mounted as a read-only filesystem.
+On Linux distributions such as Fedora CoreOS or Flatcar Container Linux, the directory `/usr` is mounted as a read-only filesystem.
For [flex-volume support](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md),
Kubernetes components like the kubelet and kube-controller-manager use the default path of
`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`, yet the flex-volume directory _must be writeable_
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 3897d6566e..2f23379400 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
@@ -72,7 +72,7 @@ Once you have a Linux-based Kubernetes control-plane node you are ready to choos
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan",
- "VNI" : 4096,
+ "VNI": 4096,
"Port": 4789
}
}
diff --git a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
index 7f56e4ec85..4f71db554a 100644
--- a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
+++ b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
@@ -23,7 +23,7 @@ dynamically, you need a strong understanding of how that change will affect your
cluster's behavior. Always carefully test configuration changes on a small set
of nodes before rolling them out cluster-wide. Advice on configuring specific
fields is available in the inline `KubeletConfiguration`
-[type documentation](https://github.com/kubernetes/kubernetes/blob/release-1.11/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go).
+[type documentation (for v1.20)](https://github.com/kubernetes/kubernetes/blob/release-1.20/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
{{< /warning >}}
diff --git a/content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md b/content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md
index 8ed9730415..23f85f109b 100644
--- a/content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md
+++ b/content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md
@@ -187,7 +187,7 @@ Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`.
To delete the Secret you have just created:
```shell
-kubectl delete secret db-user-pass
+kubectl delete secret mysecret
```
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
index ff51598f79..4cfbb98f2d 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -221,9 +221,9 @@ the global HPA settings exposed as flags for the `kube-controller-manager` compo
Starting from v1.12, a new algorithmic update removes the need for the
upscale delay.
-- `--horizontal-pod-autoscaler-downscale-stabilization`: The value for this option is a
- duration that specifies how long the autoscaler has to wait before another
- downscale operation can be performed after the current one has completed.
+- `--horizontal-pod-autoscaler-downscale-stabilization`: Specifies the duration of the
+ downscale stabilization time window. Horizontal Pod Autoscaler remembers
+ the historical recommended sizes and only acts on the largest size within this time window.
The default value is 5 minutes (`5m0s`).
{{< note >}}
diff --git a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md
index 64073549ef..f43af0e15e 100644
--- a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md
+++ b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md
@@ -552,7 +552,7 @@ In another terminal, watch the Pods in the StatefulSet:
```shell
kubectl get pod -l app=nginx -w
```
-The output is simular to:
+The output is similar to:
```
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 7m
diff --git a/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md
index 0845cf2806..284024b425 100644
--- a/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md
+++ b/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md
@@ -114,7 +114,7 @@ cpu-demo 974m
Souvenez-vous qu'en réglant `-cpu "2"`, vous avez configuré le conteneur pour faire en sorte qu'il utilise 2 CPU, mais que le conteneur ne peut utiliser qu'environ 1 CPU. L'utilisation du CPU du conteneur est entravée, car le conteneur tente d'utiliser plus de ressources CPU que sa limite.
{{< note >}}
-Une autre explication possible de la la restriction du CPU est que le Nœud pourrait ne pas avoir
+Une autre explication possible de la restriction du CPU est que le Nœud pourrait ne pas avoir
suffisamment de ressources CPU disponibles. Rappelons que les conditions préalables à cet exercice exigent que chacun de vos Nœuds doit avoir au moins 1 CPU.
Si votre conteneur fonctionne sur un nœud qui n'a qu'un seul CPU, le conteneur ne peut pas utiliser plus que 1 CPU, quelle que soit la limite de CPU spécifiée pour le conteneur.
{{< /note >}}
diff --git a/content/ja/community/static/cncf-code-of-conduct.md b/content/ja/community/static/cncf-code-of-conduct.md
index f61005e387..61255d92d9 100644
--- a/content/ja/community/static/cncf-code-of-conduct.md
+++ b/content/ja/community/static/cncf-code-of-conduct.md
@@ -25,7 +25,7 @@ CNCF コミュニティ行動規範 v1.0
Kubernetesで虐待的、嫌がらせ、または許されない行動があった場合には、から[Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct)(行動規範委員会)にご連絡ください。その他のプロジェクトにつきましては、CNCFプロジェクト管理者または仲介者にご連絡ください。
-本行動規範は、コントリビューターの合意 (http://contributor-covenant.org) バージョン 1.2.0 http://contributor-covenant.org/version/1/2/0/ から適応されています。
+本行動規範は、コントリビューターの合意 (https://contributor-covenant.org) バージョン 1.2.0 https://contributor-covenant.org/version/1/2/0/ から適応されています。
### CNCF イベント行動規範
diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
index f863cb4e92..728e0346fe 100644
--- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
+++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -52,4 +52,4 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode
* [Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
-* [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
+* [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md)
diff --git a/content/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
new file mode 100644
index 0000000000..1bc1b7951d
--- /dev/null
+++ b/content/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
@@ -0,0 +1,258 @@
+---
+title: Namespaceに対する最小および最大メモリー制約の構成
+
+content_type: task
+weight: 30
+---
+
+
+
+
+このページでは、Namespaceで実行されるコンテナが使用するメモリーの最小値と最大値を設定する方法を説明します。
+[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) で最小値と最大値のメモリー値を指定します。
+PodがLimitRangeによって課される制約を満たさない場合、そのNamespaceではPodを作成できません。
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+クラスター内の各ノードには、少なくとも1GiBのメモリーが必要です。
+
+
+
+
+## Namespaceの作成
+
+この演習で作成したリソースがクラスターの他の部分から分離されるように、Namespaceを作成します。
+
+
+```shell
+kubectl create namespace constraints-mem-example
+```
+
+## LimitRangeとPodを作成
+
+LimitRangeの設定ファイルです。
+
+{{< codenew file="admin/resource/memory-constraints.yaml" >}}
+
+LimitRangeを作成します。
+
+```shell
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example
+```
+
+LimitRangeの詳細情報を表示します。
+
+
+```shell
+kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example --output=yaml
+```
+
+出力されるのは、予想通りメモリー制約の最小値と最大値を示しています。
+しかし、LimitRangeの設定ファイルでデフォルト値を指定していないにもかかわらず、
+自動的に作成されていることに気づきます。
+
+
+```
+ limits:
+ - default:
+ memory: 1Gi
+ defaultRequest:
+ memory: 1Gi
+ max:
+ memory: 1Gi
+ min:
+ memory: 500Mi
+ type: Container
+```
+
+
+constraints-mem-exampleNamespaceにコンテナが作成されるたびに、
+Kubernetesは以下の手順を実行するようになっています。
+
+* コンテナが独自のメモリー要求と制限を指定しない場合は、デフォルトのメモリー要求と制限をコンテナに割り当てます。
+
+* コンテナに500MiB以上のメモリー要求があることを確認します。
+
+* コンテナのメモリー制限が1GiB以下であることを確認します。
+
+以下は、1つのコンテナを持つPodの設定ファイルです。設定ファイルのコンテナ(containers)では、600MiBのメモリー要求と800MiBのメモリー制限が指定されています。これらはLimitRangeによって課される最小と最大のメモリー制約を満たしています。
+
+
+{{< codenew file="admin/resource/memory-constraints-pod.yaml" >}}
+
+Podの作成
+
+```shell
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
+```
+
+Podのコンテナが実行されていることを確認します。
+
+```shell
+kubectl get pod constraints-mem-demo --namespace=constraints-mem-example
+```
+
+Podの詳細情報を見ます
+
+```shell
+kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-example
+```
+
+出力は、コンテナが600MiBのメモリ要求と800MiBのメモリー制限になっていることを示しています。これらはLimitRangeによって課される制約を満たしています。
+
+
+```yaml
+resources:
+ limits:
+ memory: 800Mi
+ requests:
+ memory: 600Mi
+```
+
+Podを消します。
+
+```shell
+kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
+```
+
+## 最大メモリ制約を超えるPodの作成の試み
+
+これは、1つのコンテナを持つPodの設定ファイルです。コンテナは800MiBのメモリー要求と1.5GiBのメモリー制限を指定しています。
+
+
+{{< codenew file="admin/resource/memory-constraints-pod-2.yaml" >}}
+
+Podを作成してみます。
+
+```shell
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
+```
+
+出力は、コンテナが大きすぎるメモリー制限を指定しているため、Podが作成されないことを示しています。
+
+
+```
+Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-2.yaml":
+pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container is 1Gi, but limit is 1536Mi.
+```
+
+## 最低限のメモリ要求を満たさないPodの作成の試み
+
+
+これは、1つのコンテナを持つPodの設定ファイルです。コンテナは100MiBのメモリー要求と800MiBのメモリー制限を指定しています。
+
+
+{{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}}
+
+Podを作成してみます。
+
+```shell
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
+```
+
+出力は、コンテナが小さすぎるメモリー要求を指定しているため、Podが作成されないことを示しています。
+
+```
+Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-3.yaml":
+pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container is 500Mi, but request is 100Mi.
+```
+
+## メモリ要求や制限を指定しないPodの作成
+
+
+これは、1つのコンテナを持つPodの設定ファイルです。コンテナはメモリー要求を指定しておらず、メモリー制限も指定していません。
+
+{{< codenew file="admin/resource/memory-constraints-pod-4.yaml" >}}
+
+Podを作成します。
+
+```shell
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example
+```
+
+Podの詳細情報を見ます
+
+```
+kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --output=yaml
+```
+
+出力を見ると、Podのコンテナのメモリ要求は1GiB、メモリー制限は1GiBであることがわかります。
+コンテナはどのようにしてこれらの値を取得したのでしょうか?
+
+
+```
+resources:
+ limits:
+ memory: 1Gi
+ requests:
+ memory: 1Gi
+```
+
+コンテナが独自のメモリー要求と制限を指定していなかったため、LimitRangeから与えられのです。
+コンテナが独自のメモリー要求と制限を指定していなかったため、LimitRangeから[デフォルトのメモリー要求と制限](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)が与えられたのです。
+
+この時点で、コンテナは起動しているかもしれませんし、起動していないかもしれません。このタスクの前提条件は、ノードが少なくとも1GiBのメモリーを持っていることであることを思い出してください。それぞれのノードが1GiBのメモリーしか持っていない場合、どのノードにも1GiBのメモリー要求に対応するのに十分な割り当て可能なメモリーがありません。たまたま2GiBのメモリーを持つノードを使用しているのであれば、おそらく1GiBのメモリーリクエストに対応するのに十分なスペースを持っていることになります。
+
+
+Podを削除します。
+
+```
+kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example
+```
+
+## 最小および最大メモリー制約の強制
+
+LimitRangeによってNamespaceに課される最大および最小のメモリー制約は、Podが作成または更新されたときにのみ適用されます。LimitRangeを変更しても、以前に作成されたPodには影響しません。
+
+
+## 最小・最大メモリー制約の動機
+
+
+クラスター管理者としては、Podが使用できるメモリー量に制限を課したいと思うかもしれません。
+
+
+例:
+
+* クラスター内の各ノードは2GBのメモリーを持っています。クラスタ内のどのノードもその要求をサポートできないため、2GB以上のメモリーを要求するPodは受け入れたくありません。
+
+
+* クラスターは運用部門と開発部門で共有されています。 本番用のワークロードでは最大8GBのメモリーを消費しますが、開発用のワークロードでは512MBに制限したいとします。本番用と開発用に別々のNamespaceを作成し、それぞれのNamespaceにメモリー制限を適用します。
+
+## クリーンアップ
+
+Namespaceを削除します。
+
+```shell
+kubectl delete namespace constraints-mem-example
+```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+### クラスター管理者向け
+
+* [名前空間に対するデフォルトのメモリー要求と制限の構成](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+
+* [名前空間に対するデフォルトのCPU要求と制限の構成](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
+
+* [名前空間に対する最小および最大CPU制約の構成](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+
+* [名前空間に対するメモリーとCPUのクォータの構成](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+
+* [名前空間に対するPodクォータの設定](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
+
+* [APIオブジェクトのクォータの設定](/docs/tasks/administer-cluster/quota-api-object/)
+
+### アプリケーション開発者向け
+
+* [コンテナとPodへのメモリーリソースの割り当て](/docs/tasks/configure-pod-container/assign-memory-resource/)
+
+* [コンテナとPodへのCPUリソースの割り当て](/docs/tasks/configure-pod-container/assign-cpu-resource/)
+
+* [PodのQoS(サービス品質)を設定](/docs/tasks/configure-pod-container/quality-service-pod/)
diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index ce453789cb..16c84d451c 100644
--- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -69,7 +69,7 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan",
- "VNI" : 4096,
+ "VNI": 4096,
"Port": 4789
}
}
diff --git a/content/zh/docs/concepts/cluster-administration/flow-control.md b/content/zh/docs/concepts/cluster-administration/flow-control.md
index 6f6b3fdc12..022596a0f2 100644
--- a/content/zh/docs/concepts/cluster-administration/flow-control.md
+++ b/content/zh/docs/concepts/cluster-administration/flow-control.md
@@ -939,10 +939,10 @@ For background information on design details for API priority and fairness, see
[enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
You can make suggestions and feature requests via
[SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)
-or the feature's [slack channel](http://kubernetes.slack.com/messages/api-priority-and-fairness).
+or the feature's [slack channel](https://kubernetes.slack.com/messages/api-priority-and-fairness).
-->
有关API优先级和公平性的设计细节的背景信息,
请参阅[增强建议](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md)。
-你可以通过 [SIG APIMachinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)
-或特性的 [Slack 频道](http://kubernetes.slack.com/messages/api-priority-and-fairness)
+你可以通过 [SIG APIMachinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery/)
+或特性的 [Slack 频道](https://kubernetes.slack.com/messages/api-priority-and-fairness/)
提出建议和特性请求。
diff --git a/content/zh/docs/concepts/cluster-administration/system-metrics.md b/content/zh/docs/concepts/cluster-administration/system-metrics.md
index e5f31b0a54..cc3cb44fa7 100644
--- a/content/zh/docs/concepts/cluster-administration/system-metrics.md
+++ b/content/zh/docs/concepts/cluster-administration/system-metrics.md
@@ -204,7 +204,7 @@ kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结
现在,收集加速器指标的责任属于供应商,而不是 kubelet。供应商必须提供一个收集指标的容器,
并将其公开给指标服务(例如 Prometheus)。
-[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/references/command-line-tools-reference/feature-gates/)
+[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
禁止由 kubelet 收集的指标。
关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。
diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
index 5873bdd497..e08fa7690d 100644
--- a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
@@ -90,6 +90,6 @@ to disable the timeout restriction. This deprecated feature gate will be removed
了解如何在自己的环境中启用聚合器。
* 接下来,了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/),
开始使用聚合层。
-* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
+* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
* 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范
diff --git a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md
index f70f5df34e..05af5323d9 100644
--- a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -97,7 +97,7 @@ Extensions are software components that extend and deeply integrate with Kuberne
They adapt it to support new types and new kinds of hardware.
Most cluster administrators will use a hosted or distribution
-instance of Kubernetes. As a result, most Kubernetes users will need to
+instance of Kubernetes. As a result, most Kubernetes users will not need to
install extensions and fewer will need to author new ones.
-->
## 扩展程序 {#extension}
@@ -105,7 +105,7 @@ install extensions and fewer will need to author new ones.
扩展程序是指对 Kubernetes 进行扩展和深度集成的软件组件。它们适合用于支持新的类型和新型硬件。
大多数集群管理员会使用托管的或统一分发的 Kubernetes 实例。
-因此,大多数 Kubernetes 用户需要安装扩展程序,而且还有少部分用户甚至需要编写新的扩展程序。
+因此,大多数 Kubernetes 用户不需要安装扩展程序,而且还有少部分用户甚至需要编写新的扩展程序。
在 webhook 模型里,Kubernetes 向远程服务发送一个网络请求。
在 *可执行文件插件* 模型里,Kubernetes 执行一个可执行文件(程序)。
可执行文件插件被 kubelet(如
-[Flex 卷插件](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)和
-[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)和
-`kubectl` 所使用。
+[Flex 卷插件](/zh/docs/concepts/storage/volumes/#flexvolume)
+和[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+和 `kubectl` 所使用。
下图显示了扩展点如何与 Kubernetes 控制平面进行交互。
@@ -184,13 +183,14 @@ This diagram shows the extension points in a Kubernetes system.
1. 用户通常使用 `kubectl` 与 Kubernetes API 进行交互。
@@ -209,9 +209,9 @@ This diagram shows the extension points in a Kubernetes system.
5. Kubernetes 的大部分行为都是由称为控制器(Controllers)的程序实现的,这些程序是 API 服务器的客户端。
控制器通常与自定义资源一起使用。
6. `kubelet` 在主机上运行,并帮助 Pod 看起来就像在集群网络上拥有自己的 IP 的虚拟服务器。
- [网络插件](/zh/docs/concepts/extend-kubernetes/#network-plugins/)让你可以实现不同的 pod 网络。
+ [网络插件](/zh/docs/concepts/extend-kubernetes/#network-plugins)让你可以实现不同的 pod 网络。
7. `kubelet` 也负责为容器挂载和卸载卷。新的存储类型可以通过
- [存储插件](/zh/docs/concepts/extend-kubernetes/#storage-plugins/)支持。
+ [存储插件](/zh/docs/concepts/extend-kubernetes/#storage-plugins)支持。
## API 扩展 {#api-extensions}
@@ -343,24 +343,23 @@ After a request is authorized, if it is a write operation, it also goes through
### Storage Plugins
-[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
-) allow users to mount volume types without built-in support by having the
+[Flex Volumes](/docs/concepts/storage/volumes/#flexvolume)
+allow users to mount volume types without built-in support by having the
Kubelet call a Binary Plugin to mount the volume.
-->
## 基础设施扩展
### 存储插件
-[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
-)
+[Flex Volumes](/zh/docs/concepts/storage/volumes/#flexvolume)
允许用户挂载无内置插件支持的卷类型,它通过 Kubelet 调用一个可执行文件插件来挂载卷。
### 设备插件 {#device-plugins}
@@ -371,7 +370,8 @@ Plugin](/docs/concepts/cluster-administration/device-plugins/).
### 网络插件 {#network-plugins}
@@ -408,17 +408,21 @@ the nodes chosen for a pod.
[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md),
它允许使用一个 Webhook 后端(调度器扩展程序)为 Pod 筛选节点和确定节点的优先级。
-## {{% heading "whatsnext" %}}
+## {{% heading "whatsnext" %}}
+
+
* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
* 详细了解基础设施扩展
diff --git a/content/zh/docs/concepts/policy/pod-security-policy.md b/content/zh/docs/concepts/policy/pod-security-policy.md
index 2c80607ed4..86d5ac24e7 100644
--- a/content/zh/docs/concepts/policy/pod-security-policy.md
+++ b/content/zh/docs/concepts/policy/pod-security-policy.md
@@ -1230,7 +1230,7 @@ By default, all safe sysctls are allowed.
- Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details.
-->
-- 参阅[Pod 安全标准](zh/docs/concepts/security/pod-security-standards/)
+- 参阅[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)
了解策略建议。
- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)了解 API 细节。
diff --git a/content/zh/docs/concepts/services-networking/connect-applications-service.md b/content/zh/docs/concepts/services-networking/connect-applications-service.md
index 3327b43986..bf54a0f2d0 100644
--- a/content/zh/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/zh/docs/concepts/services-networking/connect-applications-service.md
@@ -316,7 +316,7 @@ The rest of this section will assume you have a Service with a long lived IP
所以可以通过标准做法,使在集群中的任何 Pod 都能与该 Service 通信(例如:`gethostbyname()`)。
如果 CoreDNS 没有在运行,你可以参照
[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 或者
-[安装 CoreDNS](/docs/tasks/administer-cluster/coredns/#installing-coredns) 来启用它。
+[安装 CoreDNS](/zh/docs/tasks/administer-cluster/coredns/#installing-coredns) 来启用它。
让我们运行另一个 curl 应用来进行测试:
```shell
diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh/docs/concepts/services-networking/ingress-controllers.md
index 4f8e279da3..a50312b63d 100644
--- a/content/zh/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/zh/docs/concepts/services-networking/ingress-controllers.md
@@ -63,28 +63,29 @@ Kubernetes 作为一个项目,目前支持和维护
* [Citrix Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller#readme)
可以用来与 Citrix Application Delivery Controller 一起使用。
* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 Ingress 控制器。
-* [EnRoute](https://getenroute.io/) 是一个基于 [Envoy](https://www.envoyproxy.io) API 网关能够执行 Ingress 控制器。
+* [EnRoute](https://getenroute.io/) 是一个基于 [Envoy](https://www.envoyproxy.io) API 网关,
+ 可以作为 Ingress 控制器来执行。
* F5 BIG-IP 的
- [用于 Kubernetes 的容器 Ingress 服务](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)
+ [用于 Kubernetes 的容器 Ingress 服务](https://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)
让你能够使用 Ingress 来配置 F5 BIG-IP 虚拟服务器。
* [Gloo](https://gloo.solo.io) 是一个开源的、基于 [Envoy](https://www.envoyproxy.io) 的
Ingress 控制器,能够提供 API 网关功能,
-* [HAProxy Ingress](https://haproxy-ingress.github.io/) 针对 [HAProxy](http://www.haproxy.org/#desc)
+* [HAProxy Ingress](https://haproxy-ingress.github.io/) 针对 [HAProxy](https://www.haproxy.org/#desc)
的 Ingress 控制器。
* [用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress#readme)
- 也是一个针对 [HAProxy](http://www.haproxy.org/#desc) 的 Ingress 控制器。
+ 也是一个针对 [HAProxy](https://www.haproxy.org/#desc) 的 Ingress 控制器。
* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)
是一个基于 [Istio](https://istio.io/) 的 Ingress 控制器。
* [用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller#readme)
是一个用来驱动 [Kong Gateway](https://konghq.com/kong/) 的 Ingress 控制器。
@@ -108,7 +109,7 @@ Kubernetes 作为一个项目,目前支持和维护
设计用来作为构造你自己的定制代理的库。
* [Traefik Kubernetes Ingress 提供程序](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)
是一个用于 [Traefik](https://traefik.io/traefik/) 代理的 Ingress 控制器。
-* [Voyager](https://appscode.com/products/voyager) 是一个针对 [HAProxy](http://www.haproxy.org/#desc)
+* [Voyager](https://appscode.com/products/voyager) 是一个针对 [HAProxy](https://www.haproxy.org/#desc)
的 Ingress 控制器。
### 应用程序协议 {#application-protocol}
@@ -358,8 +358,8 @@ domain prefixed names such as `mycompany.com/my-custom-protocol`.
此字段的取值会被映射到对应的 Endpoints 和 EndpointSlices 对象。
该字段遵循标准的 Kubernetes 标签语法。
-其值可以是 [IANA 标准服务名称](http://www.iana.org/assignments/service-names)或以域名前缀的名称,
-如 `mycompany.com/my-custom-protocol`。
+其值可以是 [IANA 标准服务名称](https://www.iana.org/assignments/service-names)
+或以域名为前缀的名称,如 `mycompany.com/my-custom-protocol`。
延迟卷绑定使得调度器在为 PersistentVolumeClaim 选择一个合适的
-PersistentVolume 时能考虑到所有 Pod 的调度限制。
\ No newline at end of file
+PersistentVolume 时能考虑到所有 Pod 的调度限制。
diff --git a/content/zh/docs/concepts/workloads/controllers/job.md b/content/zh/docs/concepts/workloads/controllers/job.md
index 61a532bd02..e79bf11dc1 100644
--- a/content/zh/docs/concepts/workloads/controllers/job.md
+++ b/content/zh/docs/concepts/workloads/controllers/job.md
@@ -33,7 +33,8 @@ due to a node hardware failure or a node reboot).
You can also use a Job to run multiple Pods in parallel.
-->
-Job 会创建一个或者多个 Pods,并会持续重试直到指定数量的 Pods 成功终止。
+
+Job 会创建一个或者多个 Pods,并将继续重试 Pods 的执行,直到指定数量的 Pods 成功终止。
随着 Pods 成功结束,Job 跟踪记录成功完成的 Pods 个数。
当数量达到指定的成功个数阈值时,任务(即 Job)结束。
删除 Job 的操作会清除所创建的全部 Pods。
diff --git a/content/zh/docs/tasks/administer-cluster/highly-available-master.md b/content/zh/docs/tasks/administer-cluster/highly-available-master.md
index be4797477d..6144a634c8 100644
--- a/content/zh/docs/tasks/administer-cluster/highly-available-master.md
+++ b/content/zh/docs/tasks/administer-cluster/highly-available-master.md
@@ -320,6 +320,71 @@ To make such deployment secure, communication between etcd instances is authoriz
为了允许 etcd 组建集群,需开放 etcd 实例之间通信所需的端口(用于集群内部通信)。
为了使这种部署安全,etcd 实例之间的通信使用 SSL 进行鉴权。
+
+### API 服务器标识
+
+{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
+
+
+使用 API 服务器标识功能需要启用[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/),
+该功能默认不启用。
+你可以在启动 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} 的时候启用特性门控 `APIServerIdentity` 来激活 API 服务器标识:
+
+
+```shell
+kube-apiserver \
+--feature-gates=APIServerIdentity=true \
+ # …其他标记照常
+```
+
+
+在启动引导过程中,每个 kube-apiserver 会给自己分配一个唯一 ID。
+该 ID 的格式是 `kube-apiserver-{UUID}`。
+每个 kube-apiserver 会在 _kube-system_ {{< glossary_tooltip text="名字空间" term_id="namespace">}} 里创建一个 [`Lease` 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io)。
+
+`Lease` 对象的名字是 kube-apiserver 的唯一 ID。
+`Lease` 对象包含一个标签 `k8s.io/component=kube-apiserver`。
+每个 kube-apiserver 每过 `IdentityLeaseRenewIntervalSeconds`(默认是 10 秒)就会刷新它的 `Lease` 对象。
+每个 kube-apiserver 每过 `IdentityLeaseDurationSeconds`(默认是 3600 秒)也会检查所有 kube-apiserver 的标识 `Lease` 对象,
+并且会删除超过 `IdentityLeaseDurationSeconds` 时间还没被刷新的 `Lease` 对象。
+可以在 kube-apiserver 的 `identity-lease-renew-interval-seconds`
+和 `identity-lease-duration-seconds` 标记里配置 `IdentityLeaseRenewIntervalSeconds` 和 `IdentityLeaseDurationSeconds`。
+
+
+启用该功能是使用 HA API 服务器协调相关功能(例如,`StorageVersionAPI` 特性门控)的前提条件。
+
-你可以直接下载如下文件:
+你也可以直接下载如下文件:
- [`redis-pod.yaml`](/examples/application/job/redis/redis-pod.yaml)
- [`redis-service.yaml`](/examples/application/job/redis/redis-service.yaml)
@@ -121,7 +121,7 @@ Now hit enter, start the redis CLI, and create a list with some work items in it
-->
现在按回车键,启动 redis 命令行界面,然后创建一个存在若干个工作项的列表。
-```
+```shell
# redis-cli -h redis
redis:6379> rpush job2 "apple"
(integer) 1
@@ -214,7 +214,7 @@ your username and push to the Hub with the below commands. Replace
### Push 镜像
对于 [Docker Hub](https://hub.docker.com/),请先用你的用户名给镜像打上标签,
-然后使用下面的命令 push 你的镜像到仓库。请将 `` 替换为你自己的用户名。
+然后使用下面的命令 push 你的镜像到仓库。请将 `` 替换为你自己的 Hub 用户名。
```shell
docker tag job-wq-2 /job-wq-2
@@ -270,7 +270,7 @@ too.
-->
在这个例子中,每个 pod 处理了队列中的多个项目,直到队列中没有项目时便退出。
因为是由工作程序自行检测工作队列是否为空,并且 Job 控制器不知道工作队列的存在,
-所以依赖于工作程序在完成工作时发出信号。
+这依赖于工作程序在完成工作时发出信号。
工作程序以成功退出的形式发出信号表示工作队列已经为空。
所以,只要有任意一个工作程序成功退出,控制器就知道工作已经完成了,所有的 Pod 将很快会退出。
因此,我们将 Job 的完成计数(Completion Count)设置为 1 。
@@ -360,11 +360,10 @@ want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-comp
-如果你有连续的后台处理业务,那么可以考虑使用 `replicationController` 来运行你的后台业务,
+如果你有持续的后台处理业务,那么可以考虑使用 `ReplicaSet` 来运行你的后台业务,
和运行一个类似 [https://github.com/resque/resque](https://github.com/resque/resque)
的后台处理库。
-
diff --git a/content/zh/examples/pods/init-containers.yaml b/content/zh/examples/pods/init-containers.yaml
index 35c393d7c7..667b03eccd 100644
--- a/content/zh/examples/pods/init-containers.yaml
+++ b/content/zh/examples/pods/init-containers.yaml
@@ -19,7 +19,7 @@ spec:
- wget
- "-O"
- "/work-dir/index.html"
- - http://kubernetes.io
+ - http://info.cern.ch
volumeMounts:
- name: workdir
mountPath: "/work-dir"