<p>I have a kubernetes cluster, with two nodes running.</p>
<p>I have argocd being used to handle pulling in any changes to my microservice (one microservice, currently, but I will be adding to that).</p>
<p>My application is being built as a helm chart. So when my repo changes, i update my helm chart, and then argocd sees that the helm chart has changes and applies those changes to the cluster.</p>
<p>I'm looking to add Istio as my service mesh to my cluster. With using Istio there will be quite a few yaml configuration files.</p>
<p>My question is, <strong>how can I have my cluster auto update my istio configurations like how argocd updates when my helm chart changes?</strong></p>
<p>Of course, I could put the istio configuration files in the helm chart, but my thoughts on that were:</p>
<ol>
<li>do i want my istio configurations tied to my application?</li>
<li>even if I did do #1, which I am not opposed to, there are many istio configurations that will apply cluster-wide, not just to my one microservice, and those definitely wouldn't make sense to tie into my specific one microservice, argo-cd application. <strong>So how would I handle auto updating cluster-wide istio files?</strong></li>
</ol>
<p>Another option could be to use the argocd app of apps pattern, but from what I've read that doesn't seem to have the greatest support yet.</p>

j will
<ol>
<li><p>In my opinion, you should package Istio components like <code>VirtualService</code>, <code>RequestAuthentication</code> etc. to the application if they &quot;belong&quot; to the application. You could even add <code>Gateways</code> and <code>Certificates</code> to the app if it fits your development model (i.e., no separate team which manages these concerns). Using a tool like crossplane, you could even include database provisioning or other infrastructure to your app. That way, the app is self-contained and configuration not spread at multiple places.</p>
</li>
<li><p>You could create an &quot;infrastructure&quot; chart. This is something which could be in an own Argo app or even deployed before your apps (maybe the same phase at which Argo CD itself is deployed)</p>
</li>
</ol>
