Merge pull request #41207 from windsonsea/encryd

[zh] sync encrypt-data.md and safely-drain-node.md
pull/41230/head
Kubernetes Prow Robot 2023-05-19 01:42:29 -07:00 committed by GitHub
commit 7eada7c2ad
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 72 additions and 34 deletions

View File

@ -54,16 +54,13 @@ This page shows how to enable and configure encryption of secret data at rest.
The `kube-apiserver` process accepts an argument `--encryption-provider-config`
that controls how API data is encrypted in etcd.
The configuration is provided as an API named
[`EncryptionConfiguration`](/docs/reference/config-api/apiserver-encryption.v1/). `--encryption-provider-config-automatic-reload` boolean argument determines if the file set by `--encryption-provider-config` should be automatically reloaded if the disk contents change. This enables key rotation without API server restarts. An example configuration is provided below.
[`EncryptionConfiguration`](/docs/reference/config-api/apiserver-encryption.v1/). An example configuration is provided below.
-->
## 配置并确定是否已启用静态数据加密 {#configuration-and-determing-wheter-encryption-at-rest-is-already-enabled}
`kube-apiserver` 的参数 `--encryption-provider-config` 控制 API 数据在 etcd 中的加密方式。
该配置作为一个名为 [`EncryptionConfiguration`](/zh-cn/docs/reference/config-api/apiserver-encryption.v1/) 的 API 提供。
`--encryption-provider-config-automatic-reload` 布尔参数决定了磁盘内容发生变化时是否应自动重新加载
`--encryption-provider-config` 设置的文件。这样可以在不重启 API 服务器的情况下进行密钥轮换。
下面提供了一个示例配置。
该配置作为一个名为 [`EncryptionConfiguration`](/zh-cn/docs/reference/config-api/apiserver-encryption.v1/)
的 API 提供。下面提供了一个示例配置。
{{< caution >}}
<!--
@ -501,19 +498,19 @@ To create a new Secret, perform the following steps:
- command:
- kube-apiserver
...
- --encryption-provider-config=/etc/kubernetes/enc/enc.yaml # <--
- --encryption-provider-config=/etc/kubernetes/enc/enc.yaml # 增加这一行
volumeMounts:
...
- name: enc # <--
mountPath: /etc/kubernetes/enc # <--
readonly: true # <--
- name: enc # 增加这一行
mountPath: /etc/kubernetes/enc # 增加这一行
readonly: true # 增加这一行
...
volumes:
...
- name: enc # <--
hostPath: # <--
path: /etc/kubernetes/enc # <--
type: DirectoryOrCreate # <--
- name: enc # 增加这一行
hostPath: # 增加这一行
path: /etc/kubernetes/enc # 增加这一行
type: DirectoryOrCreate # 增加这一行
...
```
@ -719,6 +716,33 @@ Then run the following command to force decrypt all Secrets:
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
<!--
## Configure automatic reloading
-->
## 配置自动重新加载 {#configure-automatic-reloading}
<!--
You can configure automatic reloading of encryption provider configuration.
That setting determines whether the
{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} should
load the file you specify for `--encryption-provider-config` only once at
startup, or automatically whenever you change that file. Enabling this option
allows you to change the keys for encryption at rest without restarting the
API server.
-->
你可以配置加密提供程序配置的自动重新加载。
该设置决定了 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}
是仅在启动时加载一次为 `--encryption-provider-config` 指定的文件,
还是在每次你更改该文件时都自动加载。
启用此选项可允许你在不重启 API 服务器的情况下更改静态加密所需的密钥。
<!--
To allow automatic reloading, configure the API server to run with:
`--encryption-provider-config-automatic-reload=true`
-->
要允许自动重新加载,
可使用 `--encryption-provider-config-automatic-reload=true` 运行 API 服务器。
## {{% heading "whatsnext" %}}
<!--

View File

@ -1,7 +1,6 @@
---
title: 安全地清空一个节点
content_type: task
min-kubernetes-server-version: 1.5
weight: 310
---
<!--
@ -12,7 +11,6 @@ reviewers:
- kow3ns
title: Safely Drain a Node
content_type: task
min-kubernetes-server-version: 1.5
weight: 310
-->
@ -25,25 +23,20 @@ This page shows how to safely drain a node, respecting the PodDisruptionBudget y
## {{% heading "prerequisites" %}}
{{% version-check %}}
<!--
This task assumes that you have met the following prerequisites:
* You are using Kubernetes release >= 1.5.
* Either:
1. You do not require your applications to be highly available during the
node drain, or
2. You have read about the [PodDisruptionBudget concept](/docs/concepts/workloads/pods/disruptions/)
and [Configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for
applications that need them.
1. You do not require your applications to be highly available during the
node drain, or
1. You have read about the [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) concept,
and have [configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for
applications that need them.
-->
此任务假定你已经满足了以下先决条件:
* 使用的 Kubernetes 版本 >= 1.5。
* 以下两项,具备其一:
1. 在节点清空期间,不要求应用程序具有高可用性
2. 你已经了解了 [PodDisruptionBudget 的概念](/zh-cn/docs/concepts/workloads/pods/disruptions/)
并为需要它的应用程序[配置了 PodDisruptionBudget](/zh-cn/docs/tasks/run-application/configure-pdb/)。
1. 在节点清空期间,不要求应用具有高可用性
2. 你已经了解了 [PodDisruptionBudget 的概念](/zh-cn/docs/concepts/workloads/pods/disruptions/)
并为需要它的应用[配置了 PodDisruptionBudget](/zh-cn/docs/tasks/run-application/configure-pdb/)。
<!-- steps -->
@ -110,14 +103,35 @@ have been safely evicted (respecting the desired graceful termination period,
and respecting the PodDisruptionBudget you have defined). It is then safe to
bring down the node by powering down its physical machine or, if running on a
cloud platform, deleting its virtual machine.
First, identify the name of the node you wish to drain. You can list all of the nodes in your cluster with
-->
`kubectl drain` 的成功返回,表明所有的 Pod除了上一段中描述的被排除的那些
已经被安全地逐出(考虑到期望的终止宽限期和你定义的 PodDisruptionBudget
然后就可以安全地关闭节点,
比如关闭物理机器的电源,如果它运行在云平台上,则删除它的虚拟机。
{{< note >}}
<!--
If any new Pods tolerate the `node.kubernetes.io/unschedulable` taint, then those Pods
might be scheduled to the node you have drained. Avoid tolerating that taint other than
for DaemonSets.
-->
如果存在新的、能够容忍 `node.kubernetes.io/unschedulable` 污点的 Pod
那么这些 Pod 可能会被调度到你已经清空的节点上。
除了 DaemonSet 之外,请避免容忍此污点。
<!--
If you or another API user directly set the [`nodeName`](/docs/concepts/scheduling-eviction/assign-pod-node/#nodename)
field for a Pod (bypassing the scheduler), then the Pod is bound to the specified node
and will run there, even though you have drained that node and marked it unschedulable.
-->
如果你或另一个 API 用户(绕过调度器)直接为 Pod 设置了
[`nodeName`](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#nodename)字段,
则即使你已将该节点清空并标记为不可调度Pod 仍将被绑定到这个指定的节点并在该节点上运行。
{{< /note >}}
<!--
First, identify the name of the node you wish to drain. You can list all of the nodes in your cluster with
-->
首先,确定想要清空的节点的名称。可以用以下命令列出集群中的所有节点:
```shell
@ -174,9 +188,9 @@ respect the `PodDisruptionBudget` you specify.
-->
## 并行清空多个节点 {#draining-multiple-nodes-in-parallel}
`kubectl drain` 命令一次只能发送给一个节点。
但是,你可以在不同的终端或后台为不同的节点并行地运行多个 `kubectl drain` 命令。
同时运行的多个 drain 命令仍然遵循你指定的 `PodDisruptionBudget`
`kubectl drain` 命令一次只能发送给一个节点。
但是,你可以在不同的终端或后台为不同的节点并行地运行多个 `kubectl drain` 命令。
同时运行的多个 drain 命令仍然遵循你指定的 `PodDisruptionBudget`
<!--
For example, if you have a StatefulSet with three replicas and have