This project is an operator that can be used to manage the installation of an Istio control plane.

You’ll need a Kubernetes cluster to run against. You can use KIND to get a local cluster for testing, or run against a remote cluster. Note: Your controller will automatically use the current context in your kubeconfig file (i.e. whatever cluster kubectl cluster-info shows).

Deploy the operator to the cluster:

make deploy

Alternatively, you can deploy the operator using OLM:

make deploy-olm

Make sure that the HUB and TAG environment variables point to your container image repository and that the repository is publicly accessible.

Create an instance of the Istio resource to install the Istio Control Plane. Use the istio-sample-openshift.yaml file on OpenShift:

kubectl apply -f chart/samples/istio-sample-openshift.yaml

Use the istio-sample-kubernetes.yaml file on vanilla Kubernetes:

kubectl apply -f chart/samples/istio-sample-kubernetes.yaml

On OpenShift, you must also deploy the Istio CNI plugin by creating an instance of the IstioCNI resource:

kubectl apply -f chart/samples/istiocni-sample.yaml

Undeploy the operator from the cluster:

make undeploy

We welcome community contributions! For features or bugfixes, please first create an issue in our OSSM Jira project and make sure to prefix your commit message with the issue ID.

This project aims to follow the Kubernetes Operator pattern.

It uses Controllers, which provide a reconcile function responsible for synchronizing resources until the desired state is reached on the cluster.

1. Install the CRDs into the cluster:

make install

2. Run your controller (this will run in the foreground, so switch to a new terminal if you want to leave it running):

make run

NOTE: You can also run this in one step by running: make install run

If you are editing the API definitions, generate the manifests such as CRs or CRDs using:

make manifests

NOTE: Run make --help for more information on all potential make targets

More information can be found via the Kubebuilder Documentation

Please try to keep business logic in separate packages that can be independently tested wherever possible, especially if you can avoid the usage of Kubernetes clients. It greatly simplifies testing if we don't need to use envtest everywhere.

E2E tests should use the ginkgo-style BDD testing method, an example can be found in controllers/istio_controller_test.go for the test code and suite setup in controllers/suite_test.go. All other tests should use standard golang xUnit-style tests (see pkg/kube/finalizers_test.go for an example).

Must be logged into OCP using 'oc' client

make test.integration.ocp