@@ -19,17 +19,15 @@ weight: 270
19
19
20
20
## {{% heading "prerequisites" %}}
21
21
22
- {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
23
-
24
22
<!--
25
23
You need to have a Kubernetes cluster, and the kubectl command-line tool must
26
- be configured to communicate with your cluster. It is recommended to run this
27
- task on a cluster with at least two nodes that are not acting as control plane
28
- nodes . If you do not already have a cluster, you can create one by using
24
+ be configured to communicate with your cluster. It is recommended to follow this
25
+ guide on a cluster with at least two nodes that are not acting as control plane
26
+ nodes. If you do not already have a cluster, you can create one by using
29
27
[minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/).
30
28
-->
31
29
你需要有一个 Kubernetes 集群,并且必须配置 kubectl 命令行工具以与你的集群通信。
32
- 建议在至少有两个不充当控制平面的节点上运行此任务 。如果你还没有集群,
30
+ 建议参照本指南在至少有两个不充当控制平面的节点上运行此任务 。如果你还没有集群,
33
31
你可以使用 [ minikube] ( https://minikube.sigs.k8s.io/docs/tutorials/multi_node/ ) 创建一个。
34
32
35
33
<!-- steps -->
@@ -42,33 +40,35 @@ nodes . If you do not already have a cluster, you can create one by using
42
40
* etcd is a leader-based distributed system. Ensure that the leader
43
41
periodically send heartbeats on time to all followers to keep the cluster
44
42
stable.
43
+ -->
44
+ ## 先决条件 {#prerequisites}
45
45
46
+ * 运行的 etcd 集群个数成员为奇数。
47
+
48
+ * etcd 是一个基于领导者(Leader-Based)的分布式系统。确保主节点定期向所有从节点发送心跳,以保持集群稳定。
49
+
50
+ <!--
46
51
* Ensure that no resource starvation occurs.
47
52
48
53
Performance and stability of the cluster is sensitive to network and disk
49
54
I/O. Any resource starvation can lead to heartbeat timeout, causing instability
50
55
of the cluster. An unstable etcd indicates that no leader is elected. Under
51
56
such circumstances, a cluster cannot make any changes to its current state,
52
57
which implies no new pods can be scheduled.
53
-
54
- * Keeping etcd clusters stable is critical to the stability of Kubernetes
55
- clusters. Therefore, run etcd clusters on dedicated machines or isolated
56
- environments for [guaranteed resource requirements](https://etcd.io/docs/current/op-guide/hardware/).
57
-
58
- * The minimum recommended etcd versions to run in production are `3.4.22+` and `3.5.6+`.
59
58
-->
60
- ## 先决条件 {#prerequisites}
61
-
62
- * 运行的 etcd 集群个数成员为奇数。
63
-
64
- * etcd 是一个 leader-based 分布式系统。确保主节点定期向所有从节点发送心跳,以保持集群稳定。
65
-
66
59
* 确保不发生资源不足。
67
60
68
61
集群的性能和稳定性对网络和磁盘 I/O 非常敏感。任何资源匮乏都会导致心跳超时,
69
62
从而导致集群的不稳定。不稳定的情况表明没有选出任何主节点。
70
63
在这种情况下,集群不能对其当前状态进行任何更改,这意味着不能调度新的 Pod。
71
64
65
+ <!--
66
+ * Keeping etcd clusters stable is critical to the stability of Kubernetes
67
+ clusters. Therefore, run etcd clusters on dedicated machines or isolated
68
+ environments for [guaranteed resource requirements](https://etcd.io/docs/current/op-guide/hardware/).
69
+
70
+ * The minimum recommended etcd versions to run in production are `3.4.22+` and `3.5.6+`.
71
+ -->
72
72
* 保持 etcd 集群的稳定对 Kubernetes 集群的稳定性至关重要。
73
73
因此,请在专用机器或隔离环境上运行 etcd 集群,
74
74
以满足[ 所需资源需求] ( https://etcd.io/docs/current/op-guide/hardware/ ) 。
@@ -100,7 +100,7 @@ This section covers starting a single-node and multi-node etcd cluster.
100
100
<!--
101
101
### Single-node etcd cluster
102
102
103
- Use a single-node etcd cluster only for testing purpose .
103
+ Use a single-node etcd cluster only for testing purposes .
104
104
105
105
1. Run the following:
106
106
@@ -272,10 +272,10 @@ ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 \
272
272
### 限制 etcd 集群的访问 {#limiting-access-of-etcd-clusters}
273
273
274
274
<!--
275
- After configuring secure communication, restrict the access of etcd cluster to
276
- only the Kubernetes API servers. Use TLS authentication to do so .
275
+ After configuring secure communication, restrict the access of the etcd cluster to
276
+ only the Kubernetes API servers using TLS authentication.
277
277
-->
278
- 配置安全通信后,限制只有 Kubernetes API 服务器可以访问 etcd 集群。使用 TLS 身份验证来完成此任务 。
278
+ 配置安全通信后,使用 TLS 身份验证来限制只有 Kubernetes API 服务器可以访问 etcd 集群。
279
279
280
280
<!--
281
281
For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are
@@ -301,12 +301,9 @@ flags `--etcd-certfile=k8sclient.cert`, `--etcd-keyfile=k8sclient.key` and
301
301
302
302
{{< note >}}
303
303
<!--
304
- etcd authentication is not currently supported by Kubernetes. For more
305
- information, see the related issue
306
- [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398).
304
+ etcd authentication is not planned for Kubernetes.
307
305
-->
308
- Kubernetes 目前不支持 etcd 身份验证。
309
- 想要了解更多信息,请参阅相关的问题[ 支持 etcd v2 的基本认证] ( https://github.com/kubernetes/kubernetes/issues/23398 ) 。
306
+ Kubernetes 没有为 etcd 提供身份验证的计划。
310
307
{{< /note >}}
311
308
312
309
<!--
@@ -356,7 +353,7 @@ replace it with `member4=http://10.0.0.4`.
356
353
fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379
357
354
```
358
355
<!--
359
- 2 . Do either of the following:
356
+ 1 . Do either of the following:
360
357
361
358
1. If each Kubernetes API server is configured to communicate with all etcd
362
359
members, remove the failed member from the `--etcd-servers` flag, then
@@ -373,16 +370,16 @@ replace it with `member4=http://10.0.0.4`.
373
370
则停止与失败的 etcd 通信的 Kubernetes API 服务器。
374
371
375
372
<!--
376
- 3 . Stop the etcd server on the broken node. It is possible that other
377
- clients besides the Kubernetes API server is causing traffic to etcd
373
+ 1 . Stop the etcd server on the broken node. It is possible that other
374
+ clients besides the Kubernetes API server are causing traffic to etcd
378
375
and it is desirable to stop all traffic to prevent writes to the data
379
- dir .
376
+ directory .
380
377
-->
381
378
3 . 停止故障节点上的 etcd 服务器。除了 Kubernetes API 服务器之外的其他客户端可能会造成流向 etcd 的流量,
382
379
可以停止所有流量以防止写入数据目录。
383
380
384
381
<!--
385
- 4 . Remove the failed member:
382
+ 1 . Remove the failed member:
386
383
-->
387
384
4 . 移除失败的成员:
388
385
@@ -400,7 +397,7 @@ replace it with `member4=http://10.0.0.4`.
400
397
```
401
398
402
399
<!--
403
- 5 . Add the new member:
400
+ 1 . Add the new member:
404
401
-->
405
402
5 . 增加新成员:
406
403
@@ -418,7 +415,7 @@ replace it with `member4=http://10.0.0.4`.
418
415
```
419
416
420
417
<!--
421
- 6 . Start the newly added member on a machine with the IP `10.0.0.4`:
418
+ 1 . Start the newly added member on a machine with the IP `10.0.0.4`:
422
419
-->
423
420
6 . 在 IP 为 ` 10.0.0.4 ` 的机器上启动新增加的成员:
424
421
@@ -430,7 +427,7 @@ replace it with `member4=http://10.0.0.4`.
430
427
```
431
428
432
429
<!--
433
- 7 . Do either of the following:
430
+ 1 . Do either of the following:
434
431
435
432
1. If each Kubernetes API server is configured to communicate with all etcd
436
433
members, add the newly added member to the `--etcd-servers` flag, then
@@ -459,18 +456,18 @@ For more information on cluster reconfiguration, see
459
456
<!--
460
457
## Backing up an etcd cluster
461
458
462
- All Kubernetes objects are stored on etcd. Periodically backing up the etcd
459
+ All Kubernetes objects are stored in etcd. Periodically backing up the etcd
463
460
cluster data is important to recover Kubernetes clusters under disaster
464
461
scenarios, such as losing all control plane nodes. The snapshot file contains
465
- all the Kubernetes states and critical information. In order to keep the
462
+ all the Kubernetes state and critical information. In order to keep the
466
463
sensitive Kubernetes data safe, encrypt the snapshot files.
467
464
468
465
Backing up an etcd cluster can be accomplished in two ways: etcd built-in
469
466
snapshot and volume snapshot.
470
467
-->
471
468
## 备份 etcd 集群 {#backing-up-an-etcd-cluster}
472
469
473
- 所有 Kubernetes 对象都存储在 etcd 上 。
470
+ 所有 Kubernetes 对象都存储在 etcd 中 。
474
471
定期备份 etcd 集群数据对于在灾难场景(例如丢失所有控制平面节点)下恢复 Kubernetes 集群非常重要。
475
472
快照文件包含所有 Kubernetes 状态和关键信息。为了保证敏感的 Kubernetes 数据的安全,可以对快照文件进行加密。
476
473
@@ -482,22 +479,22 @@ snapshot and volume snapshot.
482
479
### 内置快照 {#built-in-snapshot}
483
480
484
481
<!--
485
- etcd supports built-in snapshot. A snapshot may either be taken from a live
482
+ etcd supports built-in snapshot. A snapshot may either be created from a live
486
483
member with the `etcdctl snapshot save` command or by copying the
487
484
`member/snap/db` file from an etcd
488
485
[data directory](https://etcd.io/docs/current/op-guide/configuration/#--data-dir)
489
- that is not currently used by an etcd process. Taking the snapshot will
486
+ that is not currently used by an etcd process. Creating the snapshot will
490
487
not affect the performance of the member.
491
488
-->
492
- etcd 支持内置快照。快照可以从使用 ` etcdctl snapshot save ` 命令的活动成员中获取 ,
489
+ etcd 支持内置快照。快照可以从使用 ` etcdctl snapshot save ` 命令的活动成员中创建 ,
493
490
也可以通过从 etcd [ 数据目录] ( https://etcd.io/docs/current/op-guide/configuration/#--data-dir )
494
- 复制 ` member/snap/db ` 文件,该 etcd 数据目录目前没有被 etcd 进程使用。获取快照不会影响成员的性能 。
491
+ 复制 ` member/snap/db ` 文件,该 etcd 数据目录目前没有被 etcd 进程使用。创建快照不会影响成员的性能 。
495
492
496
493
<!--
497
- Below is an example for taking a snapshot of the keyspace served by
494
+ Below is an example for creating a snapshot of the keyspace served by
498
495
`$ENDPOINT` to the file `snapshot.db`:
499
496
-->
500
- 下面是一个示例,用于获取 ` $ENDPOINT ` 所提供的键空间的快照到文件 ` snapshot.db ` :
497
+ 下面是一个示例,用于创建 ` $ENDPOINT ` 所提供的键空间的快照到文件 ` snapshot.db ` :
501
498
502
499
``` shell
503
500
ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshot.db
@@ -527,19 +524,19 @@ ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshot.db
527
524
528
525
<!--
529
526
If etcd is running on a storage volume that supports backup, such as Amazon
530
- Elastic Block Store, back up etcd data by taking a snapshot of the storage
527
+ Elastic Block Store, back up etcd data by creating a snapshot of the storage
531
528
volume.
532
529
-->
533
530
如果 etcd 运行在支持备份的存储卷(如 Amazon Elastic Block
534
- 存储)上,则可以通过获取存储卷的快照来备份 etcd 数据。
531
+ 存储)上,则可以通过创建存储卷的快照来备份 etcd 数据。
535
532
536
533
<!--
537
534
### Snapshot using etcdctl options
538
535
-->
539
536
### 使用 etcdctl 选项的快照 {#snapshot-using-etcdctl-options}
540
537
541
538
<!--
542
- We can also take the snapshot using various options given by etcdctl. For example
539
+ We can also create the snapshot using various options given by etcdctl. For example:
543
540
-->
544
541
我们还可以使用 etcdctl 提供的各种选项来制作快照。例如:
545
542
@@ -548,10 +545,10 @@ ETCDCTL_API=3 etcdctl -h
548
545
```
549
546
550
547
<!--
551
- will list various options available from etcdctl. For example, you can take a snapshot by specifying
552
- the endpoint, certificates etc as shown below:
548
+ will list various options available from etcdctl. For example, you can create a snapshot by specifying
549
+ the endpoint, certificates and key as shown below:
553
550
-->
554
- 列出 etcdctl 可用的各种选项。例如,你可以通过指定端点、证书等来制作快照 ,如下所示:
551
+ 列出 etcdctl 可用的各种选项。例如,你可以通过指定端点、证书和密钥来制作快照 ,如下所示:
555
552
556
553
``` shell
557
554
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
@@ -573,7 +570,7 @@ where `trusted-ca-file`, `cert-file` and `key-file` can be obtained from the des
573
570
Scaling out etcd clusters increases availability by trading off performance.
574
571
Scaling does not increase cluster performance nor capability. A general rule
575
572
is not to scale out or in etcd clusters. Do not configure any auto scaling
576
- groups for etcd clusters. It is highly recommended to always run a static
573
+ groups for etcd clusters. It is strongly recommended to always run a static
577
574
five-member etcd cluster for production Kubernetes clusters at any officially
578
575
supported scale.
579
576
-->
@@ -599,7 +596,7 @@ for information on how to add members into an existing cluster.
599
596
<!--
600
597
etcd supports restoring from snapshots that are taken from an etcd process of
601
598
the [major.minor](http://semver.org/) version. Restoring a version from a
602
- different patch version of etcd also is supported. A restore operation is
599
+ different patch version of etcd is also supported. A restore operation is
603
600
employed to recover the data of a failed cluster.
604
601
-->
605
602
etcd 支持从 [ major.minor] ( http://semver.org/ ) 或其他不同 patch 版本的 etcd 进程中获取的快照进行恢复。
@@ -637,7 +634,7 @@ etcdctl --data-dir <data-dir-location> snapshot restore snapshot.db
637
634
```
638
635
639
636
<!--
640
- If `<data-dir-location>` is the same folder as before, delete it and stop etcd process before restoring the cluster. Else change etcd configuration and restart the etcd process after restoration to make it use the new data directory.
637
+ If `<data-dir-location>` is the same folder as before, delete it and stop the etcd process before restoring the cluster. Otherwise, change etcd configuration and restart the etcd process after restoration to have it use the new data directory.
641
638
-->
642
639
如果 ` <data-dir-location> ` 与之前的文件夹相同,请先删除此文件夹并停止 etcd 进程,再恢复集群。
643
640
否则,需要在恢复后更改 etcd 配置并重新启动 etcd 进程才能使用新的数据目录。
@@ -650,7 +647,7 @@ For more information and examples on restoring a cluster from a snapshot file, s
650
647
[ etcd 灾难恢复文档] ( https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster ) 。
651
648
652
649
<!--
653
- If the access URLs of the restored cluster is changed from the previous
650
+ If the access URLs of the restored cluster are changed from the previous
654
651
cluster, the Kubernetes API server must be reconfigured accordingly. In this
655
652
case, restart Kubernetes API servers with the flag
656
653
`--etcd-servers=$NEW_ETCD_CLUSTER` instead of the flag
@@ -730,13 +727,13 @@ For more details on etcd maintenance, please refer to the [etcd maintenance](htt
730
727
731
728
{{< note >}}
732
729
<!--
733
- Defragmentation is an expensive operation, so it should be executed as infrequent
730
+ Defragmentation is an expensive operation, so it should be executed as infrequently
734
731
as possible. On the other hand, it's also necessary to make sure any etcd member
735
- will not run out of the storage quota. The Kubernetes project recommends that when
732
+ will not exceed the storage quota. The Kubernetes project recommends that when
736
733
you perform defragmentation, you use a tool such as [etcd-defrag](https://github.com/ahrtr/etcd-defrag).
737
734
-->
738
735
碎片整理是一种昂贵的操作,因此应尽可能少地执行此操作。
739
- 另一方面,也有必要确保任何 etcd 成员都不会用尽存储配额 。
736
+ 另一方面,也有必要确保任何 etcd 成员都不会超过存储配额 。
740
737
Kubernetes 项目建议在执行碎片整理时,
741
738
使用诸如 [ etcd-defrag] ( https://github.com/ahrtr/etcd-defrag ) 之类的工具。
742
739
{{< /note >}}
0 commit comments