問題タブ [statefulset]

私は kubernetes にデプロイされたアプリケーションを持っています。それは cassandra、go クライアント、および Java クライアント (およびその他のものですが、この議論には関係ありません) で構成されています。デプロイには helm を使用しました。カサンドラにはステートフル セットとヘッドレス サービスを使用しています。クラスター作成の連絡先としてヘッドレス サービス dns を使用するようにクライアントを構成しました。

すべてがうまく機能します。すべてのノードがダウンするか、その他の悪意のあるノードの組み合わせがダウンするまで、すべての cassandra ノードで kubectl delete を使用してすべてのポッドを連続して削除することで、それをシミュレートしています。

これを行うと、クライアントは Java で NoHostAvailableException をスローします。

cqlsh を使用して cassandra にクエリを実行できます。ノードは nodetool ステータスを使用して問題ないようです。新しい IP はすべてそこにあります。

2 つのクライアント ポッドで bash を実行すると、nslookup を使用して dns が適切であることを確認できますが、... netstat には cassandra への確立された接続が表示されません (ノードを停止する前に接続が存在します)。

クライアントを再起動すると、すべて正常に動作します。

私はたくさんグーグルで検索しました（つまり、たくさんのことを意味します）、私が見つけたもののほとんどは、接続が機能していないことに関連しており、最も関連性の高いものは非常に古いようです（2014、2016など）。

したがって、ダウンするノードは非常に基本的なものであり、cassandra クラスターがそれ自体を管理し、オンラインになると新しいノードを検出し、負荷を分散するなど、すべてが機能することを期待します。

すべての cassandra ノードを一度に 1 つずつゆっくりとダウンさせると、すべてが正常に機能します (負荷が適切に適切なノードに分散されていることは確認していませんが、少なくとも機能します)。

では、この動作が期待されるポイントはありますか? つまり、すべてを停止しました。最初のクラスタの最後のクラスタが停止される前に、何も稼働していませんでした。この動作は予期されたものですか?

私には、解決するのは簡単な問題のように思えます。何が欠けているか、間違っているかはわかりません。両方のクライアントが同じ症状を示していることに驚いています。私たちのステートフルセットとサービスで何かが起こっていないと思います

単一ノード クラスター (Docker デスクトップ Windows) でエラスティック クラスターをセットアップしようとしています。このため、次のようにPVを作成しました（動作中）

次に、構成は次のとおりです。

その結果、PVC が pv にバインドされた「ポッド」が 1 つだけになり、他のポッドは「0/1 ノードが使用可能です: 1 つのポッドにはバインドされていない即時の PersistentVolumeClaims があります」というエラー ループが発生します。kubectl get pv,pvcの結果は次のとおりです。

私が正しく理解できなかった場合、次の識別子を持つ 2 番目の persistantolumeclaim が必要です: es-data-esnode-1 ご協力いただきありがとうございます

ここでは、関連のない部分 (configmap、loadbalancer など) はスキップします。

私のデータベース (mongodbと) は、ファイルのようにmysql宣言されています。バックエンド フレームワークは. 書き込み操作 (編集または削除) を実行する関数を として定義すると、スレッドセーフになりますよね? ロックまたはミューテックスを使用する必要がありますか?StatefulSetyamldjangoasync

liveness プローブは、失敗したコンテナーの再起動をトリガーすることになっています。デフォルトのステートフル セットの展開とスケーリングの保証を尊重しますか。たとえば、1 つの同じステートフル セット内の複数のポッドで liveness プローブが同時に失敗した場合、K8S は一度に 1 つのコンテナーを再起動しようとしますか、それともすべて並行して再起動しようとしますか?