网站首页 > 技术文章 正文
Kubernetes作为目前最炙手可热的容器编排软件,受到越来越多互联网公司的喜爱,之所以会出现这样的现象,主要还是因为这套编排软件不仅功能强大,还非常方便进行二次开发,整个Kubernetes的生态圈非常活跃。有了Kubernetes这套“骨架”,可以在上面运行非常多的中间件和应用程序。Apiserver,Controller Manager,Scheduler,Proxy可以认为是这套“骨架”的组成部分,而Etcd便是这套系统的底座,整个系统的数据都存储在它当中,保证了Etcd的稳定性整个容器编排系统的稳定性就有了保证。
在正式开始之前,说明下实验环境,五台主机组成Kubernetes集群。
控制平面主机:p1.xufu.xyz、p2.xufu.xyz、p3.xufu.xyz
工作主机:p4.xufu.xyz、p5.xufu.xyz
主机系统:CentOS Linux release 7.9.2009 (Core)
Etcd版本:3.5.1
集群使用kubeadm搭建,具体可参考Kubernetes集群快速部署
Etcd
- 简介
它是一种键值数据库,Kubernetes将自身的状态数据都存储在Etcd中,这些数据包含deployment,pod,daemonset等各种对象。整个集群组件中只有Apiserver会直接和Etcd通信,其他组件都是直接和Apiserver通信。在生产环境中,最好以集群的方式运行Etcd,官方建议运行五个节点组成集群,这样可以在丢失两个节点的情况下, 保证数据的可用性。
- 访问
Etcd中存放有不少敏感数据,所以对它的访问需要使用公钥和私钥。为了方便访问,在家目录文件“.bashrc”配置如下命令别名,
alias ectl='etcdctl --endpoints p1.xufu.xyz:2379 \
--cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt'
显示当前Etcd存储的所有Key,
ectl get / --prefix --keys-only
- 备份
使用kubeadm部署的集群,Etcd默认将数据存放在宿主机的目录/var/lib/etcd下,
Etcd的版本2和3差别很大,因笔者使用的是3版本,备份命令是这样(在任一控制平面主机操作均可),命令执行不用对Etcd做关闭操作。
ectl snapshot save snapshot-$(date +%F)
查看备份的快照,
- 恢复
恢复操作相比较备份操作有稍许麻烦。下面步骤需要在三台控制平面主机上都操作。
1,关闭kubelet,否则它会自动重启apiserver
systemctl stop kubelet.service
2,关闭apiserver容器,使用docker命令找到容器,直接stop
docker stop apiservername
3,重命名目录/var/lib/etcd,创建新的,并修改目录权限
mv /var/lib/etcd /var/lib/etcd_old
mkdir /var/lib/etcd
chmod 700 /var/lib/etcd
4,使用备份的快照,恢复数据,
ectl snapshot restore /data/etcd_backup/etcd-snapshot-2022-08-03.db \
--name p1.xufu.xyz \
--initial-cluster "etcd-0=https://p1.xufu.xyz:2380,etcd-1=https://p2.xufu.xyz:2380,etcd-2=https://p3.xufu.xyz:2380" \
--initial-advertise-peer-urls https://p1.xufu.xyz:2380 \
--data-dir=/var/lib/etcd
p2和p3节点类似。
5,启动三台etcd,确认下集群是否健康,
[root@p1 etcd]# ectl --endpoints=https://p1.xufu.xyz:2379,https://p2.xufu.xyz:2379,https://p3.xufu.xyz:2379 endpoint health
https://p2.xufu.xyz:2379 is healthy: successfully committed proposal: took = 100.193247ms
p1.xufu.xyz:2379 is healthy: successfully committed proposal: took = 111.234607ms
https://p1.xufu.xyz:2379 is healthy: successfully committed proposal: took = 113.788721ms
https://p3.xufu.xyz:2379 is healthy: successfully committed proposal: took = 118.403445ms
确认没问题后,启动apiserver容器。
至此,整个恢复备份过程操作完毕。
猜你喜欢
- 2024-10-21 数据库同步 Elasticsearch 后数据不一致,怎么办
- 2024-10-21 (建议收藏)小白视角总结分布式搜索组件elasticsearch《二》
- 2024-10-21 RabbitMQ消息服务用户手册(rabbitmq消息id)
- 2024-10-21 索引生命周期管理ILM看完不懂你锤我
- 2024-10-21 Elasticsearch技术问答系列-NO3(elasticsearch curator)
- 2024-10-21 从裸机到700亿参数大模型,这里有份教程,还有现成可用的脚本
- 2024-10-21 「一文搞懂」Nacos健康检查机制(nacos修改健康检查模式)
- 2024-10-21 「ceph-deploy」CentOS7部署Ceph-nautilus 14.2.18版本集群学习
- 2024-10-21 Kibana 最常见的“启动报错”的故障原因及解决方案汇总
- 2024-10-21 二进制部署Kubernetes V1.18.X(etcd集群篇)
- 最近发表
- 标签列表
-
- cmd/c (57)
- c++中::是什么意思 (57)
- sqlset (59)
- ps可以打开pdf格式吗 (58)
- phprequire_once (61)
- localstorage.removeitem (74)
- routermode (59)
- vector线程安全吗 (70)
- & (66)
- java (73)
- org.redisson (64)
- log.warn (60)
- cannotinstantiatethetype (62)
- js数组插入 (83)
- resttemplateokhttp (59)
- gormwherein (64)
- linux删除一个文件夹 (65)
- mac安装java (72)
- reader.onload (61)
- outofmemoryerror是什么意思 (64)
- flask文件上传 (63)
- eacces (67)
- 查看mysql是否启动 (70)
- java是值传递还是引用传递 (58)
- 无效的列索引 (74)