回复
Kubernetes集群管理（下）
fldj
发布于 2022-9-6 11:56
浏览
0收藏
作者 | 乔克
来源 |运维开发故事(ID：mygsdcsf)
转载请联系授权(微信ID：wanger5354)
更新集群
集群的更新操作有很多，比如创建或删除应用、添加或者删除节点等，这里主要介绍几种常用的操作：
- 升级集群
- 更新集群证书
- 添加或删除集群
升级集群
Kubernetes社区新版本的推出速度很快的，至少保持一年3个版本的迭代。在实际生产中，我们可能不会频繁的升级集群，因为这样的动作太大，可能导致其他生产问题。
但是，有时候会因为某些原因（比如软件版本兼容性、集群BUG等）不得不做升级集群的操作，所以，有必要掌握集群的升级方法以备不时之需。
升级前准备
- 升级前，需要认真阅读每个版本的?CHANGELOG。
- 务必备份所有重要组件，例如存储在数据库中应用层面的状态。kubeadm upgrade 不会影响你的工作负载，只会涉及 Kubernetes 内部的组件，但备份终究是好的。
- 可以小版本升级，也可以跨一个大版本升级，不建议跨两个大版本升级
升级目标
现在集群的版本是1.24.0，预计升级的目标版本是1.24.2。
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
kk-master Ready control-plane 7m20s v1.24.0
kk-node01 Ready <none> 6m40s v1.24.0备份集群
kubeadm upgrade 不会影响你的工作负载，只会涉及 Kubernetes 内部的组件，但备份终究是好的。这里主要是对集群的所有资源进行备份，我使用的是一个开源的脚本，项目地址是：?https://github.com/solomonxu/k8s-backup-restore
（1）下载脚本
$ mkdir -p /data
$ cd /data
$ git clone https://github.com/solomonxu/k8s-backup-restore.git（2）执行备份
$ cd /data/k8s-backup-restore
$ ./bin/k8s_backup.sh 如果要恢复怎么办？只需要执行如下步骤。（1）创建恢复目录
$ mkdir -p /data/k8s-backup-restore/data/restore（2）将需要恢复的YAML清单复制到该目录下
$ cp devops_deployments_gitlab.yaml ../../restore/（3）执行恢复命令
$ cd /data/k8s-backup-restore
$ ./bin/k8s_restore.sh升级控制节点
（1）确定要升级的版本包是否存在
$ yum list --showduplicates kubeadm --disableexcludes=kubernetes（2）升级kubeadm到指定版本
$ yum install -y kubeadm-1.24.2-0 --disableexcludes=kubernetes执行以下命令查看是否升级成功。
$ kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.2", GitCommit:"f66044f4361b9f1f96f0053dd46cb7dce5e990a8", GitTreeState:"clean", BuildDate:"2022-06-15T14:20:54Z", GoVersion:"go1.18.3", Compiler:"gc", Platform:"linux/amd64"}（3）排空节点
$ kubectl cordon kk-master
$ kubectl drain kk-master （4）运行升级计划，查看是否可以升级
$ kubeadm upgrade plan
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.24.0
[upgrade/versions] kubeadm version: v1.24.2
[upgrade/versions] Target version: v1.24.2
[upgrade/versions] Latest version in the v1.24 series: v1.24.2
Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT CURRENT TARGET
kubelet 2 x v1.24.0 v1.24.2
Upgrade to the latest version in the v1.24 series:
COMPONENT CURRENT TARGET
kube-apiserver v1.24.0 v1.24.2
kube-controller-manager v1.24.0 v1.24.2
kube-scheduler v1.24.0 v1.24.2
kube-proxy v1.24.0 v1.24.2
CoreDNS v1.8.6 v1.8.6
etcd 3.5.3-0 3.5.3-0
You can now apply the upgrade by executing the following command:
kubeadm upgrade apply v1.24.2
_____________________________________________________________________
The table below shows the current state of component configs as understood by this version of kubeadm.
Configs that have a "yes" mark in the "MANUAL UPGRADE REQUIRED" column require manual config upgrade or
resetting to kubeadm defaults before a successful upgrade can be performed. The version to manually
upgrade to is denoted in the "PREFERRED VERSION" column.
API GROUP CURRENT VERSION PREFERRED VERSION MANUAL UPGRADE REQUIRED
kubeproxy.config.k8s.io v1alpha1 v1alpha1 no
kubelet.config.k8s.io v1beta1 v1beta1 no
_____________________________________________________________________（5）升级集群
$ kubeadm upgrade apply v1.24.2 --config kubeadm.yaml 看到如下输出表示升级成功。
......
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.24.2". Enjoy!
......（6）取消节点调度保护
$ kubectl uncordon kk-master（7）由于这里Master即是控制平面，也是节点，所以需要对其在进行一次升级
$ kubeadm upgrade node（8）升级kubectl和kubelet
$ yum install -y kubelet-1.24.2-0 kubectl-1.24.2-0 --disableexcludes=kubernetes（9）重启kubelet
$ systemctl daemon-reload
$ systemctl restart kubelet升级节点
（1）升级kubeadm
$ yum install -y kubeadm-1.24.2-0 --disableexcludes=kubernetes（2）设置节点不可调度且排空节点
$ kubectl cordon kk-node01
$ kubectl drain kk-node01（3）升级节点
$ kubeadm upgrade node（4）升级kubelet
$ yum install -y kubelet-1.24.2-0 --disableexcludes=kubernetes（5）重启节点
$ systemctl daemon-reload
$ systemctl restart kubelet（6）恢复节点可调度
$ kubectl uncordon kk-node01验证集群
（1）查看集群状态信息是否正常
$ kubectl get no
NAME STATUS ROLES AGE VERSION
kk-master Ready control-plane 33m v1.24.2
kk-node01 Ready <none> 32m v1.24.2（2）查看集群Pod是否正常
$ kubectl get po -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-kube-controllers-5d49fc6c56-pq57d 1/1 Running 0 31m
kube-system calico-node-rjdqh 1/1 Running 0 31m
kube-system calico-node-s8475 1/1 Running 0 31m
kube-system coredns-7f74c56694-qpvmv 1/1 Running 0 35m
kube-system coredns-7f74c56694-ww8kb 1/1 Running 0 35m
kube-system etcd-kk-master 1/1 Running 0 35m
kube-system kube-apiserver-kk-master 1/1 Running 0 11m
kube-system kube-controller-manager-kk-master 1/1 Running 0 10m
kube-system kube-proxy-5pf65 1/1 Running 0 10m
kube-system kube-proxy-mcxlq 1/1 Running 0 10m
kube-system kube-scheduler-kk-master 1/1 Running 0 10m其他
在升级过程中如果升级失败并且没有回滚，可以继续执行kubeadm upgrade。如果要从故障状态恢复，可以执行kubeadm upgrade --force。
在升级期间，会在/etc/kubernetes/tmp目录下生成备份文件：
- kubeadm-backup-etcd-
- kubeadm-backup-manifests-
kubeadm-backup-etcd中包含本地etcd的数据备份，如果升级失败并且无法修复，可以将其数据复制到etcd数据目录进行手动修复。
kubeadm-backup-manifests中保存的是节点静态pod的YAML清单，如果升级失败并且无法修复，可以将其复制到/etc/kubernetes/manifests下进行手动修复。
升级证书
升级集群可能不会经常发送，但是升级证书应该是一个常态化操作。
使用kubeadm安装的证书默认有效期是一年，也就是说在证书过期之前必须对证书进行升级，不然就会导致整个集群异常。
可以使用如下命令查看集群的证书情况。
$ kubeadm certs check-expiration
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
admin.conf Jul 04, 2023 08:43 UTC 364d ca no
apiserver Jul 04, 2023 08:39 UTC 364d ca no
apiserver-etcd-client Jul 04, 2023 08:39 UTC 364d etcd-ca no
apiserver-kubelet-client Jul 04, 2023 08:39 UTC 364d ca no
controller-manager.conf Jul 04, 2023 08:40 UTC 364d ca no
etcd-healthcheck-client Jul 04, 2023 08:16 UTC 364d etcd-ca no
etcd-peer Jul 04, 2023 08:16 UTC 364d etcd-ca no
etcd-server Jul 04, 2023 08:16 UTC 364d etcd-ca no
front-proxy-client Jul 04, 2023 08:39 UTC 364d front-proxy-ca no
scheduler.conf Jul 04, 2023 08:40 UTC 364d ca no
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
ca Jul 01, 2032 08:16 UTC 9y no
etcd-ca Jul 01, 2032 08:16 UTC 9y no
front-proxy-ca Jul 01, 2032 08:16 UTC 9y no（1）使用kubeadm certs check-expiration检查证书是否过期
（2）备份证书
$ mkdir /etc/kubernetes.bak.20220704
$ cp -r /etc/kubernetes/* /etc/kubernetes.bak.20220704（3）备份etcd数据库
# 备份数据目录
$ cp -r /var/lib/etcd /var/lib/etcd.bak
# 快照备份
$ export ETCDCTL_API=3
$ etcdctl --endpoints localhost:2379 snapshot save snapshot.db \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
# 快照恢复命令
$ etcdctl snapshot restore snapshot.db --name m3 --data-dir=/home/etcd_data（4）更新证书
$ kubeadm alpha certs renew all --config=kubeadm.yaml（5）更新kubeconfig
$ kubeadm init phase kubeconfig all --config kubeadm.yaml（6）覆盖控制节点的kubeconfig
$ mv $HOME/.kube/config $HOME/.kube/config.old
$ cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# chown $(id -u):$(id -g) $HOME/.kube/config（7）完成后重启kubernetes控制面的组件
$ cd /etc/kubernetes/manifests
$ mv *.yaml ../
$ mv ../*.yaml .containerd运行时没有重启容器的命令，所以这里采用是直接移出再拷贝进来的操作。如果底层安装有docker，可以使用docker命令进行重启。
（8）检查证书是否更新
$ echo | openssl s_client -showcerts -connect 127.0.0.1:6443 -servername api 2>/dev/null | openssl x509 -noout -enddate
$ kubeadm certs check-expiration
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
admin.conf Jul 04, 2023 09:21 UTC 364d ca no
apiserver Jul 04, 2023 09:21 UTC 364d ca no
apiserver-etcd-client Jul 04, 2023 09:21 UTC 364d etcd-ca no
apiserver-kubelet-client Jul 04, 2023 09:21 UTC 364d ca no
controller-manager.conf Jul 04, 2023 09:21 UTC 364d ca no
etcd-healthcheck-client Jul 04, 2023 09:21 UTC 364d etcd-ca no
etcd-peer Jul 04, 2023 09:21 UTC 364d etcd-ca no
etcd-server Jul 04, 2023 09:21 UTC 364d etcd-ca no
front-proxy-client Jul 04, 2023 09:21 UTC 364d front-proxy-ca no
scheduler.conf Jul 04, 2023 09:21 UTC 364d ca no
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
ca Jul 01, 2032 08:16 UTC 9y no
etcd-ca Jul 01, 2032 08:16 UTC 9y no
front-proxy-ca Jul 01, 2032 08:16 UTC 9y no（7）其他 默认情况下，kubeadm 使用 /etc/kubernetes/kubelet.conf 中指定的 /var/lib/kubelet/pki/kubelet-client-current.pem 符号链接 来配置 kubelet 自动轮换客户端证书。如果此轮换过程失败，你可能会在 kube-apiserver 日志中看到 诸如x509: certificate has expired or is not yet valid之类的错误。
要解决此问题，你必须执行以下步骤：
从故障节点备份和删除 /etc/kubernetes/kubelet.conf 和 /var/lib/kubelet/pki/kubelet-client*。
在集群中具有 /etc/kubernetes/pki/ca.key 的、正常工作的控制平面节点上 执行 kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf。$NODE 必须设置为集群中现有故障节点的名称。手动修改生成的 kubelet.conf 以调整集群名称和服务器端点， 或传递 kubeconfig user --config（此命令接受 InitConfiguration）。如果你的集群没有 ca.key，你必须在外部对 kubelet.conf 中的嵌入式证书进行签名。
将得到的 kubelet.conf 文件复制到故障节点上，作为 /etc/kubernetes/kubelet.conf。
在故障节点上重启 kubelet（systemctl restart kubelet），等待 /var/lib/kubelet/pki/kubelet-client-current.pem 重新创建。
在故障节点上运行 kubeadm init phase kubelet-finalize all。这将使新的 kubelet.conf 文件使用 /var/lib/kubelet/pki/kubelet-client-current.pem 并将重新启动 kubelet。
确保节点状况变为 Ready。
PS：除了使用上面方式升级集群证书之外，还可以通过升级集群版本的方式升级证书。
添加/删除节点
当集群节点不足以支撑业务的时候，我们也许会对集群进行扩容，也就是添加节点以满足日常需求。当集群节点比较空闲的时候，也会对集群进行缩容，也就是删除节点以节约开支。
所以添加/删除节点在日常的工作中是比较常见的操作，而且整体操作也比较简单。
添加节点
添加节点的操作和初始化node节点一样，严格按照环境准备和初始化Node节点操作即可。
有几点需要注意：
（1）所有主机hosts添加新的主机
$ cat >> /etc/hosts << EOF
192.168.205.128 kk-master
192.168.205.130 kk-node01
192.168.205.133 kk-node02
EOF（2）查看集群token
$ kubeadm token list（3）如果token不存在就自己创建
$ kubeadm token create（4）获取ca证书sha256编码hash值
$ kubeadm join 192.168.205.128:6443 --token q0mjah.4k3oavynezdj8jf9 \
--discovery-token-ca-cert-hash sha256:3d5c2e7d2532a4f085159d89de3ea2ea515e0784787b9c1adf0d3826c283733c \
--node-name kk-node02（5）然后可以看到集群添加成功
$ kubectl get no
NAME STATUS ROLES AGE VERSION
kk-master Ready control-plane 111m v1.24.2
kk-node01 Ready <none> 111m v1.24.2
kk-node02 Ready <none> 54s v1.24.2删除节点
删除节点的操作也非常简单，总结如下：
（1）设置节点不可调度
$ kubectl cordon kk-node02（2）驱逐待删除节点上面的Pod
$ kubectl drain kk-node02 --ignore-daemonsets=true --delete-emptydir-data=true（3）然后进行节点删除
$ kubectl delete nodes kk-node02现在，节点已经从整个集群移除。
备份集群
对任何系统来说，备份都必不可少，比如备份数据库，备份文件系统，备份配置文件等。
对于Kubernetes来说，备份也尤为重要。Kubernetes中的所有对象都是存储在Etcd中，我们可以直接对数据库进行备份。当然，Kubernetes中所有对象的配置文件也是可见的，我们也可以直接对这些配置文件进行备份。
在真正使用中，一般会做两手方案，即备份数据库和备份配置清单。如果其中一种方案无法进行恢复，还可以通过另一种来兜底。
这里同时会介绍备份Etcd数据库和备份集群配置清单，以方便各位在实际中酌情处理。
备份数据库
备份
备份数据库比较简单，可以直接用etcdctl进行备份，在上面升级证书章节有简单提到。
（1）安装etcdctl命令，在?https://github.com/etcd-io/etcd/releases上下载对应的etcd安装包
$ wget https://github.com/etcd-io/etcd/releases/download/v3.5.3/etcd-v3.5.3-linux-amd64.tar.gz
$ tar xf etcd-v3.5.3-linux-amd64.tar.gz
$ mv etcd-v3.5.3-linux-amd64/etcdctl /usr/local/bin/（2）检验命令
$ etcdctl version
etcdctl version: 3.5.3
API version: 3.5（3）进行备份操作
$ export ETCDCTL_API=3
$ etcdctl --endpoints localhost:2379 snapshot save snapshot.db \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key备份Ectd需要指定证书，如果执行节点没有，可以从主节点拷贝过来。
执行完成过后，可以在当前目录查看到备份结果。
$ export ETCDCTL_API=3
$ etcdctl --endpoints localhost:2379 snapshot save snapshot.db \
> --cacert=/etc/kubernetes/pki/etcd/ca.crt \
> --cert=/etc/kubernetes/pki/etcd/server.crt \
> --key=/etc/kubernetes/pki/etcd/server.key
{"level":"info","ts":"2022-07-04T20:00:17.509+0800","caller":"snapshot/v3_snapshot.go:65","msg":"created temporary db file","path":"snapshot.db.part"}
{"level":"info","ts":"2022-07-04T20:00:17.520+0800","logger":"client","caller":"v3/maintenance.go:211","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":"2022-07-04T20:00:17.520+0800","caller":"snapshot/v3_snapshot.go:73","msg":"fetching snapshot","endpoint":"localhost:2379"}
{"level":"info","ts":"2022-07-04T20:00:17.544+0800","logger":"client","caller":"v3/maintenance.go:219","msg":"completed snapshot read; closing"}
{"level":"info","ts":"2022-07-04T20:00:17.556+0800","caller":"snapshot/v3_snapshot.go:88","msg":"fetched snapshot","endpoint":"localhost:2379","size":"3.6 MB","took":"now"}
{"level":"info","ts":"2022-07-04T20:00:17.556+0800","caller":"snapshot/v3_snapshot.go:97","msg":"saved","path":"snapshot.db"}
Snapshot saved at snapshot.db
$ ll
total 3472
-rw-------. 1 root root 3551264 Jul 4 20:00 snapshot.db但是，我们不可能每次都手动来进行备份，所以最好是通过定时任务来执行。为了更好的备份，这里编写了一个简单的shell脚本，然后再加到定时任务中。
#! /bin/bash
ETCDCTL_PATH='/usr/local/bin/etcdctl'
ENDPOINTS='192.168.205.128:2379'
ETCD_DATA_DIR="/var/lib/etcd"
BACKUP_DIR="/var/backups/kube_etcd/etcd-$(date +%Y-%m-%d_%H:%M:%S)"
ETCDCTL_CERT="/etc/kubernetes/pki/etcd/server.crt"
ETCDCTL_KEY="/etc/kubernetes/pki/etcd/server.key"
ETCDCTL_CA_FILE="/etc/kubernetes/pki/etcd/ca.crt"
[ ! -d $BACKUP_DIR ] && mkdir -p $BACKUP_DIR
export ETCDCTL_API=2;$ETCDCTL_PATH backup --data-dir $ETCD_DATA_DIR --backup-dir $BACKUP_DIR
sleep 3
{
export ETCDCTL_API=3;$ETCDCTL_PATH --endpoints="$ENDPOINTS" snapshot save $BACKUP_DIR/snapshot.db \
--cacert="$ETCDCTL_CA_FILE" \
--cert="$ETCDCTL_CERT" \
--key="$ETCDCTL_KEY"
} > /dev/null
sleep 3
cd $BACKUP_DIR/../;ls -lt |awk '{if(NR>(5+1)){print "rm -rf "$9}}'|sh然后加入Linux定时任务，如下：
$ crontab -l
*/30 * * * * /opt/etcd_back/etcd_backup.sh恢复
（1）停止kube-apiserver和etcd
我这里直接将所有静态Pod的YAML文件移除。
cd /etc/kubernetes/manifests
mv *.yaml ../（2）移除etcd数据目录
$ mv /var/lib/etcd{,.bak.20220705}（3）执行恢复
￥ ETCDCTL_API=3 etcdctl snapshot restore snapshot.db --name kk-master --initial-cluster "kk-master=https://192.168.205.128:2380" --initial-cluster-token etcd-cluster --initial-advertise-peer-urls https://192.168.205.128:2380 --data-dir=/var/lib/etcd（4）重启Kubernetes组件
mv ../*.yaml .（5）验证集群状态
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
kk-master Ready control-plane 7h48m v1.24.2
kk-node01 Ready <none> 7h48m v1.24.2
$ kubectl get po -A
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx1-585f98d7bf-45fnk 1/1 Running 0 3h58m
kube-system calico-kube-controllers-5d49fc6c56-pq57d 1/1 Running 3 (<invalid> ago) 7h45m
kube-system calico-node-rjdqh 1/1 Running 0 7h45m
kube-system calico-node-s8475 1/1 Running 0 7h45m
kube-system coredns-7f74c56694-qpvmv 1/1 Running 0 7h48m
kube-system coredns-7f74c56694-ww8kb 1/1 Running 0 7h48m
kube-system etcd-kk-master 1/1 Running 0 7h48m
kube-system kube-apiserver-kk-master 1/1 Running 2 (2m1s ago) 7h24m
kube-system kube-controller-manager-kk-master 1/1 Running 0 7h24m
kube-system kube-proxy-5pf65 1/1 Running 0 7h24m
kube-system kube-proxy-mcxlq 1/1 Running 0 7h23m
kube-system kube-scheduler-kk-master 1/1 Running 0 7h24m备份集群清单
在Kubernetes的实际使用中，需要备份的集群清单主要有以下几种：
- Deployment类
- StatfulSet类
- DaemonSet类
- Service类
- ConfigMap类
- Secret类
- CronJob类
- ......
备份整个清单可以用于快速恢复集群。而且由于备份etcd是备份的某一时刻的完整数据，无法选择备份哪些内容，并且其备份的数据除了etcd本身，其他程序不可读。
备份集群的方式有很多 ，简单点的可以按照“备份集群”的步骤使用脚本进行备份，由于上面已经介绍了这种方法，这章节将采用另外的工具——velero进行备份。
velero 是开源方案，项目地址：https://velero.io/
velero的作用：
- 灾备能力：提供备份恢复k8s集群的能力
- 迁移能力：提供拷贝集群资源到其他集群的能力
和 etcd 备份的区别： - etcd 的备份必须拥有 etcd 运维权限，有些用户无法操作 etcd，如多租户场景。
- etcd 更适合单集群内数据备份，不太适合集群迁移
- etcd 是当前状态备份，velero 可以做到只备份集群内的一部分资源
velero 会在你的 k8s 集群上运行一个 server pod，然后配合 velero 客户端进行操作，安装过程可以参考文档，操作是很简单的。
安装客户端
到https://github.com/vmware-tanzu/velero/releases下载对应的版本并安装
$ wget https://github.com/vmware-tanzu/velero/releases/download/v1.9.0/velero-v1.9.0-linux-amd64.tar.gz
$ tar xf velero-v1.9.0-linux-amd64.tar.gz
$ mv velero-v1.9.0-linux-amd64/velero /usr/local/bin/
$ velero version
Client:
Version: v1.9.0
Git commit: 6021f148c4d7721285e815a3e1af761262bff029
<error getting server version: namespaces "velero" not found>安装服务端
安装服务端的方式有两种：
- 使用velero客户端安装
- 使用helm chart安装
这里使用velero客户端进行安装。velero的后端可以选择很多对象存储，比如阿里云OSS，mino等。由于阿里云OSS需要单独购买，所以这里采用minio作为后端存储。
安装minio
（1）添加helm源
$ helm repo add minio https://helm.min.io/（2）部署minio。由于这里只是做测试，所以没有做数据持久化等处理。
$ helm install minio \
--namespace velero --create-namespace \
--set accessKey=minio,secretKey=minio123 \
--set mode=standalone \
--set service.type=NodePort \
--set persistence.enabled=false \
minio/minio（2）使用UI访问查看
$ kubectl get svc -n velero
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
minio NodePort 10.110.75.97 <none> 9000:32000/TCP 92s
登录用户名密码为：minio:minio123
安装velero服务端
（1）在minio上创建buckrt
（2）在velero安装目录中创建credentials-velero，写入以下内容
[default]
aws_access_key_id=minio
aws_secret_access_key=minio123（3）安装velero
$ velero install \
--provider aws \
--bucket velero \
--image velero/velero:v1.6.3 \
--plugins velero/velero-plugin-for-aws:v1.2.1 \
--namespace velero \
--secret-file ./credentials-velero \
--use-volume-snapshots=false \
--use-restic \
--backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio.velero.svc:9000（4）检查所有组件是否正常启动
$ kubectl get po -n velero
NAME READY STATUS RESTARTS AGE
minio-6c9f559d5b-cpc2d 1/1 Running 0 3m3s
restic-pq5bm 1/1 Running 0 3m28s
velero-887577984-2tmm4 1/1 Running 0 3m28s执行备份操作
（1）在default的namespace下创建一个nginx Pod
$ kubectl create deployment nginx --image nginx（2）执行备份操作，备份default下面的资源
$ velero backup create default-backup-20220705 --include-namespaces default --default-volumes-to-restic（3）在minio上可以查看到备份的目录已经存在
（4）现在删除default命名空间下的nginx Pod
$ kubectl delete deployment nginx（5）执行恢复操作
$ velero restore create --from-backup default-backup-20220705（6）可以看到default命名空间下的nginx Pod已经恢复
$ kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-8f458dc5b-z6fnh 1/1 Running 0 38s总结
Kubernetes是应用的底座，如果底座出问题了，就谈不上应用的稳定性。在实际的工作中，对基础平台的备份尤为重要，可以在遇到不可描述的事情时有兜底的方案，所以，建议对Kubernetes做好备份操作，最好是定时备份。
最后
上面就是常用的集群相关操作，熟练的掌握它们，并应用于实际，可以为你节约不少的时间成本。
当然除了这些常规操作，还有迁移集群、导入集群等，我认为其本质上还是备份还原的问题，只是会多考虑一点数据完整性和业务连续性，这跟具体的企业情况相关，所以在这里也不在赘述。
分类
标签
已于2022-9-6 11:56:56修改
赞
收藏
回复
相关推荐
