Sail Operator makes Istio revisions explicit resources

Moving an injection tag to a new control plane does not upgrade a sidecar already running in a Pod. The old proxy still needs its old revision until the workload is replaced. Any operator automating Istio upgrades has to represent that interval, rather than treating the new control plane becoming ready as completion of the migration.

The April 3 Sail Operator announcement presents the 1.0.0 general availability release through that distinction. Sail manages Istio control planes with custom resources, including explicit revisions and stable revision tags. Its example keeps two control planes running while an existing workload moves between them.

I like the operator approach where it puts lifecycle state into Kubernetes objects that can be inspected. Istio already adds a distributed system to operate. Automation is useful when it describes the transition accurately, including the old components that still have clients.

Configuration follows the Helm value model

Sail is a community project launched by Red Hat and hosted in istio-ecosystem. The announcement explains that its APIs are built around Istio Helm chart values. Users supply configuration through the custom resource's values, rather than maintaining a separate translation for every Istio chart option.

The 1.0.0 repository documentation describes the basic reconciliation. An Istio resource causes the operator to create an IstioRevision representing a control plane deployment. The distinction lets the parent express desired management state while the revision identifies an actual deployed version.

Other resources divide responsibility further. IstioCNI manages the node agent, while ZTunnel manages the ambient ztunnel DaemonSet. IstioRevisionTag provides the stable alias that points to a revision. Components can therefore have separate configuration and upgrade lifecycles without being hidden inside one undifferentiated installation operation.

This does not imply that all supported components have equal maturity. The announcement explicitly calls ambient support alpha, including the ztunnel resource. The operator's 1.0 release should not be read as a general availability statement for every installation mode it can manage.

The supported Istio versions are also explicit. The announcement lists 1.24.3 and several earlier 1.24 and 1.23 patches for Sail 1.0.0. A general availability release of the operator does not establish support for every Istio release available on the same date.

A revision-based update preserves the old dependency

Sail supports InPlace and RevisionBased update strategies. The announcement's example uses RevisionBased and upgrades from Istio 1.24.2 to 1.24.3. Changing the parent's version creates a new revision while the old one remains available for existing proxies.

This is the relevant shape of the example's control plane resource. It assumes the Sail custom resources and operator have already been installed.

apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: default
spec:
  namespace: istio-system
  version: v1.24.2
  updateStrategy:
    type: RevisionBased
    inactiveRevisionDeletionGracePeriodSeconds: 30

A corresponding tag references the managed Istio resource. The operator can update that alias to the new active revision as the desired version changes.

apiVersion: sailoperator.io/v1
kind: IstioRevisionTag
metadata:
  name: default
spec:
  targetRef:
    kind: Istio
    name: default

The tag is indirection for clients that use it. It does not rewrite the executable inside an existing sidecar. In the announcement's example, proxy status still shows 1.24.2 after the control plane has been updated and the tag points to 1.24.3.

Restarting the sample workload creates a replacement Pod whose injected proxy uses the new revision. Only then does its proxy status show the new version. The example therefore demonstrates separate control plane and workload transitions instead of claiming a transparent replacement of every running proxy.

In-use state governs cleanup

The announcement explains why both revisions can be considered in use simultaneously. An existing sidecar remains connected to the old revision. The new revision is referenced by the stable tag, which is itself referenced by the sample namespace.

Before the sample namespace receives its injection label, the example reports the tag as NotReferencedByAnything. After labeling, the tag becomes in use even before the later upgrade. This is useful evidence about what the status means. It tracks a reference relationship and does not merely count running application containers. A reader can therefore interpret a newly created but unused tag differently from one that selects a revision for a namespace.

The release also supports several multicluster deployment models, including multi-primary and primary-remote. Those capabilities extend the management scope, but they do not remove the version and reference distinctions demonstrated by the single-cluster example.

These relationships are different forms of use. A connected proxy is a current client, while a tag reference preserves an intended injection target. Both matter when deciding whether a revision is disposable. Counting only currently connected proxies could remove a revision still selected for future workloads.

When a revision is no longer in use and is not active in the parent Istio resource, Sail deletes it after a grace period. The example sets that period to thirty seconds, which is also the announced default. Cleanup therefore depends on observed references as well as the desired version.

I consider this the most useful part of the operator model. The old control plane can remain visible for a reason the API explains. Its continued existence is evidence of an incomplete dependency transition, rather than unexplained debris from an installation command.

Migration needs resource equivalence as well as syntax conversion

The announcement identifies Sail as an option for users of the removed in-cluster Istio operator. It links documentation on resource equivalence and a converter for IstioOperator resources. Conversion helps carry configuration into the new model, but the separate lifecycle resources still need to be understood.

Addons remain outside Sail's management scope in this release. That boundary is relevant when comparing an existing installation with the set of objects Sail reconciles. Managing the control plane does not automatically transfer ownership of every dashboard or supporting component deployed alongside it.

The concrete benefit of the release is a maintained reconciliation model for Istio installation state, with revisions represented directly. A version update can create the new control plane, move the stable reference and preserve the old revision while workloads still depend on it. Completion is then observable through the proxy versions and reference state that determine when cleanup is appropriate.