The Sail Operator manages the lifecycle of your Istio control plane. It provides custom resources for you to deploy and manage your control plane components.
This document aims to provide an overview of the project and some information for contributors. For information on how to use the operator, take a look at the User Documentation.
You manage your control plane through an Istio
resource.
apiVersion: sailoperator.io/v1alpha1
kind: Istio
metadata:
name: example
spec:
namespace: istio-system
version: v1.22.0
When you create an Istio
resource, the sail operator then creates an IstioRevision
that represents a control plane deployment.
apiVersion: sailoperator.io/v1alpha1
kind: IstioRevision
metadata:
name: example
...
spec:
namespace: istio-system
version: v1.22.0
status:
...
state: Healthy
You can customize your control plane installation through the Istio
resource using Istio's Helm
configuration values:
apiVersion: sailoperator.io/v1alpha1
kind: Istio
metadata:
name: example
spec:
version: v1.20.0
values:
global:
mtls:
enabled: true
trustDomainAliases:
- example.net
meshConfig:
trustDomain: example.com
trustDomainAliases:
- example.net
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:
# Create the istio-system namespace if it does not exist
kubectl create ns istio-system
kubectl apply -f chart/samples/istio-sample-kubernetes.yaml
Use the istio-sample-openshift.yaml
file on OpenShift:
# Create the istio-system namespace if it does not exist
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:
# Create the istio-cni namespace if it does not exist
kubectl create ns istio-cni
kubectl apply -f chart/samples/istiocni-sample.yaml
View your control plane:
kubectl get istio default
Undeploy the operator from the cluster:
make undeploy
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.
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.
make install
make run
NOTE: You can also run this in one step by running: make install run
Important: Any API change should be discussed in an SEP before being implemented.
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
The API reference documentation can be found in the docs
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
Please refer to the CONTRIBUTING-SAIL-PROJECT.md file for more information on how to contribute to the Sail Operator project. This file contains all the information you need to get started with contributing to the project.
SEP documents are used to propose and discuss non-trivial features or epics and any API changes. Please refer to the SEP1-enhancement-process.md file for more information on how to create a Sail Enhancement Proposal (SEP) for the Sail Operator project.
SEP documents are stored in the enhancements directory of the Sail Operator repository in Markdown format. If you want to create a SEP, be sure to check out the SEP template.
Please refer to the ISSUE-MANAGEMENT.md file for more information on how to report bugs and feature requests to the Sail Operator team.
If you found a bug in Istio, please refer to the Istio GitHub repository