Today, we don’t have any official examples or documentation for Istio, and in general, our recommendation for components of Istio’s size and complexity is to consider this requirement carefully. Istio is quite complex and can be difficult to add to an existing cluster without lots of preparation. If you ship an embedded cluster, or if you require your customers to bring a dedicated existing cluster for your application, some of these concerns can be mitigated.
Points of consideration:
- Installing Istio requires cluster-admin scope
- Istio might already be installed; what happens in your release if it encounters an existing Istio installation?
- Does your app just consume CRDs that are expected to exist? Or does your app require specific Istio configurations that may affect the whole cluster?
- If you encounter an Istio configuration that is not correct, should the app reconfigure the cluster, or fail?
Since kURL doesn’t manage Istio as a kURL addon, you will have to install it yourself or make it part of a Replicated app; if you want to make it part of a Replicated app, you would make all the manifests part of your release, or you would bundle it as a helm chart or chart dependency, or install it as an operator. If you need to take advantage of features in Istio, such as consuming a CRD as part of your app, Istio might need to be installed and working first. So you have an order of operations that you’ll need to consider. Replicated releases built with Helm charts can take advantage of helm hooks either as part of a KOTS release or with the Replicated SDK.