API Review 3/22: Operator API

Hi folks,

Just a reminder that we will be discussing the Operator API at this Friday’s API review meeting. Here is the design document, for your reviewing pleasure before the meeting:


Some more details can be found in the API Review meeting schedule doc:

1 Like

What about the banzai operator?

We’ve joined forces with Banzaicloud to all work on the official Istio operator. Also with Rob from Red Hat, as he’s been working on one too: https://github.com/rcernich/istio-operator

So in a few weeks there’s will be a unified operator ? I am currently using the helm chart but I would like to change.

We’re targeting 1.2 timeframe but may make some alpha version available sooner as a preview to get some early feedback.

Thanks everyone for the review feedback. I’ve taken another pass and put the new protos here for easier commenting:
Changes based on the review:

  • proto2 -> proto3 (will add wrappers for unset checking later)
  • Moved anything “feature” related into top level config messages (TrafficManagementConfig, SecurityConfig etc). Anything that’s necessarily component specific, like k8s settings, env vars, flags etc. is now under messages with Component name e.g. PilotComponentConfig, CitadelComponentConfig. These are still grouped under the feature messages based on the feature they belong to.
  • Moved out tracer and policy/telemetry adapter configs to separate packages and referencing these as proto.Any in the main CRD.
    I still don’t have a good idea what to call top level CRD. It seems like it should have Istio in it because it bootstraps Istio into the cluster. Installer seems controversial because it also manages upgrade.
    I propose IstioOperator, hopefully most folks don’t find this confusing with human operator.
    Otherwise, open to suggestions here.

We will do a follow-up review on 4/4, during Config WG meeting.