Skip to content

Understanding ServiceTemplates#

ServiceTemplate objects are meant to let Mirantis k0rdent Enterprise know where to find a Helm chart with instructions for installing an application. In many cases, these charts will be in a private repository. For example, consider this template for installing Nginx Ingress:

apiVersion: k0rdent.mirantis.com/v1beta1
kind: ServiceTemplate
metadata:
  name: project-ingress-nginx-4.11.0
  namespace: tenant42
spec:
  helm:
    chartSpec:
      chart: demo-ingress-nginx
      version: 4.11.0
      interval: 10m0s
      sourceRef:
        kind: HelmRepository
        name: k0rdent-demos
---
apiVersion: k0rdent.mirantis.com/v1beta1
kind: ServiceTemplateChain
metadata:
  name: project-ingress-nginx-4.11.0
  namespace: tenant42
spec:
  supportedTemplates:
    - name: project-ingress-nginx-4.11.0
    - name: project-ingress-nginx-4.10.0
      availableUpgrades:
        - name: project-ingress-nginx-4.11.0

Here you see a template called project-ingress-nginx-4.11.0 that is meant to be deployed in the tenant42 namespace. The .spec.helm.chartSpec specifies the name of the Helm chart and where to find it, as well as the version and other important information. The ServiceTemplateChain shows that this template is also an upgrade path from version 4.10.0.

If you wanted to deploy this as an application, you would first go ahead and add the template to the cluster in which you were working, so if you were to save this YAML to a file called project-ingress.yaml you could run this command on the management cluster:

kubectl apply -f project-ingress.yaml -n tenant42

Simply put, ServiceTemplate objects are a representation of where Mirantis k0rdent Enterprise can find a resource or set of resources to be deployed as a complete application.

ServiceTemplate supports the following types as a source:

Helm-based ServiceTemplate#

A Helm-based ServiceTemplate can be created in two ways:

  1. By defining a Helm chart right in the template object, as in:

    apiVersion: k0rdent.mirantis.com/v1beta1
kind: ServiceTemplate
metadata:
  name: foo
  namespace: bar
spec:
  helm:
    chartSpec:
      chart: ingress-nginx
      version: 4.11.0
      interval: 10m
      sourceRef:
        kind: HelmRepository
        name: foo-repository

    In this case, the corresponding HelmChart object will be created by the controller.

  2. By referring to an existing Helm chart, as in:

    apiVersion: k0rdent.mirantis.com/v1beta1
kind: ServiceTemplate
metadata:
  name: foo
  namespace: bar
spec:
  helm:
    chartRef:
      kind: HelmChart
      name: foo-chart

Kustomize-based ServiceTemplate#

A Kustomize-based ServiceTemplate can be created with either local or remote sources. You can create the ServiceTemplate using an existing flux source object, such as a GitRepository, Bucket or OCIRepository, or by using an existing ConfigMap or Secret:

apiVersion: k0rdent.mirantis.com/v1beta1
kind: ServiceTemplate
metadata:
  name: foo
  namespace: bar
spec:
  kustomize:
    localSourceRef:
      kind: Bucket  # also can be GitRepository, OCIRepository, ConfigMap or Secret
      name: foo-bar
    deploymentType: Remote
    path: "./base"

The ConfigMap or Secret, in this case, must embed the tar-gzipped archive containing the kustomization files. Assuming the archive already exists, you can do this by executing the following command:

kubectl create configmap foo-bar --from-file=/path/to/kustomization/archive.tar.gz

Ypu can also create a ServiceTemplate by defining a remote source right in the template object, as in:

apiVersion: k0rdent.mirantis.com/v1beta1
kind: ServiceTemplate
metadata:
  name: kustomization-app
  namespace: kcm-system
spec:
  kustomize:
    remoteSourceSpec:
      oci:
        url: oci://ghcr.io/org/project-x
        reference:
          tag: latest
        interval: 10m
    deploymentType: Remote
    path: "./overlays"

Note that .spec.kustomize.remoteSourceSpec has mutually exclusive fields, .git, .bucket and .oci, with inline GitRepositorySpec, BucketSpec and OCIRepositorySpec versions respectively.

Raw-resources-based ServiceTemplate#

Similar to the kustomize-based ServiceTemplate, you can create a raw-resources-based ServiceTemplate with either a local or remote source. Using the remote source is no different from the kustomize-based ServiceTemplate, but using local source differs slightly if you use a ConfigMap or Secret object as a source:

  • spec.resources.localSourceRef.path will be ignored.
  • the ConfigMap or Secret must contain inlined resources' definitions, instead of embedding a tar-gzipped archive.