I have a kubernetes cluster, with two nodes running.
I have argocd being used to handle pulling in any changes to my microservice (one microservice, currently, but I will be adding to that).
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.
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.
My question is, how can I have my cluster auto update my istio configurations like how argocd updates when my helm chart changes?
Of course, I could put the istio configuration files in the helm chart, but my thoughts on that were: 1. do i want my istio configurations tied to my application? 2. 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. So how would I handle auto updating cluster-wide istio files?
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.
It depends on how to choose to install Istio. If you are installing it using Helm then I believe you can do something similar or otherwise you'll have to create some automation scripts to install using istioctl every-time you make changes to your configs.
1. "Do i want my istio configurations tied to my application?"
What do you mean by this? There is a Data Plane and a Control Plane. You have multiple ways to attach a sidecar-proxy to your app and also deploy any other CRDs like VirtualService, DestinationRule, PeerAuthentication Policy etc.
2. "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. So how would I handle auto updating cluster-wide istio files?"
Again, what do you mean by this? Whenever you update Istio Control Plane, the Data Plane proxies will sync automatically and will reload the new config using Envoy Hot-Restarts. It's another story if you bump up the version in which case you'll have to restart your application pods to pick up the new changes.
Did you look at using the Istio operator to deploy your service mesh ?
I already do this today with ArgoCD and the "app of apps" pattern. The Istio operator is one application and I created another one for the custom resource (Kind: IstioOperator) that deploys Istio's control plane (istiod and gateways).
If your service mesh configurations changes, it should happen through that custom resource.
In my opinion, you should package Istio components like VirtualService, RequestAuthentication etc. to the application if they "belong" to the application. You could even add Gateways and Certificates 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.
You could create an "infrastructure" 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)