Kubernetes クラスタ管理を 1 つの記事で理解する

ピクセル;パディング: 0px;背景: なし 0% 0% / 自動繰り返しスクロールパディングボックスボーダーボックス rgba(0, 0, 0, 0);">usr / local / bin /

（２）検査命令

 $ etcdctl バージョン
etcdctl バージョン: 3.5.3
 API バージョン: 3.5

（３）バックアップ操作を実行する。

 $ エクスポートETCDCTL_API = 3
 $ etcdctl --endpoints localhost : 2379 スナップショットスナップショットを保存します。 デシベル\
 --cacert = /etc/kubernetes/pki/etcd/ca.crt \         
 -- cert = /etc/kubernetes/pki/etcd/server.crt \         
 -- キー= /etc/kubernetes/pki/etcd/server.key

バックアップ Ectd では証明書を指定する必要があります。実行ノードにない場合は、マスターノードからコピーできます。

実行が完了すると、現在のディレクトリでバックアップ結果を表示できます。

 $ エクスポートETCDCTL_API = 3
 $ etcdctl --endpoints localhost : 2379 スナップショットスナップショットを保存します。 デシベル\
 > --cacert = /etc/kubernetes/pki/etcd/ca.crt \         
 > --cert = /etc/kubernetes/pki/etcd/server.crt \         
 > -- キー= /etc/kubernetes/pki/etcd/server.key         
 { "level" : "info" 、 "ts" : "2022-07-04T20:00:17.509+0800" 、 "caller" : "snapshot/v3_snapshot.go:65" 、 "msg" : "一時 DB ファイルを作成しました" 、 "path" : "snapshot.db.part" }
 { "level" : "info" , "ts" : "2022-07-04T20:00:17.520+0800" , "logger" : "client" , "caller" : "v3/maintenance.go:211" , "msg" : "スナップショット ストリームを開きました。ダウンロードしています" }
 { "level" : "info" 、 "ts" : "2022-07-04T20:00:17.520+0800" 、 "caller" : "snapshot/v3_snapshot.go:73" 、 "msg" : "スナップショットを取得しています" 、 "endpoint" : "localhost:2379" }
 { "level" : "info" , "ts" : "2022-07-04T20:00:17.544+0800" , "logger" : "client" , "caller" : "v3/maintenance.go:219" , "msg" : "スナップショットの読み取りが完了しました。終了しています" }
 { "level" : "info" 、 "ts" : "2022-07-04T20:00:17.556+0800" 、 "caller" : "snapshot/v3_snapshot.go:88" 、 "msg" : "取得されたスナップショット" 、 "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" }
 スナップショットはスナップショット.db に保存されました
$ ll
 合計3472
 - rw ------- . 1 ルートルート3551264 7月4日20:00 スナップショット。 デシベル

ただし、毎回手動でバックアップを実行することはできないため、スケジュールされたタスクを通じてバックアップを実行するのが最適です。より良いバックアップのために、ここで簡単なシェルスクリプトを記述し、スケジュールされたタスクに追加します。

 # ! / bin / バッシュ
ETCDCTL_PATH = '/usr/local/bin/etcdctl'
 エンドポイント= '192.168.205.128:2379'
 ETCD_DATA_DIR = "/var/lib/etcd"
 BACKUP_DIR = "/var/backups/kube_etcd/etcd-$(日付 +%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
 ETCDCTL_API = 2 をエクスポートします。 $ETCDCTL_PATH バックアップ- データ- ディレクトリ$ETCD_DATA_DIR - バックアップ- ディレクトリ$BACKUP_DIR
 睡眠3
 {
 ETCDCTL_API = 3 をエクスポートします。 $ETCDCTL_PATH -- エンドポイント= "$ENDPOINTS" スナップショットは$BACKUP_DIR / スナップショットを保存します。 デシベル\
 -- cacert = "$ETCDCTL_CA_FILE" \
 --cert = "$ETCDCTL_CERT " \
 --key = "$ETCDCTL_KEY "
 } > / dev / null
 睡眠3
 cd $BACKUP_DIR / .. / ; ls - lt | awk '{if(NR>(5+1)){print "rm -rf "$9}}' | シュ

次に、次のように Linux スケジュールタスクを追加します。

 $ crontab -l
 */ 30 * * * * / opt / etcd_back / etcd_backup .sh

回復する

（1）kube-apiserverとetcdを停止します。

ここで、すべての静的 Pod YAML ファイルを直接削除します。

 cd / etc / kubernetes / マニフェスト
mv * .yaml ../

（2）etcdデータディレクトリを削除します。

 $ mv / var / lib / etcd {,. 20220705 をバックアップします

（３）リカバリを実行する。

 ￥ ETCDCTL_API = 3 etcdctl 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コンポーネントを再起動します。

 yaml ファイルを編集します。

（５）クラスタの状態を確認します。

 $ kubectl ノードを取得する
名前ステータス役割年齢バージョン
kk - マスター準備完了コントロールプレーン7 h48m v1 .24 .2
 kk - node01 準備完了< なし> 7 h48m v1 .24 .2
 $ kubectl get po -A
 名前空間名準備完了ステータス再起動年齢
デフォルトnginx1 - 585f 98 d7bf - 45f nk 1 / 1 実行中0 3 h58m
 kube - システムcalico - kube - コントローラ- 5 d49fc6c56 - pq57d 1 / 1 実行中3 ( < 無効> 前) 7 時間 45 分
kube - システムcalico - ノード- rjdqh 1 / 1 実行中0 7 時間 45 分
kube - システムcalico - ノード- s8475 1 / 1 実行中0 7 時間 45 分
kube - システムcoredns - 7f 74 c56694 - qpvmv 1 / 1 実行中0 7 h48m
 kube - システムcoredns - 7f 74 c56694 - ww8kb 1 / 1 実行中0 7 h48m
 kube - システムetcd - kk - マスター1 / 1 実行中0 7 時間 48 分
kube - system kube - apiserver - kk - master 1 / 1 実行中2 ( 2 分 1 秒前) 7 時間 24 分
kube - システムkube - コントローラ- マネージャ- kk - マスター1 / 1 実行中0 7 h24m
 kube - システムkube - プロキシ- 5 pf65 1 / 1 実行中0 7 h24m
 kube - システムkube - プロキシ- mcxlq 1 / 1 実行中0 7 h23m
 kube - システムkube - スケジューラ- kk - マスター1 / 1 実行中0 7 h24m

クラスターリストのバックアップ

Kubernetes の実際の使用において、バックアップが必要なクラスターリストは主に次のとおりです。

デプロイメントクラス
StatfulSet クラス
DaemonSet クラス
サービスクラス
ConfigMap クラス
シークレットクラス
CronJob クラス
......

マニフェスト全体をバックアップすると、クラスターをすばやく復元できます。さらに、etcd のバックアップはある瞬間の完全なデータであるため、何をバックアップするかを選択することは不可能であり、バックアップされたデータは etcd 自体以外のプログラムでは読み取ることができません。

クラスターをバックアップする方法は多数あります。より簡単な方法は、「クラスターのバックアップ」の手順に従って、スクリプトを使用してクラスターをバックアップすることです。この方法は上で紹介したので、このセクションではバックアップに別のツール velero を使用します。

Velero はオープンソースソリューションです。プロジェクトアドレス: https://velero.io/。

ベレロの役割:

災害復旧機能: k8s クラスターをバックアップおよび復元する機能を提供します。
移行機能: クラスターリソースを他のクラスターにコピーする機能を提供します。

etcd バックアップとの違い:

etcd のバックアップには、etcd の操作および保守権限が必要です。マルチテナントのシナリオなどでは、一部のユーザーは etcd を操作できません。
etcd は単一クラスター内のデータバックアップに適しており、クラスターの移行にはあまり適していません。
etcd は現在の状態のバックアップであり、velero はクラスター内のリソースの一部のみをバックアップできます。

Velero は k8s クラスター上でサーバーポッドを実行し、Velero クライアントで動作します。インストールプロセスはドキュメントを参照することができ、操作は非常に簡単です。

クライアントをインストールする

https://github.com/vmware-tanzu/velero/releases にアクセスして、対応するバージョンをダウンロードしてインストールしてください。

 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 。 タール。 日本語
$ mv velero - v1.9.0 - linux - amd64 / velero / usr / local / bin /
 $ velero バージョン
クライアント：
 バージョン: v1.9.0
 Git コミット: 6021f 148 c4d7721285e815a3e1af761262bff029
 < サーバーバージョンの取得エラー: 名前空間「velero」が見つかりません>

サーバーをインストールする

サーバーをインストールするには 2 つの方法があります。

velero クライアントを使用してインストールします。
Helm チャートを使用してインストールします。

ここでのインストールには velero クライアントが使用されます。 Velero のバックエンドは Alibaba Cloud OSS、mino など多くのオブジェクトストレージから選択できます。Alibaba Cloud OSS は別途購入する必要があるため、ここではバックエンドストレージとして minio を使用します。

minioをインストールする

（１）ヘルムソースを追加します。

 $ helm リポジトリにminio を追加しますhttps://helm.min.io/

（２）ミニオを展開する。これは単なるテストなので、データの永続化は行われません。

 $ ヘルムインストールminio \
 -- 名前空間velero -- 作成- 名前空間\
 -- accessKey = minio 、 secretKey = minio123 を設定します\
 --set モード= スタンドアロン\
 -- サービスを設定します。 タイプ= NodePort \
 -- 永続性を設定します。 有効= false \
 ミニオ/ ミニオ

（２）UIを使用してアクセスし、閲覧します。

 $ kubectl get svc -n velero
 名前タイプクラスタ- IP 外部- IP ポート( S ) 年齢
minio NodePort 10.110 .75 .97 < なし> 9000 : 32000 / TCP 92 秒

ログインユーザー名とパスワードは、minio:minio123 です。

veleroサーバーをインストールする

（1）minio上にbuckrtを作成します。

（２）veleroインストールディレクトリにcredentials-veleroを作成し、以下の内容を記述します。

 [ デフォルト]
 aws_access_key_id = ミニオ
aws_secret_access_key = minio123

（３）veleroをインストールします。

 $ velero インストール\
 --provider aws \
 -- バケットベレロ\
 -- 画像velero / velero : v1 .6 .3 \
 -- プラグインvelero / velero - プラグイン- for - aws : v1 .2 .1 \
 --namespace velero \
 -- シークレット- ファイル./ 資格情報 - velero \
 -- 使用- ボリューム- スナップショット= false \
 --use - レスティック\
 -- バックアップ- 場所- 設定リージョン= minio 、 s3ForcePathStyle = "true" 、 s3Url = http ： //minio.velero.svc： 9000

（4）すべてのコンポーネントが正常に起動しているかどうかを確認します。

 $ kubectl get po -n velero
名前 準備完了 ステータス 再起動 年齢
minio-6c9f559d5b-cpc2d 1/1 実行中 0 3分3秒
restic-pq5bm 1/1 ランニング 0 3分28秒
velero-887577984-2tmm4 1/1 ランニング 0 3分28秒

バックアップ操作の実行

（1）デフォルトの名前空間にnginx Podを作成します。

 $ kubectl デプロイメントnginx を作成-- イメージnginx

（２）バックアップ操作を実行して、デフォルトのリソースをバックアップします。

 $ velero バックアップ作成デフォルト- バックアップ- 20220705 --include - namespaces default --default - volumes - to - restic

（3）minioでバックアップディレクトリがすでに存在していることがわかります

（4）次に、デフォルトの名前空間にあるnginx Podを削除します。

 $ kubectl デプロイメントnginx を削除します

（５）回復操作を実行する。

 $ velero 復元作成--from - バックアップデフォルト- バックアップ- 20220705

（6）デフォルトの名前空間のnginx Podが復元されたことがわかります。

 $ kubectl でpo を取得する
名前準備完了ステータス再起動年齢
nginx - 8f 458 dc5b - z6fnh 1 / 1 実行中0 38 秒

要約する

Kubernetes はアプリケーションの基盤です。基盤に問題があれば、アプリケーションの安定性に問題はありません。実際の業務においては、言葉にできない事態に遭遇した際にバックアッププランが立てられるように、基本プラットフォームのバックアップを取っておくことが特に重要です。したがって、Kubernetes をできれば定期的にバックアップすることをお勧めします。