Advanced installation

The SKE Operator

The recommended approach to install and manage your SKE installation is to use the SKE Operator. As well as full lifecycle support, it provides a simpler interface to customise and secure your SKE instance.

The operator has its own releases and it manages instances of SKE as defined by a Kratix Custom Resource.

To install the SKE Operator and instantiate a new SKE instance, we provide several mechanisms:

• With the SKE Operator Helm Chart, you can deploy the Operator and SKE with all the customisations you need, including air-gapped environments.
• With the SKE Operator manifest and the Kratix CRD, you have direct access to the files being deployed, and can customise it manually.

The sections below cover each one of these methods of installation.

Via the Helm Chart

info

Syntasso Kratix Enterprise requires cert-manager to be installed on the cluster unless you are configuring custom certificates. Please refer to its documentation for installation instructions.

To install SKE operator using the Helm chart, start by adding the Syntasso Helm repository:

helm repo add syntasso https://syntasso.github.io/helm-charts
helm repo update

Configure values

Helm can accept values via the values file. Refer to the examples below for common configuration options. Any configuration should be placed in a values.yaml file that is then passed in to the helm install command.

tip

You can see all available configuration in the helm chart repository.

Suggested starter values.yaml file

skeLicense: your-token-here
skeDeployment:
  version: latest

Example air-gapped values.yaml file

To use this example, please set all values to your specific environment

  skeLicense: your-token-here
  skeDeployment:
    version: latest
  imageRegistry:
    host: "ghcr.io"
    imagePullSecret: "my-secret"
    skeOperatorImage:
      name: "syntasso/ske-operator"
    skePlatformImage:
      name: "syntasso/ske-platform"
  releaseStorage:
    path: "ske"
    git:
      branch: main
      repo: https://github.com/org/repo
      secret:
        name: git-creds # must be in the same namespace as the operator; must contain keys: username, password
        values: # optional: provide username/password here and the chart creates the Secret for you;
                # omit values and pre-create the Secret yourself to avoid storing credentials in Helm values
          username: "my-username"
          password: "my-password"

The SKE license

To run SKE, you need a license. You can get one by requesting a free trial. SKE images are hosted in a private registry, and your cluster needs image pull credentials to access them. By default, the license token is used as the credential for the Syntasso registry, but you can also pre-create your own pull secret if you prefer not to inline credentials or if you are pulling from a self-hosted registry.

Option 1: Provide the license token directly

Set skeLicense in your values file and the chart will create the image pull secret automatically:

skeLicense: LICENSE # provided to you by Syntasso

Option 2: Pre-create the image pull secret

To avoid inlining credentials in your values file, omit skeLicense and instead pre-create a kubernetes.io/dockerconfigjson Secret manually. The credentials will depend on the registry you are pulling from. This could still be your SKE license token (for the Syntasso registry), or your own credentials if you are using a self-hosted registry.

For example, when pulling from the Syntasso registry:

kubectl create secret docker-registry syntasso-registry \
  --namespace=kratix-platform-system \
  --docker-server=ghcr.io \
  --docker-username=syntasso-pkg \
  --docker-password=<YOUR_LICENSE_TOKEN>

Then reference the secret in your values file. The chart will skip creating the pull secret and use the pre-existing one instead:

imageRegistry:
  imagePullSecret: "syntasso-registry"

SKE version

The Helm chart version determines what version of the SKE Operator is installed. To configure the version of SKE that the operator will install, you can use the skeDeployment.version field as shown below.

skeDeployment:
  version: v0.99.0 # select your desired version

Custom Certs

By default, the SKE Operator and the SKE instance it deploys use cert-manager to manage TLS certificates for their webhooks and metrics server. This default setup requires no additional configuration. However, if you prefer not to use cert-manager, you can disable it and manually provide your own TLS certificates.

Note that for the SKE Deployment (the instance the operator deploys), both webhook and metrics server certificates are required. The SKE Operator itself only requires webhook certificates.

To disable cert-manager and supply your custom certificates, you have two options:

Option 1: Provide certificate data inline

global:
  skeOperator:
    tlsConfig:
      certManager:
        disabled: true
      webhookCACert: |
        -----BEGIN CERTIFICATE-----
        ...
      webhookTLSKey: |
        -----BEGIN PRIVATE KEY-----
        ...
      webhookTLSCert: |
        -----BEGIN CERTIFICATE-----
        ...

skeDeployment:
  enabled: true
  tlsConfig:
    certManager:
      disabled: true
    webhookCACert: |
      -----BEGIN CERTIFICATE-----
      ...
    webhookTLSKey: |
      -----BEGIN PRIVATE KEY-----
      ...
    webhookTLSCert: |
      -----BEGIN CERTIFICATE-----
      ...
    metricsServerCACert: |
      -----BEGIN CERTIFICATE-----
      ...
    metricsServerTLSKey: |
      -----BEGIN PRIVATE KEY-----
      ...
    metricsServerTLSCert: |
      -----BEGIN CERTIFICATE-----
      ...

Option 2: Reference pre-existing Secrets

To avoid inlining certificate data in your values file, pre-create Kubernetes Secrets containing the TLS data and reference them by name. The referenced Secrets must contain the keys: ca.crt, tls.crt, and tls.key.

For the SKE Deployment, both webhookTLSSecretRef and metricsServerTLSSecretRef are required:

skeDeployment:
  enabled: true
  tlsConfig:
    certManager:
      disabled: true
    webhookTLSSecretRef:
      name: "my-webhook-tls-secret"
    metricsServerTLSSecretRef:
      name: "my-metrics-server-tls-secret"

The chart will skip creating the TLS Secrets and use the referenced Secrets instead.

Both the SKE Operator and SKE Deployment require valid TLS certificates for their webhook servers to securely communicate with the Kubernetes API. Below are the DNS names that must be included in the TLS certificates for each component.

The TLS certificate for the SKE Operator's webhook server must cover the following DNS names:

• ske-operator-webhook-service.kratix-platform-system.svc
• ske-operator-webhook-service.kratix-platform-system.svc.cluster.local

The TLS certificate for the SKE Deployment's webhook server must cover the following DNS names:

• kratix-platform-webhook-service.kratix-platform-system.svc
• kratix-platform-webhook-service.kratix-platform-system.svc.cluster.local

The TLS certificate for the SKE Deployment's metrics server must cover the following DNS names:

• kratix-platform-controller-manager-metrics-service.kratix-platform-system.svc
• kratix-platform-controller-manager-metrics-service.kratix-platform-system.svc.cluster.local

Air-gapped mirrors

To run SKE in air-gapped environments, you first need to mirror the Image Registry and the Release Storage, as described in the air-gapped setup instructions.

You can then provide the details of the mirrored Image Registry and Release Storage via the imageRegistry and releaseStorage fields in your helm values file.

Image Registry

imageRegistry:
  host: "ghcr.io"
  imagePullSecret: "my-secret"
  skeOperatorImage:
    name: "syntasso/ske-operator"
  skePlatformImage:
    name: "syntasso/ske-platform"

Release Storage

Mirroring from Bucket

releaseStorage:
  path: "ske" # the path within the bucket that contains the SKE Versions
  bucket:
    name: "syntasso-enterprise-releases"
    region: "eu-west-2"
      secret:
        name: "my-secret" # must be in the same namespace as the operator; must contain keys: accessKeyID, secretAccessKey
        values: # optional: provide accessKeyID/secretAccessKey here and the chart creates the Secret for you;
                # omit values and pre-create the Secret yourself to avoid storing credentials in Helm values
          accessKeyID: "my-access"
          secretAccessKey: "my-secret"

Mirroring from Git Repo

releaseStorage:
  path: "ske" # the path within the Git Repo that contains the SKE Versions
  git:
    branch: main
    repo: https://github.com/org/repo
    secret:
      name: git-creds # must be in the same namespace as the operator; must contain keys: username, password
      values: # optional: provide username/password here and the chart creates the Secret for you;
              # omit values and pre-create the Secret yourself to avoid storing credentials in Helm values
        username: "my-username"
        password: "my-password"

Install the Operator

Next, install the SKE Operator:

helm install ske-operator syntasso/ske-operator \
  --namespace kratix-platform-system \
  --create-namespace \
  --wait \
  --values values.yaml # This is optional. Only use if you are configuring custom values.

Verify the installation

To verify that Syntasso Kratix Enterprise has been installed successfully, run the following command:

kubectl get deployments.apps --namespace kratix-platform-system

You should see the following output:

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
kratix-platform-controller-manager   1/1     1            1           1h
ske-operator-controller-manager      1/1     1            1           1h

You can now proceed with the configuration of Kratix (i.e. registering destinations or installing promises). For that, refer to the Open-Source Kratix documentation.

Via the Manifests

Create the namespace

To install the SKE Operator via the distribution manifest, you will first need to create the kratix-platform-system namespace. This is where the SKE operator will be installed:

kubectl create namespace kratix-platform-system

Create the Operator configuration

If you are not running SKE in an air-gapped environment, all you need to do is create a secret with your license token:

kubectl create secret docker-registry syntasso-registry \
  --namespace=kratix-platform-system \
  --docker-server=ghcr.io \
  --docker-username=syntasso-pkg \
  --docker-password=<YOUR TOKEN>

For air-gapped environments, you will need to create a ConfigMap with the following structure:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: ske-operator
  namespace: kratix-platform-system
data:
  config: |
    releaseStorage:
      path: # path within the git repository or bucket to look for releases
      # one of: git or bucket
      git:
        secretName: # the name of the secret containing the git credentials
        repo: # the git repository to look for releases
        branch: # the branch to look for releases
      bucket:
        name: # the name of the bucket to look for releases
        endpoint: # the endpoint of the bucket
        region: # the region of the bucket
        secretName: # optional: the name of the secret containing the credentials to access the bucket
    imageRegistry:
      host: # the host of the image registry
      pullSecret: # optional: the name of the secret containing the image registry credentials
      platformImage: # the image of the platform

Refer to the air-gapped installations section for more information on how to configure the underlying storage and image registry, as well as the expected structure of the referenced secrets.

Deploy the SKE Operator

With all of the prerequisites in place, the platform is now ready to deploy the SKE Operator. Locate the desired release of the SKE-Operator and apply its manifest with kubectl:

kubectl apply -f http://s3.eu-west-2.amazonaws.com/syntasso-enterprise-releases/ske-operator/<VERSION>/ske-operator-distribution.yaml

Applying the manifest will install the SKE Operator in the kratix-platform-system namespace, together with a Kratix Custom Resource Definition (CRD) that allows you to manage the Syntasso Kratix Enterprise installation.

Deploy SKE

The SKE Operator includes a custom resource definition (CRD) for managing SKE. Only one instance of SKE can be created by the SKE Operator in a given cluster.

To deploy SKE, create a file named ske-instance.yaml with the following contents:

apiVersion: platform.syntasso.io/v1alpha1
kind: Kratix
metadata:
  name: my-kratix
spec:
  version: v0.99.0 # The desired version of SKE

Apply the file with kubectl:

kubectl apply --filename ske-instance.yaml

The operator will then install SKE and its necessary configurations. For more information about the Kratix CRD, see the SKE Operator documentation.

Verify the installation

To verify that Syntasso Kratix Enterprise has been installed successfully, run the following command:

kubectl get deployments.apps --namespace kratix-platform-system

You should see the following output:

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
kratix-platform-controller-manager   1/1     1            1           1h
ske-operator-controller-manager      1/1     1            1           1h

You can now proceed with the configuration of Kratix (i.e. registering destinations or installing promises). For that, refer to the Open-Source Kratix documentation.

Post Installation

After installing SKE, you must ensure that every namespace where resource requests will be made has access to the SKE license token. When SKE triggers a Workflow for a Promise, the Workflow pulls a SKE image to run as a container in the pod. The secret must therefore be present in the namespace so the image can be pulled successfully. For example, to ensure resource requests can be made successfully in the default namespace you would run the following:

kubectl create secret docker-registry syntasso-registry \
  --namespace=default \
  --docker-server=ghcr.io \
  --docker-username=syntasso-pkg \
  --docker-password=<YOUR TOKEN>