❗ Issues for this repository are disabled
Issues for OpenShift Service Mesh are tracked in Red Hat Jira. Please head to the OSSM Jira project in order to browse or open an issue

Maistra Istio Operator

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

Getting Started

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).

Running on the cluster

1. 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.

2. Create an instance of the Istio resource to install the Istio Control Plane:

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

or

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

Undeploy controller

UnDeploy the controller from the cluster:

make undeploy

Contributing

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.

How it works

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.

Test It Out

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

Modifying the API definitions

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

Writing Tests

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).

OCP Integration Tests

Must be logged into OCP using 'oc' client

make test.integration.ocp