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

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 をできれば定期的にバックアップすることをお勧めします。

やっと

上記は、一般的に使用されるクラスター関連の操作です。これらを上手に習得し、実際に応用することで、多くの時間を節約できます。

もちろん、これらの日常的な操作に加えて、クラスターの移行、クラスターのインポートなどもあります。本質的にはバックアップと復元の問題だと思いますが、データの整合性とビジネスの継続性をさらに考慮することになります。これは具体的なビジネス状況に関係するため、ここでは詳細には触れません。

<<:  ガートナー：クラウドは2025年までに普及し、企業のデジタル化の基盤となる

>>:  IDC: アリババクラウド、中国のビデオクラウド市場で4年連続1位に

推薦する

ウェブサイト分析: データを活用してデザインを支援する

設計においては、対象グループ、シナリオ、運用習慣が異なるため、経験と直感だけに頼ることはできません。...

Xiake Station Group System V3の無料版の経験とWORDPRESSプラットフォームの実践的な経験

最近、サイトグループで遊びたくなって、朝A5を開いて、Xiakeサイトグループシステムの無料版がある...

百度のスナップショットの誤解、完全な分析はランキングの重みに影響を与えない

多くのウェブマスターは、Baiduスナップショットについて非常に懸念しています。多くの友人が、ウェブ...

「ゼロトラストで信頼を再構築」ゼロトラスト開発トレンドフォーラムが5月に開催されます

企業のデジタルアップグレードの加速により、従来のネットワーク境界は徐々に消滅し、ゼロトラスト概念の実...

インベントリ: 2022 年に注目すべきエッジ コンピューティング オープンソース プロジェクト トップ 10

IDC の最新の「グローバル エッジ コンピューティング支出レポート」によると、エッジ コンピューテ...

アンクルオペレーションズ: モバイル業界のすべての CP とチャネル パートナーの皆様に、楽しい中秋節をお過ごしください!

 この台風の間、私体存在する南部の美しい海辺の都市、厦門は、オペレーション・アンクルの願い:モバイル...

Baidu の青大根アルゴリズムが中小企業サイトに偏っている理由について議論する

百度の青大根アルゴリズムが発表されてから一週間が経ちました。ここ数日、石頭は青大根アルゴリズムに関す...

ブロックチェーンの破壊力4: 分散型インテリジェントID認証システム

前の記事からの続き: 《ブロックチェーンの破壊力の一つ：基盤技術》ブロックチェーンの第二の破壊力：信...

中央銀行がオンライン決済監督の嵐を巻き起こし、アリババとテンセントの競争の内幕が明らかに

これは、2つのインターネット金融大手によるカーブでの競争ゲームです。中央銀行はタイミングよく介入し、...

クラウド移行を成功させるための8つのステップ

今日の競争の激しいデジタル環境において、企業が権威を保つためには、最新のトレンドとテクノロジーに遅れ...

クラウドへの移行方法: 7 つのベスト プラクティス

クラウドに移行する理由は明確ですが、組織がクラウド移行を完了するために必要な概念と実践を把握するのは...

「スポーツ専門学生」PPTV：インターネット流スポーツロジック

サッカーの試合をライブで観戦するには、どこで観戦すればいいのでしょうか? CCTV-5 を諦めて、代...

短期間でウェブサイトのトラフィックを増やすための簡単な方法

トラフィックはウェブサイトにとって重要ですか? それに疑いの余地はありません。トラフィックのないウェ...

Alibaba Cloud で効率的で安定した安全な Echsop モールの Web サイトを展開する方法

2018年最もホットなプロジェクト：テレマーケティングロボットがあなたの参加を待っていますEcsho...

Xiong Zhanghao: ブログ最適化のための SEO テクニックは何ですか?

月収10万元の起業の夢を実現するミニプログラム起業支援プラン新しいメディアプラットフォームの発展に伴...