SKE Operator

The SKE Operator provides full lifecycle support for Syntasso Kratix Enterprise (SKE) and is the recommended approach for installing and managing your SKE installation.

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

info

While SKE is can be installed directly via the released SKE distribution manifests, we highly recommend that you use the SKE Operator.

Using the Operator will reduce the workload of maintaining SKE, and all future operational features will only be available via the Operator.

Features

The SKE Operator will:

Install a Kratix instance into your cluster, including dependencies
Prevent drift of Kratix resources by continuously reconciling them against the declared SKE distribution
Validate SKE is in a healthy state before upgrading with pre-upgrade checks
Roll out an upgrade to the next minor version at the latest patch
Provide information about the status of the upgrade

The Kratix CRD

The Kratix CRD is the resource definition corresponding to a Kratix installation. This resource is managed by the SKE Operator.

  apiVersion: platform.syntasso.io/v1alpha1
  kind: Kratix
  metadata:
    name: my-kratix
  spec:
    version: vX.Y.Z # The desired version of SKE; set to "latest" to always use the latest
    featureFlags:
      dryRun: false # preview feature, see Kratix Config for details
    tlsConfig:
      certManager:
        disabled: false # Set to true to disable cert-manager integration
        issuerRef: # Optional: reference a custom cert-manager issuer
          kind: ClusterIssuer # or Issuer
          name: my-issuer
      certSecretName: my-tls-secret # Required if cert-manager is disabled
      metricsServerCertSecretName: my-metrics-secret # Required if cert-manager is disabled
      platformManagerCertSecretName: my-platform-manager-secret # Required if cert-manager is disabled and the SKE version includes the SKE Platform Manager
    deploymentConfig: # Kratix
      replicas: 2 # Number of Kratix pods; defaults to 1
      topologySpreadConstraints: # Standard Kubernetes topology spread constraints
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule
          nodeTaintsPolicy: Honor
          matchLabelKeys:
            - pod-template-hash
          labelSelector:
            matchLabels:
              app.kubernetes.io/component: kratix-manager
      resources:
        limits:
          memory: 500Mi
          cpu: 300m
        requests:
          memory: 500Mi
          cpu: 300m
      nodeSelector: # Constrain scheduling to nodes matching these labels
        kubernetes.io/os: linux
      affinity: # Standard Kubernetes affinity rules
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: kubernetes.io/arch
                    operator: In
                    values:
                      - amd64
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - my-app
              topologyKey: kubernetes.io/hostname
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - my-app
                topologyKey: kubernetes.io/hostname
      tolerations: # Allow scheduling on tainted nodes
        - key: example-key
          operator: Exists
          effect: NoSchedule
      volumes: # Additional volumes to mount into the deployment
        - name: my-volume
          configMap:
            name: my-configmap
      volumeMounts: # Additional volume mounts for the manager container
        - name: my-volume
          mountPath: /etc/config
    platformManagerDeploymentConfig: # SKE Platform Manager; takes the same fields as deploymentConfig
      replicas: 2

Deployment config fields

spec.deploymentConfig configures the Kratix Deployment. spec.platformManagerDeploymentConfig configures the SKE Platform Manager Deployment. Both take the same fields:

Field	Description
`replicas`	Number of pods. Defaults to 1, and must be at least 1. See Run SKE with more than one replica.
`topologySpreadConstraints`	Standard Kubernetes topology spread constraints
`resources`	CPU and memory requests and limits for the manager container.
`nodeSelector`	Only schedule the pods on nodes with these labels.
`affinity`	Standard Kubernetes affinity rules.
`tolerations`	Let the pods run on nodes with matching taints.
`volumes`	Extra volumes to add to the pods.
`volumeMounts`	Extra volume mounts for the manager container.

When a field is not set, the value in the SKE distribution is kept. The SKE Operator owns these Deployments, so changes made to them directly, such as kubectl scale, are set back on the next reconcile.

The Kratix resource is the owner of all resources installed as part of the SKE distribution, and ensures that their state always matches the definition in the distribution manifest.

The SKEIntegration CRD

Where the Kratix CRD manages SKE itself, SKEIntegration (platform.syntasso.io/v1alpha1) is the same lifecycle-management pattern applied to an optional integration, such as Backstage, Cortex, or the Portal Controller. Applying one installs and upgrades that integration's controller from a single, declarative resource.

apiVersion: platform.syntasso.io/v1alpha1
kind: SKEIntegration
metadata:
  name: my-integration
spec:
  type: portal-controller # backstage | cortex | portal-controller
  version: v1.2.0 # or "latest", to resolve the newest available release
  deploymentConfig:
    resources:
      limits:
        memory: "256Mi"
        cpu: "100m"
      requests:
        memory: "256Mi"
        cpu: "100m"

spec.type selects which integration this resource installs. Only one SKEIntegration of a given type may exist in a cluster at a time, a validating webhook rejects a second.
spec.version is the desired version of that integration's controller image.
spec.deploymentConfig tunes the installed controller's resource requests/limits
The rest of spec is type-specific, see Backstage, Cortex, or Portal Controller for the fields each type adds.

Status

Every SKEIntegration reports install health on .status.conditions, condition type IntegrationDeploymentReady:

Status	Reason	When
`False`	`NotAllReplicasAvailable`	Set on the first reconcile, and again whenever a previously-ready Deployment stops being available.
`False`	`RegistrySecretNotFound`	The image registry pull Secret or the release storage Secret has no matching Secret in `kratix-platform-system`.
`False`	`CredentialSecretNotFound`	Portal Controller only. A Secret named in `spec.portals[].secretRef` has no matching Secret in `kratix-platform-system`. The operator checks this before it fetches the release, so nothing is installed until the Secret exists.
`True`	`AllReplicasAvailable`	The Deployment is available at the current generation and the installed version matches the resolved version.

.status.ready mirrors the condition. .status.lastAppliedVersion records the resolved version once ready, so later reconciles can detect a version bump.

Features​

The Kratix CRD​

Deployment config fields​

The SKEIntegration CRD​

Status​

Features

The Kratix CRD

Deployment config fields

The SKEIntegration CRD

Status