マイクロサービスベースのアプリケーション用のヘルムチャートの設計
現在、4つのマイクロサービス（a、b、c、d）で構成されるアプリケーションを構築しています。 KubernetesHelmをCI/CDパイプラインの一部にしたいと考えています。
チャートを定義する最善の方法について話し合っているところですが、コミュニティからのアドバイスがあるのではないかと考えていました。
現在のオプションは次のようです。
- マイクロサービスごとのチャート（つまり4つのチャート）
- 「アプリケーションフロー」ごとのグラフ（サービスaはbを呼び出し、サービスcはdを呼び出すため、合計2つのグラフ）
- 4つのマイクロサービスすべてをデプロイする単一のチャート
- helmの依存関係機能を活用する1.と3.の組み合わせ
それを呼び出す価値があるかもしれません：
- 現在、マイクロサービスを個別にデプロイする必要はありません。別のアプリケーションで利用できるようにします。
- マイクロサービスを個別にスケーリングする機能が必要になる可能性があります。つまり、4つのサービスすべてを単純に複製するだけではありません。
これらの要件は、チャートの設計に関連している可能性があると思われるため、ここで言及します。
遅い答えかもしれませんが、FWIW、それはマイクロサービスアプリを開発する方法と場所によって異なります。各マイクロサービスに独自のリポジトリとCIパイプラインがある場合は、グラフも分離するのが理にかなっています（サービスごとに1つ）。ただし、すべてのサービスが同じリポジトリにあり、単一のciパイプラインでデプロイされている場合は、単一のチャートの方が適しています。
4つのオプションすべてが機能します。また、アプリを個別のグラフでデプロイする場合でも、1つのグラフでデプロイする場合でも、最終的にすべてのサービスがデプロイされる限り、違いはありません。
サービスを個別にスケーリングする場合、1つの大きなグラフでサービスに個別のデプロイメントを使用する場合、values.yamlの各デプロイメントの入力値を使用して、サービスを個別にスケーリングできます。したがって、チャートを分割する必要はありません。 。
また、コメント内の画像変更の質問については、新しい画像タグを使用してインストールされたリリースのアップグレードのみが必要です。
ちなみに、CI/CDパイプラインのコードからヘルムチャートをデプロイ（および管理）するために helmsman を使用します。あなたに役立つかもしれません;）
同様の問題があり、最初はシンプルで機能的で、次に進化するという無駄のない方法を選択します。
私たちの主な要件は1つのインストーラーを持つことであるため、すべてのサービスを展開する単純なチャートから始めました。しかし、短期間で、サードパーティのチャートを使用するようにリファクタリングし、独自のリポジトリで独自のチャートを使用して、さまざまな展開戦略とサービスの独立した進化を処理することを知っています。