1

2 つのノードが実行されている kubernetes クラスターがあります。

マイクロサービスへの変更の取り込みを処理するために argocd を使用しています (現在は 1 つのマイクロサービスですが、それに追加する予定です)。

私のアプリケーションは Helm チャートとして構築されています。そのため、リポジトリが変更されたときにヘルム チャートを更新すると、argocd はヘルム チャートに変更があることを確認し、それらの変更をクラスターに適用します。

Istio をサービス メッシュとしてクラスターに追加しようとしています。Istio を使用すると、かなりの数の yaml 構成ファイルが存在します。

私の質問は、Helm チャートが変更されたときに argocd がどのように更新されるかのように、クラスターに Istio 構成を自動更新させるにはどうすればよいですか?

もちろん、Istio 構成ファイルを Helm チャートに配置することもできますが、それについての私の考えは次のとおりです。

  1. Istio 構成をアプリケーションに結び付けたいですか?
  2. #1 を実行したとしても、反対ではありませんが、私の 1 つのマイクロサービスだけでなく、クラスター全体に適用される多くの istio 構成があり、それらを私の特定の 1 つのマイクロサービスに結びつけることは間違いなく意味がありません。アルゴ CD アプリケーション。では、クラスター全体の istio ファイルの自動更新をどのように処理すればよいでしょうか?

別のオプションとして、argocd app of apps パターンを使用することもできますが、私が読んだ限りでは、まだ十分なサポートが得られていないようです。

4

3 に答える 3

2

  1. VirtualService私の意見では、などのIstio コンポーネントRequestAuthenticationがアプリケーションに「属している」場合は、それらをアプリケーションにパッケージ化する必要があります。開発モデルに適合する場合 (つまり、これらの問題を管理する別のチームがない場合) は、アプリにGatewaysとを追加することもできます。Certificatescrossplane のようなツールを使用すると、データベース プロビジョニングやその他のインフラストラクチャをアプリに含めることもできます。このように、アプリは自己完結型であり、構成が複数の場所に広がることはありません。

  2. 「インフラストラクチャ」チャートを作成できます。これは、独自の Argo アプリに含まれるか、アプリの前に展開される可能性があります (おそらく、Argo CD 自体が展開されるのと同じフェーズです)。

于 2021-09-12T07:53:56.397 に答える