Skip to content

Commit b97980d

Browse files
authored
Merge pull request #34235 from tengqm/zh-34221-task-3
[zh] Resync tasks pages (task-3)
2 parents 5a2283d + dd7f235 commit b97980d

File tree

9 files changed

+60
-64
lines changed

9 files changed

+60
-64
lines changed

content/zh-cn/docs/tasks/administer-cluster/encrypt-data.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -128,8 +128,8 @@ Name | Encryption | Strength | Speed | Key Length | Other Considerations
128128
`identity` | None | N/A | N/A | N/A | Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written.
129129
`secretbox` | XSalsa20 and Poly1305 | Strong | Faster | 32-byte | A newer standard and may not be considered acceptable in environments that require high levels of review.
130130
`aesgcm` | AES-GCM with random nonce | Must be rotated every 200k writes | Fastest | 16, 24, or 32-byte | Is not recommended for use except when an automated key rotation scheme is implemented.
131-
`aescbc` | AES-CBC with PKCS#7 padding | Weak | Fast | 32-byte | Not recommended due to CBC's vulnerability to padding oracle attacks.
132-
`kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with PKCS#7 padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes | The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/)
131+
`aescbc` | AES-CBC with [PKCS#7](https://datatracker.ietf.org/doc/html/rfc2315) padding | Weak | Fast | 32-byte | Not recommended due to CBC's vulnerability to padding oracle attacks.
132+
`kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with [PKCS#7](https://datatracker.ietf.org/doc/html/rfc2315) padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes | The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/)
133133

134134
Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider
135135
is the first provider, the first key is used for encryption.
@@ -140,8 +140,8 @@ is the first provider, the first key is used for encryption.
140140
`identity` | 无 | N/A | N/A | N/A | 不加密写入的资源。当设置为第一个 provider 时,资源将在新值写入时被解密。
141141
`secretbox` | XSalsa20 和 Poly1305 | 强 | 更快 | 32字节 | 较新的标准,在需要高度评审的环境中可能不被接受。
142142
`aesgcm` | 带有随机数的 AES-GCM | 必须每 200k 写入一次 | 最快 | 16, 24 或者 32字节 | 建议不要使用,除非实施了自动密钥循环方案。
143-
`aescbc` | 填充 PKCS#7 的 AES-CBC | 弱 | 快 | 32字节 | 由于 CBC 容易受到密文填塞攻击(Padding Oracle Attack),不推荐使用。
144-
`kms` | 使用信封加密方案:数据使用带有 PKCS#7 填充的 AES-CBC 通过数据加密密钥(DEK)加密,DEK 根据 Key Management Service(KMS)中的配置通过密钥加密密钥(Key Encryption Keys,KEK)加密 | 最强 | 快 | 32字节 | 建议使用第三方工具进行密钥管理。为每个加密生成新的 DEK,并由用户控制 KEK 轮换来简化密钥轮换。[配置 KMS 提供程序](/zh/docs/tasks/administer-cluster/kms-provider/)
143+
`aescbc` | 填充 [PKCS#7](https://datatracker.ietf.org/doc/html/rfc2315) 的 AES-CBC | 弱 | 快 | 32字节 | 由于 CBC 容易受到密文填塞攻击(Padding Oracle Attack),不推荐使用。
144+
`kms` | 使用信封加密方案:数据使用带有 [PKCS#7](https://datatracker.ietf.org/doc/html/rfc2315) 填充的 AES-CBC 通过数据加密密钥(DEK)加密,DEK 根据 Key Management Service(KMS)中的配置通过密钥加密密钥(Key Encryption Keys,KEK)加密 | 最强 | 快 | 32字节 | 建议使用第三方工具进行密钥管理。为每个加密生成新的 DEK,并由用户控制 KEK 轮换来简化密钥轮换。[配置 KMS 提供程序](/zh/docs/tasks/administer-cluster/kms-provider/)
145145

146146
每个 provider 都支持多个密钥 - 在解密时会按顺序使用密钥,如果是第一个 provider,则第一个密钥用于加密。
147147

content/zh-cn/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md

Lines changed: 4 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -4,11 +4,9 @@ content_type: task
44
weight: 10
55
---
66
<!--
7-
---
87
title: Configuring a cgroup driver
98
content_type: task
109
weight: 10
11-
---
1210
-->
1311

1412
<!-- overview -->
@@ -26,6 +24,7 @@ You should be familiar with the Kubernetes
2624
[container runtime requirements](/docs/setup/production-environment/container-runtimes).
2725
-->
2826
你应该熟悉 Kubernetes 的[容器运行时需求](/zh/docs/setup/production-environment/container-runtimes)
27+
2928
<!-- steps -->
3029

3130
<!--
@@ -122,18 +121,13 @@ Kubeadm 对集群所有的节点,使用相同的 `KubeletConfiguration`。
122121
# 使用 `cgroupfs` 驱动
123122

124123
<!--
125-
As this guide explains using the `cgroupfs` driver with kubeadm is not recommended.
126-
127-
To continue using `cgroupfs` and to prevent `kubeadm upgrade` from modifying the
124+
To use `cgroupfs` and to prevent `kubeadm upgrade` from modifying the
128125
`KubeletConfiguration` cgroup driver on existing setups, you must be explicit
129126
about its value. This applies to a case where you do not wish future versions
130127
of kubeadm to apply the `systemd` driver by default.
131128
-->
132-
正如本指南阐述的:不推荐与 kubeadm 一起使用 `cgroupfs` 驱动。
133-
134-
如仍需使用 `cgroupfs`
135-
且要防止 `kubeadm upgrade` 修改现有系统中 `KubeletConfiguration` 的 cgroup 驱动,
136-
你必须显式声明它的值。
129+
如仍需使用 `cgroupfs` 且要防止 `kubeadm upgrade` 修改现有系统中
130+
`KubeletConfiguration` 的 cgroup 驱动,你必须显式声明它的值。
137131
此方法应对的场景为:在将来某个版本的 kubeadm 中,你不想使用默认的 `systemd` 驱动。
138132

139133
<!--

content/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -150,11 +150,11 @@ on these resources, the two values must be the same.
150150
<!--
151151
Here's a manifest for a Pod that has one container. The container manifest
152152
specifies a CPU request of 500 millicpu and a CPU limit of 800 millicpu. These satisfy the
153-
minimum and maximum CPU constraints imposed by the LimitRange.
153+
minimum and maximum CPU constraints imposed by the LimitRange for this namespace.
154154
-->
155155
以下为某个仅包含一个容器的 Pod 的清单。
156156
该容器声明了 CPU 请求 500 millicpu 和 CPU 限制 800 millicpu 。
157-
这些参数满足了 LimitRange 对象规定的 CPU 最小和最大限制。
157+
这些参数满足了 LimitRange 对象为此名字空间规定的 CPU 最小和最大限制。
158158

159159
{{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}}
160160

@@ -336,7 +336,7 @@ from the LimitRange for this namespace.
336336
设置[默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。
337337
338338
<!--
339-
At this point, your Pod might be running or it might not be running. Recall that a prerequisite for
339+
At this point, your Pod may or may not be running. Recall that a prerequisite for
340340
this task is that your Nodes must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU,
341341
then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu.
342342
If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request.
@@ -348,6 +348,8 @@ Delete your Pod:
348348
如果你的每个节点都只有 1 CPU,那将没有一个节点拥有足够的可分配 CPU 来满足 800 millicpu 的请求。
349349
如果你在用的节点恰好有 2 CPU,那么有可能有足够的 CPU 来满足 800 millicpu 的请求。
350350
351+
删除你的 Pod:
352+
351353
```
352354
kubectl delete pod constraints-cpu-demo-4 --namespace=constraints-cpu-example
353355
```

content/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -213,9 +213,10 @@ kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml
213213
```
214214

215215
<!--
216-
View the specification of the Pod that you created:
216+
View the [specification](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)
217+
of the Pod that you created:
217218
-->
218-
查看所你创建的 Pod 的规约:
219+
查看你所创建的 Pod [规约](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)
219220

220221
```
221222
kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example

content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md

Lines changed: 11 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,8 @@ title: 配置命名空间的最小和最大内存约束
33
content_type: task
44
weight: 30
55
description: >-
6-
为命名口空间定义一个有效的内存资源限制范围,在该命名空间中每个新创建 Pod 的内存资源是在设置的范围内。
6+
为命名口空间定义一个有效的内存资源限制范围,在该命名空间中每个新创建
7+
Pod 的内存资源是在设置的范围内。
78
---
89

910
<!--
@@ -16,14 +17,17 @@ weight: 30
1617

1718
<!--
1819
This page shows how to set minimum and maximum values for memory used by containers
19-
running in a namespace. You specify minimum and maximum memory values in a
20-
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
20+
running in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}.
21+
You specify minimum and maximum memory values in a
22+
[LimitRange](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/)
2123
object. If a Pod does not meet the constraints imposed by the LimitRange,
2224
it cannot be created in the namespace.
2325
-->
24-
本页介绍如何设置在命名空间中运行的容器使用的内存的最小值和最大值。 你可以在
25-
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
26-
对象中指定最小和最大内存值。如果 Pod 不满足 LimitRange 施加的约束,则无法在命名空间中创建它。
26+
本页介绍如何设置在{{< glossary_tooltip text="名字空间" term_id="namespace" >}}
27+
中运行的容器所使用的内存的最小值和最大值。你可以在
28+
[LimitRange](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/)
29+
对象中指定最小和最大内存值。如果 Pod 不满足 LimitRange 施加的约束,
30+
则无法在名字空间中创建它。
2731

2832
## {{% heading "prerequisites" %}}
2933

@@ -32,7 +36,6 @@ it cannot be created in the namespace.
3236
<!--
3337
You must have access to create namespaces in your cluster.
3438
Each node in your cluster must have at least 1 GiB of memory available for Pods.
35-
3639
-->
3740
在你的集群里你必须要有创建命名空间的权限。
3841

@@ -108,7 +111,7 @@ Now whenever you define a Pod within the constraints-mem-example namespace, Kube
108111
performs these steps:
109112
110113
* If any container in that Pod does not specify its own memory request and limit,
111-
the control plane assig nthe default memory request and limit to that container.
114+
the control plane assigns the default memory request and limit to that container.
112115
113116
* Verify that every container in that Pod requests at least 500 MiB of memory.
114117
@@ -122,9 +125,7 @@ minimum and maximum memory constraints imposed by the LimitRange.
122125
现在,每当在 constraints-mem-example 命名空间中创建 Pod 时,Kubernetes 就会执行下面的步骤:
123126

124127
* 如果 Pod 中的任何容器未声明自己的内存请求和限制,控制面将为该容器设置默认的内存请求和限制。
125-
126128
* 确保该 Pod 中的每个容器的内存请求至少 500 MiB。
127-
128129
* 确保该 Pod 中每个容器内存请求不大于 1 GiB。
129130

130131
以下为包含一个容器的 Pod 清单。该容器声明了 600 MiB 的内存请求和 800 MiB 的内存限制,

content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@ title: 为命名空间配置默认的内存请求和限制
33
content_type: task
44
weight: 10
55
description: >-
6-
为命名空间定义默认的内存资源限制,在该命名空间中每个新建的 Pod 都会被配置上内存资源限制。
6+
为命名空间定义默认的内存资源限制,这样在该命名空间中每个新建的 Pod 都会被配置上内存资源限制。
77
---
88

99
<!--
@@ -113,7 +113,7 @@ does not specify a memory request and limit.
113113
<!--
114114
Create the Pod.
115115
-->
116-
创建 Pod
116+
创建 Pod
117117

118118
```shell
119119
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod.yaml --namespace=default-mem-example

content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md

Lines changed: 11 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
---
2-
title: "从 dockershim 迁移"
2+
title: 从 dockershim 迁移
33
weight: 10
44
content_type: task
55
no_list: true
@@ -31,11 +31,11 @@ to understand the problem better.
3131

3232
<!--
3333
Dockershim was removed from Kubernetes with the release of v1.24.
34-
If you use Docker via dockershim as your container runtime, and wish to upgrade to v1.24,
34+
If you use Docker Engine via dockershim as your container runtime, and wish to upgrade to v1.24,
3535
it is recommended that you either migrate to another runtime or find an alternative means to obtain Docker Engine support.
3636
-->
3737
Dockershim 在 Kubernetes v1.24 版本已经被移除。
38-
如果你集群内是通过 dockershim 使用 Docker 作为容器运行时,并希望 Kubernetes 升级到 v1.24,
38+
如果你集群内是通过 dockershim 使用 Docker Engine 作为容器运行时,并希望 Kubernetes 升级到 v1.24,
3939
建议你迁移到其他容器运行时或使用其他方法以获得 Docker 引擎支持。
4040

4141
<!--
@@ -58,19 +58,20 @@ configuration.
5858
These tasks will help you to migrate:
5959
6060
* [Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
61-
* [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/)
61+
* [Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)
6262
* [Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)
6363
-->
6464
你的集群中可以有不止一种类型的节点,尽管这不是常见的情况。
6565

6666
下面这些任务可以帮助你完成迁移:
6767

68-
* [检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
69-
* [dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)
68+
* [检查弃用 Dockershim 是否影响到你](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
69+
* [将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)
7070
* [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)
71-
<!--
71+
7272
## {{% heading "whatsnext" %}}
7373

74+
<!--
7475
* Check out [container runtimes](/docs/setup/production-environment/container-runtimes/)
7576
to understand your options for a container runtime.
7677
* There is a
@@ -80,11 +81,9 @@ These tasks will help you to migrate:
8081
you can [report an issue](https://github.com/kubernetes/kubernetes/issues/new/choose)
8182
to the Kubernetes project.
8283
-->
83-
84-
## 下一步
85-
8684
* 查看[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)了解可选的容器运行时。
87-
* [GitHub 问题](https://github.com/kubernetes/kubernetes/issues/106917)跟踪有关 dockershim 的弃用和删除的讨论。
85+
* [GitHub 问题](https://github.com/kubernetes/kubernetes/issues/106917)跟踪有关
86+
dockershim 的弃用和删除的讨论。
8887
* 如果你发现与 dockershim 迁移相关的缺陷或其他技术问题,
8988
可以在 Kubernetes 项目[报告问题](https://github.com/kubernetes/kubernetes/issues/new/choose)
90-
89+

content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md

Lines changed: 11 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -69,18 +69,15 @@ node-3 Ready v1.16.15 docker://19.3.1
6969
```
7070
<!--
7171
If your runtime shows as Docker Engine, you still might not be affected by the
72-
removal of dockershim in Kubernetes 1.24. [Check the runtime
72+
removal of dockershim in Kubernetes v1.24. [Check the runtime
7373
endpoint](#which-endpoint) to see if you use dockershim. If you don't use
7474
dockershim, you aren't affected.
7575
7676
For containerd, the output is similar to this:
7777
-->
78-
79-
如果你的容器运行时显示为 Docker Engine,你仍然可能不会被 1.24 中 dockershim 的移除所影响。
78+
如果你的容器运行时显示为 Docker Engine,你仍然可能不会被 v1.24 中 dockershim 的移除所影响。
8079
通过[检查运行时端点](#which-endpoint),可以查看你是否在使用 dockershim。
8180
如果你没有使用 dockershim,你就不会被影响。
82-
看下是否是使用的 dockershim,如何是 dockershim 则会受到在 Kubernetes 1.24 中移除 dockershim 的影响。
83-
反之则不会受到影响。
8481

8582
对于 containerd,输出类似于这样:
8683

@@ -110,27 +107,24 @@ The container runtime talks to the kubelet over a Unix socket using the [CRI
110107
protocol](/docs/concepts/architecture/cri/), which is based on the gRPC
111108
framework. The kubelet acts as a client, and the runtime acts as the server.
112109
In some cases, you might find it useful to know which socket your nodes use. For
113-
example, with the removal of dockershim in Kubernetes 1.24 and later, you might
110+
example, with the removal of dockershim in Kubernetes v1.24 and later, you might
114111
want to know whether you use Docker Engine with dockershim.
115112
-->
116113

117114
容器运行时使用 Unix Socket 与 kubelet 通信,这一通信使用基于 gRPC 框架的
118115
[CRI 协议](/zh/docs/concepts/architecture/cri/)。kubelet 扮演客户端,运行时扮演服务器端。
119116
在某些情况下,你可能想知道你的节点使用的是哪个 socket。
120-
如若集群是 Kubernetes 1.24 及以后的版本,
117+
如若集群是 Kubernetes v1.24 及以后的版本,
121118
或许你想知道当前运行时是否是使用 dockershim 的 Docker Engine。
122119

120+
{{< note >}}
123121
<!--
124-
{{<note>}}
125122
If you currently use Docker Engine in your nodes with `cri-dockerd`, you aren't
126123
affected by the dockershim removal.
127-
{{</note>}}
128124
-->
129-
130-
{{<note>}}
131125
如果你的节点在通过 `cri-dockerd` 使用 Docker Engine,
132126
那么集群不会受到 Kubernetes 移除 dockershim 的影响。
133-
{{</note>}}
127+
{{< /note >}}
134128

135129
<!--
136130
You can check which socket you use by checking the kubelet configuration on your
@@ -175,12 +169,14 @@ nodes.
175169
如若套接字 `unix:///run/containerd/containerd.sock` 是 containerd 的端点。
176170

177171
<!--
178-
If you use Docker Engine with the dockershim, [migrate to a different runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/),
172+
If you want to change the Container Runtime on a Node from Docker Engine to containerd,
173+
you can find out more information on [migrating from Docker Engine to containerd](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/),
179174
or, if you want to continue using Docker Engine in v1.24 and later, migrate to a
180175
CRI-compatible adapter like [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
181176
-->
182-
如果你通过 dockershim 来使用 Docker Engine,可在
177+
如果你将节点上的容器运行时从 Docker Engine 改变为 containerd,可在
183178
[迁移到不同的运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/)
184179
找到更多信息。或者,如果你想在 Kubernetes v1.24 及以后的版本仍使用 Docker Engine,
185180
可以安装 CRI 兼容的适配器实现,如 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)
186-
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)
181+
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)
182+

0 commit comments

Comments
 (0)