この記事では引き続き、 RabbitMQ の移行について、MongoDB 専用です。 私たちは多くの Kubernetes と MongoDB クラスターを維持しているため、あるインストールから別のインストールにデータを移行し、ダウンタイムなしで実行する必要があることが自然にわかりました。 主なシナリオは同じです。MongoDB を仮想/ハードウェア サーバーから Kubernetes に移動するか、同じ Kubernetes クラスター内で (ある名前空間から別の名前空間に) MongoDB を移動します。
私たちのレシピは、Kubernetes でホストされているアプリケーションが実行されている古い MongoDB クラスター (たとえば、3 つのノードで、すでに K8s または古いサーバーに配置されている) がある場合を対象としています。
このようなクラスターを Kubernetes の新しいプロダクションにどのように転送するのでしょうか?
Теория
一般的な移行アルゴリズムは、RabbitMQ の場合で説明したものと似ています。
この移行では、MongoDB サーバーと Kubernetes サーバーが同じネットワーク上にある必要があることに注意することが重要です。 MongoDB クラスター ノードは、古いサーバー (古い MongoDB インストールが配置されている場所) の IP と、K8s の MongoDB を備えたポッドの DNS 名を使用して相互に通信します。 したがって、ハードウェア サーバー (古いインストール環境) では、ルートをポッドに転送し、Kubernetes で実行されている DNS サーバーを使用するようにポッドを構成する (または必要な名前をポッドに登録する) 必要があります。 /etc/hostsただし、一般的にはこの可能性を避ける方が良いでしょう)。
次のステップは、Kubernetes ポッドで MongoDB クラスターを起動することです。 この例では、データベース クラスターは 3 つのノードで構成され、各ノードは別の K8s ポッドに配置されています。ただし、その数は異なる場合があります。 ConfigMap で、古いインストールの MongoDB マスターのアドレスを指定する必要があります。これにより、K8s のポッドにある MongoDB ノードが直ちにそのマスターとの同期を開始します。
すべてのポッドが起動すると、6 ノードの MongoDB クラスターが形成されます。
各ポッドは順番に起動され、起動時にマスターからのデータを同期するため、ポッドの起動には時間がかかることに注意してください。
その後、新しい MongoDB サーバーを使用するようにアプリケーションを切り替えることができます。
残っているのは、MongoDB クラスターから古いノードを削除することだけです。その後、移動は完了したと見なされます。
私たちは実稼働環境でこのスキームをよく使用しますが、使いやすさのために、このスキームをモジュール内に実装しました。 （私たちは )、これにより、一般的な MongoDB 構成を多くのクラスターに分散できます。 私たちはモジュールをすぐに公開する予定ですが、現時点では、アドオン オペレーターを使用せずに提案されたソリューションを実際に試すことができる別の手順を紹介します。
実際に試してみましょう
必要条件
必要条件：
- Kubernetes クラスター (minikube も機能します)。
- MongoDB クラスター (ベアメタル上にデプロイでき、公式 Helm チャートから Kubernetes の通常のクラスターのように作成できます)。
以下の例では、古い MongoDB クラスターには次の名前が付けられます。 mongo-old 同じ Kubernetes クラスターにインストールされます。後で新しいクラスターをインストールします (mongo-new).
古いクラスターの準備
1. 説明したスキームの動作を示す例として、「古い」（つまり、移行の対象となる）MongoDB クラスターを Kubernetes 内に直接作成してみましょう（実際には、K8 の外部の別のサーバーに配置できます）。 これを行うには、Helm チャートをダウンロードします。
helm fetch --untar stable/mongodb-replicaset...認可を設定して少し編集します。
auth:
enabled: true
adminUser: mongo
adminPassword: pa33w0rd
# metricsUser: metrics
# metricsPassword: password
# key: keycontent
# existingKeySecret:
# existingAdminSecret:
# exisitingMetricsSecret: また values.yaml 証明書などを構成できます。
2. チャートをインストールします。
helm install . --name mongo-old --namespace mongo-oldこの後、MongoDB のテスト用「古い」インストールが起動されます。
kubectl --namespace=mongo-old get pods 
マスターのあるポッドに入り、テスト データベースを作成しましょう。
kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo
use admin
db.auth('mongo','password')
use music
db.artists.insert({ artistname: "The Tea Party" })
show dbs 
別のポッドに行くと、マスターが mongo-old-mongodb-replicaset-0。 ただし、この問題をより便利に解決するには、Helm チャートをインストールした後、次のことを確認する方法に関するコマンドが表示されます。 MASTER_POD。 私の場合（ mongo-old 3 ノードの場合)、次のようになります。
for ((i = 0; i < 3; ++i)); do kubectl exec --namespace mongo-old mongo-old-mongodb-replicaset-$i -- sh -c 'mongo --eval="printjson(rs.isMaster())"'; doneこの時点で、データが転送される古い MongoDB インストールの準備が完了しました。
MongoDB クラスターの移行
次に、MongoDB の新しいインストールをデプロイしましょう。これは Kubernetes に配置され、運用環境のアプリケーションによって使用されます。
NB: 以前と同じバージョンの MongoDB を使用する必要があることに注意してください。 そうしないと、互換性の問題が発生する可能性があります。
前のセクション (「古い」MongoDB インストールをシミュレートしました) と同様に、すでに述べた Helm チャートを見てみましょう (コマンドを使用) helm fetch) を使用して、認可およびその他のパラメーター (使用する場合) を構成します。 ついでにファイルも修正しておきます init/on-start.sh、165 行目に、前の手順で取得した (または個々のサーバーに MongoDB をインストールすることでわかった) マスター アドレスを一時的に追加します。
peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'新しい MongoDB インストールを作成する準備ができました。
helm install . --name mongo-new --namespace mongo-newすべてのポッドが開始されるまで待ちます (大量のデータがある場合、ポッドの起動には数時間かかることがあります)。
さあ、やってみましょう exec 新しいポッドに接続し、データベースのリストを確認します。
kubectl --namespace=mongo-new exec -ti mongo-new-mongodb-replicaset-0 mongo 
6 つの MongoDB クラスターが XNUMX つに結合され、XNUMX つのノードで構成されます。
この時点で、アプリケーションを新しいクラスターに切り替えることができますが、移行を完了するにはいくつかの手順が残っています。
ファイルから init/on-start.sh 新しいインストールでは、追加した行を削除します。
peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'次に、古いクラスター マスターに移動して、それを「破棄」しましょう。そうすると、新しいマスターがクラスターに割り当てられます。 MongoDB マスターを使用してポッドに入ります。
kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo
use admin
db.auth('mongo','password')その後、ノードの優先順位を変更し、マスターを変更します。
cfg = rs.conf()
cfg.members[5].priority = 2
rs.reconfig(cfg)
rs.stepDown(120)現在のノードはマスターではなくなりました。新しいノードが選出されます。 優先順位を変更したため、必要なノードがマスターになります。
NB: デフォルトでは、すべての MongoDB ノードの優先度は 1 です。上記では、必要なノードの優先度を 2 に上げています。 したがって、新しいクラスタのメンバーは間違いなく全体マスターになります。 MongoDB でこれらのメカニズムがどのように機能するかについて詳しくは、次の記事を参照してください。 .
古い MongoDB インストールを無効にしてから、新しいウィザードに移動して古いノードを削除しましょう。
rs.remove("mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")
rs.remove("mongo-old-mongodb-replicaset-1.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")
rs.remove("mongo-old-mongodb-replicaset-2.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")この後、移行は完了したと見なされます。古い MongoDB クラスターから新しいクラスターに正常に切り替えられました。
結果
説明したスキームは、MongoDB を移行するか、単に新しいクラスターに移動する必要がある場合のほとんどすべてのケースに適しています。
おそらく、転送時の主なニュアンスは、新しいポッドの IP アドレスを古い MongoDB インストールのサーバー (K8 の外部にある場合) に転送し、DNS でそれらに正しく名前を付ける必要があることです (または /etc/hosts）。 この例では、同じ Kubernetes クラスターの異なる名前空間間で移行が行われたため、これらの手順は必要ありませんでした。
PS
私たちのブログもお読みください:
- «";
- «";
- «'。
出所： habr.com
