whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Sync between master and dev-1.18

Browse Source 
This PR contains sync up between master and dev-1.18 and also reolsved merge conflicts occured during previous sync during previous sync up caused due to missed adding tide-method merge

Signed-off-by: vineeth <vineethpothulapati@outlook.com>
This commit is contained in:
vineeth
2020-02-14 01:30:05 +05:30
parent 63f30b086a 669bf498a9
commit 9433b26564
37 changed files with 1287 additions and 433 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/services-networking/ingress.md
+18 -8
View File
@@ -35,35 +35,45 @@ For clarity, this guide defines the following terms:
Node
: A worker machine in Kubernetes, part of a cluster.
-->
节点（Node）
: Kubernetes 集群中其中一台工作机器，是集群的一部分。
节点（Node）:
Kubernetes 集群中其中一台工作机器，是集群的一部分。
<!--
Cluster
: A set of Nodes that run containerized applications managed by Kubernetes. For this example, and in most common Kubernetes deployments, nodes in the cluster are not part of the public internet.
-->
集群（Cluster）
: 一组运行程序（这些程序是容器化的，被 Kubernetes 管理的）的节点。 在此示例中，和在大多数常见的Kubernetes部署方案，集群中的节点都不会是公共网络。
集群（Cluster）:
一组运行程序（这些程序是容器化的，被 Kubernetes 管理的）的节点。 在此示例中，和在大多数常见的Kubernetes部署方案，集群中的节点都不会是公共网络。
<!--
Edge router
: A router that enforces the firewall policy for your cluster. This could be a gateway managed by a cloud provider or a physical piece of hardware.
-->
边缘路由器（Edge router）
: 在集群中强制性执行防火墙策略的路由器（router）。可以是由云提供商管理的网关，也可以是物理硬件。
边缘路由器（Edge router）:
在集群中强制性执行防火墙策略的路由器（router）。可以是由云提供商管理的网关，也可以是物理硬件。
<!--
Cluster network
: A set of links, logical or physical, that facilitate communication within a cluster according to the Kubernetes [networking model](/docs/concepts/cluster-administration/networking/).
-->
集群网络（Cluster network）
: 一组逻辑或物理的链接，根据 Kubernetes [网络模型](/docs/concepts/cluster-administration/networking/) 在集群内实现通信。
集群网络（Cluster network）:
一组逻辑或物理的链接，根据 Kubernetes [网络模型](/docs/concepts/cluster-administration/networking/) 在集群内实现通信。
<!--
Service
: A Kubernetes {{< glossary_tooltip term_id="service" >}} that identifies a set of Pods using {{< glossary_tooltip text="label" term_id="label" >}} selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network.
-->
服务（Service）：
Kubernetes {{< glossary_tooltip term_id="service" >}} 使用 {{< glossary_tooltip text="标签" term_id="label" >}} 选择器（selectors）标识的一组 Pod。除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。
content/zh/docs/concepts/workloads/controllers/deployment.md
+325 -63
View File
@@ -42,8 +42,10 @@ Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in th
{{% /capture %}}
You describe a _desired state_ in a Deployment, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
{{% capture body %}}
-->
描述 Deployment 中的 _desired state_，并且 Deployment 控制器以受控速率更改实际状态，以达到期望状态。可以定义 Deployments 以创建新的 ReplicaSets ，或删除现有 Deployments ，并通过新的 Deployments 使用其所有资源。
<!--
@@ -144,7 +146,9 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
-->
* `selector` 字段定义 Deployment 如何查找要管理的 Pods。
在这种情况下，只需选择在 Pod 模板（`app: nginx`）中定义的标签。但是，更复杂的选择规则是可能的，只要 Pod 模板本身满足规则。
{{< note >}}
{{< 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",
@@ -152,7 +156,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
-->
`matchLabels` 字段是 {key,value} 的映射。单个 {key,value}在 `matchLabels` 映射中的值等效于 `matchExpressions` 的元素，其键字段是“key”，运算符为“In”，值数组仅包含“value”。所有要求，从 `matchLabels` 和 `matchExpressions`，必须满足才能匹配。
{{< /note >}}
{{< /note >}}
<!--
* The `template` field contains the following sub-fields:
@@ -191,16 +195,16 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
-->
1. 通过运行以下命令创建 Deployment ：
{{< note >}}
<!--
{{< note >}}
<!--
You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future introspection.
-->
可以指定 `--record` 标志来写入在资源注释`kubernetes.io/change-cause`中执行的命令。它对以后的检查是有用的。
<!--
<!--
For example, to see the commands executed in each Deployment revision.
-->
例如，查看在每个 Deployment 修改中执行的命令。
{{< /note >}}
{{< /note >}}
```shell
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
@@ -210,10 +214,12 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
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 ，则输出以下内容：
```shell
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:
-->
@@ -243,6 +249,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
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`。输出：
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
@@ -252,6 +259,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
4. Run the `kubectl get deployments` again a few seconds later. The output is similar to this:
-->
4. 几秒钟后再次运行 `kubectl get deployments`。输出：
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 18s
@@ -265,6 +273,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
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`。输出：
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
@@ -279,6 +288,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
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`。返回以下输出：
```shell
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
@@ -291,13 +301,13 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
-->
创建的复制集可确保有三个 `nginx` Pods。
{{< note >}}
{{< 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.
-->
必须在 Deployment 中指定适当的选择器和 Pod 模板标签（在本例中为`app: nginx`）。不要与其他控制器（包括其他 Deployments 和状态设置）重叠标签或选择器。Kubernetes 不会阻止重叠，如果多个控制器具有重叠的选择器，这些控制器可能会冲突并运行意外。
{{< /note >}}
{{< /note >}}
<!--
### Pod-template-hash label
@@ -343,16 +353,18 @@ is changed, for example if the labels or container images of the template are up
<!--
1. Let's update the nginx Pods to use the `nginx:1.9.1` image instead of the `nginx:1.7.9` image.
-->
1. 让我们更新 nginx Pods，以使用 `nginx:1.9.1` 镜像 ，而不是 `nginx:1.7.9` 镜像 。
1. 让我们更新 nginx Pods，以使用 `nginx:1.9.1` 镜像 ，而不是 `nginx:1.7.9` 镜像 。
```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:
-->
输出：
```
```shell
deployment.apps/nginx-deployment image updated
```
@@ -368,15 +380,17 @@ is changed, for example if the labels or container images of the template are up
<!--
The output is similar to this:
-->
输出：
```
```shell
deployment.apps/nginx-deployment edited
```
<!--
2. To see the rollout status, run:
-->
2. 要查看展开状态，运行：
2. 要查看展开状态，运行：
```shell
kubectl rollout status deployment.v1.apps/nginx-deployment
@@ -386,14 +400,16 @@ is changed, for example if the labels or container images of the template are up
The output is similar to this:
-->
输出：
```
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
```
<!--
or
-->
或者
```
```shell
deployment.apps/nginx-deployment successfully rolled out
```
@@ -408,7 +424,8 @@ is changed, for example if the labels or container images of the template are up
-->
* 在展开成功后，可以通过运行 `kubectl get deployments`来查看 Deployment 。
输出：
```
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 36s
```
@@ -427,7 +444,8 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
The output is similar to this:
-->
输出：
```
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 3 6s
nginx-deployment-2035384211 0 0 0 36s
@@ -446,7 +464,8 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
The output is similar to this:
-->
输出：
```
```shell
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-khku8 1/1 Running 0 14s
nginx-deployment-1564180365-nacti 1/1 Running 0 14s
@@ -486,10 +505,11 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
kubectl describe deployments
```
<!--
The output is similar to this:
The output is similar to this:
-->
输出：
```
```shell
Name: nginx-deployment
Namespace: default
CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000
@@ -526,7 +546,8 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1
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
@@ -636,7 +657,8 @@ rolled back.
The output is similar to this:
-->
输出：
```
```shell
deployment.apps/nginx-deployment image updated
```
@@ -653,7 +675,8 @@ rolled back.
The output is similar to this:
-->
输出：
```
```shell
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
```
@@ -678,7 +701,8 @@ rolled back.
The output is similar to this:
-->
输出：
```
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 3 25s
nginx-deployment-2035384211 0 0 0 36s
@@ -698,7 +722,8 @@ rolled back.
The output is similar to this:
-->
输出：
```
```shell
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-70iae 1/1 Running 0 25s
nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s
@@ -706,17 +731,17 @@ rolled back.
nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s
```
{{< note >}}
{{< 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%.
-->
Deployment 控制器自动停止不良展开，并停止向上扩展新的 ReplicaSet 。这取决于指定的滚动更新参数（具体为 `maxUnavailable`）。默认情况下，Kubernetes 将值设置为 25%。
{{< /note >}}
{{< /note >}}
<!--
* Get the description of the Deployment:
* Get the description of the Deployment:
-->
* 获取 Deployment 描述信息：
```shell
@@ -724,10 +749,11 @@ rolled back.
```
<!--
The output is similar to this:
The output is similar to this:
-->
输出：
```
```shell
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
@@ -783,17 +809,19 @@ rolled back.
按照如下步骤检查回滚历史：
<!--
1. First, check the revisions of this Deployment:
1. First, check the revisions of this Deployment:
-->
1. 首先，检查 Deployment 修改历史：
1. 首先，检查 Deployment 修改历史：
```shell
kubectl rollout history deployment.v1.apps/nginx-deployment
```
<!--
The output is similar to this:
The output is similar to this:
-->
输出：
```
```shell
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
@@ -818,16 +846,18 @@ rolled back.
<!--
2. To see the details of each revision, run:
-->
2. 查看修改历史的详细信息，运行：
2. 查看修改历史的详细信息，运行：
```shell
kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
```
<!--
The output is similar to this:
The output is similar to this:
-->
输出：
```
```shell
deployments "nginx-deployment" revision 2
Labels: app=nginx
pod-template-hash=1159050644
@@ -854,16 +884,18 @@ Follow the steps given below to rollback the Deployment from the current version
<!--
1. Now you've decided to undo the current rollout and rollback to the previous revision:
-->
1. 现在已决定撤消当前展开并回滚到以前的版本：
1. 现在已决定撤消当前展开并回滚到以前的版本：
```shell
kubectl rollout undo deployment.v1.apps/nginx-deployment
```
<!--
The output is similar to this:
The output is similar to this:
-->
输出：
```
```shell
deployment.apps/nginx-deployment
```
<!--
@@ -876,10 +908,11 @@ Follow the steps given below to rollback the Deployment from the current version
```
<!--
The output is similar to this:
The output is similar to this:
-->
输出：
```
```shell
deployment.apps/nginx-deployment
```
@@ -897,16 +930,18 @@ Follow the steps given below to rollback the Deployment from the current version
<!--
2. Check if the rollback was successful and the Deployment is running as expected, run:
-->
2. 检查回滚是否成功、 Deployment 是否正在运行，运行：
2. 检查回滚是否成功、 Deployment 是否正在运行，运行：
```shell
kubectl get deployment nginx-deployment
```
<!--
The output is similar to this:
The output is similar to this:
-->
输出：
```
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 30m
```
@@ -914,15 +949,18 @@ Follow the steps given below to rollback the Deployment from the current version
<!--
3. Get the description of the Deployment:
-->
3. 获取 Deployment 描述信息：
3. 获取 Deployment 描述信息：
```shell
kubectl describe deployment nginx-deployment
```
<!--
The output is similar to this:
The output is similar to this:
-->
输出：
```
```shell
Name: nginx-deployment
Namespace: default
CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
@@ -985,7 +1023,8 @@ kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
The output is similar to this:
-->
输出：
```
```shell
deployment.apps/nginx-deployment scaled
```
@@ -1005,7 +1044,8 @@ kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-pe
The output is similar to this:
-->
输出：
```
```shell
deployment.apps/nginx-deployment scaled
```
@@ -1040,7 +1080,7 @@ ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *p
-->
输出：
```
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 10 10 10 10 50s
```
@@ -1057,7 +1097,8 @@ ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *p
The output is similar to this:
-->
输出：
```
```shell
deployment.apps/nginx-deployment image updated
```
@@ -1073,7 +1114,8 @@ ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *p
The output is similar to this:
-->
输出：
```
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 5 5 0 9s
nginx-deployment-618515232 8 8 8 1m
@@ -1092,7 +1134,7 @@ ReplicaSet with the most replicas. ReplicaSets with zero replicas are not scaled
<!--
In our example above, 3 replicas are added to the old ReplicaSet and 2 replicas are added to the
new ReplicaSet. The rollout process should eventually move all replicas to the new ReplicaSet, assuming
the new replicas become healthy. To confirm this, run:
the new replicas become healthy. To confirm this, run:
-->
在上面的示例中，3 个副本添加到旧 ReplicaSet 中，2 个副本添加到新 ReplicaSet 。展开过程最终应将所有副本移动到新的 ReplicaSet ，假定新的副本变得正常。要确认这一点，请运行：
@@ -1104,7 +1146,8 @@ kubectl get deploy
The output is similar to this:
-->
输出：
```
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 15 18 7 8 7m
```
@@ -1113,6 +1156,7 @@ nginx-deployment 15 18 7 8 7m
The rollout status confirms how the replicas were added to each ReplicaSet.
-->
展开状态确认副本如何添加到每个 ReplicaSet 。
```shell
kubectl get rs
```
@@ -1121,7 +1165,8 @@ kubectl get rs
The output is similar to this:
-->
输出：
```
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
@@ -1138,6 +1183,219 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
-->
可以在触发一个或多个更新之前暂停 Deployment ，然后继续它。这允许在暂停和恢复之间应用多个修补程序，而不会触发不必要的 Deployment 。
<!--
* For example, with a Deployment that was just created:
Get the Deployment details:
-->
* 例如，对于一个刚刚创建的 Deployment ：
获取 Deployment 信息：
```shell
kubectl get deploy
```
<!--
The output is similar to this:
-->
输出：
```shell
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:
-->
输出：
```shell
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 1m
```
<!--
* Pause by running the following command:
-->
使用如下指令中断运行：
```shell
kubectl rollout pause deployment.v1.apps/nginx-deployment
```
<!--
The output is similar to this:
-->
输出：
```shell
deployment.apps/nginx-deployment paused
```
<!--
* Then update the image of the Deployment:
-->
* 然后更新 Deployment 镜像：
```shell
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
```
<!--
The output is similar to this:
-->
输出：
```shell
deployment.apps/nginx-deployment image updated
```
<!--
* Notice that no new rollout started:
-->
* 注意没有新的展开：
```shell
kubectl rollout history deployment.v1.apps/nginx-deployment
```
<!--
The output is similar to this:
-->
输出：
```shell
deployments "nginx"
REVISION CHANGE-CAUSE
1 <none>
```
<!--
* Get the rollout status to ensure that the Deployment is updates successfully:
-->
* 获取展开状态确保 Deployment 更新已经成功：
```shell
kubectl get rs
```
<!--
The output is similar to this:
-->
输出：
```shell
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 2m
```
<!--
* You can make as many updates as you wish, for example, update the resources that will be used:
-->
* 更新是很容易的，例如，可以这样更新使用到的资源：
```shell
kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
```
<!--
The output is similar to this:
-->
输出：
```shell
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.
-->
暂停 Deployment 之前的初始状态将继续其功能，但新的更新只要暂停 Deployment ， Deployment 就不会产生任何效果。
<!--
* Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
-->
* 最后，恢复 Deployment 并观察新的 ReplicaSet ，并更新所有新的更新：
```shell
kubectl rollout resume deployment.v1.apps/nginx-deployment
```
<!--
The output is similar to this:
-->
输出：
```shell
deployment.apps/nginx-deployment resumed
```
<!--
* Watch the status of the rollout until it's done.
-->
* 观察展开的状态，直到完成。
```shell
kubectl get rs -w
```
<!--
The output is similar to this:
-->
输出：
```shell
NAME DESIRED CURRENT READY AGE
nginx-2142116321 2 2 2 2m
nginx-3926361531 2 2 0 6s
nginx-3926361531 2 2 1 18s
nginx-2142116321 1 2 2 2m
nginx-2142116321 1 2 2 2m
nginx-3926361531 3 2 1 18s
nginx-3926361531 3 2 1 18s
nginx-2142116321 1 1 1 2m
nginx-3926361531 3 3 1 18s
nginx-3926361531 3 3 2 19s
nginx-2142116321 0 1 1 2m
nginx-2142116321 0 1 1 2m
nginx-2142116321 0 0 0 2m
nginx-3926361531 3 3 3 20s
```
<!--
* Get the status of the latest rollout:
-->
* 获取最近展开的状态：
```shell
kubectl get rs
```
<!--
The output is similar to this:
-->
输出：
```shell
NAME DESIRED CURRENT READY AGE
nginx-2142116321 0 0 0 2m
nginx-3926361531 3 3 3 28s
```
<!--
You can pause a Deployment before triggering one or more updates and then resume it. This allows you to
apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
-->
可以在触发一个或多个更新之前暂停 Deployment ，然后继续它。这允许在暂停和恢复之间应用多个修补程序，而不会触发不必要的 Deployment 。
<!--
* For example, with a Deployment that was just created:
Get the Deployment details:
@@ -1408,7 +1666,8 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
The output is similar to this:
-->
输出：
```
```shell
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment.apps/nginx-deployment successfully rolled out
$ echo $?
@@ -1463,7 +1722,8 @@ kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadline
The output is similar to this:
-->
输出：
```
```shell
deployment.apps/nginx-deployment patched
```
@@ -1515,7 +1775,8 @@ kubectl describe deployment nginx-deployment
The output is similar to this:
-->
输出：
```
```shell
<...>
Conditions:
Type Status Reason
@@ -1531,7 +1792,7 @@ Conditions:
-->
如果运行 `kubectl get deployment nginx-deployment -o yaml`， Deployment 状态输出：
```
```shell
status:
availableReplicas: 2
conditions:
@@ -1565,7 +1826,7 @@ reason for the Progressing condition:
-->
最终，一旦超过 Deployment 进度截止时间，Kubernetes 将更新状态和进度状态：
```
```shell
Conditions:
Type Status Reason
---- ------ ------
@@ -1582,7 +1843,7 @@ Deployment's status update with a successful condition (`Status=True` and `Reaso
-->
可以通过缩减 Deployment 来解决配额不足的问题，或者直接在命名空间中增加配额。如果配额条件满足， Deployment 控制器完成了 Deployment 展开， Deployment 状态会更新为成功（`Status=True` and `Reason=NewReplicaSetAvailable`）。
```
```shell
Conditions:
Type Status Reason
---- ------ ------
@@ -1612,7 +1873,8 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
The output is similar to this:
-->
输出：
```
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline
$ echo $?
content/zh/docs/tasks/federation/policy.rego
-74
View File
@@ -1,74 +0,0 @@
# OPA supports a high-level declarative language named Rego for authoring and
# enforcing policies. For more information on Rego, visit
# http://openpolicyagent.org.
# Rego policies are namespaced by the "package" directive.
package kubernetes.placement
# Imports provide aliases for data inside the policy engine. In this case, the
# policy simply refers to "clusters" below.
import data.kubernetes.clusters
# The "annotations" rule generates a JSON object containing the key
# "federation.kubernetes.io/replica-set-preferences" mapped to <preferences>.
# The preferences values is generated dynamically by OPA when it evaluates the
# rule.
#
# The SchedulingPolicy Admission Controller running inside the Federation API
# server will merge these annotations into incoming Federated resources. By
# setting replica-set-preferences, we can control the placement of Federated
# ReplicaSets.
#
# Rules are defined to generate JSON values (booleans, strings, objects, etc.)
# When OPA evaluates a rule, it generates a value IF all of the expressions in
# the body evaluate successfully. All rules can be understood intuitively as
# <head> if <body> where <body> is true if <expr-1> AND <expr-2> AND ...
# <expr-N> is true (for some set of data.)
annotations["federation.kubernetes.io/replica-set-preferences"] = preferences {
input.kind = "ReplicaSet"
value = {"clusters": cluster_map, "rebalance": true}
json.marshal(value, preferences)
}
# This "annotations" rule generates a value for the "federation.alpha.kubernetes.io/cluster-selector"
# annotation.
#
# In English, the policy asserts that resources in the "production" namespace
# that are not annotated with "criticality=low" MUST be placed on clusters
# labelled with "on-premises=true".
annotations["federation.alpha.kubernetes.io/cluster-selector"] = selector {
input.metadata.namespace = "production"
not input.metadata.annotations.criticality = "low"
json.marshal([{
"operator": "=",
"key": "on-premises",
"values": "[true]",
}], selector)
}
# Generates a set of cluster names that satisfy the incoming Federated
# ReplicaSet's requirements. In this case, just PCI compliance.
replica_set_clusters[cluster_name] {
clusters[cluster_name]
not insufficient_pci[cluster_name]
}
# Generates a set of clusters that must not be used for Federated ReplicaSets
# that request PCI compliance.
insufficient_pci[cluster_name] {
clusters[cluster_name]
input.metadata.annotations["requires-pci"] = "true"
not pci_clusters[cluster_name]
}
# Generates a set of clusters that are PCI certified. In this case, we assume
# clusters are annotated to indicate if they have passed PCI compliance audits.
pci_clusters[cluster_name] {
clusters[cluster_name].metadata.annotations["pci-certified"] = "true"
}
# Helper rule to generate a mapping of desired clusters to weights. In this
# case, weights are static.
cluster_map[cluster_name] = {"weight": 1} {
replica_set_clusters[cluster_name]
}
content/zh/docs/tasks/federation/set-up-placement-policies-federation.md
+76 -1
View File
@@ -188,7 +188,82 @@ Configure a sample policy to test the external policy engine:
-->
配置一个示例策略来测试外部策略引擎:
{{< code file="policy.rego" >}}
```
# OPA supports a high-level declarative language named Rego for authoring and
# enforcing policies. For more information on Rego, visit
# http://openpolicyagent.org.
# Rego policies are namespaced by the "package" directive.
package kubernetes.placement
# Imports provide aliases for data inside the policy engine. In this case, the
# policy simply refers to "clusters" below.
import data.kubernetes.clusters
# The "annotations" rule generates a JSON object containing the key
# "federation.kubernetes.io/replica-set-preferences" mapped to <preferences>.
# The preferences values is generated dynamically by OPA when it evaluates the
# rule.
#
# The SchedulingPolicy Admission Controller running inside the Federation API
# server will merge these annotations into incoming Federated resources. By
# setting replica-set-preferences, we can control the placement of Federated
# ReplicaSets.
#
# Rules are defined to generate JSON values (booleans, strings, objects, etc.)
# When OPA evaluates a rule, it generates a value IF all of the expressions in
# the body evaluate successfully. All rules can be understood intuitively as
# <head> if <body> where <body> is true if <expr-1> AND <expr-2> AND ...
# <expr-N> is true (for some set of data.)
annotations["federation.kubernetes.io/replica-set-preferences"] = preferences {
input.kind = "ReplicaSet"
value = {"clusters": cluster_map, "rebalance": true}
json.marshal(value, preferences)
}
# This "annotations" rule generates a value for the "federation.alpha.kubernetes.io/cluster-selector"
# annotation.
#
# In English, the policy asserts that resources in the "production" namespace
# that are not annotated with "criticality=low" MUST be placed on clusters
# labelled with "on-premises=true".
annotations["federation.alpha.kubernetes.io/cluster-selector"] = selector {
input.metadata.namespace = "production"
not input.metadata.annotations.criticality = "low"
json.marshal([{
"operator": "=",
"key": "on-premises",
"values": "[true]",
}], selector)
}
# Generates a set of cluster names that satisfy the incoming Federated
# ReplicaSet's requirements. In this case, just PCI compliance.
replica_set_clusters[cluster_name] {
clusters[cluster_name]
not insufficient_pci[cluster_name]
}
# Generates a set of clusters that must not be used for Federated ReplicaSets
# that request PCI compliance.
insufficient_pci[cluster_name] {
clusters[cluster_name]
input.metadata.annotations["requires-pci"] = "true"
not pci_clusters[cluster_name]
}
# Generates a set of clusters that are PCI certified. In this case, we assume
# clusters are annotated to indicate if they have passed PCI compliance audits.
pci_clusters[cluster_name] {
clusters[cluster_name].metadata.annotations["pci-certified"] = "true"
}
# Helper rule to generate a mapping of desired clusters to weights. In this
# case, weights are static.
cluster_map[cluster_name] = {"weight": 1} {
replica_set_clusters[cluster_name]
}
```
<!--
Shown below is the command to create the sample policy: