Istio operator plans for 1.2

1

Hi folks,
There have been a lot of questions about how operator fits in with installer and the upcoming Istio 1.2 release. Let me clarify:

  • istio-installer will be the fully-tested, preferred method for production installation.
  • we plan to release a preview version of the operator at the same time.
  • operator will use the same charts and general approach to upgrades (co-resident versions) as installer.
  • both installer and operator will use kustomize style overlays for specializing the rendered charts, but operator will not use kustomize itself.

The differences between the two will be:

  • operator uses a CRD and can function either as an installer but also to dynamically update the install based on the CRD (“tiller like” mode)
  • operator has a new API in addition to values.yaml. This API replaces the k8s resource definitions in values.yaml with a more direct passthrough to k8s approach.
  • operator will do validation of values.yaml and the new API.
  • we’re still discussing what else, if anything, we might want to expose through the operator API rather than passing through to values.yaml
  • overlay spec is going to a bit different to kustomize. kustomize is a tool not a library, so we’re creating our own overlay mechanism that fits better with using a CRD for the operator.

Martin

1 Like
2

I think we should continue to evaluate using kustomize itself as part of operator - if we need changes in kustomize ( like making it possible to embed it in another tool) we can file feature requests.

We intend to support direct use of kustomize and (kubect apply -k) in the new installer - and it would be good if operator could just ‘embrace and extend’ this, to minimize user change.

If there are strong reasons we can’t use kustomize files and patches in their native format - it should also be documented and provided as feedback to kustomize.

Re. differences - I think both installer and operator should use the same base mesh config (==CRD), and evolve at the same time. When operator is used as an installer - it should be a super-set of the
current installer, i.e. automate various operations but still be backward compatible. This will also minimize user disruption. The new APIs - after they are reviewed and approved - can and should
be used by future installer versions, again to keep everything aligned.

I assume galley should do validation for values.yaml ( there was a feature request to allow ‘offline validation’ integrated in istioctl).

Re. overlay spec - I hope we can sync up with kustomize community and find some middle ground,
and not invent our own. Either way - I don’t think we have a final, approved decision on diverging -
we may have to, but ideally we shouldn’t.