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

[zh]sync misc task files

Browse Source 
related: #29329
This commit is contained in:
chenxuc
2021-08-22 17:19:42 +08:00
parent f244bb0e30
commit a33bc3b2b1
6 changed files with 46 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/tasks/configmap-secret/managing-secret-using-config-file.md
+3 -3
View File
@@ -5,7 +5,7 @@ weight: 20
description: 使用资源配置文件创建 Secret 对象。
---
<!--
title: Managing Secret using Configuration File
title: Managing Secrets using Configuration File
content_type: task
weight: 20
description: Creating Secret objects using resource configuration file.
@@ -259,8 +259,8 @@ kubectl delete secret mysecret
<!--
- Read more about the [Secret concept](/docs/concepts/configuration/secret/)
- Learn how to [manage Secret with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
- Learn how to [manage Secrets with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
-->
- 进一步阅读 [Secret 概念](/zh/docs/concepts/configuration/secret/)
- 了解如何[使用 `kubectl` 命令管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
content/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize.md
+3 -3
View File
@@ -5,7 +5,7 @@ weight: 30
description: 使用 kustomization.yaml 文件创建 Secret 对象。
---
<!--
title: Managing Secret using Kustomize
title: Managing Secrets using Kustomize
content_type: task
weight: 30
description: Creating Secret objects using kustomization.yaml file.
@@ -184,8 +184,8 @@ kubectl delete secret db-user-pass-96mffmfh4k
<!--
- Read more about the [Secret concept](/docs/concepts/configuration/secret/)
- Learn how to [manage Secret with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- Learn how to [manage Secrets with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- Learn how to [manage Secrets using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
-->
- 进一步阅读 [Secret 概念](/zh/docs/concepts/configuration/secret/)
- 了解如何[使用 `kubectl` 命令管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
+2 -2
View File
@@ -27,12 +27,12 @@ Kubernetes API 的一部分。
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the Kubernetes general CA.
-->
{{< note >}}
要使聚合层在你的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证，
需要满足一些设置要求。Kubernetes 和 kube-apiserver 具有多个 CA，
因此请确保代理是由聚合层 CA 签名的，而不是由主 CA 签名的。
因此请确保代理是由聚合层 CA 签名的，而不是由 Kubernetes 通用 CA 签名的。
{{< /note >}}
<!--
content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
+8 -4
View File
@@ -269,22 +269,26 @@ from the YAML you used to create it:
```yaml
apiVersion: v1
kind: List
items:
- apiVersion: stable.example.com/v1
kind: CronTab
metadata:
creationTimestamp: 2017-05-31T12:56:35Z
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"stable.example.com/v1","kind":"CronTab","metadata":{"annotations":{},"name":"my-new-cron-object","namespace":"default"},"spec":{"cronSpec":"* * * * */5","image":"my-awesome-cron-image"}}
creationTimestamp: "2021-06-20T07:35:27Z"
generation: 1
name: my-new-cron-object
namespace: default
resourceVersion: "285"
uid: 9423255b-4600-11e7-af6a-28d2447dc82b
resourceVersion: "1326"
uid: 9aab1d66-628e-41bb-a422-57b8b3b1f5a9
spec:
cronSpec: '* * * * */5'
image: my-awesome-cron-image
kind: List
metadata:
resourceVersion: ""
selfLink: ""
```
<!--
content/zh/docs/tasks/manage-daemon/update-daemon-set.md
+21 -19
View File
@@ -19,10 +19,7 @@ This page shows how to perform a rolling update on a DaemonSet.
## {{% heading "prerequisites" %}}
<!--
* The DaemonSet rolling update feature is only supported in Kubernetes version 1.6 or later.
-->
* Kubernetes 1.6 或者更高版本中才支持 DaemonSet 滚动更新功能。
{{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
@@ -36,20 +33,20 @@ DaemonSet has two update strategy types:
DaemonSet 有两种更新策略：
<!--
* OnDelete: With `OnDelete` update strategy, after you update a DaemonSet template, new
* `OnDelete`: With `OnDelete` update strategy, after you update a DaemonSet template, new
DaemonSet pods will *only* be created when you manually delete old DaemonSet
pods. This is the same behavior of DaemonSet in Kubernetes version 1.5 or
before.
* RollingUpdate: This is the default update strategy.
* `RollingUpdate`: This is the default update strategy.
With `RollingUpdate` update strategy, after you update a
DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods
will be created automatically, in a controlled fashion.
At most one pod of the DaemonSet will be running on each node during the whole update process.
-->
* OnDelete: 使用 `OnDelete` 更新策略时，在更新 DaemonSet 模板后，只有当你手动删除老的
* `OnDelete`: 使用 `OnDelete` 更新策略时，在更新 DaemonSet 模板后，只有当你手动删除老的
DaemonSet pods 之后，新的 DaemonSet Pod *才会*被自动创建。跟 Kubernetes 1.6 以前的版本类似。
* RollingUpdate: 这是默认的更新策略。使用 `RollingUpdate` 更新策略时，在更新 DaemonSet 模板后，
* `RollingUpdate`: 这是默认的更新策略。使用 `RollingUpdate` 更新策略时，在更新 DaemonSet 模板后，
老的 DaemonSet pods 将被终止，并且将以受控方式自动创建新的 DaemonSet pods。
更新期间，最多只能有 DaemonSet 的一个 Pod 运行于每个节点上。
@@ -64,12 +61,18 @@ To enable the rolling update feature of a DaemonSet, you must set its
要启用 DaemonSet 的滚动更新功能，必须设置 `.spec.updateStrategy.type` 为 `RollingUpdate`。
<!--
You may want to set [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) (default
to 1) and [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) as well.
You may want to set
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable)
(default to 1),
[`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds)
(default to 0) and
[`.spec.maxSurge`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-surge)
(a beta feature and defaults to 25%) as well.
-->
你可能想设置
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/zh/docs/concepts/workloads/controllers/deployment/#max-unavailable) (默认为 1) 和
[`.spec.minReadySeconds`](/zh/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (默认为 0)。
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/zh/docs/concepts/workloads/controllers/deployment/#max-unavailable) (默认为 1)，
[`.spec.minReadySeconds`](/zh/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (默认为 0) 和
[`.spec.maxSurge`](/zh/docs/concepts/workloads/controllers/deployment/#max-surge) (一种 Beta 阶段的特性，默认为 25%)
<!--
### Creating a DaemonSet with `RollingUpdate` update strategy
@@ -248,13 +251,13 @@ causes:
<!--
The rollout is stuck because new DaemonSet pods can't be scheduled on at least one
node. This is possible when the node is
[running out of resources](/docs/tasks/administer-cluster/out-of-resource/).
[running out of resources](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
When this happens, find the nodes that don't have the DaemonSet pods scheduled on
by comparing the output of `kubectl get nodes` and the output of:
-->
DaemonSet 滚动更新可能会卡住，其 Pod 至少在某个节点上无法调度运行。
当节点上[可用资源耗尽](/zh/docs/tasks/administer-cluster/out-of-resource/)时，
当节点上[可用资源耗尽](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)时，
这是可能的。
发生这种情况时，通过对 `kubectl get nodes` 和下面命令行的输出作比较，
@@ -328,10 +331,9 @@ kubectl delete ds fluentd-elasticsearch -n kube-system
## {{% heading "whatsnext" %}}
<!--
* See [Task: Performing a rollback on a
DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
* See [Concepts: Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
* See [Performing a rollback on a DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
* See [Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
-->
* 查看[任务：在 DaemonSet 上执行回滚](/zh/docs/tasks/manage-daemon/rollback-daemon-set/)
* 查看[概念：创建 DaemonSet 以收养现有 DaemonSet Pod](/zh/docs/concepts/workloads/controllers/daemonset/)
* 查看[在 DaemonSet 上执行回滚](/zh/docs/tasks/manage-daemon/rollback-daemon-set/)
* 查看[创建 DaemonSet 以收养现有 DaemonSet Pod](/zh/docs/concepts/workloads/controllers/daemonset/)
content/zh/docs/tasks/tls/certificate-rotation.md
+9 -7
View File
@@ -40,14 +40,14 @@ Kubelet 使用证书进行 Kubernetes API 的认证。
默认情况下，这些证书的签发期限为一年，所以不需要太频繁地进行更新。
<!--
Kubernetes 1.8 contains [kubelet certificate
rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), a beta feature
Kubernetes contains [kubelet certificate
rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/),
that will automatically generate a new key and request a new certificate from
the Kubernetes API as the current certificate approaches expiration. Once the
new certificate is available, it will be used for authenticating connections to
the Kubernetes API.
-->
Kubernetes 1.8 版本中包含 beta 特性
Kubernetes 包含特性
[kubelet 证书轮换](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)，
在当前证书即将过期时，
将自动生成新的秘钥，并从 Kubernetes API 申请新的证书。 一旦新的证书可用，它将被用于与
@@ -99,7 +99,7 @@ criteria, it will be auto approved by the controller manager, then it will have
a status of `Approved`. Next, the controller manager will sign a certificate,
issued for the duration specified by the
`--cluster-signing-duration` parameter, and the signed certificate
will be attached to the certificate signing requests.
will be attached to the certificate signing request.
-->
最初，来自节点上 kubelet 的证书签名请求处于 `Pending` 状态。 如果证书签名请求满足特定条件，
控制器管理器会自动批准，此时请求会处于 `Approved` 状态。 接下来，控制器管理器会签署证书，
@@ -116,14 +116,16 @@ Kubelet 会从 Kubernetes API 取回签署的证书，并将其写入磁盘，
<!--
As the expiration of the signed certificate approaches, the kubelet will
automatically issue a new certificate signing request, using the Kubernetes
API. Again, the controller manager will automatically approve the certificate
automatically issue a new certificate signing request, using the Kubernetes API.
This can happen at any point between 30% and 10% of the time remaining on the
certificate. Again, the controller manager will automatically approve the certificate
request and attach a signed certificate to the certificate signing request. The
kubelet will retrieve the new signed certificate from the Kubernetes API and
write that to disk. Then it will update the connections it has to the
Kubernetes API to reconnect using the new certificate.
-->
当签署的证书即将到期时，kubelet 会使用 Kubernetes API，发起新的证书签名请求。
当签署的证书即将到期时，kubelet 会使用 Kubernetes API，自动发起新的证书签名请求。
该请求会发生在证书的有效时间剩下 30% 到 10% 之间的任意时间点。
同样地，控制器管理器会自动批准证书请求，并将签署的证书附加到证书签名请求中。 Kubelet
会从 Kubernetes API 取回签署的证书，并将其写入磁盘。 然后它会更新与 Kubernetes API
的连接，使用新的证书重新连接到 Kubernetes API。