为Kubernetes运行etcd集群
etcd是兼具一致性和高可用性的键值数据库,可以作为保存Kubernetes所有集群数据的后台数据库。
你的Kubernetes集群的etcd数据库通常需要有个备份计划。
要了解etcd更深层次的信息,请参考etcd文档。
在开始之前
你必须拥有一个Kubernetes的集群,同时你的Kubernetes集群必须带有kubectl命令行工具。建议在至少有两个节点的集群上运行本教程,且这些节点不作为控制平面主机。如果你还没有集群,你可以通过Minikube构建一个你自己的集群,或者你可以使用下面任意一个Kubernetes工具构建:
要检查版本,请输入kubectlversion。
先决条件 资源需求
使用有限的资源运行etcd只适合测试目的。为了在生产中部署,需要先进的硬件配置。在生产中部署etcd之前,请查看所需资源参考文档。
启动etcd集群
本节介绍如何启动单节点和多节点etcd集群。
单节点etcd集群
只为测试目的使用单节点etcd集群。
运行以下命令:
etcd --listen-client-urls=http://$PRIVATE_IP:2379 \
--advertise-client-urls=http://$PRIVATE_IP:2379
使用参数--etcd-servers=$PRIVATE_IP:2379启动KubernetesAPI服务器。
确保将PRIVATE_IP设置为etcd客户端IP。
多节点etcd集群
出于耐用性和高可用性考量,在生产环境中应以多节点集群的方式运行etcd,并且定期备份。建议在生产环境中使用五个成员的集群。有关该内容的更多信息,请参阅常见问题文档。
可以通过静态成员信息或动态发现的方式配置etcd集群。有关集群的详细信息,请参阅etcd集群文档。
例如,考虑运行以下客户端URL的五个成员的etcd集群:$IP1:2379、$IP2:2379、$IP3:2379、$IP4:2379和$IP5:2379。要启动KubernetesAPI服务器:
运行以下命令:
etcd --listen-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379 --advertise-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379
使用参数--etcd-servers=$IP1:2379,$IP2:2379,$IP3:2379,$IP4:2379,$IP5:2379启动KubernetesAPI服务器。
确保将IP变量设置为客户端IP地址。
使用负载均衡的多节点etcd集群
要运行负载均衡的etcd集群:
建立一个etcd集群。在etcd集群前面配置负载均衡器。例如,让负载均衡器的地址为$LB。使用参数--etcd-servers=$LB:2379启动KubernetesAPI服务器。加固etcd集群
对etcd的访问相当于集群中的root权限,因此理想情况下只有API服务器才能访问它。考虑到数据的敏感性,建议只向需要访问etcd集群的节点授予权限。
想要确保etcd的安全,可以设置防火墙规则或使用etcd提供的安全特性,这些安全特性依赖于x509公钥基础设施(PKI)。首先,通过生成密钥和证书对来建立安全的通信通道。例如,使用密钥对peer.key和peer.cert来保护etcd成员之间的通信,而client.key和client.cert用于保护etcd与其客户端之间的通信。请参阅etcd项目提供的 示例脚本,以生成用于客户端身份验证的密钥对和CA文件。
安全通信
若要使用安全对等通信对etcd进行配置,请指定参数--peer-key-file=peer.key和--peer-cert-file=peer.cert,并使用HTTPS作为URL模式。
类似地,要使用安全客户端通信对etcd进行配置,请指定参数--key-file=k8sclient.key和--cert-file=k8sclient.cert,并使用HTTPS作为URL模式。使用安全通信的客户端命令的示例:
ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
member list
限制etcd集群的访问
配置安全通信后,限制只有KubernetesAPI服务器可以访问etcd集群。使用TLS身份验证来完成此任务。
例如,考虑由CAetcd.ca信任的密钥对k8sclient.key和k8sclient.cert。当etcd配置为--client-cert-auth和TLS时,它使用系统CA或由--trusted-ca-file参数传入的CA验证来自客户端的证书。指定参数--client-cert-auth=true和--trusted-ca-file=etcd.ca将限制对具有证书k8sclient.cert的客户端的访问。
一旦正确配置了etcd,只有具有有效证书的客户端才能访问它。要让KubernetesAPI服务器访问,可以使用参数--etcd-certfile=k8sclient.cert、--etcd-keyfile=k8sclient.key和--etcd-cafile=ca.cert配置。
Note:Kubernetes目前不支持etcd身份验证。想要了解更多信息,请参阅相关的问题支持etcdv2的基本认证。
替换失败的etcd成员
etcd集群通过容忍少数成员故障实现高可用性。但是,要改善集群的整体健康状况,请立即替换失败的成员。当多个成员失败时,逐个替换它们。替换失败成员需要两个步骤:删除失败成员和添加新成员。
虽然etcd在内部保留唯一的成员ID,但建议为每个成员使用唯一的名称,以避免人为错误。例如,考虑一个三成员的etcd集群。假定URL分别为:member1=http://10.0.0.1、member2=http://10.0.0.2和member3=http://10.0.0.3。当member1失败时,将其替换为member4=http://10.0.0.4。
获取失败的member1的成员ID:
etcdctl --endpoints=http://10.0.0.2,http://10.0.0.3 member list
显示以下信息:
8211f1d0f64f3269, started, member1, http://10.0.0.1:2380, http://10.0.0.1:2379
91bc3c398fb3c146, started, member2, http://10.0.0.2:2380, http://10.0.0.2:2379
fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379
移除失败的成员
etcdctl member remove 8211f1d0f64f3269
显示以下信息:
Removed member 8211f1d0f64f3269 from cluster
增加新成员:
etcdctl member add member4 --peer-urls=http://10.0.0.4:2380
显示以下信息:
Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4
在IP为10.0.0.4的机器上启动新增加的成员:
export ETCD_NAME="member4"
export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380"
export ETCD_INITIAL_CLUSTER_STATE=existing
etcd [flags]
执行以下操作之一:
有关集群重新配置的详细信息,请参阅etcd重构文档。
备份etcd集群
所有Kubernetes对象都存储在etcd上。定期备份etcd集群数据对于在灾难场景(例如丢失所有控制平面节点)下恢复Kubernetes集群非常重要。快照文件包含所有Kubernetes状态和关键信息。为了保证敏感的Kubernetes数据的安全,可以对快照文件进行加密。
备份etcd集群可以通过两种方式完成:etcd内置快照和卷快照。
内置快照
etcd支持内置快照。快照可以从使用etcdctlsnapshotsave命令的活动成员中获取,也可以通过从etcd数据目录复制member/snap/db文件,该etcd数据目录目前没有被etcd进程使用。获取快照不会影响成员的性能。
下面是一个示例,用于获取$ENDPOINT所提供的键空间的快照到文件snapshotdb:
ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshotdb
验证快照:
ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshotdb
+----------+----------+------------+------------+
| HASH | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| fe01cf57 | 10 | 7 | 2.1 MB |
+----------+----------+------------+------------+
卷快照
如果etcd运行在支持备份的存储卷(如AmazonElasticBlock存储)上,则可以通过获取存储卷的快照来备份etcd数据。
使用etcdctl选项的快照
我们还可以使用etcdctl提供的各种选项来制作快照。例如:
ETCDCTL_API=3 etcdctl -h
列出etcdctl可用的各种选项。例如,你可以通过指定端点、证书等来制作快照,如下所示:
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert= --cert= --key= \
snapshot save
可以从etcdPod的描述中获得trusted-ca-file、cert-file和key-file。
为etcd集群扩容
通过交换性能,对etcd集群扩容可以提高可用性。缩放不会提高集群性能和能力。一般情况下不要扩大或缩小etcd集群的集合。不要为etcd集群配置任何自动缩放组。强烈建议始终在任何官方支持的规模上运行生产Kubernetes集群时使用静态的五成员etcd集群。
合理的扩展是在需要更高可靠性的情况下,将三成员集群升级为五成员集群。请参阅etcd重新配置文档以了解如何将成员添加到现有集群中的信息。
恢复etcd集群
etcd支持从major.minor或其他不同patch版本的etcd进程中获取的快照进行恢复。还原操作用于恢复失败的集群的数据。
在启动还原操作之前,必须有一个快照文件。它可以是来自以前备份操作的快照文件,也可以是来自剩余数据目录的快照文件。例如:
ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshotdb
恢复时也可以指定操作选项,例如:
ETCDCTL_API=3 etcdctl --data-dir snapshot restore snapshotdb
有关从快照文件还原集群的详细信息和示例,请参阅etcd灾难恢复文档。
如果还原的集群的访问URL与前一个集群不同,则必须相应地重新配置KubernetesAPI服务器。在本例中,使用参数--etcd-servers=$NEW_ETCD_CLUSTER而不是参数--etcd-servers=$OLD_ETCD_CLUSTER重新启动KubernetesAPI服务器。用相应的IP地址替换$NEW_ETCD_CLUSTER和$OLD_ETCD_CLUSTER。如果在etcd集群前面使用负载平衡,则可能需要更新负载均衡器。
如果大多数etcd成员永久失败,则认为etcd集群失败。在这种情况下,Kubernetes不能对其当前状态进行任何更改。虽然已调度的pod可能继续运行,但新的pod无法调度。在这种情况下,恢复etcd集群并可能需要重新配置KubernetesAPI服务器以修复问题。
Note:
如果集群中正在运行任何API服务器,则不应尝试还原etcd的实例。相反,请按照以下步骤还原etcd:
我们还建议重启所有组件(例如
kube-scheduler、
kube-controller-manager、
kubelet),以确保它们不会依赖一些过时的数据。请注意,实际中还原会花费一些时间。在还原过程中,关键组件将丢失领导锁并自行重启。
升级etcd集群
有关etcd升级的更多详细信息,请参阅etcd升级文档。
Note:在开始升级之前,请先备份你的etcd集群。