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

translation for the run-app section

Browse Source
This commit is contained in:
Steven Yan
2021-08-18 14:53:12 +08:00
parent 40f055cacc
commit 742e7d7ee4
6 changed files with 35 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/tasks/debug-application-cluster/audit.md
+2 -2
View File
@@ -168,7 +168,7 @@ rules:
<!--
If you're crafting your own audit profile, you can use the audit profile for Google Container-Optimized OS as a starting point. You can check the
[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)
script, which generates the audit policy file. You can see most of the audit policy file by looking directly at the script.
You can also refer to the [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
@@ -176,7 +176,7 @@ for details about the fields defined.
-->
如果你在打磨自己的审计配置文件，你可以使用为 Google Container-Optimized OS
设计的审计配置作为出发点。你可以参考
[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)
脚本，该脚本能够生成审计策略文件。你可以直接在脚本中看到审计策略的绝大部份内容。
你也可以参考 [`Policy` 配置参考](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
content/zh/docs/tasks/debug-application-cluster/debug-cluster.md
+1 -1
View File
@@ -202,7 +202,7 @@ This is an incomplete list of things that could go wrong, and how to adjust your
- Action: Use IaaS providers reliable storage (e.g. GCE PD or AWS EBS volume) for VMs with apiserver+etcd
- Mitigates: Apiserver backing storage lost
- Action: Use [high-availability](/docs/admin/high-availability) configuration
- Action: Use [high-availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) configuration
- Mitigates: Control plane node shutdown or control plane components (scheduler, API server, controller-manager) crashing
- Will tolerate one or more simultaneous node or component failures
- Mitigates: API server backing storage (i.e., etcd's data directory) lost
content/zh/docs/tasks/debug-application-cluster/debug-running-pod.md
+8 -10
View File
@@ -110,30 +110,27 @@ kubectl exec -it cassandra -- sh
<!--
## Debugging with an ephemeral debug container {#ephemeral-container}
{{< feature-state state="alpha" for_k8s_version="v1.18" >}}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
{{< glossary_tooltip text="Ephemeral containers" term_id="ephemeral-container" >}}
are useful for interactive troubleshooting when `kubectl exec` is insufficient
because a container has crashed or a container image doesn't include debugging
utilities, such as with [distroless images](
https://github.com/GoogleContainerTools/distroless). `kubectl` has an alpha
command that can create ephemeral containers for debugging beginning with version
`v1.18`.
https://github.com/GoogleContainerTools/distroless).
-->
## 使用临时调试容器来进行调试 {#ephemeral-container}
{{< feature-state state="alpha" for_k8s_version="v1.18" >}}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
当由于容器崩溃或容器镜像不包含调试程序（例如[无发行版镜像](https://github.com/GoogleContainerTools/distroless)等）
而导致 `kubectl exec` 无法运行时，{{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}}对于排除交互式故障很有用。
从 'v1.18' 版本开始，'kubectl' 有一个可以创建用于调试的临时容器的 alpha 命令。
<!--
### Example debugging using ephemeral containers {#ephemeral-container-example}
The examples in this section require the `EphemeralContainers` [feature gate](
/docs/reference/command-line-tools-reference/feature-gates/) enabled in your
cluster and `kubectl` version v1.18 or later.
cluster and `kubectl` version v1.22 or later.
You can use the `kubectl debug` command to add ephemeral containers to a
running Pod. First, create a pod for the example:
@@ -151,7 +148,7 @@ images.
{{< note >}}
本示例需要你的集群已经开启 `EphemeralContainers`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
`kubectl` 版本为 v1.18 或者更高。
`kubectl` 版本为 v1.22 或者更高。
{{< /note >}}
你可以使用 `kubectl debug` 命令来给正在运行中的 Pod 增加一个临时容器。
@@ -224,7 +221,7 @@ creates.
The `--target` parameter must be supported by the {{< glossary_tooltip
text="Container Runtime" term_id="container-runtime" >}}. When not supported,
the Ephemeral Container may not be started, or it may be started with an
isolated process namespace.
isolated process namespace so that `ps` does not reveal processes in other containers.
You can view the state of the newly created ephemeral container using `kubectl describe`:
-->
@@ -234,7 +231,8 @@ You can view the state of the newly created ephemeral container using `kubectl d
{{< note >}}
{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}必须支持`--target`参数。
如果不支持，则临时容器可能不会启动，或者可能使用隔离的进程命名空间启动。
如果不支持，则临时容器可能不会启动，或者可能使用隔离的进程命名空间启动，
以便 `ps` 不显示其他容器内的进程。
{{< /note >}}
你可以使用 `kubectl describe` 查看新创建的临时容器的状态：
content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+2 -2
View File
@@ -54,11 +54,11 @@ the container starts.
kubectl create -f https://k8s.io/examples/debug/termination.yaml
```
<!--In the YAML file, in the `cmd` and `args` fields, you can see that the
<!--In the YAML file, in the `command` and `args` fields, you can see that the
container sleeps for 10 seconds and then writes "Sleep expired" to
the `/dev/termination-log` file. After the container writes
the "Sleep expired" message, it terminates.-->
YAML 文件中，在 `cmd` 和 `args` 字段，你可以看到容器休眠 10 秒然后将 "Sleep expired"
YAML 文件中，在 `command` 和 `args` 字段，你可以看到容器休眠 10 秒然后将 "Sleep expired"
写入 `/dev/termination-log` 文件。
容器写完 "Sleep expired" 消息后就终止了。
content/zh/docs/tasks/run-application/delete-stateful-set.md
+5 -5
View File
@@ -66,21 +66,21 @@ kubectl delete service <服务名称>
```
<!--
When deleting a StatefulSet through `kubectl`, the StatefulSet scales down to 0. All Pods that are part of this workload are also deleted. If you want to delete only the StatefulSet and not the Pods, use `--cascade=false`.
When deleting a StatefulSet through `kubectl`, the StatefulSet scales down to 0. All Pods that are part of this workload are also deleted. If you want to delete only the StatefulSet and not the Pods, use `--cascade=orphan`.
For example:
--->
当通过 `kubectl` 删除 StatefulSet 时，StatefulSet 会被缩容为 0。
属于该 StatefulSet 的所有 Pod 也被删除。
如果你只想删除 StatefulSet 而不删除 Pod，使用 `--cascade=false`。
如果你只想删除 StatefulSet 而不删除 Pod，使用 `--cascade=orphan`。
```shell
kubectl delete -f <file.yaml> --cascade=false
kubectl delete -f <file.yaml> --cascade=orphan
```
<!--
By passing `--cascade=false` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app=myapp`, you can then delete them as follows:
By passing `--cascade=orphan` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app=myapp`, you can then delete them as follows:
--->
通过将 `--cascade=false` 传递给 `kubectl delete`，在删除 StatefulSet 对象之后，
通过将 `--cascade=orphan` 传递给 `kubectl delete`，在删除 StatefulSet 对象之后，
StatefulSet 管理的 Pod 会被保留下来。如果 Pod 具有标签 `app=myapp`，则可以按照
如下方式删除它们：
content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md
+17 -15
View File
@@ -367,27 +367,29 @@ The detailed documentation of `kubectl autoscale` can be found [here](/docs/refe
<!--
## Autoscaling during rolling update
Currently in Kubernetes, it is possible to perform a rolling update by using the deployment object,
which manages the underlying replica sets for you.
Horizontal Pod Autoscaler only supports the latter approach: the Horizontal Pod Autoscaler is bound to the deployment object,
it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets.
Kubernetes lets you perform a rolling update on a Deployment. In that
case, the Deployment manages the underlying ReplicaSets for you.
When you configure autoscaling for a Deployment, you bind a
HorizontalPodAutoscaler to a single Deployment. The HorizontalPodAutoscaler
manages the `replicas` field of the Deployment. The deployment controller is responsible
for setting the `replicas` of the underlying ReplicaSets so that they add up to a suitable
number during the rollout and also afterwards.
-->
## 滚动升级时扩缩 {#autoscaling-during-rolling-update}
目前在 Kubernetes 中，可以针对 ReplicationController 或 Deployment 执行
滚动更新，它们会为你管理底层副本数。
Pod 水平扩缩只支持后一种：HPA 会被绑定到 Deployment 对象，
HPA 设置副本数量时，Deployment 会设置底层副本数。
Kubernetes 允许你在 Deployment 上执行滚动更新。在这种情况下，Deployment 为你管理下层的 ReplicaSet。
当你为一个 Deployment 配置自动扩缩时，你要为每个 Deployment 绑定一个 HorizontalPodAutoscaler。
HorizontalPodAutoscaler 管理 Deployment 的 `replicas` 字段。
Deployment Controller 负责设置下层 ReplicaSet 的 `replicas` 字段，
以便确保在上线及后续过程副本个数合适。
<!--
Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers,
i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update.
The reason this doesn't work is that when rolling update creates a new replication controller,
the Horizontal Pod Autoscaler will not be bound to the new replication controller.
If you perform a rolling update of a StatefulSet that has an autoscaled number of
replicas, the StatefulSet directly manages its set of Pods (there is no intermediate resource
similar to ReplicaSet).
-->
通过直接操控副本控制器执行滚动升级时，HPA 不能工作，
也就是说你不能将 HPA 绑定到某个 RC 再执行滚动升级。
HPA 不能工作的原因是它无法绑定到滚动更新时所新创建的副本控制器。
如果你对一个副本个数被自动扩缩的 StatefulSet 执行滚动更新， 该 StatefulSet
会直接管理它的 Pod 集合 （不存在类似 ReplicaSet 这样的中间资源）。
<!--
## Support for cooldown/delay