I was a late adopter of the Istio Operator but didn’t expect that it will be gone so soon. I didn’t want to go back to manage Istio using istioctl
or Helm templates so I was in a rush to pick a successor for Istio Operator. After reading a few articles, looks like I’m gonna go with the Sail Operator because:
- It’s backed by Redhat and has active development
- Good design of CRDs(istio, istio revision, istio CNI), in my opinion
Comparing to the old Istio Operator the installation of Sail Operator using ArgoCD is very similar. Here’s an example of an ArgoCD Application for Sail Operator’s installation:
apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: sail-operator namespace: argocd spec: destination: namespace: sail-operator server: https://kubernetes.default.svc project: default source: path: chart repoURL: https://github.com/istio-ecosystem/sail-operator targetRevision: 0.2.0 helm: values: | # https://github.com/istio-ecosystem/sail-operator/blob/release-0.2/chart/values.yaml name: sailoperator syncPolicy: automated: prune: true syncOptions: - CreateNamespace=true
Once this operator is up and running, an Istio custom resource is the only thing to install a new Istio control plane. It’s also nice to have an Istio Revision when it’s a canary upgrade.
--- apiVersion: sailoperator.io/v1alpha1 kind: Istio metadata: name: default spec: version: v1.23.3 namespace: istio-system updateStrategy: type: RevisionBased --- apiVersion: sailoperator.io/v1alpha1 kind: IstioRevisionTag metadata: name: default spec: targetRef: kind: Istio name: default
To verify if the new control plane is running:
$ k get pods -n istio-system NAME READY STATUS RESTARTS AGE istiod-default-v1-23-3-5d4f7b5c6-jpd85 1/1 Running 0 10m
It’s still the same old way to switch apps to the new revision. For more info on that please see my old post here.
As someone might have noticed, there’s no resource supported for Ingress Gateway. I was confused for a bit but then I realized something better is coming: Kubernetes Gateway API!
🙂