Yunxiデータベースを使用したKubernetesの概要

その他 2022-04-22 11:13:02 訪問数: null

Kubernetesを選ぶ理由

コンテナは、アプリケーションをパッケージ化して実行するための優れた方法です。実稼働環境では、アプリケーションを実行するコンテナーを管理し、ダウンタイムが発生しないようにする必要があります。1つのコンテナに障害が発生した場合は、別のコンテナを起動する必要があります。システムがこの動作を処理した方が便利ではないでしょうか。これは、分散システムを柔軟に実行するためのフレームワークを提供するKubernetes（以下、K8sと呼びます）の価値です。K8sは、コンテナー化されたワークロードとサービスを管理するために使用され、宣言型の構成と自動化を容易にします。同時に、k8sは、自動デプロイとロールバック、サービス検出と負荷分散、ストレージオーケストレーション、自己修復、キーと構成の管理などの多くの機能を提供します。k8sの複雑さについていくつかの不満がありますが、その利点が複雑さのコストをはるかに上回っていると確信しています。  

 

Kubernetesがアプリケーションの状態を維持する方法

初期段階のKubernetesは、主にステートレスアプリケーション（独自の永続データを管理しないアプリケーション）を対象としていました。この機能は、k8sが永続ボリューム（永続ボリューム）とStatefulSetsを導入するまで改善されました。通常、Kubernetesコンテナが停止すると、新しいIPアドレスとホスト名を含む新しいIDを持つ新しいコンテナに置き換えられます。ただし、StatefulSet機能により、再起動の回数に関係なく、各ポッドが独自の安定したID（DNSを介して解決可能）を持つことが保証されます。これは、ポッドが交換または再起動されるたびに、ポッドをクラスター内の新しいノードとして扱う必要がなく、大量のデータ複製を回避できることを意味するため、Yunxiデータベース（Yunxiデータベース）に役立ちます。これは、Yunxiデータベースのコンセンサスプロトコルと分散トランザクションをサポートするために非常に重要です。クラウドネイティブデータベースであるYunxiDatabaseは、単一のデータノードのデータ損失を許容し、クラスター内の欠落しているレプリカを検出し、新しいレプリカを自動的に追加できます。レイテンシを低くするには、ストレージにローカルディスクを使用することをお勧めしますが、リモートストレージでは、データを失うことなくレプリカを移動できます。  

 

KubernetesでYunxiデータベースを使用する理由

ほとんどの場合、物理マシンや仮想マシンよりもK8でYunxiデータベースをデプロイ、運用、維持する方が便利です。これは主に、Yunxiデータベースが、各ノードを介してデータベースへの共通のゲートウェイを提供する単一の実行可能ファイルであるためです。各ノードは完全に等しく、唯一の違いは、ノードが管理するデータの部分です。断続的な障害やローリングアップグレードが発生した場合、K8sはデータベースクラスターの迅速なリカバリを容易にします。k8sには多くの便利さがありますが、k8sがもたらす弾力性と、物理マシンまたは仮想マシンによるパフォーマンスの長所と短所を比較検討する必要があります。物理マシンまたは仮想マシンでデータベースを維持するにはより多くの手作業が必要ですが、得られる最高のパフォーマンスはk8sよりも優れています。

 

YunxiデータベースがKubernetesでどのように実行されるか

1.データベースクラスターを作成します

1.ネットワークストレージではなくローカルストレージボリュームを使用する場合は、使用するポッドを提供するために3つの永続ボリューム（永続ボリューム）を作成する必要があります。

$ kubectl apply -f pv0.yaml -f pv1.yaml -f pv2.yaml

次の永続ボリューム（pv）yamlファイルを参照してください。

apiVersion：v1
種類：PersistentVolume
メタデータ：
 名前：pv-bini-0
 ラベル：
   アプリ：bini
仕様：
 容量：
   ストレージ：10Gi
 volumeMode：ファイルシステム
 accessModes：
 -ReadWriteOnce
 storageClassName：ローカル
 persistVolumeReclaimPolicy：保持
 ローカル：
   パス：/ home / inspur / pv / pv0
 nodeAffinity：
   必要：
     nodeSelectorTerms：
     --matchExpressions：
       -キー：kubernetes.io/hostname
         演算子：で
         値：['slave1']

2. Kubernetes環境を準備した後、yamlファイルを使用してStatefulSetを作成し、データベースクラスターを作成できます。

$ kubectl create -f bini-statefulset.yaml
service/bini-publicが作成しました
service/biniが作成されました
poddisruptionbudget.policy/bini-budgetが作成されました
statefulset.apps/biniが作成されました

3.クラスターをまだ初期化していないため、3つのポッドは次のrunning状態。 

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
bini-00/1ランニング01m
bini-10/1ランニング01m
bini-20/1ランニング01m

4.ローカル永続ボリューム宣言とローカル永続ボリュームが正常にバインドされていることを確認します。

$kubectlはpersistentvolumeclaimsを取得します
名前ステータスボリューム容量アクセスモードストレージクラス年齢
datadir-bini-0バインドされたpv-bini-11GiRWOローカル2m
datadir-bini-1バウンドpv-bini-01GiRWOローカル2m
datadir-bini-2バウンドpv-bini-21GiRWOローカル2m

5.クラスター初期化用のyamlファイルを作成します。

$ kubectl create -f cluster-init.yaml
job.batch/cluster-initが作成されました

6.初期化のジョブはまもなく次のcompleted状態。 

$ kubectl get job cluster-init
名前の完了期間の年齢
cluster-init 1/1 10s 30s

データベースノードの3つのポッドも次のrunning状態。 

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
cluster-init-bw9280/1完了050秒
bini-01/1ランニング03m23s
bini-11/1ランニング03m23s
bini-21/1ランニング03m23s

次に、組み込みのSQLクライアントを使用します。

1.一時的な対話型ポッドを起動し、そのポッドで組み込みのSQLクライアントを起動します。

$ kubectl run bini -it \
--image = bini：release2.0 \
--rm \
--restart = Never \
--sql \
--安全でない\
--host = bini-public

2.いくつかのSQLステートメントを実行します。

root @ bini-public：2​​6257/defaultdb>データベースバンクを作成します。
root @ bini-public：2​​6257/defaultdb>データベースバンクを作成します。
root @ bini-public：2​​6257 / defaultdb> create table bank.accounts（
名前varchar（255）、
小数のバランス
）;
root @ bini-public：2​​6257 / defaultdb> bank.accountsに挿入値（'Andy'、100）、（'Bob'、200）、（'Chris'、300）;
root @ bini-public：2​​6257 / defaultdb> select * from bank.accounts;
 名前| 残高  
+ ------- + --------- +
 アンディ| 100  
 ボブ| 200  
 クリス| 300  
（3行）

3. SQLシェルを終了すると、ポッドも削除されます

root @ bini-public：2​​6257 / defaultdb> \ q

3.管理UIを介してクラスターのステータスを表示します

方法1：サービス用にNodePortを設定する

サービスのNodePortを使用して、管理UIのポートをローカルマシンのポートにマップし、localhost+NodePortの方法を使用してアクセスします。

方法2：ポート転送を使用してK8sのサービスをローカルマシンのポートに手動で転送する 
$ kubectl port-forward service / bini-public --address 0.0.0.0 8080：8080
0.0.0.0:8080->8080から転送

 

クラスターを管理する

1.ノードを追加します

$ kubectl scale statefulset bini --replicas = 4
statefulset.apps/biniスケーリング

新しいローカル永続ストレージボリュームを構成すると、4番目のポッドがクラスターに正常に参加することがわかります。

NAME READY STATUS RESTARTS AGE
cluster-init-bw9280/1完了01分39秒
bini-01/1ランニング04m12s
bini-11/1ランニング04m12s
bini-21/1ランニング04m12s
bini-31/1ランニング030秒

2.ノードを削除します

1.一時的な対話型ポッドを起動bini node statusし、次のコマンドを使用してデータベースノードの内部IDを取得します。 

$ kubectl run bini -it \
--image = bini / release2.0 \
--rm \
--restart = Never \
-ノードステータス\
--安全でない\
--host = bini-public
 id | 住所| ビルド| start_at | updated_at | is_available | is_live  
+ ---- + -------------------------------------------- -+ --------- + ---------------------------- + --------- ------------------- + -------------- + --------- +
  1 | bini-0.bini.default.svc.cluster.local：26257 | ff04cdd | 2021-02-04 09：34：47.053657 | 2021-02-05 02：45：31.756302 | 真| true    
  2 | bini-2.bini.default.svc.cluster.local：26257 | ff04cdd | 2021-02-04 09：34：47.814316 | 2021-02-05 02：45：32.464036 | 真| true    
  3 | bini-1.bini.default.svc.cluster.local：26257 | ff04cdd | 2021-02-04 09：34：47.077002 | 2021-02-05 02：45：31.756099 | 真| true    
  4 | bini-3.bini.default.svc.cluster.local：26257 | ff04cdd | 2021-02-05 02：01：14.868258 | 2021-02-05 02：45：29.947311 | 真| true    
（4行）

2.アドレス内の最も大きい番号のノードのID（つまりbini-3、前の手順に含まれているアドレス）をbini node decommissionメモし、次のコマンドで非アクティブ化します。 

kubectl run bini -it \
--image = bini：release2.0 \
--rm \
--restart = Never \
--ノードの廃止<ノードID>\
--安全でない\
--host = bini-public

次に、廃止されたノードのステータスが表示されます。

id | is_live | レプリカ| is_decommissioning | is_draining  
+ --- + --------- + ---------- + -------------------- + --- ---------- +
 4 | 真| 28 | 真| false

ノードが完全に停止すると、次の情報が表示されます。

id | is_live | レプリカ| is_decommissioning | is_draining  
+ --- + --------- + ---------- + -------------------- + --- ---------- +
 4 | 真| 0 | 真| false    
（1行）


ターゲットノードで報告されるデータはこれ以上ありません。ノードを削除する前に、クラスターの状態を確認してください。

3.StatefulSetからノードを削除します。

$ kubectl scale statefulset bini --replicas = 3
ステートフルセット「bini」スケーリング

3.ローリングアップグレード

$ kubectl patch statefulset bini -p'{"spec"：{"template"：{"spec"：{"containers"：[{"name"： "bini"、 "image"： "bini：release2.0"} ]}}}} '

第四に、クラスターを削除します

作成されたすべてのリソースを削除します

$ kubectl delete pods、statefulsets、services、persistentvolumeclaims、persistentvolumes、poddisruptionbudget、jobs -l app = bini
ポッド「bini-0」を削除
ポッド「bini-1」を削除
ポッド「bini-2」を削除
ポッド「bini-3」を削除
サービス「bini」を削除
サービス「bini-public」を削除
persistvolumeclaim"datadir-bini-0"が削除されました
persistvolumeclaim"datadir-bini-1"が削除されました
persistvolumeclaim"datadir-bini-2"が削除されました
persistvolumeclaim"datadir-bini-3"が削除されました
poddisruptionbudget「bini-budget」が削除されました
ジョブ「cluster-init」が削除されました
{{o.name}}
{{m.name}}

おすすめ

転載: my.oschina.net/u/5148943/blog/5438126
おすすめ
ランキング
欲張りアルゴリズムLeetcode45ジャンプゲームの証明プロセス
Résumé des outils couramment utilisés pour l'acoustique et l'informatique musicale (soundfile, librosa, pydub, madmom, spleeter)
OpenCVの。コンセプト
直接公式招待コード88886981の下ダイハツ
ミリ秒の形式に現在時刻を取得するJava
umijs/plugin-qiankun (vue+umi) に基づくマイクロフロントエンド構成
クローン化されたカードからLinux仮想マシンは、eth1にはeth0になり
10G SFP + 10G XFP光モジュール及び光モジュール
DevExpressがDateEditを設定して年、月、四半期を表示
Mavenがローカルに外部jarパッケージをインポートする
アーカイブ
もっと
2024-05-19(0)
2024-05-18(30)
2024-05-17(6)
2024-05-16(24)
2024-05-15(5)
2024-05-14(9)
2024-05-13(8)
2024-05-12(27)
2024-05-11(31)
2024-05-10(33)

コードワールド

© 2018 codetd.com