hide some original comments in translate docs (#18986)
* hide original comment * hide some original comments
This commit is contained in:
@@ -431,6 +431,7 @@ parameters:
|
||||
type: pd-standard
|
||||
replication-type: none
|
||||
```
|
||||
|
||||
<!--
|
||||
* `type`: `pd-standard` or `pd-ssd`. Default: `pd-standard`
|
||||
* `zone` (Deprecated): GCE zone. If neither `zone` nor `zones` is specified, volumes are
|
||||
@@ -518,6 +519,7 @@ parameters:
|
||||
* `restauthenabled`:Gluster REST 服务身份验证布尔值,用于启用对 REST 服务器的身份验证。如果此值为 'true',则必须填写 `restuser` 和 `restuserkey` 或 `secretNamespace` + `secretName`。此选项已弃用,当在指定 `restuser`,`restuserkey`,`secretName` 或 `secretNamespace` 时,身份验证被启用。
|
||||
* `restuser`:在 Gluster 可信池中有权创建卷的 Gluster REST服务/Heketi 用户。
|
||||
* `restuserkey`:Gluster REST 服务/Heketi 用户的密码将被用于对 REST 服务器进行身份验证。此参数已弃用,取而代之的是 `secretNamespace` + `secretName`。
|
||||
|
||||
<!--
|
||||
* `secretNamespace`, `secretName` : Identification of Secret instance that
|
||||
contains user password to use when talking to Gluster REST service. These
|
||||
@@ -544,6 +546,7 @@ parameters:
|
||||
```
|
||||
|
||||
secret 的例子可以在 [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml) 中找到。
|
||||
|
||||
<!--
|
||||
* `clusterid`: `630372ccdc720a92c681fb928f27b53f` is the ID of the cluster
|
||||
which will be used by Heketi when provisioning the volume. It can also be a
|
||||
@@ -559,6 +562,7 @@ parameters:
|
||||
* `clusterid`:`630372ccdc720a92c681fb928f27b53f` 是集群的 ID,当分配卷时,Heketi 将会使用这个文件。它也可以是一个 clusterid 列表,例如:
|
||||
`"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`。这个是可选参数。
|
||||
* `gidMin`,`gidMax`:storage class GID 范围的最小值和最大值。在此范围(gidMin-gidMax)内的唯一值(GID)将用于动态分配卷。这些是可选的值。如果不指定,卷将被分配一个 2000-2147483647 之间的值,这是 gidMin 和 gidMax 的默认值。
|
||||
|
||||
<!--
|
||||
* `volumetype` : The volume type and its parameters can be configured with this
|
||||
optional value. If the volume type is not mentioned, it's up to the provisioner
|
||||
@@ -766,6 +770,7 @@ parameters:
|
||||
* `adminSecretNamespace`:`adminSecret` 的命名空间。默认是 "default"。
|
||||
* `pool`: Ceph RBD 池. 默认是 "rbd"。
|
||||
* `userId`:Ceph 客户端 ID,用于映射 RBD 镜像。默认与 `adminId` 相同。
|
||||
|
||||
<!--
|
||||
* `userSecretName`: The name of Ceph Secret for `userId` to map RBD image. It
|
||||
must exist in the same namespace as PVCs. This parameter is required.
|
||||
|
||||
@@ -65,41 +65,48 @@ The following are typical use cases for Deployments:
|
||||
|
||||
-->
|
||||
* [创建 Deployment 以展开 ReplicaSet ](#creating-a-deployment)。 ReplicaSet 在后台创建 Pods。检查 ReplicaSet 展开的状态,查看其是否成功。
|
||||
|
||||
<!--
|
||||
|
||||
* [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
|
||||
|
||||
-->
|
||||
* [声明 Pod 的新状态](#updating-a-deployment) 通过更新 Deployment 的 PodTemplateSpec。将创建新的 ReplicaSet ,并且 Deployment 管理器以受控速率将 Pod 从旧 ReplicaSet 移动到新 ReplicaSet 。每个新的 ReplicaSet 都会更新 Deployment 的修改历史。
|
||||
|
||||
<!--
|
||||
|
||||
* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
|
||||
|
||||
-->
|
||||
* [回滚到较早的 Deployment 版本](#rolling-back-a-deployment),如果 Deployment 的当前状态不稳定。每次回滚都会更新 Deployment 的修改。
|
||||
|
||||
<!--
|
||||
|
||||
* [Scale up the Deployment to facilitate more load](#scaling-a-deployment).
|
||||
|
||||
-->
|
||||
* [扩展 Deployment 以承担更多负载](#scaling-a-deployment).
|
||||
|
||||
<!--
|
||||
|
||||
* [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
|
||||
|
||||
-->
|
||||
* [暂停 Deployment ](#pausing-and-resuming-a-deployment) 对其 PodTemplateSpec 进行修改,然后恢复它以启动新的展开。
|
||||
|
||||
<!--
|
||||
|
||||
* [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck.
|
||||
-->
|
||||
* [使用 Deployment 状态](#deployment-status) 作为卡住展开的指示器。
|
||||
|
||||
<!--
|
||||
|
||||
* [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore.
|
||||
|
||||
-->
|
||||
* [清理较旧的 ReplicaSets ](#clean-up-policy) ,那些不在需要的。
|
||||
|
||||
<!--
|
||||
## Creating a Deployment
|
||||
-->
|
||||
@@ -123,10 +130,12 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
|
||||
* A Deployment named `nginx-deployment` is created, indicated by the `.metadata.name` field.
|
||||
-->
|
||||
* 将创建名为 `nginx-deployment` 的 Deployment ,由 `.metadata.name` 字段指示。
|
||||
|
||||
<!--
|
||||
* The Deployment creates three replicated Pods, indicated by the `replicas` field.
|
||||
-->
|
||||
* Deployment 创建三个复制的 Pods,由 `replicas` 字段指示。
|
||||
|
||||
<!--
|
||||
* The `selector` field defines how the Deployment finds which Pods to manage.
|
||||
In this case, you simply select a label that is defined in the Pod template (`app: nginx`).
|
||||
@@ -136,7 +145,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
|
||||
* `selector` 字段定义 Deployment 如何查找要管理的 Pods。
|
||||
在这种情况下,只需选择在 Pod 模板(`app: nginx`)中定义的标签。但是,更复杂的选择规则是可能的,只要 Pod 模板本身满足规则。
|
||||
{{< note >}}
|
||||
<!--
|
||||
<!--
|
||||
The `matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map
|
||||
is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In",
|
||||
and the values array contains only "value".
|
||||
@@ -149,32 +158,35 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
|
||||
* The `template` field contains the following sub-fields:
|
||||
-->
|
||||
* `template` 字段包含以下子字段:
|
||||
<!--
|
||||
|
||||
<!--
|
||||
* The Pods are labeled `app: nginx`using the `labels` field.
|
||||
-->
|
||||
* Pod 标记为`app: nginx`,使用`labels`字段。
|
||||
<!--
|
||||
|
||||
<!--
|
||||
* The Pod template's specification, or `.template.spec` field, indicates that
|
||||
the Pods run one container, `nginx`, which runs the `nginx`
|
||||
[Docker Hub](https://hub.docker.com/) image at version 1.7.9.
|
||||
-->
|
||||
* Pod 模板规范或 `.template.spec` 字段指示 Pods 运行一个容器, `nginx`,运行 `nginx` [Docker Hub](https://hub.docker.com/)版本1.7.9的镜像 。
|
||||
<!--
|
||||
|
||||
<!--
|
||||
* Create one container and name it `nginx` using the `name` field.
|
||||
-->
|
||||
* 创建一个容器并使用`name`字段将其命名为 `nginx`。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Follow the steps given below to create the above Deployment:
|
||||
-->
|
||||
按照以下步骤创建上述 Deployment :
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Before you begin, make sure your Kubernetes cluster is up and running.
|
||||
-->
|
||||
开始之前,请确保的 Kubernetes 集群已启动并运行。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
1. Create the Deployment by running the following command:
|
||||
-->
|
||||
1. 通过运行以下命令创建 Deployment :
|
||||
@@ -194,7 +206,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
|
||||
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
2. Run `kubectl get deployments` to check if the Deployment was created. If the Deployment is still being created, the output is similar to the following:
|
||||
-->
|
||||
2. 运行 `kubectl get deployments` 以检查 Deployment 是否已创建。如果仍在创建 Deployment ,则输出以下内容:
|
||||
@@ -202,11 +214,12 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3 0 0 0 1s
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
When you inspect the Deployments in your cluster, the following fields are displayed:
|
||||
-->
|
||||
检查集群中的 Deployments 时,将显示以下字段:
|
||||
<!--
|
||||
|
||||
<!--
|
||||
* `NAME` lists the names of the Deployments in the cluster.
|
||||
* `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_.
|
||||
* `CURRENT` displays how many replicas are currently running.
|
||||
@@ -221,12 +234,12 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
|
||||
* `AVAILABLE`显示应用程序可供用户使用的副本数。
|
||||
* `AGE` 显示应用程序运行的时间量。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Notice how the number of desired replicas is 3 according to `.spec.replicas` field.
|
||||
-->
|
||||
请注意,根据`.spec.replicas`副本字段,所需副本的数量为 3。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. The output is similar to this:
|
||||
-->
|
||||
3. 要查看 Deployment 展开状态,运行 `kubectl rollout status deployment.v1.apps/nginx-deployment`。输出:
|
||||
@@ -235,7 +248,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
|
||||
deployment.apps/nginx-deployment successfully rolled out
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
4. Run the `kubectl get deployments` again a few seconds later. The output is similar to this:
|
||||
-->
|
||||
4. 几秒钟后再次运行 `kubectl get deployments`。输出:
|
||||
@@ -243,12 +256,12 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3 3 3 3 18s
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available.
|
||||
-->
|
||||
请注意, Deployment 已创建所有三个副本,并且所有副本都是最新的(它们包含最新的 Pod 模板)并且可用。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this:
|
||||
-->
|
||||
5. 要查看 Deployment 创建的 ReplicaSet (`rs`),运行 `kubectl get rs`。输出:
|
||||
@@ -256,13 +269,13 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-75675f5897 3 3 3 18s
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is
|
||||
randomly generated and uses the pod-template-hash as a seed.
|
||||
-->
|
||||
请注意, ReplicaSet 的名称始终被格式化为`[DEPLOYMENT-NAME]-[RANDOM-STRING]`。随机字符串是随机生成并使用 pod-template-hash 作为种子。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`. The following output is returned:
|
||||
-->
|
||||
6. 要查看每个 Pod 自动生成的标签,运行 `kubectl get pods --show-labels`。返回以下输出:
|
||||
@@ -272,13 +285,14 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
|
||||
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
|
||||
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
|
||||
```
|
||||
<!--
|
||||
|
||||
<!--
|
||||
The created ReplicaSet ensures that there are three `nginx` Pods.
|
||||
-->
|
||||
创建的复制集可确保有三个 `nginx` Pods。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
<!--
|
||||
You must specify an appropriate selector and Pod template labels in a Deployment (in this case,
|
||||
`app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.
|
||||
-->
|
||||
@@ -334,7 +348,7 @@ is changed, for example if the labels or container images of the template are up
|
||||
```shell
|
||||
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -342,7 +356,7 @@ is changed, for example if the labels or container images of the template are up
|
||||
deployment.apps/nginx-deployment image updated
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`:
|
||||
-->
|
||||
或者,可以 `edit` Deployment 并将 `.spec.template.spec.containers[0].image` 从 `nginx:1.7.9` 更改至 `nginx:1.9.1`。
|
||||
@@ -351,7 +365,7 @@ is changed, for example if the labels or container images of the template are up
|
||||
kubectl edit deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -368,14 +382,14 @@ is changed, for example if the labels or container images of the template are up
|
||||
kubectl rollout status deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
```
|
||||
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
or
|
||||
-->
|
||||
或者
|
||||
@@ -409,7 +423,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
|
||||
kubectl get rs
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -428,7 +442,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -439,24 +453,24 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
|
||||
nginx-deployment-1564180365-z9gth 1/1 Running 0 14s
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Next time you want to update these Pods, you only need to update the Deployment's Pod template again.
|
||||
-->
|
||||
下次要更新这些 Pods 时,只需再次更新 Deployment Pod 模板。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Deployment ensures that only a certain number of Pods are down while they are being updated. By default,
|
||||
it ensures that at least 75% of the desired number of Pods are up (25% max unavailable).
|
||||
-->
|
||||
Deployment 可确保在更新时仅关闭一定数量的 Pods。默认情况下,它确保至少 75%所需 Pods 运行(25%最大不可用)。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Deployment also ensures that only a certain number of Pods are created above the desired number of Pods.
|
||||
By default, it ensures that at most 25% of the desired number of Pods are up (25% max surge).
|
||||
-->
|
||||
Deployment 还确保仅创建一定数量的 Pods 高于期望的 Pods 数。默认情况下,它可确保最多增加 25% 期望 Pods 数(25%最大增量)。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
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.
|
||||
@@ -471,7 +485,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
|
||||
```shell
|
||||
kubectl describe deployments
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -513,7 +527,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
|
||||
Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3
|
||||
Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
Here you see that when you first created the Deployment, it created a ReplicaSet (nginx-deployment-2035384211)
|
||||
and scaled it up to 3 replicas directly. When you updated the Deployment, it created a new ReplicaSet
|
||||
(nginx-deployment-1564180365) and scaled it up to 1 and then scaled down the old ReplicaSet to 2, so that at
|
||||
@@ -618,7 +632,7 @@ rolled back.
|
||||
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -635,7 +649,7 @@ rolled back.
|
||||
kubectl rollout status deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -660,7 +674,7 @@ rolled back.
|
||||
kubectl get rs
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -680,7 +694,7 @@ rolled back.
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -693,7 +707,7 @@ rolled back.
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
<!--
|
||||
The Deployment controller stops the bad rollout automatically, and stops scaling up the new
|
||||
ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
|
||||
Kubernetes by default sets the value to 25%.
|
||||
@@ -709,7 +723,7 @@ rolled back.
|
||||
kubectl describe deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -753,7 +767,7 @@ rolled back.
|
||||
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
To fix this, you need to rollback to a previous revision of Deployment that is stable.
|
||||
-->
|
||||
要解决此问题,需要回滚到以前稳定的 Deployment 版本。
|
||||
@@ -775,7 +789,7 @@ rolled back.
|
||||
```shell
|
||||
kubectl rollout history deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -787,12 +801,12 @@ rolled back.
|
||||
3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
`CHANGE-CAUSE` is copied from the Deployment annotation `kubernetes.io/change-cause` to its revisions upon creation. You can specify the`CHANGE-CAUSE` message by:
|
||||
-->
|
||||
`CHANGE-CAUSE` 从 Deployment 注释 `kubernetes.io/change-cause` 创建时复制到其修改版。可以通过以下条件指定 `CHANGE-CAUSE` 消息:
|
||||
|
||||
<!--
|
||||
<!--
|
||||
* Annotating the Deployment with `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"`
|
||||
* Append the `--record` flag to save the `kubectl` command that is making changes to the resource.
|
||||
* Manually editing the manifest of the resource.
|
||||
@@ -809,7 +823,7 @@ rolled back.
|
||||
kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -845,14 +859,14 @@ Follow the steps given below to rollback the Deployment from the current version
|
||||
kubectl rollout undo deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
```
|
||||
deployment.apps/nginx-deployment
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`:
|
||||
-->
|
||||
或者,可以通过使用 `--to-revision` 来回滚到特定修改版本:
|
||||
@@ -861,7 +875,7 @@ Follow the steps given below to rollback the Deployment from the current version
|
||||
kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -869,12 +883,12 @@ Follow the steps given below to rollback the Deployment from the current version
|
||||
deployment.apps/nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
For more details about rollout related commands, read [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout).
|
||||
-->
|
||||
更多有关回滚相关指令,请参考 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout).
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event
|
||||
for rolling back to revision 2 is generated from Deployment controller.
|
||||
-->
|
||||
@@ -888,7 +902,7 @@ Follow the steps given below to rollback the Deployment from the current version
|
||||
kubectl get deployment nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -896,6 +910,7 @@ Follow the steps given below to rollback the Deployment from the current version
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3 3 3 3 30m
|
||||
```
|
||||
|
||||
<!--
|
||||
3. Get the description of the Deployment:
|
||||
-->
|
||||
@@ -903,7 +918,7 @@ Follow the steps given below to rollback the Deployment from the current version
|
||||
```shell
|
||||
kubectl describe deployment nginx-deployment
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -956,6 +971,7 @@ Follow the steps given below to rollback the Deployment from the current version
|
||||
-->
|
||||
## 缩放 Deployment
|
||||
|
||||
|
||||
<!--
|
||||
You can scale a Deployment by using the following command:
|
||||
-->
|
||||
@@ -964,6 +980,7 @@ Follow the steps given below to rollback the Deployment from the current version
|
||||
```shell
|
||||
kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
@@ -983,6 +1000,7 @@ Pods you want to run based on the CPU utilization of your existing Pods.
|
||||
```shell
|
||||
kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
@@ -1016,7 +1034,8 @@ ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *p
|
||||
```shell
|
||||
kubectl get deploy
|
||||
```
|
||||
<!--
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1034,7 +1053,7 @@ ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *p
|
||||
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1050,7 +1069,7 @@ ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *p
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1089,6 +1108,7 @@ kubectl get deploy
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 15 18 7 8 7m
|
||||
```
|
||||
|
||||
<!--
|
||||
The rollout status confirms how the replicas were added to each ReplicaSet.
|
||||
-->
|
||||
@@ -1127,7 +1147,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
```shell
|
||||
kubectl get deploy
|
||||
```
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1135,14 +1155,16 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx 3 3 3 3 1m
|
||||
```
|
||||
<!--
|
||||
|
||||
<!--
|
||||
Get the rollout status:
|
||||
-->
|
||||
获取 Deployment 状态:
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
<!--
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1159,7 +1181,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
kubectl rollout pause deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1175,7 +1197,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1191,7 +1213,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
kubectl rollout history deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1200,6 +1222,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
REVISION CHANGE-CAUSE
|
||||
1 <none>
|
||||
```
|
||||
|
||||
<!--
|
||||
* Get the rollout status to ensure that the Deployment is updates successfully:
|
||||
-->
|
||||
@@ -1208,7 +1231,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
kubectl get rs
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1225,7 +1248,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1233,7 +1256,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
deployment.apps/nginx-deployment resource requirements updated
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The initial state of the Deployment prior to pausing it will continue its function, but new updates to
|
||||
the Deployment will not have any effect as long as the Deployment is paused.
|
||||
-->
|
||||
@@ -1247,7 +1270,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
kubectl rollout resume deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1262,7 +1285,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
kubectl get rs -w
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1283,6 +1306,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
nginx-2142116321 0 0 0 2m
|
||||
nginx-3926361531 3 3 3 20s
|
||||
```
|
||||
|
||||
<!--
|
||||
* Get the status of the latest rollout:
|
||||
-->
|
||||
@@ -1291,7 +1315,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
kubectl get rs
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
@@ -1317,6 +1341,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
||||
rolling out a new ReplicaSet, it can be [complete](#complete-deployment), or it can [fail to progress](#failed-deployment).
|
||||
-->
|
||||
一个 Deployment 的生命周期中会有许多状态。当正在生产新的 ReplicaSet 时可能是[正在运行](#progressing-deployment),可能是[已完成](#complete-deployment),也可能是[ Deployment 失败](#failed-deployment)。
|
||||
|
||||
<!--
|
||||
### Progressing Deployment
|
||||
-->
|
||||
@@ -1358,10 +1383,12 @@ Kubernetes 将 Deployment 标记为 _完成_,当它具有以下特征时:
|
||||
updates you've requested have been completed.
|
||||
-->
|
||||
* 与 Deployment 关联的所有副本都已更新到指定的最新版本,这意味着请求的任何更新都已完成。
|
||||
|
||||
<!--
|
||||
* All of the replicas associated with the Deployment are available.
|
||||
-->
|
||||
* 与 Deployment 关联的所有副本都可用。
|
||||
|
||||
<!--
|
||||
* No old replicas for the Deployment are running.
|
||||
-->
|
||||
@@ -1376,6 +1403,7 @@ successfully, `kubectl rollout status` returns a zero exit code.
|
||||
```shell
|
||||
kubectl rollout status deployment.v1.apps/nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
@@ -1396,7 +1424,7 @@ $ echo $?
|
||||
Your Deployment may get stuck trying to deploy its newest ReplicaSet without ever completing. This can occur
|
||||
due to some of the following factors:
|
||||
-->
|
||||
的 Deployment 可能会在未完成的情况下尝试 Deployment 其最新的 ReplicaSet 时遇到问题。可能发生此情况由于以下一些因素:
|
||||
你的 Deployment 可能会在未完成的情况下尝试 Deployment 其最新的 ReplicaSet 时遇到问题。可能发生此情况由于以下一些因素:
|
||||
|
||||
<!--
|
||||
* Insufficient quota
|
||||
@@ -1430,6 +1458,7 @@ lack of progress for a Deployment after 10 minutes:
|
||||
```shell
|
||||
kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
@@ -1437,6 +1466,7 @@ kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadline
|
||||
```
|
||||
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`:
|
||||
@@ -1480,6 +1510,7 @@ insufficient quota. If you describe the Deployment you will notice the following
|
||||
```shell
|
||||
kubectl describe deployment nginx-deployment
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
@@ -1846,6 +1877,7 @@ a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/
|
||||
Field `.spec.rollbackTo` has been deprecated in API versions `extensions/v1beta1` and `apps/v1beta1`, and is no longer supported in API versions starting `apps/v1beta2`. Instead, `kubectl rollout undo` as introduced in [Rolling Back to a Previous Revision](#rolling-back-to-a-previous-revision) should be used.
|
||||
-->
|
||||
`.spec.rollbackTo` 字段已经在 API 版本 `extensions/v1beta1` 和 `apps/v1beta1`中废弃了,并且从 `apps/v1beta2`版本开始不在支持。相应的,会开始使用已经引入[回滚到上一个版本](#rolling-back-to-a-previous-revision)中的 `kubectl rollout undo`。
|
||||
|
||||
<!--
|
||||
### Revision History Limit
|
||||
-->
|
||||
@@ -1894,6 +1926,7 @@ it is created.
|
||||
<!--
|
||||
[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) updates Pods and ReplicationControllers
|
||||
-->
|
||||
|
||||
<!--
|
||||
in a similar fashion. But Deployments are recommended, since they are declarative, server side, and have
|
||||
additional features, such as rolling back to any previous revision even after the rolling update is done.
|
||||
|
||||
@@ -44,6 +44,7 @@ Read operations:
|
||||
* nodes
|
||||
* pods
|
||||
* secrets、configmaps、以及绑定到 kubelet 的节点的 pod 的持久卷申领和持久卷
|
||||
|
||||
<!--
|
||||
* services
|
||||
* endpoints
|
||||
@@ -60,6 +61,7 @@ Write operations:
|
||||
* 节点和节点状态(启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改自己的节点)
|
||||
* Pod 和 Pod 状态 (启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改绑定到自身的 Pod)
|
||||
* 事件
|
||||
|
||||
<!--
|
||||
* nodes and node status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify its own node)
|
||||
* pods and pod status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify pods bound to itself)
|
||||
@@ -73,6 +75,7 @@ Auth-related operations:
|
||||
|
||||
* 对于基于 TLS 的启动引导过程时使用的 certificationsigningrequests API 的读/写权限
|
||||
* 为委派的身份验证/授权检查创建 tokenreviews 和 subjectaccessreviews 的能力
|
||||
|
||||
<!--
|
||||
* read/write access to the certificationsigningrequests API for TLS bootstrapping
|
||||
* the ability to create tokenreviews and subjectaccessreviews for delegated authentication/authorization checks
|
||||
|
||||
@@ -529,6 +529,7 @@ kubectl [flags]
|
||||
* [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions) - 以“组/版本”的格式输出服务端所支持的 API 版本
|
||||
* [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) - 基于文件名或标准输入,将新的配置应用到资源上
|
||||
* [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands#attach) - 连接到一个正在运行的容器
|
||||
|
||||
<!--
|
||||
* [kubectl auth](/docs/reference/generated/kubectl/kubectl-commands#auth) - Inspect authorization
|
||||
* [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) - Auto-scale a Deployment, ReplicaSet, or ReplicationController
|
||||
@@ -543,6 +544,7 @@ kubectl [flags]
|
||||
* [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info) - 显示集群信息
|
||||
* [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion) - 根据已经给出的 Shell(bash 或 zsh),输出 Shell 补全后的代码
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) - 修改 kubeconfig 配置文件
|
||||
|
||||
<!--
|
||||
* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) - Convert config files between different API versions
|
||||
* [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon) - Mark node as unschedulable
|
||||
@@ -555,6 +557,7 @@ kubectl [flags]
|
||||
* [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp) - 将文件和目录拷入/拷出容器。
|
||||
* [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) - 通过文件或标准输入来创建资源
|
||||
* [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete) - 通过文件名、标准输入、资源和名字删除资源,或者通过资源和标签选择器来删除资源
|
||||
|
||||
<!--
|
||||
* [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe) - Show details of a specific resource or group of resources
|
||||
* [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff) - Diff live version against would-be applied version
|
||||
@@ -571,6 +574,7 @@ kubectl [flags]
|
||||
* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands#exec) - 在容器中执行相关命令
|
||||
* [kubectl explain](/docs/reference/generated/kubectl/kubectl-commands#explain) - 显示资源文档说明
|
||||
* [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands#expose) - 给定副本控制器、服务、Deployment 或 Pod,将其暴露为新的 kubernetes Service
|
||||
|
||||
<!--
|
||||
* [kubectl get](/docs/reference/generated/kubectl/kubectl-commands#get) - Display one or many resources
|
||||
* [kubectl kustomize](/docs/reference/generated/kubectl/kubectl-commands#kustomize) - Build a kustomization target from a directory or a remote url.
|
||||
@@ -585,6 +589,7 @@ kubectl [flags]
|
||||
* [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs) - 输出 pod 中某容器的日志
|
||||
* [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options) - 打印所有命令都支持的共有参数列表
|
||||
* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch) - 基于策略性合并修补(Stategic Merge Patch)规则更新某资源中的字段
|
||||
|
||||
<!--
|
||||
* [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin) - Provides utilities for interacting with plugins.
|
||||
* [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward) - Forward one or more local ports to a pod
|
||||
@@ -599,6 +604,7 @@ kubectl [flags]
|
||||
* [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands#replace) - 基于文件名或标准输入替换资源
|
||||
* [kubectl rollout](/docs/reference/generated/kubectl/kubectl-commands#rollout) - 管理资源的上线
|
||||
* [kubectl run](/docs/reference/generated/kubectl/kubectl-commands#run) - 在集群中使用指定镜像启动容器
|
||||
|
||||
<!--
|
||||
* [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands#scale) - Set a new size for a Deployment, ReplicaSet, Replication Controller, or Job
|
||||
* [kubectl set](/docs/reference/generated/kubectl/kubectl-commands#set) - Set specific features on objects
|
||||
|
||||
@@ -186,6 +186,7 @@ for LoadBalancer and NodePort type services, but risks potentially imbalanced
|
||||
traffic spreading.
|
||||
-->
|
||||
* `service.spec.externalTrafficPolicy` - 表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。有两个可用选项:Cluster(默认)和 Local。Cluster 隐藏了客户端源 IP,可能导致第二跳到另一个节点,但具有良好的整体负载分布。Local 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务的第二跳,但存在潜在的不均衡流量传播风险。
|
||||
|
||||
<!--
|
||||
* `service.spec.healthCheckNodePort` - specifies the health check nodePort
|
||||
(numeric port number) for the service. If not specified, `healthCheckNodePort` is
|
||||
|
||||
@@ -44,18 +44,21 @@ ip-masq-agent 配置 iptables 规则以隐藏位于集群节点 IP 地址后面
|
||||
-->
|
||||
* **NAT (网络地址解析)**
|
||||
是一种通过修改 IP 地址头中的源和/或目标地址信息将一个 IP 地址重新映射到另一个 IP 地址的方法。通常由执行 IP 路由的设备执行。
|
||||
|
||||
<!--
|
||||
* **Masquerading**
|
||||
A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In Kubernetes this is the Node's IP address.
|
||||
-->
|
||||
* **伪装**
|
||||
NAT 的一种形式,通常用于执行多对一地址转换,其中多个源 IP 地址被隐藏在单个地址后面,该地址通常是执行 IP 路由的设备。在 Kubernetes 中,这是节点的 IP 地址。
|
||||
|
||||
<!--
|
||||
* **CIDR (Classless Inter-Domain Routing)**
|
||||
Based on the variable-length subnet masking, allows specifying arbitrary-length prefixes. CIDR introduced a new method of representation for IP addresses, now commonly known as **CIDR notation**, in which an address or routing prefix is written with a suffix indicating the number of bits of the prefix, such as 192.168.2.0/24.
|
||||
-->
|
||||
* **CIDR (无类别域间路由)**
|
||||
基于可变长度子网掩码,允许指定任意长度的前缀。CIDR 引入了一种新的 IP 地址表示方法,现在通常称为**CIDR表示法**,其中地址或路由前缀后添加一个后缀,用来表示前缀的位数,例如 192.168.2.0/24。
|
||||
|
||||
<!--
|
||||
* **Link Local**
|
||||
A link-local address is a network address that is valid only for communications within the network segment or the broadcast domain that the host is connected to. Link-local addresses for IPv4 are defined in the address block 169.254.0.0/16 in CIDR notation.
|
||||
@@ -79,10 +82,12 @@ The agent configuration file must be written in YAML or JSON syntax, and may con
|
||||
* **nonMasqueradeCIDRs:** A list of strings in [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges.
|
||||
-->
|
||||
* **nonMasqueradeCIDRs:** [CIDR](https://zh.wikipedia.org/wiki/%E6%97%A0%E7%B1%BB%E5%88%AB%E5%9F%9F%E9%97%B4%E8%B7%AF%E7%94%B1) 表示法中的字符串列表,用于指定不需伪装的地址范围。
|
||||
|
||||
<!--
|
||||
* **masqLinkLocal:** A Boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
|
||||
-->
|
||||
* **masqLinkLocal:** 布尔值 (true / false),表示是否将流量伪装到本地链路前缀169.254.0.0/16。 默认为 false。
|
||||
|
||||
<!--
|
||||
* **resyncInterval:** An interval at which the agent attempts to reload config from disk. e.g. '30s' where 's' is seconds, 'ms' is milliseconds etc...
|
||||
-->
|
||||
|
||||
@@ -120,6 +120,7 @@ This works for e2e clusters created on GCE. On all other environments, the follo
|
||||
* A yaml similar to [this](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml) can be applied using `kubectl create -f` command.
|
||||
-->
|
||||
* 可以使用 `kubectl create -f` 命令应用类似于[这个](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml)的 Yaml 。
|
||||
|
||||
<!--
|
||||
* --cluster-dns flag to kubelet needs to be modified to use the LOCAL_DNS IP that NodeLocal DNSCache is listening on (169.254.20.10 by default)
|
||||
-->
|
||||
|
||||
@@ -40,6 +40,7 @@ applications, such as key-value stores (such as Redis) and databases.
|
||||
## 为 Pod 配置卷
|
||||
|
||||
在本练习中,您将创建一个运行 Pod,该 Pod 仅运行一个容器并拥有一个类型为 [emptyDir](/docs/concepts/storage/volumes/#emptydir) 的卷,在整个 Pod 生命周期中一直存在,即使 Pod 中的容器被终止和重启。以下是 Pod 的配置:
|
||||
|
||||
<!--
|
||||
## Configure a volume for a Pod
|
||||
|
||||
@@ -185,6 +186,7 @@ of `Always`.
|
||||
* 参阅 [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)。
|
||||
|
||||
* 除了 `emptyDir` 提供的本地磁盘存储外,Kubernetes 还支持许多不同的网络附加存储解决方案,包括 GCE 上的 PD 和 EC2 上的 EBS,它们是关键数据的首选,并将处理节点上的一些细节,例如安装和卸载设备。了解更多详情请参阅[卷](/docs/concepts/storage/volumes/)。
|
||||
|
||||
<!--
|
||||
* See [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core).
|
||||
|
||||
|
||||
@@ -36,6 +36,7 @@ parallelism and completions exist across the registered clusters.
|
||||
|
||||
* {{< include "federated-task-tutorial-prereqs.md" >}}
|
||||
* 你需要具备基本的 [Kubernetes 的工作知识](/docs/tutorials/kubernetes-basics/),特别是 [job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。
|
||||
|
||||
<!--
|
||||
* You should also have a basic
|
||||
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
|
||||
|
||||
Reference in New Issue
Block a user