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-kubernetes.yaml
file on vanilla Kubernetes:
# Namespace must exist prior to creating istio resource
kubectl get ns istio-system || kubectl create ns istio-system
kubectl apply -f chart/samples/istio-sample-kubernetes.yaml
Use the istio-sample-openshift.yaml
file on OpenShift:
# Namespace must exist prior to creating istio resource
kubectl get ns istio-system || kubectl create ns istio-system
kubectl apply -f chart/samples/istio-sample-openshift.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 use GitHub to track all of our bugs and feature requests. Please create a GitHub issue for any new bug or feature request.
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.
- Install the CRDs into the cluster:
make install
- 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 and integration tests should use the ginkgo-style BDD testing method, an example can be found in tests/integration/api/istio_test.go
for the test code and suite setup in tests/integration/api/suite_test.go
. Unit tests should use standard golang xUnit-style tests (see pkg/kube/finalizers_test.go
for an example).
Please check the specific instructions for the integration tests in the integration directory.
To run the integration tests, you can use the following command:
make test.integration
Please check the specific instructions for the end-to-end tests in the e2e directory.
To run the end-to-end tests, you can use the following command:
make test.e2e.kind
or
make test.e2e.ocp