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 controlplane through an Istio resource.
apiVersion: operator.istio.io/v1alpha1
kind: Istio
metadata:
name: example
spec:
namespace: istio-system
version: v1.22.0When you create an Istio resource, the sail operator then creates an IstioRevision that represents a control plane deployment.
apiVersion: operator.istio.io/v1alpha1
kind: IstioRevision
metadata:
name: example
...
spec:
namespace: istio-system
version: v1.22.0
status:
...
state: HealthyYou can customize your controlplane installation through the Istio resource using Istio's Helm configuration values:
apiVersion: operator.istio.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.netYou’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 deployAlternatively, you can deploy the operator using OLM:
make deploy-olmMake 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.yamlUse 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.yamlOn OpenShift, you must also deploy the Istio CNI plugin by creating an instance of the IstioCNI resource:
kubectl apply -f chart/samples/istiocni-sample.yamlView your controlplane:
kubectl get istio defaultUndeploy the operator from the cluster:
make undeployThis 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-hookYou 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.
- 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 runNOTE: 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 manifestsNOTE: 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.integrationPlease 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.kindor
make test.e2e.ocpPlease 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.
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
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent