diff --git a/content/zh-cn/docs/tasks/administer-cluster/encrypt-data.md b/content/zh-cn/docs/tasks/administer-cluster/encrypt-data.md index 1f2eefd0a0..3363415f91 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/zh-cn/docs/tasks/administer-cluster/encrypt-data.md @@ -128,8 +128,8 @@ Name | Encryption | Strength | Speed | Key Length | Other Considerations `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. `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. `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. -`aescbc` | AES-CBC with PKCS#7 padding | Weak | Fast | 32-byte | Not recommended due to CBC's vulnerability to padding oracle attacks. -`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/) +`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. +`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/) Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider 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. `identity` | 无 | N/A | N/A | N/A | 不加密写入的资源。当设置为第一个 provider 时，资源将在新值写入时被解密。 `secretbox` | XSalsa20 和 Poly1305 | 强 | 更快 | 32字节 | 较新的标准，在需要高度评审的环境中可能不被接受。 `aesgcm` | 带有随机数的 AES-GCM | 必须每 200k 写入一次 | 最快 | 16, 24 或者 32字节 | 建议不要使用，除非实施了自动密钥循环方案。 -`aescbc` | 填充 PKCS#7 的 AES-CBC | 弱 | 快 | 32字节 | 由于 CBC 容易受到密文填塞攻击（Padding Oracle Attack），不推荐使用。 -`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/) +`aescbc` | 填充 [PKCS#7](https://datatracker.ietf.org/doc/html/rfc2315) 的 AES-CBC | 弱 | 快 | 32字节 | 由于 CBC 容易受到密文填塞攻击（Padding Oracle Attack），不推荐使用。 +`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/) 每个 provider 都支持多个密钥 - 在解密时会按顺序使用密钥，如果是第一个 provider，则第一个密钥用于加密。 diff --git a/content/zh-cn/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md b/content/zh-cn/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md index 9faeeadbb6..d49e2d570a 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md +++ b/content/zh-cn/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md @@ -4,11 +4,9 @@ content_type: task weight: 10 --- @@ -26,6 +24,7 @@ You should be familiar with the Kubernetes [container runtime requirements](/docs/setup/production-environment/container-runtimes). --> 你应该熟悉 Kubernetes 的[容器运行时需求](/zh/docs/setup/production-environment/container-runtimes)。 + -正如本指南阐述的：不推荐与 kubeadm 一起使用 `cgroupfs` 驱动。 - -如仍需使用 `cgroupfs`， -且要防止 `kubeadm upgrade` 修改现有系统中 `KubeletConfiguration` 的 cgroup 驱动， -你必须显式声明它的值。 +如仍需使用 `cgroupfs` 且要防止 `kubeadm upgrade` 修改现有系统中 +`KubeletConfiguration` 的 cgroup 驱动，你必须显式声明它的值。 此方法应对的场景为：在将来某个版本的 kubeadm 中，你不想使用默认的 `systemd` 驱动。 以下为某个仅包含一个容器的 Pod 的清单。 该容器声明了 CPU 请求 500 millicpu 和 CPU 限制 800 millicpu 。 -这些参数满足了 LimitRange 对象规定的 CPU 最小和最大限制。 +这些参数满足了 LimitRange 对象为此名字空间规定的 CPU 最小和最大限制。 {{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}} @@ -336,7 +336,7 @@ from the LimitRange for this namespace. 设置[默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 -查看所你创建的 Pod 的规约: +查看你所创建的 Pod 的[规约](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)： ``` kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example diff --git a/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index 203fcc95eb..70b3cf381d 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -3,7 +3,8 @@ title: 配置命名空间的最小和最大内存约束 content_type: task weight: 30 description: >- - 为命名口空间定义一个有效的内存资源限制范围，在该命名空间中每个新创建 Pod 的内存资源是在设置的范围内。 + 为命名口空间定义一个有效的内存资源限制范围，在该命名空间中每个新创建 + Pod 的内存资源是在设置的范围内。 --- -本页介绍如何设置在命名空间中运行的容器使用的内存的最小值和最大值。 你可以在 -[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) -对象中指定最小和最大内存值。如果 Pod 不满足 LimitRange 施加的约束，则无法在命名空间中创建它。 +本页介绍如何设置在{{< glossary_tooltip text="名字空间" term_id="namespace" >}} +中运行的容器所使用的内存的最小值和最大值。你可以在 +[LimitRange](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/) +对象中指定最小和最大内存值。如果 Pod 不满足 LimitRange 施加的约束， +则无法在名字空间中创建它。 ## {{% heading "prerequisites" %}} @@ -32,7 +36,6 @@ it cannot be created in the namespace. 在你的集群里你必须要有创建命名空间的权限。 @@ -108,7 +111,7 @@ Now whenever you define a Pod within the constraints-mem-example namespace, Kube performs these steps: * If any container in that Pod does not specify its own memory request and limit, -the control plane assig nthe default memory request and limit to that container. + the control plane assigns the default memory request and limit to that container. * Verify that every container in that Pod requests at least 500 MiB of memory. @@ -122,9 +125,7 @@ minimum and maximum memory constraints imposed by the LimitRange. 现在，每当在 constraints-mem-example 命名空间中创建 Pod 时，Kubernetes 就会执行下面的步骤： * 如果 Pod 中的任何容器未声明自己的内存请求和限制，控制面将为该容器设置默认的内存请求和限制。 - * 确保该 Pod 中的每个容器的内存请求至少 500 MiB。 - * 确保该 Pod 中每个容器内存请求不大于 1 GiB。 以下为包含一个容器的 Pod 清单。该容器声明了 600 MiB 的内存请求和 800 MiB 的内存限制， diff --git a/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index a88e74255d..fe9a8d7f63 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -3,7 +3,7 @@ title: 为命名空间配置默认的内存请求和限制 content_type: task weight: 10 description: >- - 为命名空间定义默认的内存资源限制，在该命名空间中每个新建的 Pod 都会被配置上内存资源限制。 + 为命名空间定义默认的内存资源限制，这样在该命名空间中每个新建的 Pod 都会被配置上内存资源限制。 --- -创建 Pod +创建 Pod： ```shell kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod.yaml --namespace=default-mem-example diff --git a/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md index 8b55a149c0..cbfbaba782 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md +++ b/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md @@ -1,5 +1,5 @@ --- -title: "从 dockershim 迁移" +title: 从 dockershim 迁移 weight: 10 content_type: task no_list: true @@ -31,11 +31,11 @@ to understand the problem better. Dockershim 在 Kubernetes v1.24 版本已经被移除。 -如果你集群内是通过 dockershim 使用 Docker 作为容器运行时，并希望 Kubernetes 升级到 v1.24， +如果你集群内是通过 dockershim 使用 Docker Engine 作为容器运行时，并希望 Kubernetes 升级到 v1.24， 建议你迁移到其他容器运行时或使用其他方法以获得 Docker 引擎支持。 你的集群中可以有不止一种类型的节点，尽管这不是常见的情况。 下面这些任务可以帮助你完成迁移： -* [检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) -* [dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/) +* [检查弃用 Dockershim 是否影响到你](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) +* [将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) * [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/) - - -## 下一步 - * 查看[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)了解可选的容器运行时。 -* [GitHub 问题](https://github.com/kubernetes/kubernetes/issues/106917)跟踪有关 dockershim 的弃用和删除的讨论。 +* [GitHub 问题](https://github.com/kubernetes/kubernetes/issues/106917)跟踪有关 + dockershim 的弃用和删除的讨论。 * 如果你发现与 dockershim 迁移相关的缺陷或其他技术问题， 可以在 Kubernetes 项目[报告问题](https://github.com/kubernetes/kubernetes/issues/new/choose)。 - \ No newline at end of file + diff --git a/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md b/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md index 4e1380322b..9d1f0e461f 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md +++ b/content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md @@ -69,18 +69,15 @@ node-3 Ready v1.16.15 docker://19.3.1 ``` - -如果你的容器运行时显示为 Docker Engine，你仍然可能不会被 1.24 中 dockershim 的移除所影响。 +如果你的容器运行时显示为 Docker Engine，你仍然可能不会被 v1.24 中 dockershim 的移除所影响。 通过[检查运行时端点](#which-endpoint)，可以查看你是否在使用 dockershim。 如果你没有使用 dockershim，你就不会被影响。 -看下是否是使用的 dockershim，如何是 dockershim 则会受到在 Kubernetes 1.24 中移除 dockershim 的影响。 -反之则不会受到影响。 对于 containerd，输出类似于这样： @@ -110,27 +107,24 @@ The container runtime talks to the kubelet over a Unix socket using the [CRI protocol](/docs/concepts/architecture/cri/), which is based on the gRPC framework. The kubelet acts as a client, and the runtime acts as the server. In some cases, you might find it useful to know which socket your nodes use. For -example, with the removal of dockershim in Kubernetes 1.24 and later, you might +example, with the removal of dockershim in Kubernetes v1.24 and later, you might want to know whether you use Docker Engine with dockershim. --> 容器运行时使用 Unix Socket 与 kubelet 通信，这一通信使用基于 gRPC 框架的 [CRI 协议](/zh/docs/concepts/architecture/cri/)。kubelet 扮演客户端，运行时扮演服务器端。 在某些情况下，你可能想知道你的节点使用的是哪个 socket。 -如若集群是 Kubernetes 1.24 及以后的版本， +如若集群是 Kubernetes v1.24 及以后的版本， 或许你想知道当前运行时是否是使用 dockershim 的 Docker Engine。 +{{< note >}} - -{{}} 如果你的节点在通过 `cri-dockerd` 使用 Docker Engine， 那么集群不会受到 Kubernetes 移除 dockershim 的影响。 -{{}} +{{< /note >}} -如果你通过 dockershim 来使用 Docker Engine，可在 +如果你将节点上的容器运行时从 Docker Engine 改变为 containerd，可在 [迁移到不同的运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/) 找到更多信息。或者，如果你想在 Kubernetes v1.24 及以后的版本仍使用 Docker Engine， 可以安装 CRI 兼容的适配器实现，如 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)。 -[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)。 \ No newline at end of file +[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)。 + diff --git a/content/zh-cn/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/zh-cn/docs/tasks/administer-cluster/reconfigure-kubelet.md index c6208c405d..ba28ae13dd 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/reconfigure-kubelet.md +++ b/content/zh-cn/docs/tasks/administer-cluster/reconfigure-kubelet.md @@ -39,12 +39,13 @@ each {{< glossary_tooltip term_id="node" >}} to use it. [动态 kubelet 配置](https://github.com/kubernetes/enhancements/issues/281) 允许你通过部署并配置{{< glossary_tooltip text="节点" term_id="node" >}}使用的 {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}， -达到更改正在运行的 Kubernetes 集群的 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 配置的目的。 +达到更改正在运行的 Kubernetes 集群的 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} +配置的目的。 -请在 [早期版本的文档](https://v1-23.docs.kubernetes.io/zh/docs/tasks/administer-cluster/reconfigure-kubelet/) 中找到有关此功能的文档。 +请在[早期版本的文档](https://v1-23.docs.kubernetes.io/zh/docs/tasks/administer-cluster/reconfigure-kubelet/)中寻找有关此功能的文档。 ## 不再使用动态 Kubelet 配置 @@ -60,8 +61,8 @@ practices for customizing your Kubernetes. If you are using KubeAdm, refer to 这里没有跨不同的 Kubernetes 发行版替换这个功能的建议方法。 如果你使用托管 Kubernetes 版本， 请咨询托管 Kubernetes 的供应商，以获得自定义 Kubernetes 的最佳实践。 -如果你使用的是 `kubeadm`，请参考 -[使用 kubeadm 配置集群中的每个 kubelet](/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration/)。 +如果你使用的是 `kubeadm`， +请参考[使用 kubeadm 配置集群中的各个 kubelet](/zh/docs/setup/production-environment/tools/kubeadm/kubelet-integration/)。 请注意，从 v1.24 开始 `DynamicKubeletConfig` 特性门控无法在 kubelet 上设置， 因为不会生效。在 v1.26 之前 API 服务器和控制器管理器不会移除该特性门控。 -这是专为控制面支持有旧版本 kubelet 的节点以及满足 [Kubernetes 版本偏差策略](/releases/version-skew-policy/)。 \ No newline at end of file +这是专为控制面支持有旧版本 kubelet 的节点以及满足 +[Kubernetes 版本偏差策略](/zh-cn/releases/version-skew-policy/)。 +