sail-operator

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

Deploying the operator

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.

Deploying the Istio Control Plane

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

Deploying the Istio CNI plugin

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

Undeploying the operator

Undeploy the operator from the cluster:

make undeploy

Contributing

We use GitHub to track all of our bugs and feature requests. Please create a GitHub issue for any new bug or feature request.

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.

Repository Setup

We're using gitleaks to scan the repository for secrets. After cloning, please enable the pre-commit hook by running make git-hook. This will make sure that gitleaks scans your contributions before you push them to GitHub, avoiding any potential secret leaks.

make git-hook

You will also need to sign off your commits to this repository. This can be done by adding the -s flag to your git commit command. If you want to automate that for this repository, take a look at .git/hooks/prepare-commit-msg.sample, it contains an example to do just that.

Test It Out

1. Install the CRDs into the cluster:

make install

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

Integration Tests

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

End-to-End Tests

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