1. etcdの概要
etcd は、2013 年 6 月に CoreOS チームによって開始されたオープンソース プロジェクトです。その目標は、可用性の高い分散キー/値データベースを構築することです。
- etcd は内部的にコンセンサス アルゴリズムとして raft プロトコルを採用しており、etcd は Go 言語に基づいて実装されています。
- 完全レプリケーション: クラスター内のすべてのノードが完全なアーカイブを使用できます。
- 高可用性: etcd を使用すると、ハードウェアの単一障害点やネットワークの問題を回避できます。
- 一貫性: すべての読み取りで、複数のマスターにわたる最新の書き込みが返されます。
- シンプル: 明確に定義されたユーザー向け API (gRPC) が含まれています
- セキュリティ : オプションのクライアント証明書認証による自動 TLS の実装
- 高速: 1 秒あたり 10,000 回の書き込みのベンチマーク速度
- 信頼性: Raft アルゴリズムを使用して、一貫性が高く、可用性の高いサービス ストレージ ディレクトリを実現します。
ETCD クラスターの運用と保守に関する基本的な知識:
- 読み取りおよび書き込みポート: 2379 、データ同期ポート: 2380
- ETCD クラスターは、Raft プロトコルを使用してクラスター内の各ノードの状態の一貫性を維持する分散システムです。
- ホストステータス リーダー、フォロワー、候補者
- クラスターが初期化されると、各ノードはフォロワーの役割となり、ハートビートを通じて他のノードとデータを同期します。
- フォロワー経由でデータを読み取り、リーダー経由でデータを書き込みます
- フォロワーが一定期間内にマスター ノードからハートビートを受信しない場合、フォロワーはその役割を候補者に変更し、マスター選挙の投票を開始します。
- etcd クラスターを構成するには、偶数のノードではなく、できるだけ奇数のノードを使用することをお勧めします (クラスターを構成するノードの数は 3、5、または 7 個が推奨されます)。
- etcd の組み込みバックアップ/復元ツールを使用して、ソース デプロイメントからデータをバックアップし、新しいデプロイメントでデータを復元します。リカバリの前にデータ ディレクトリをクリーンアップする必要があります
- データ ディレクトリにスナップします。スナップショット データ、WAL ファイルが多すぎるのを防ぐために etcd によって設定されたスナップショット、および etcd データ ステータスを保存します。
- データ ディレクトリ wal の下: 事前に書き込まれたログを保存します。最大の機能は、データ全体の変更履歴全体を記録することです。etcd では、すべてのデータ変更は送信前に WAL に書き込まれる必要があります。
- etcd クラスターにはおそらく 7 ノードを超えるべきではなく、書き込みパフォーマンスが低下するため、5 つのノードを実行することをお勧めします。5 メンバーの etcd クラスターは 2 つのメンバーの障害を許容でき、3 つのメンバーは 1 つの障害を許容できます。
共通の構成パラメータ:
- ETCD_NAME ノード名、デフォルトはデフォルトです
- ETCD_DATA_DIR サービス実行データが保存されるパス
- ETCD_LISTEN_PEER_URLS 監視するピア通信のアドレス(http://ip:2380 など)。複数ある場合はカンマを使用して区切ります。すべてのノードにアクセスできる必要があるため、localhost は使用しないでください
- ETCD_LISTEN_CLIENT_URLS 監視するクライアント サービス アドレス
- ETCD_ADVERTISE_CLIENT_URLS 外部に発表されたノードのクライアントのリスナー アドレス。この値はクラスター内の他のノードに通知します。
- ETCD_INITIAL_ADVERTISE_PEER_URLS 外部に発表されたノードのピアのリスナー アドレス。この値はクラスター内の他のノードに通知します。
- ETCD_INITIAL_CLUSTER クラスター内のすべてのノードの情報
- ETCD_INITIAL_CLUSTER_STATE 新しいクラスターを作成する場合、この値は新しい値になります。既存のクラスターに参加する場合、この値は既存の値になります
- ETCD_INITIAL_CLUSTER_TOKEN クラスターの ID 複数のクラスターがある場合、各クラスターの ID は一意である必要があります
2. etcdctl ツールをインストールする
【公式サイト】https://github.com/etcd-io/etcd/releases
#查看版本号
cat /etc/kubernetes/manifests/etcd.yaml |grep image
#输入版本号:v3.5.4
$ install_etcdctl.sh
#!/bin/bash
read -p "输入·etcd的版本号": VERSION
ETCD_VER=$VERSION
ETCD_DIR=etcd-download
DOWNLOAD_URL=https://ghproxy.com/github.com/coreos/etcd/releases/download
# 下载
cd /usr/local
mkdir ${ETCD_DIR}
cd ${ETCD_DIR}
rm -rf *
wget ${DOWNLOAD_URL}/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz
tar -xzvf etcd-${ETCD_VER}-linux-amd64.tar.gz
# 安装etcdctl
cd etcd-${ETCD_VER}-linux-amd64
#重命名,便于识别
cp etcdctl /usr/local/bin/
#删除安装数据目录
cd /usr/local&& rm -rf ${ETCD_DIR}
#添加环境变量
echo "ETCDCTL_API=3" >>/etc/profile
#查看版本
etcdctl version
chmod o+x install_etcdctl.sh
sh install_etcdctl.sh
输入:v3.5.4
3、kubeadm デプロイメントモードのデプロイメント
基本的な理解:
- K8s は etcd データベースを使用してクラスターにデータをリアルタイムで保存します。安全のため、データベースをバックアップする必要があります。
- バックアップは 1 つのノードでのみバックアップする必要があり (バックアップ ノードの損傷を避けるために、2 つのノードをバックアップすることをお勧めします)、各ノードのデータは同期されますが、データのリカバリは各ノードで実行する必要があります。 。
- ectd コンテナはホスト マシンとネットワーク共有されており、hostNetwork メソッドを使用すると、2379 データ ポートをホスト マシンで表示できます ( ss -ntlp|grep 2379)。
[root@k8s-master-01 etcd_backup]# ss -ntlp|grep 2379
LISTEN 0 128 192.168.4.114:2379 *:* users:(("etcd",pid=1841,fd=9))
LISTEN 0 128 127.0.0.1:2379 *:* users:(("etcd",pid=1841,fd=8))
- kubeadm によってデプロイされたクラスターでは、etcd が静的ポッドによってデプロイされ、起動されます。その yaml ファイルは /etc/kubernetes/manifests ディレクトリにあり、起動イメージ、バージョン、証明書パス、データ ディレクトリなどが記録されます。
[root@k8s-master-01 ~]# cat /etc/kubernetes/manifests/etcd.yaml |grep -A 10 volumes:
volumes:
- hostPath:
path: /etc/kubernetes/pki/etcd
type: DirectoryOrCreate
name: etcd-certs
- hostPath:
path: /data/k8s/etcd
type: DirectoryOrCreate
name: etcd-data
status: {}
etcd データ ディレクトリが置き換えられるかどうかに注意してください。デフォルトは /var/lib/etcd/ で、etcd データ ディレクトリは /data/k8s/etcd です。置き換えないと、クラスターは回復できません。
1) バックアップ
- バックアップ マシンの障害だけを避けるために、2 つのノードをバックアップすることが最善です
#创建命名空间
kubectl create ns test
#部署
cat > nginx-deployment.yaml<<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: test
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
namespace: test
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: NodePort
EOF
#部署
kubectl apply -f nginx-deployment.yaml
#创建备份目录
mkdir -p /data/etcd_backup
cd /data/etcd_backup
#备份
ETCDCTL_API=3 etcdctl \
snapshot save snap.db_$(date +%F) \
--endpoints=https://192.168.4.114:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
#检查
[root@k8s-master-01 etcd_backup]# ETCDCTL_API=3 etcdctl --write-out=table snapshot status /opt/etcd_backup/snap.db_2023-08-24
Deprecated: Use `etcdutl snapshot status` instead.
+----------+----------+------------+------------+
| HASH | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| 4c5447a8 | 2333766 | 1308 | 6.9 MB |
+----------+----------+------------+------------+
#集群节点状态
[root@k8s-master-01 etcd_backup]# ETCDCTL_API=3 etcdctl --endpoints https://127.0.0.1:2379 --cert="/etc/kubernetes/pki/etcd/server.crt" --key="/etc/kubernetes/pki/etcd/server.key" --cacert="/etc/kubernetes/pki/etcd/ca.crt" member list -w table
+------------------+---------+---------------+----------------------------+----------------------------+------------+
| ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER |
+------------------+---------+---------------+----------------------------+----------------------------+------------+
| c3509e57d5f53562 | started | k8s-master-01 | https://192.168.4.114:2380 | https://192.168.4.114:2379 | false |
+------------------+---------+---------------+----------------------------+----------------------------+------------+
#任意节点查看 etcd 集群信息
[root@k8s-master-01 etcd_backup]# ETCDCTL_API=3 etcdctl --endpoints https://127.0.0.1:2379 --cert="/etc/kubernetes/pki/etcd/server.crt" --key="/etc/kubernetes/pki/etcd/server.key" --cacert="/etc/kubernetes/pki/etcd/ca.crt" endpoint status --cluster -w table
+----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| https://192.168.4.114:2379 | c3509e57d5f53562 | 3.5.4 | 6.9 MB | true | false | 10 | 2649811 | 2649811 | |
+----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
- デプロイ前のnginxがあるので、nginxを削除し、etcdを復元してnginxの存在を確認します。
[root@k8s-master-01 etcd_backup]# kubectl get pods -n test
NAME READY STATUS RESTARTS AGE
nginx-deployment-ff6774dc6-7mm2j 1/1 Running 0 11s
nginx-deployment-ff6774dc6-hdvbf 1/1 Running 0 11s
nginx-deployment-ff6774dc6-zcf8m 1/1 Running 0 11s
[root@k8s-master-01 ~]#kubectl delete -f nginx-deployment.yaml
[root@k8s-master-01 etcd_backup]# kubectl get pods -n test
2) 回復
クビーズ
- kubeadm でデプロイされたクラスター内の etcd は静的コンテナとして動作し、静的コンテナの設定ファイル格納ディレクトリは /etc/kubernetes/manifests/ になります。
- コアプロセスは次のとおりです: API サーバーと etcd サービスを停止 -> 復元を実行 -> API サーバーと etcd サービスを再起動
#先停止api server和etcd服务。因为是静态Pod部署,监控这个目录下的yaml文件,当把目录备份后就直接相当于停服
mkdir -p /tmp/etcd/manifests/
mv /etc/kubernetes/manifests/{kube-apiserver.yaml,etcd.yaml} /tmp/etcd/manifests/
mv /data/k8s/etcd /data/k8s/etcd.`date +%Y%m%d`
#查看api-server是否停止
[root@k8s-master-01 ~]# kubectl get pod
The connection to the server 192.168.4.114:6443 was refused - did you specify the right host or port?
#使用snap.db文件恢复数据到/var/lib/etcd目录。
ETCDCTL_API=3 etcdctl snapshot restore snap.db_2023-08-24 --endpoints=https://192.168.4.114:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --data-dir=/data/k8s/etcd
#启动kube-apiserver和etcd容器
mv /tmp/etcd/manifests/{kube-apiserver.yaml,etcd.yaml} /etc/kubernetes/manifests/
#查看结果,数据恢复
[root@k8s-master-01 etcd_backup]# kubectl get pods -n test
NAME READY STATUS RESTARTS AGE
nginx-deployment-ff6774dc6-ch9p2 1/1 Running 0 2m3s
nginx-deployment-ff6774dc6-cklzj 1/1 Running 0 2m3s
nginx-deployment-ff6774dc6-fb6wb 1/1 Running 0 2m3s
#检查集群是否正常
[root@k8s-master-01 etcd_backup]# kubectl get cs
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health":"true","reason":""}
4. タイミングバックアップ
- バックアップ マシンの障害だけを避けるために、2 つのノードをバックアップすることが最善です
#创建etcd脚本存放目录
mkdir -p /opt/etcd_backup
#创建etcd数据备份目录
mkdir -p /data/etcd_backup
#创建定时备份脚本
[root@master etcd]# cat /opt/etcd_backup/etcd_backup.sh
#!/bin/bash
CACERT="/etc/kubernetes/pki/etcd/ca.crt "
CERT="/etc/kubernetes/pki/etcd/server.crt"
EKY="/etc/kubernetes/pki/etcd/server.key"
ENDPOINTS="192.168.4.114:2379"
ETCDCTL_API=3 etcdctl \
--cacert="${CACERT}" \
--cert="${CERT}" \
--key="${EKY}" \
--endpoints=${ENDPOINTS} \
snapshot save /data/etcd_backup/etcd-snapshot-`date +%Y-%m-%d_%H:%M:%S`.db
# 备份保留30天
find /data/etcd_backup/ -name *.db -mtime +30 -exec rm -f {} \;
#设置定时任务
crontab -e
#每天凌晨2点执行
0 2 * * * sh /opt/etcd_backup/etcd_backup.sh
#停止apisever和etcd
mkdir -p /tmp/etcd/manifests/
mv /etc/kubernetes/manifests/{kube-apiserver.yaml,etcd.yaml} /tmp/etcd/manifests/
mv /data/k8s/etcd /data/k8s/etcd.`date +%Y-%m-%d_%H:%M:%S`
#恢复命令
ETCDCTL_API=3 etcdctl snapshot restore /data/etcd_backup/etcd-snapshot-20230825.db \
--endpoints=https://192.168.4.114:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
--data-dir=/data/k8s/etcd
#启动kube-apiserver和etcd容器
mv /tmp/etcd/manifests/{kube-apiserver.yaml,etcd.yaml} /etc/kubernetes/manifests/
#查看集群
kubectl get cs
5、バイナリ展開バックアップ
ノード | IP |
---|---|
etdc_1 | 192.168.4.114 |
etdc_2 | 192.168.4.115 |
etdc_3 | 192.168.4.116 |
1) バックアップ
- バックアップ マシンの障害だけを避けるために、2 つのノードをバックアップすることが最善です
ETCDCTL_API=3 etcdctl \
snapshot save snap.db \
--endpoints=https://192.168.4.114:2379 \ #备份节点IP
--cacert=/opt/etcd/ssl/ca.pem \
--cert=/opt/etcd/ssl/server.pem \
--key=/opt/etcd/ssl/server-key.pem
2) 回復
- etcd クラスターはサービスの形式で複数のサーバー上で実行されます。コンテナー方式との唯一の違いはサービスのエンドポイントです。バックアップは kubeadm と同じです。
- 回復シーケンス: kube-apiserver の停止 –> ETCD の停止 –> データの復元 –> ETCD の開始 –> kube-apiserve の開始
1. apiserver と etcd を停止します。
#每个etcd节点需要先手动停止kube-apiserver和etcd服务
systmectl stop kube-apiserver
systemctl stop etcd
mv /var/lib/etcd/default.etcd /var/lib/etcd/default.etcd.`date +%Y-%m-%d_%H:%M:%S`
2. etcd_1 の回復
- リカバリは各 etcd ノードで実行する必要があります。
# 每个etcd依次恢复,需要修改 name, initialadvertise-peer-urls等参数
ETCDCTL_API=3 etcdctl snapshot restore snap.db \
--name etcd_1 \ # 每台节点name不一样,根据当前节点etcd配置文件即可
--initial-cluster="etcd-1=https:/192.168.4.114:2380,etcd-1=https://192.168.4.115:2380,etcd-1=https:/192.168.4.116:2380" \ #描述集群节点信息
--initial-cluster-token=etcd-cluster \
--initialadvertise-peer-urls=https://192.168.4.114:2380 \ # 修改为当前节点ip
--data-dir=/vaf/lib/default.etcd #注意数据目录
3. etcd_2 の回復
ETCDCTL_API=3 etcdctl snapshot restore snap.db \
--name etcd_2 \
--initial-cluster="etcd-1=https:/192.168.4.114:2380,etcd-1=https://192.168.4.115:2380,etcd-1=https:/192.168.4.116:2380" \
--initial-cluster-token=etcd-cluster \
--initialadvertise-peer-urls=https://192.168.4.115:2380 \
--data-dir=/vaf/lib/default.etcd
4.etcd_3のリカバリ
ETCDCTL_API=3 etcdctl snapshot restore snap.db \
--name etcd_3 \
--initial-cluster="etcd-1=https:/192.168.4.114:2380,etcd-1=https://192.168.4.115:2380,etcd-1=https:/192.168.4.116:2380" \
--initial-cluster-token=etcd-cluster \
--initialadvertise-peer-urls=https://192.168.4.116:2380 \
--data-dir=/vaf/lib/default.etcd
5. etcdとapiserverを起動します。
#启动 kube-apiserver和etcd 服务
systemctl start kube-apiserver
systemctl start etcd
6. クラスターを確認する
#查看集群状态
ETCDCTL_API=3 /opt/etcd/bin/etcdctl \
--cacert=/opt/etcd/ssl/etcd-ca.pem \
--cert=/opt/etcd/ssl/server.pem \
--key=/opt/etcd/ssl/server-key.pem \
--endpoints="https://192.168.4.114:2379,https://192.168.4.115:2379,https://192.168.4.116:2379" endpoint health \
--write-out=table
#查看集群
[root@k8s-master-01 k8s]# kubectl get cs
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok
scheduler Healthy ok
etcd-0 Healthy {"health":"true","reason":""}
ヒント:
- バックアップが復元されると、apiserver サービスと etcd サービスが再起動されるため、クラスターは一時的に使用できなくなります。
- etcdctl はスナップショット バックアップであり、最後に書き込まれたデータは記録されないため、バックアップから復元すると最新のデータが失われる可能性があります。
- etcd は、PV データボリュームに格納されているビジネスデータをバックアップできません。
- etcd はグローバル バックアップであるため、特定の名前空間に対してバックアップおよび復元することはできません。
6. veleroをインストールする
Velero アドレス: https://github.com/vmware-tanzu/velero
ACK プラグインのアドレス: https://github.com/AliyunContainerService/velero-plugin
1) ヴェレロの紹介
Velero はバックアップにオブジェクト ストレージ システムを使用するため、Velero をインストールする前に、Ceph や Minio などのオブジェクト ストレージ システムをインストールする必要があります。Minio のインストールは比較的簡単で、Velero のバックアップ ストレージ システムとして Minio を使用することも推奨されます。
velero を使用すると、ユーザーは Kubernetes クラスター リソースと永続ボリュームを安全にバックアップ、復元、移行できます。その基本原理は、クラスター リソースや永続データ ボリュームなどのクラスター データをオブジェクト ストレージにバックアップし、リカバリ中にオブジェクト ストレージからデータをプルすることです。災害復旧に加えて、リソースの移行を実行し、あるクラスターから別のクラスターへのコンテナー アプリケーションの移行をサポートすることもでき、これも velero の非常に成功した使用シナリオです。
Velero には主に、サーバーとクライアントという 2 つのコア コンポーネントが含まれています。サーバーは特定の Kubernetes クラスターで実行され、クライアントはローカルで実行されるコマンドライン ツールであり、kubectl と kubeconfig が構成されている限り使用でき、非常に簡単です。
Velero は、その Kubernetes リソース バックアップ機能に基づいて、Kubernetes クラスターのデータ バックアップとリカバリを簡単に実現したり、Kubernetes クラスター リソースを他の Kubernetes クラスターにコピーしたり、運用環境をテスト環境やその他の機能に迅速にコピーしたりできます。
リソースのバックアップに関しては、velero は、AWS S3 または S3 互換ストレージ システム、Azure Blob、Google Cloud ストレージ、Aliyun OSS など、多数のクラウド ストレージへのデータ バックアップをサポートしています。Kubernetes全体をバックアップするデータストレージエンジンであるetcdに比べて、veleroの制御はより細かく、kubernetesクラスタ内のオブジェクトレベルでのバックアップが可能で、タイプ、名前空間、ラベルなどのオブジェクトを分類ごとにバックアップまたはリストアすることも可能です。 。
2) ワークフロー
コア データのバックアップを例として、velero バックアップを実行するときに my-backup を作成します。
- Velero クライアントは、まず Kubernetes API サーバーを呼び出してバックアップ オブジェクトを作成します。
- BackupController は、新しい Backup オブジェクトが作成されたことが通知され、検証が実行されます。
- BackupController はバックアップ プロセスを開始し、API サーバーにリソースを問い合わせることによってバックアップ用のデータを収集します。
- BackupController は、AWS S3 などのオブジェクト ストレージ サービスを呼び出して、バックアップ ファイルをアップロードします。デフォルトでは、velero Backup create は任意の永続ボリュームのディスク スナップショットをサポートします。追加のフラグを指定することでスナップショットを調整できます。利用可能なフラグを確認するには、velero Backup create --help を実行します。また、--snapshot-volumes=false オプションを使用してスナップショットを無効にすることもできます。
バックアップ ストレージの場所とボリューム スナップショットに関して、Velero には BackupStorageLocation と VolumeSnapshotLocation という 2 つのカスタム リソースがあり、Velero バックアップとそれに関連する永続ボリューム スナップショットの保存場所を構成するために使用されます。
BackupStorageLocation によってサポートされるプライマリ バックエンド ストレージは、S3 互換ストレージ、すべての Velero データが保存されるバケット内のプレフィックス、およびその他のプロバイダー固有のフィールドのセットです。例: Minio や Alibaba Cloud OSS など。
VolumeSnapshotLocation (pv データ) は主に PV のスナップショットを取得するために使用され、クラウド プロバイダーがプラグインを提供する必要があり、プロバイダーが提供する特定のフィールド (AWS リージョン、Azure リソース グループ、Portworx スナップショット タイプなど) によって完全に定義されます。 )。データの一貫性が最も重視されるデータベースとミドルウェアを例に挙げると、オープンソースのストレージ プラグイン Carina は、ミドルウェア データの高速バックアップとリカバリを実現できる、データベース対応の velero ボリューム スナップショット機能を間もなく提供する予定です。
3) 全体のプロセス
Kubernetes Velero を実装するための全体的な手順は次のとおりです。
ステップ | 説明する |
---|
- Velero をインストールする | Kubernetes クラスターに Velero をインストールする
- Velero バックエンド ストレージの作成 | Velero が使用するクラウド ストレージまたはローカル ストレージを構成する
- Velero 証明書と認証を作成する | TLS 証明書とキーを生成し、Kubernetes シークレットを作成する
- Velero を構成する | Velero の構成ファイルを作成する
- Velero バケットの作成と構成 | Velero バックエンド ストレージでのバケットの作成
- Velero プラグインの構成 | Velero プラグインのインストールと構成
- Velero スケジュールの作成 | バックアップ スケジュールを作成するように Velero を構成する
4) NFS 永続ボリューム
[root@k8s-master ~]# vim nfs.sh
#!/bin/bash
IPADDR=$(ip a|grep brd|grep ens160|awk '{print $2}'|grep -o -E "[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}")
read -p "请输入本机IP:" -t 30 HOST_IP
yum install -y nfs-utils
mkdir -p /data/nfs
chmod -R 777 /data/nfs
#增加配置文件
echo "/data/nfs s $IPADDR/24(rw,sync,no_subtree_check,no_root_squash)" >>/etc/exports
#查看配置文件
cat /etc/exports
#授权(chown 修改文件和文件夹的用户和用户组属性)
chown nfsnobody:nfsnobody /data/nfs
#启动和增加开启自启动
systemctl restart nfs-server.service
systemctl enable nfs-server.service
systemctl status nfs-server.service
#创建数据目录
mkdir -p /opt/nfs-storageclass
cd /opt/nfs-storageclass
cat >nfs-client-provisioner.yaml<<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
labels:
app: nfs-client-provisioner
namespace: kube-system
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app: nfs-client-provisioner
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs-client-provisioner
image: gcr.io/k8s-staging-sig-storage/nfs-subdir-external-provisioner:v4.0.1
imagePullPolicy: IfNotPresent
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: nfs # 存储分配器的默认名称 ,根据自己的名称来修改,与 storageclass.yaml 中的 provisioner 名字一致
- name: NFS_SERVER
value: $HOST_IP # NFS服务器所在的 ip
- name: NFS_PATH
value: /data/nfs # 共享存储目录
volumes:
- name: nfs-client-root
nfs:
server: $HOST_IP # NFS服务器所在的 ip
path: /data/nfs # 共享存储目录
EOF
sed -i 's#gcr.io/k8s-staging-sig-storage/nfs-subdir-external-provisioner:v4.0.1# dyrnq/nfs-subdir-external-provisioner:v4.0.1#g' nfs-client-provisioner.yaml
cat >rbac.yaml<<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: kube-system
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: nfs-client-provisioner-runner
rules:
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "delete"]
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "update"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: run-nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: kube-system
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-runner
apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: kube-system
rules:
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: kube-system
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: kube-system
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io
EOF
cat >storageclass.yaml<<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-nfs-storage
provisioner: nfs # 或者选择其他名称,必须匹配部署变量 PROVISIONER_NAME'
parameters:
archiveOnDelete: "false" #当设置为“false”时,在删除PVC时,您的pv将不会被配置程序存档。
EOF
kubectl apply -f /opt/nfs-storageclass/.
chmod o+x nfs.sh
sh nfs.sh
输入nfs的节点IP
kubectl get pods -n kube-system|grep fs-client-provisioner-
5) Velero をインストールする
【公式文書】
- https://velero.io/docs/v1.9/
- https://github.com/vmware-tanzu/velero/
【Velero版とk8s版の互換性】
- https://github.com/vmware-tanzu/velero
ヨットバージョン | Kubernetes バージョンでテスト済み |
---|---|
1.12 | 1.25.7、1.26.5、1.26.7、および1.27.3 |
1.11 | 1.23.10、1.24.9、1.25.5、および1.26.1 |
1.10 | 1.22.5、1.23.8、1.24.6、1.25.1 |
1.9 | 1.20.5、1.21.2、1.22.5、1.23、1.24 |
- Velero は IPv4、IPv6、およびデュアルスタック環境をサポートします
#查看k8s版本,选择Velero版本kubeadm version
[root@k8s-master1 ~]# kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.0", GitCommit:"a866cbe2e5bbaa01cfd5e969aa3e033f3282a8a2", GitTreeState:"clean", BuildDate:"2022-08-23T17:43:25Z", GoVersion:"go1.19", Compiler:"gc", Platform:"linux/amd64"}
cd /opt/
wget -c https://ghproxy.com/github.com/vmware-tanzu/velero/releases/download/v1.10.0/velero-v1.10.0-linux-amd64.tar.gz
tar -zxvf velero-v1.10.0-linux-amd64.tar.gz
cd velero-v1.10.0-linux-amd64
mv velero /usr/local/bin
chmod +x /usr/local/bin/velero
velero version
6) minioをインストールする
1. 正式な住所
【正式な住所】
- https://github.com/minio/mc
- https://min.io/docs/minio/linux/index.html?ref=docs-redirect
- https://zhuanlan.zhihu.com/p/557868296
【ミラー指定バージョン】
- https://github.com/minio/mc/tree/RELEASE.2023-08-18T21-57-55Z
2. yamlをデプロイする
ここでは、minio を使用してクラウド環境のオブジェクト ストレージを置き換えることができます。上記の解凍された圧縮パッケージには、examples/minio/00-minio-deployment.yaml のリソース リスト ファイルが含まれています。テストの便宜のために、サービスを次のように変更できます。 NodePort タイプ。コンソール ページのアクセス エントリを提供するように console-address を設定できます。完全なリソース リスト ファイルは次のとおりです。
#配置一个 console-address 来提供一个 console 页面的访问入口
args:
- server
- /storage
- --config-dir=/config
- --console-address=:9001 #添加
。。。。。。
ports:
- containerPort: 9000
- containerPort: 9001 #添加
#暴露端口
# type: ClusterIP
# ports:
# - port: 9000
# targetPort: 9000
# protocol: TCP
type: NodePort
ports:
- name: api
port: 9000
targetPort: 9000
- name: console
port: 9001
targetPort: 9001
nodePort: 30009
#修改minio部署yaml
cd /opt/velero-v1.10.0-linux-amd64/examples/minio
#查看
[root@k8s-master1 minio]# cat 00-minio-deployment.yaml
# Copyright 2017 the Velero contributors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
---
apiVersion: v1
kind: Namespace
metadata:
name: velero
---
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: velero
name: minio
labels:
component: minio
spec:
strategy:
type: Recreate
selector:
matchLabels:
component: minio
template:
metadata:
labels:
component: minio
spec:
volumes:
- name: storage
emptyDir: {}
- name: config
emptyDir: {}
containers:
- name: minio
image: minio/minio:edge
imagePullPolicy: IfNotPresent
args:
- server
- /storage
- --config-dir=/config
- --console-address=:9001
env:
- name: MINIO_ACCESS_KEY
value: "minio"
- name: MINIO_SECRET_KEY
value: "minio123"
ports:
- containerPort: 9000
- containerPort: 9001
volumeMounts:
- name: storage
mountPath: "/storage"
- name: config
mountPath: "/config"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: storage
namespace: velero
spec:
storageClassName: "managed-nfs-storage"
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Service
metadata:
namespace: velero
name: minio
labels:
component: minio
spec:
# ClusterIP is recommended for production environments.
# Change to NodePort if needed per documentation,
# but only if you run Minio in a test/trial environment, for example with Minikube.
type: NodePort
ports:
# - port: 9000
# targetPort: 9000
# protocol: TCP
- name: api
port: 9000
targetPort: 9000
- name: console
port: 9001
targetPort: 9001
nodePort: 30009
selector:
component: minio
---
apiVersion: batch/v1
kind: Job
metadata:
namespace: velero
name: minio-setup
labels:
component: minio
spec:
template:
metadata:
name: minio-setup
spec:
restartPolicy: OnFailure
volumes:
- name: config
emptyDir: {}
containers:
- name: mc
image: minio/mc:edge
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- "mc --config-dir=/config config host add velero http://minio:9000 minio minio123 && mc --config-dir=/config mb -p velero/velero"
volumeMounts:
- name: config
mountPath: "/config"
アクセス:http://192.168.4.115:30009/login
- ユーザー名: ミニオ
- パスワード: minio123
minio のデータと構成は、cephfs などを使用して永続化できます。
通常は、クラスターの外部にデプロイすることをお勧めします。
3. IDとキーの作成
バケットを作成することを選択できます。その後、対応するバケットへの通常のアップロードを許可するユーザーを作成する必要があります (ID とキーを覚えておいてください)。
- ユーザーを選択 - ユーザーの作成を選択します。
- アクセスキー:バックアップ
- 秘密キー: Abcd123456
- ポリシーの選択: 読み取り書き込み
4. バックアップバケットを作成する
- 「バケット」を選択して、velerodata という名前のバックアップ バケットを作成します。
- 「バケットの作成」を選択して作成します。残りはデフォルトです
5. テストアクセス
バックアップアカウントにアクセス: http://192.168.4.115:30009/login
- ユーザー名: minioadmin
- パスワード: minioadmin
7) velero サーバーをインストールする
上記で作成した読み取り書き込み権限を持つユーザーを使用して、minio 認証ファイルを作成します。
cd /opt/velero-v1.10.0-linux-amd64/
cat >velero-auth.txt << EOF
[default]
aws_access_key_id = minioadmin
aws_secret_access_key = minioadmin
EOF
velero --kubeconfig /root/.kube/config install \
--use-node-agent \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.7.0 \
--bucket velerodata --secret-file ./velero-auth.txt \
--use-volume-snapshots=false \
--namespace velero default-volumes-to-restic \
--backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio.velero.svc:9000
s3URL アドレスが k8s 内部解決アドレスを使用しない場合は、データ ポート 9000 (ノード IP+30008) の公開アドレスを使用します。
【パラメータの説明】
- –kubeconfig は、デフォルトで KUBECONFIG 環境変数によって作成された認証ファイルを検索します。
- –bucket minio ストレージ名を作成する
- --secret-file パスワード認証ファイル
- –namespace のデフォルトは velero 名前空間で、このパラメータを指定すると名前空間の作成が指定されます。
【重要なパラメータの説明】
インストールパラメータ | パラメータの説明 |
---|---|
–プロバイダー | aws が提供するプラグインタイプの使用を宣言します。 |
–プラグイン | AWS S3 互換 API プラグイン「velero-plugin-for-aws」を使用します。 |
-バケツ | COS で作成されたバケット名。 |
–秘密ファイル | COS にアクセスするためのアクセス資格情報ファイル。詳細については、上で作成した「credentials-velero」資格情報ファイルを参照してください。 |
–使用レストスティック | Velero は、無料のオープン ソース バックアップ ツール Restic を使用した、Kubernetes ストレージ ボリューム データのバックアップと復元をサポートしています (hostPath ボリュームはサポートされていません。詳細については、Restic の制限を参照してください)。この統合は、Velero のバックアップ機能を補足するものであり、有効にすることをお勧めします。それ。 |
–default-volumes-to-restic | --use-restic パラメータを有効にする必要がある場合は、Restic の使用を有効にしてすべての Pod ボリュームをバックアップします。 |
–バックアップの場所の構成 | リージョン、s3ForcePathStyle、s3Url などのバックアップ バケット アクセス関連の設定。 |
地域 | S3 API と互換性のあるオブジェクト ストレージ COS バケット リージョン。たとえば、作成リージョンは広州、リージョン パラメータ値は「ap-guangzhou」です。 |
s3フォースパススタイル | S3 ファイル パス形式を使用します。 |
s3URL | オブジェクト ストレージ COS 互換の S3 API アクセス アドレス。アクセス アドレスのドメイン名は、上記の COS ストレージ バケットを作成するためのパブリック ネットワーク アクセス ドメイン名ではなく、URL 形式は https://cos..myqcloud.com を使用する必要があることに注意してください。リージョンは広州、パラメータ値は https://cos.ap-guangzhou.myqcloud.com です。 |
- 他のインストール パラメータは、コマンド velero install --help で表示できます。たとえば、ストレージ ボリューム データをバックアップする代わりに、 --use-volume-snapshots=false を設定して、ストレージ ボリューム スナップショット バックアップをオフにすることができます。
#查看
[root@k8s-master1 velero-v1.10.0-linux-amd64]# kubectl get backupstoragelocation -A -oyaml
apiVersion: v1
items:
- apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
creationTimestamp: "2023-09-05T06:08:12Z"
generation: 15
labels:
component: velero
name: default
namespace: velero
resourceVersion: "1116179"
uid: 3eb2e6ef-f95e-4674-92c7-8b296f864d57
spec:
config:
region: minio
s3ForcePathStyle: "true"
s3Url: http://minio.velero.svc:9000
default: true
objectStorage:
bucket: velerodata
provider: aws
status:
lastSyncedTime: "2023-09-05T06:14:21Z"
lastValidationTime: "2023-09-05T06:14:21Z"
phase: Available
kind: List
metadata:
resourceVersion: ""
#删除
kubectl delete -n velero backupstoragelocations.velero.io default
kubectl delete deployments.apps -n velero velero
#卸载
velero uninstall
#查看安装状态
[root@k8s-master1 ~]# kubectl get pod -n velero
NAME READY STATUS RESTARTS AGE
minio-597fcfdb94-cksx2 1/1 Running 0 18m
minio-setup-76r5g 0/1 Completed 0 18m
node-agent-frqjq 1/1 Running 0 12m
node-agent-mtb96 1/1 Running 0 12m
node-agent-nlsg7 1/1 Running 0 12m
velero-5bb5bd6699-f8z9q 1/1 Running 0 12m
[root@k8s-master1 ~]# kubectl get crd | grep velero
backuprepositories.velero.io 2023-09-05T06:08:09Z
backups.velero.io 2023-09-05T06:08:09Z
backupstoragelocations.velero.io 2023-09-05T06:08:09Z
deletebackuprequests.velero.io 2023-09-05T06:08:09Z
downloadrequests.velero.io 2023-09-05T06:08:09Z
podvolumebackups.velero.io 2023-09-05T06:08:09Z
podvolumerestores.velero.io 2023-09-05T06:08:09Z
restores.velero.io 2023-09-05T06:08:10Z
schedules.velero.io 2023-09-05T06:08:10Z
serverstatusrequests.velero.io 2023-09-05T06:08:10Z
volumesnapshotlocations.velero.io 2023-09-05T06:08:10Z
#查看安装状态
[root@k8s-master1 ~]# kubectl get backupstoragelocations -A
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT
velero default Available 45s 13m true
[ヘルムを通して取り付けられたヴェロ]
- http://www.1024sky.cn/blog/article/77733
7. テスト アプリケーションをデプロイする
1) テストサービスをデプロイする
2 つのテスト アプリケーションを展開してバックアップとリカバリの結果をテストし、minio を使用してバックアップ データを保存します
- mysql 5.7
cd /opt/velero-v1.10.0-linux-amd64/
cat >mysql5.7.yaml<<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
spec:
storageClassName: managed-nfs-storage
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
apiVersion: apps/v1 #版本
kind: Deployment #创建资源的类型
metadata: #资源的元数据
name: mysql-dep #资源的名称,是元数据必填项
spec: #期望状态
replicas: 1 #创建的副本数量(pod数量),不填默认为1
selector: #
matchLabels:
app: mysql-pod
template: #定义pod的模板
metadata: #pod的元数据
labels: #labels标签,必填一个
app: mysql-pod
spec: #pod的期望状态
containers: #容器
- name: mysql #容器名称
image: mysql:5.7 #镜像
imagePullPolicy: IfNotPresent
ports: #容器的端口
- containerPort: 3306
env:
- name: MYSQL_ROOT_PASSWORD
value: "root"
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
---
apiVersion: v1 #版本
kind: Service #创建资源的类型
metadata: #资源的元数据
name: mysql-svc #资源的名称,是元数据必填项
labels: #labels标签
app: mysql-svc
spec: #期望状态
type: NodePort #服务类型
ports: #端口
- port: 3306
targetPort: 3306 #与containerPort一样
protocol: TCP
nodePort: 30306
selector:
app: mysql-pod
EOF
- nginxデプロイメントファイル
cat >nginx.yaml<<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: managed-nfs-storage
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
volumes:
- name: data-volume
persistentVolumeClaim:
claimName: my-pvc
containers:
- name: nginx
image: nginx
volumeMounts:
- name: data-volume
mountPath: /var/www/html
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
selector:
app: nginx
EOF
#创建
kubectl apply -f mysql5.7.yaml
kubectl apply -f nginx.yaml
2) テスト内容を書く
kubectl exec -it -n default mysql-dep-58cb9d765f-4sd58 /bin/bash
mysql -uroot -proot
-- 创建测试数据库
CREATE DATABASE testdb;
-- 使用测试数据库
USE testdb;
-- 创建测试表
CREATE TABLE test_table (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(50),
age INT,
email VARCHAR(100)
);
-- 插入测试数据
INSERT INTO test_table (name, age, email) VALUES
('John Doe', 25, '[email protected]'),
('Jane Smith', 30, '[email protected]'),
('Mike Johnson', 35, '[email protected]');
select * from test_table;
+----+--------------+------+--------------------------+
| id | name | age | email |
+----+--------------+------+--------------------------+
| 1 | John Doe | 25 | [email protected] |
| 2 | Jane Smith | 30 | [email protected] |
| 3 | Mike Johnson | 35 | [email protected] |
+----+--------------+------+--------------------------+
#退出MySQL和容器
mysql> exit
Bye
bash-4.2# exit
exit
8、テストバックアップ
1) バックアップの概要
1. バックアップの分類
velero にはステートフル データをバックアップする 2 つの方法があります。比較は次のとおりです。
寸法を考慮する | CSI スナップショットに基づく | ファイルコピー |
---|---|---|
アプリケーションのパフォーマンスへの影響 | Low、CSI インターフェイスはストレージ システムのスナップショットを呼び出します | データ量に応じて、追加のリソースが必要になります |
データの可用性 | ストレージ システムによっては、スナップショットをサポートする CSI を使用する必要があります | オブジェクトストレージと本番環境の分離、独立した可用性、クロスサイト可用性のサポート |
データの一貫性 | クラッシュの一貫性をサポートし、フックメカニズムと連携して一貫性を実現します。 | フックに基づく保証なし |
⋓ファイルのコピーは暗号化、圧縮され、増分バックアップされます。圧縮率は約60%です。バックアップファイルはすべて暗号化されたバイナリファイルであり、文字化けします。
2 つのファイル コピー プラグイン:
- Restic (デフォルト) https://restic.readthedocs.io/en/latest/100_references.html#terminology
- https://kopia.io/docs/advanced/architecture をコピーします
2. バックアップのベストプラクティス
- ストレージがスナップショット、高頻度のローカル スナップショット + s3 への低頻度の静的バックアップをサポートしている場合
- アプリケーションの観点から適切なバックアップ粒度とバックアップ戦略を選択します。
- マルチクラスタ環境で同じオブジェクト ストアを共有する場合の競合を防止する
3. 同期機構
- velero バックアップはこのバックアップ タスクのメタ情報を s3 にアップロードするため、クラスター内でバックアップ タスクが削除されても s3 内のデータが削除された場合、velero は定期的に s3 のバックアップ タスクをクラスターに同期します。
4.ピット
- 長期間完了していないバックアップまたはリカバリタスクを削除すると、velero がブロックされ、後続のタスクを処理できなくなります。
- ファイル コピー バックアップ方法を使用する場合、Es や Ck などの急速に変化するバックアップ ファイル システムを使用するアプリケーションは、ほぼ確実にバックアップに失敗します。
2) バックアップ
- バックアップは、完全バックアップ、指定された名前空間バックアップ、指定されたセレクター バックアップなどをサポートします。詳細については、velero Backup create -h を使用してヘルプを表示できます。
#创建单次的备份任务,备份数据库与nginx
velero backup create test3 --include-namespaces=default --default-volumes-to-fs-backup
共通パラメータ:
- --include-namespaces: バックアップする名前空間を複数のカンマで区切って指定します。
- –include-resources: configmap、secret など、バックアップするリソースの種類を複数のカンマで区切って指定します。
- --include-cluster-resources: true に設定すると、バックアップに複数のカンマで区切られたクラスターレベルのリソースが含まれることを示します。
- –exclude-namespaces: 複数のカンマで区切って、指定した名前空間を除外します。
- exclude-resources: 指定されたリソースタイプを除外します
- velero バックアップ ビューのバックアップを取得
- velerobackupdescribe --details バックアップデータリストの表示
3) タイミングバックアップ
#这里我们为了测试将备份周期调整成了每分钟一次
[root@master1 yaml]# velero schedule create schedule-backup --schedule="* * * * *" --include-namespaces=default --default-volumes-to-fs-backup Schedule "schedule-backup" created successfully.
[root@master1 yaml]# kubectl get schedule -A
NAMESPACE NAME STATUS SCHEDULE LASTBACKUP AGE PAUSED
velero schedule-backup Enabled * * * * * 15s
8. 回復
- まず、mysql と nginx を削除します。データ損失をシミュレートするために、ここでは nginx と mysql を手動で削除しました。
#删除
cd /opt/velero-v1.10.0-linux-amd64/
kubectl delete -f mysql5.7.yaml
kubectl delete -f nginx.yaml
#查看
kubectl get pod -n default
kubectl get all -n default
- 回復の開始、回復戦略の作成、以前にバックアップしたバックアップ タスクからの復元
#查看备份
[root@k8s-master1 ~]# kubectl get backup -A
NAMESPACE NAME AGE
velero test3 5m47s
#恢复
[root@k8s-master1 ~]# velero restore create --from-backup test3
Restore request "test3-20230905145431" submitted successfully.
Run `velero restore describe test3-20230905145431` or `velero restore logs test3-20230905145431` for more details.
#查看恢复记录
[root@k8s-master1 ~]# kubectl get restore -A
NAMESPACE NAME AGE
velero test3-20230905145431 26s
#查看恢复的数据
[root@k8s-master1 ~]# kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
mysql-dep-58cb9d765f-4sd58 0/1 PodInitializing 0 64s
nginx-deployment-7bb559659f-w6tpw 1/1 Running 0 64s
- しばらく待つとすべてのPodが起動していることが分かり、MySQLにデータがあるか確認します。
[root@k8s-master1 ~]# kubectl exec -it -n default mysql-dep-58cb9d765f-4sd58 /bin/bash
bash-4.2# mysql -uroot -proot
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| testdb |
+--------------------+
5 rows in set (0.00 sec)
mysql> use testdb;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from test_table;
+----+--------------+------+--------------------------+
| id | name | age | email |
+----+--------------+------+--------------------------+
| 1 | John Doe | 25 | [email protected] |
| 2 | Jane Smith | 30 | [email protected] |
| 3 | Mike Johnson | 35 | [email protected] |
+----+--------------+------+--------------------------+
3 rows in set (0.00 sec)
9. クラスターデータの移行
#首先,在集群 1 中创建备份(默认 TTL 是 30 天,你可以使用 --ttl 来修改):
velero backup create <BACKUP-NAME>
#然后,为集群 2 配置 BackupStorageLocations 和 VolumeSnapshotLocations,指向与集群 1 相同的备份和快照路径,并确保 BackupStorageLocations 是只读的(使用 --access-mode=ReadOnly)。接下来,稍微等一会(默认的同步时间为 1 分钟),等待 Backup 对象创建成功。
velero backup describe <BACKUP-NAME>
#最后,执行数据恢复:
velero restore create --from-backup <BACKUP-NAME>
velero restore get
velero restore describe <RESTORE-NAME-FROM-GET-COMMAND>
10. 参考アドレス
【クビーズ】
- http://wed.xjx100.cn/news/186281.html?action=onClick
- http://www.inspinia.net/a/216380.html?action=onClick
- https://www.cnblogs.com/xiaozhi1223/p/16570606.html
- https://cloud.tencent.com/developer/article/2098673
【脚本】
- https://www.cnblogs.com/zhangmingcheng/p/13892140.html
- https://www.cnblogs.com/xiaozhi1223/p/16570606.html
[バイナリ展開リファレンス]
- https://www.yii666.com/blog/509712.html
- https://www.cnblogs.com/xiaozhi1223/p/16570606.html
【ヴェレロツール】
- https://github.com/vmware-tanzu/velero
【主な参考資料】
- https://www.jb51.cc/k8s/3812803.html
- https://blog.51cto.com/u_16175439/6627299
- http://yunxue521.top/archives/velero
【Tencentクラウドドキュメント】
- https://www.tencentcloud.com/zh/document/product/457/38939
【バックアップツールカニスター】
- https://zhuanlan.zhihu.com/p/391732609
【素晴らしいブログ】
- https://www.hi-linux.com/posts/60858.html