クラウドネイティブを採用し、k8s を使用してオープンソースプロジェクトをデプロイするにはどうすればよいでしょうか?

K8s とクラウドネイティブ関連の概念は近年非常に人気があります。 Awan は最近関連プロジェクトを立ち上げました。以下にその概要を示します。

この記事では、Alibaba のオープンソースプロジェクト Otter が k8s デプロイメントに適応するための変革プロセスを共有することに焦点を当てます。変換プロセスとテクニックは、ほとんどのオープンソースプロジェクトを k8s に変換して展開する場合に適用できるはずです。

1. 背景

Otter は Alibaba のオープンソース分散データベース同期システムであり、データベースの増分ログ分析に基づいて、ローカルコンピュータルームまたはリモートコンピュータルームの MySQL/Oracle データベースに準リアルタイムで同期します (関連コンテンツについては、この記事では詳しく説明しませんが、https://github.com/alibaba/otter を参照してください)。

物理リソースを最大限に活用し、同期ノードを迅速に拡張し、クラウドネイティブを採用するために、k8s を使用して otter を展開することが決定されました。

Otter のプロジェクトは全体として自己完結的です。変換コストを考慮して、ソースコードを変更せずに、プロジェクトの既存の基盤にいくつかの適応を加えるように努めます。

この記事では、k8s デプロイメントに適応するための Otter の変換プロセスを共有することに焦点を当てます。不適切な点がありましたら、さらにアドバイスをお願いします。

いくつかのコアコンテンツが含まれます:

カワウソの基本アーキテクチャ
Dockerfileの書き方
デプロイメントの記述
起動スクリプトの変換
K8s の IP/ポートアクセスを修正

2. Otterの基本構造

典型的な管理システムアーキテクチャ、マネージャー（Web管理）+ノード（作業ノード）

マネージャは実行時に同期構成をノードにプッシュします
ノードは同期ステータスをマネージャーにフィードバックします
Zookeeperをベースに、分散状態スケジューリングを解決し、複数のノードが連携できるようにします。
Canal オープンソース製品に基づいて、データベースの増分ログデータを取得します。もちろん、Otter は独立した canal ノードではなく、canal の埋め込みモードを使用します。

上記のデプロイメントアーキテクチャに基づいて、otter-manager と otter-node を k8s にデプロイするだけで済みます。

特に otter-node では、ノードの急速な水平拡張とコンピューティング性能の弾力的な拡張と縮小を実現するために k8s が必要です。

2. Dockerfileの記述

2.1 otter-managerのDockerfile

otter-manager は比較的シンプルで、いくつかのステップで構成されています。

Centosベースのイメージを使用する
タイムゾーンを設定する
ディレクトリを作成する
ダウンロードしたmanager.deployer-4.2.18を指定されたディレクトリにコピーします。
startup-new.sh スクリプトを起動します (元の起動スクリプトにいくつかの変更が加えられていますが、これについては後で詳しく説明します)

詳細は以下の通りです。

2.2 otter-node の Dockerfile

otter-node は少し異なります。公式ドキュメントによると、ファイル転送には aria2 をインストールする必要があります。

注: aria2 のインストールは非常に遅いため、最初に aria2 を新しいベースイメージとしてインストールし、次に新しいベースイメージ上に otter-node イメージをビルドする必要があります。これにより、その後のイメージビルド速度が大幅に向上します。

新しいベースイメージは、registry.xxx.com/xxx/otter-node-base:1.0 という名前です。

次に、これに基づいて新しい otter-node イメージを構築します。

otter-node の設定方法は非常に特殊であることに注意してください。 otter-node を実行する前に、otter-admin で nid を取得する必要があります。

したがって、dockerfile で ARG を使用して nid を宣言し、後でイメージをビルドするときに --docker-arg を介して nid の特定の値を渡します。

もちろん、nid を設定ファイルとして扱う場合は、後述する ConfigMap の形式で Deployment にマウントすることもできます。

3.デプロイメントの記述

デプロイメントとは何ですか?

k8s のデプロイメントコントローラーは、Pod と ReplicaSet の宣言的な更新機能を提供します。望ましいターゲット状態を記述する Deployment を記述し、その後 Deployment コントローラーが Pod または ReplicaSet の実際の状態を変更して望ましい状態にします。

デプロイメントに関する具体的な知識については詳しく説明されていないため、公式の k8s ドキュメントを参照してください。

テスト環境と本番環境用に 2 つのクラスターをデプロイする必要があります。 otter-manager と otter-node はどちらも、設定として conf/otter.properties の読み取りに依存しています。

したがって、環境に応じて異なる otter.properties を変更する必要があります。

そして、k8s のデプロイメントでは、同じイメージを使用して、otter.properties を異なる環境 (k8s の異なる名前空間) に ConfigMap として書き込み、最後にボリュームの形式でポッドの指定されたパスにマウントすることができます。

ここでいくつかの用語について簡単に紹介します。詳細については、k8s の公式ドキュメントを参照してください。

ConfigMap : 非機密データをキーと値のペアで保存するために使用される API オブジェクト。使用すると、Pod はこれを環境変数、コマンドライン引数、またはストレージボリューム内の構成ファイルとして使用できます。 (保存したいデータが機密情報である場合は、ConfigMap の代わりに Secret を使用できます)
ボリューム: 本質的に、ボリュームはポッド内のコンテナがアクセスできるデータを含むディレクトリです。使用される特定のボリュームタイプによって、ディレクトリの形成方法、データの保存に使用されるメディア、およびディレクトリに配置される内容が決まります。ボリュームを使用する場合は、.spec.volumes フィールドに Pod によって提供されるボリュームを設定し、.spec.containers[*].volumeMounts フィールドにコンテナ内のボリュームのマウント場所を宣言します。

したがって、最初に、otter.properties をキーとして、ファイルの内容を値として、指定された環境 (名前空間) に configmap を作成します。

具体的なコマンドは以下のとおりです

kubectl で otter-manager-dev-config の設定マップを作成します --from-file=otter.properties=conf/otter-dev.properties -n otter-system

名前空間 otter-system に otter-manager-dev-config という名前の ConfigMap を作成し、otter.properties をキーとして、ファイルの内容を値として指定します。

生成されたConfigMapは次の図のようになります。

最後に、Deployment のボリュームでこの ConfigMap を参照し、volumeMounts を介して指定されたディレクトリにマウントします。展開は以下のとおりです。

ここでは、volumeMounts のパス上書き問題に特に注意する必要があります。 volumeMounts の subPath を特定のファイル名として設定する必要があります。

4. スクリプト変換を開始する

Otter は、管理コンソールマネージャーと作業ノードの 2 つの部分で構成されます。通常の状況では、それぞれの起動スクリプト startup.sh を使用して起動されます。

k8s に適応するには、起動スクリプトを変更する必要があります。この記事では otter-manager の起動スクリプトを例に挙げていますが、otter-node も同様です。

起動スクリプトstartup.shをstartup-moon.shに変換し、2つの問題を解決することに焦点を当てます。

フォアグラウンドプロセスは実行され続けます
JVMパラメータのカスタマイズ

4.1 フォアグラウンドプロセスが実行し続ける

コンテナ内のエントリポイントで開始されたプロセスはプロセス 1 であるため、プロセス 1 の実行が終了すると、コンテナは終了します。

本来の startup.sh では、java で起動した後、「&」を使用して java プロセスをバックグラウンドプロセスに変換しているため、プロセス 1 である startup.sh がすぐに実行され、コンテナが自動的に終了します。

したがって、プロセス 1 を維持し、終了しないようにする必要があります。

ここでは 2 つのオプションが検討されます。

Startup.sh スクリプトにフォアグラウンドプロセスを追加して維持します (tail -f /dev/null コマンドなど)。
「&」を削除すると、Java が起動後にフォアグラウンドプロセスとして維持されます。

検討した結果、オプション 2 を選択することにしました。主な理由は、ポッドの自動再起動機能を活用するためです。

Java プロセスが予期せず終了した場合、ソリューション 2 はプロセス 1 も終了し、ポッドを自動的に再起動できます。ソリューション 1 では、startup.sh スクリプトが引き続き tail を実行しているため、Java プロセスが終了してもプロセス 1 は終了しません。

具体的な変更点は以下のとおりです。

ポッド内の最終プロセスは図に示されている。

プロセス1は起動スクリプトです
プロセス1の子プロセスはotterのJavaアプリケーションプロセス（フォアグラウンドプロセス）です。

4.2 仮想マシンのサイズをカスタマイズする

Otter プロジェクトでは、JVM の起動パラメータは start.sh で構成されますが、手動で構成するのは不便です。

そのため、start.sh で jvm パラメータを設定するロジックをコメントアウトし、注入用に自分で設定した環境変数 JAVA_OPTIONS を使用します。

この環境変数の挿入方法も比較的簡単で、デプロイメント内の env 構成 (青いボックス部分) であり、イメージを変更せずに jvm パラメータのサイズを手動で変更するのに便利です。

5. k8s上の固定IP/ポートアクセス

otter-node のデプロイメントには特別な機能があります。

通常のマイクロサービスのステートレス拡張とは異なり、otter-node のデプロイメントでは nid、ip、および port を指定する必要があります。この設計は、単一マシン上に複数のインスタンスをデプロイする際の問題を解決するために設計されたと言われており、単一マシン上の複数のノードが異なるポートを指定できるようにします（詳細については、ここでは説明しませんが、公式 wiki https://github.com/alibaba/otter/wiki/Node_Quickstart を参照してください）。

これを k8s に適応させる方法を見てみましょう。

ここでは処理にk8sのNodePortが使用されます。

NodePort サービスは、外部トラフィックをサービスに誘導する最も原始的な方法です。 NodePort は、その名前が示すように、すべてのノード (仮想マシン) で特定のポートを開き、このポートに送信されたトラフィックは対応するサービスに転送されます。下の図の通りです。

上記の構成では、IP1:3000 または IP2:3000 または IP3:3000 を使用してサービスにアクセスできます。

もちろん、特定の KVM の IP がバインドされないようにするために、前面に SLB サービスを掛けて、SLB の仮想 IP:PORT にアクセスしてアクセスします。

otter のデプロイメントでは、otter-manager に 2 セットの IP:PORT が必要であり、各ノードに 3 セットの IP:PORT が必要です。

Otter デプロイメントでは、各ノードが異なるポートを公開する必要があるため、otter ノードを追加するたびに、3 セットの IP:PORT を追加する必要があることに注意してください。

otter-node を例に、NodePort タイプのサービスの yml ファイルを見てみましょう。

親切は奉仕である
タイプはNodePortです
3 つのポートグループが構成されます。 port/targetport はどちらもアプリケーション公開ポートであり、nodePort は外部アクセスポートです。

6. まとめ

この変換後、k8s を使用して otter-manager と otter-node をデプロイし、ノードを迅速に拡張してマシンリソースを柔軟に使用できるようになります。

重要な問題とテクニックを確認しましょう。

Dockerfile を記述するときに、環境関連の依存関係を新しい基本イメージにパッケージ化して、後続のアプリケーションイメージの構築速度を向上させることができます。
Dockerfile では、ARG を使用してビルドプロセスでいくつかの変数を定義し、それらを置き換えることができます。
異なる環境の設定ファイルの場合、異なる環境 (k8s 名前空間) で異なる ConfigMap を設定し、volumeMounts を介して Deployment ファイルにマウントできます。
バックグラウンドプロセスの場合、ポッドが維持できるようにフォアグラウンドプロセスに変換する必要があります。
特定の環境変数については、デプロイメントの env を介して渡すことができます。

他のオープンソースプロジェクトで k8s を使用する必要がある場合は、これらの手法を使用できるはずです。

<<: 話し合う！ CDN とは何でしょうか?

>>: 怖い！真夜中に、このプログラムは仮想マシンから実行されなくなりました。