The install.sh is provided within the Operator package and can be used to easily launch a default 3-node cluster, with 2 connectors.

Usage:

If no options are specified, then the script will prompt for the registry URL and operator version, then continue to ensure prerequisites are in place such as cert-manager and kubectl.

The script will then go on to issue the helm commands to launch the cluster.

The example below shows the output of running the install.sh script with no options supplied:

shell> cd /opt/continuent/software/tungsten-operator-8.0.0-10
shell> ./install.sh

Please input the container registry URL where Tungsten operator image is stored (without a tag) [tungsten-operator]:
<Enter your registry URL here>

Please enter Tungsten operator version tag [8.0.0-10]:

Current Kubernetes context is set to: your-kubernetes-context
Press enter to continue or any other key to abort
Ensuring Cert-Manager is installed...
Installing Tungsten Operator Helm chart...
NAME: tungsten-operator
LAST DEPLOYED: Tue Feb 25 12:49:14 2025
NAMESPACE: tungsten-operator
STATUS: deployed
REVISION: 1
TEST SUITE: None
Waiting for operator to become ready...
deployment.apps/tungsten-operator condition met
Operator is ready!

Installation completed!

To create an example cluster, run:
kubectl apply -f examples/mysql-passwords.yaml && kubectl apply -f examples/tungsten_v1alpha1_tungstenmysqlcluster.yaml

If you do not wish to use the install.sh script, you can manually execute the helm commands to do perform the installation. These steps are shown below as examples:

shell> cd /opt/continuent/software/tungsten-operator-8.0.0-10
shell> helm install tungsten-operator charts/tungsten-operator-0.1.0.tgz

If you need to customize the registry of the image, this can be done by:

shell> helm install tungsten-operator --set image.repository=${REGISTRY}/tungsten-operator charts/tungsten-operator-0.1.0.tgz

It is recommended to install the operator in a separate namespace, for example:

shell> helm install tungsten-operator \
  --set image.repository=${REGISTRY}/tungsten-operator \
  --namespace=tungsten-operator \
  --create-namespace \
  charts/tungsten-operator-0.1.0.tgz

For a comprehensive list of configurable Helm values, you can extract the Helm chart and refer to the values.yaml file contained within it.

The first step is to build the yaml files, and to make this simple we provide a number of example files that can be used and adjusted to suit your requirements.

The files are located within the examples directory of the extracted operator package, for example:

shell> cd /opt/continuent/software/tungsten-operator-8.0.0-10/examples

The following table lists the available template files and what each one can be used for:

Depending on the use-case, you may choose to employ one or more of the sample YAML files, additionally you may wish to create one single YAML file that combines more than one of the above samples together. Whilst this is supported, it is not recommended as this may result in large files that may become dificult to manage.

An example of some of the use-cases that can be achieved using combine YAML files is shown below. This is not an exhaustive list of all possibilities, but are provided as examples of the kind of combinations you can leverage.

The operator, by default, generates the MySQL root password, along with the passwords for the replicator and application user during the creation of the cluster.

You have the option to provide custom passwords using a pre-existing Kubernetes secret during cluster creation, using the following example as a guide.

You can use the provided mysql-passwords.yaml file as a template. Either edit directly or make a copy to a directory of your choice. You can then edit it, changing the passwords to suit.

An example is shown below:

apiVersion: v1
kind: Secret
metadata:
  name: tungsten-passwords-sample-secret
type: Opaque
stringData:
  mysqlRootPassword: rootsecret
  applicationPassword: appsecret
  replicatorPassword: replicatorsecret
  restApiAdminPassword: apisecret

In the above example, apiVersion, kind and type should be left untouched. The passwords within the stringData block can be changed to suit, along with the name in the metadata block.

This name can be used if you have multiple clusters and different password yaml files with different passwords for each cluster. You could then change the name to help identify which cluster the passwords are associated with. The value you set here should then be used within the customPasswordSecret property in the cluster yaml file.

For more details on the cluster yaml files, see Section 3.2.2.3, “Configuring Custom Cluster YAML templates”

To then apply this configuration, issue:

shell> kubectl apply -f mysql-passwords.yaml

To configure the cluster, it is recommended to first select the example YAML file that matches the topology you wish the deploy, and then customize the content to match your needs.

A full list of all the sample files available is outlined in Section 3.2.2.1, “Working with the YAML files”

You can either edit the sample file directly or copy it and rename it to a different location. A number of options can be edited, and these are all explained below. Additionally, you can create your own if you wish but it is strongly recommended to take a sample file as the template to ensure you do not miss out any key entries.

Each YAML file has a number of key/value blocks depending on the complexity of the chosen deployment topology. The following is a complete example of the tungsten_v1alpha1_mysqlcluster.yaml, the sections that follow explain each individual component of the file and how it can be changed to suit your needs.

apiVersion: tungsten.continuent.com/v1alpha1
kind: MySQLCluster
metadata:
  labels:
    app.kubernetes.io/name: mysqlcluster
    app.kubernetes.io/instance: sample
    app.kubernetes.io/part-of: tungsten-operator
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: tungsten-operator
  name: sample
spec:
  configuration:
    customPasswordSecret: tungsten-passwords-sample-secret
    enablePodDisruptionBudget: true
  monitoring:
    enabled: false
  dataServices:
  - name: alpha
    topology: clustered
    size: 3
  connector:
    replicas: 2
    podTemplate:
      spec:
        containers:
        - name: connector
          resources:
            requests:
              cpu: 1
              memory: 512Mi
            limits:
              memory: 512Mi
    # Uncomment to expose via external load balancer
    #serviceTemplate:
    #  spec:
    #    externalTrafficPolicy: Local
    #    type: LoadBalancer
  podTemplate:
    spec:
      containers:
      - name: mysql
        resources:
          requests:
            cpu: 1
            memory: 2Gi
          limits:
            memory: 2Gi
      - name: manager
        resources:
          requests:
            cpu: 100m
            memory: 512Mi
          limits:
            memory: 512Mi
      - name: replicator
        resources:
          requests:
            cpu: 1
            memory: 2Gi
          limits:
            memory: 2Gi
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 40Gi
  - metadata:
      name: thl
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 20Gi
  - metadata:
      name: state
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 100Mi

apiVersion: tungsten.continuent.com/v1alpha1
kind: MySQLCluster

metadata:
  labels:
    app.kubernetes.io/name: mysqlcluster
    app.kubernetes.io/instance: sample
    app.kubernetes.io/part-of: tungsten-operator
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: tungsten-operator
  name: sample

spec:
  configuration:
    customPasswordSecret: tungsten-passwords-sample-secret
    enablePodDisruptionBudget: true

monitoring:
    enabled: false

dataServices:
  - name: alpha
    topology: clustered
    size: 3

dataServices:
  - name: global
    topology: composite-active-passive
    sources:
    - east
    - west
  - name: east
    topology: clustered
    size: 3
  - name: west
    topology: clustered
    sources:
    - east
    size: 3

dataServices:
  - name: global
    topology: composite-active-active
    sources:
    - north
    - south
  - name: north
    topology: clustered
    size: 3
  - name: south
    topology: clustered
    size: 3

connector:
    replicas: 2
    podTemplate:
      spec:
        containers:
        - name: connector
          resources:
            requests:
              cpu: 1
              memory: 512Mi
            limits:
              memory: 512Mi

podTemplate:
    spec:
      containers:
      - name: mysql
        resources:
          requests:
            cpu: 1
            memory: 2Gi
          limits:
            memory: 2Gi
      - name: manager
        resources:
          requests:
            cpu: 100m
            memory: 512Mi
          limits:
            memory: 512Mi
      - name: replicator
        resources:
          requests:
            cpu: 1
            memory: 2Gi
          limits:
            memory: 2Gi

volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 40Gi
  - metadata:
      name: thl
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 20Gi
  - metadata:
      name: state
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 100Mi

If you are familiar with Tungsten Clustering, you will know that there are many properties that can be set via the /etc/tungsten/tungsten.ini file which will influence the behavior of the cluster. You have the option to include these custom properties by including the name/value key pairs within the yaml file.

You will need to include a section with the keyword customTungstenIniProperties under which you add the appropriate name and value. The location of this property will influence where within the /etc/tungsten/tungsten.ini the property is included.

For it to be part of the [defaults] and apply to all clusters, you should add this within configuration. For the values to apply only to a specific cluster, you should include this within the relevant cluster section under dataServices section.

The example below shows values included in both of these sections:

...
spec:
  configuration:
    customPasswordSecret: custom-tungsten-passwords-sample
    customTungstenIniProperties:
      - name: connector-bridge-mode
        value: "true"
      - name: repl-buffer-size
        value: "10"
  dataServices:
  - name: composite
    topology: composite-active-passive
    sources:
    - east
    - west
  - name: east
    topology: clustered
    size: 3
    customTungstenIniProperties:
      - name: connector-disconnect-timeout
        value: "10"
      - name: property=manager.prometheus.exporter.enabled
        value: "true"
...

For a full list of valid properties, their behavior and options, consult the Tungsten Clustering™ Doc pages

When you have prepared the yaml files to suit your needs, you install the cluster using the kubectl apply command. The following example sets custom passwords using the mysql-passwords.yaml file and then creates a 3-node cluster using the tungsten_v1alpha1_mysqlcluster.yaml file:

shell> kubectl apply -f examples/mysql-passwords.yaml
shell> kubectl apply -f examples/tungsten_v1alpha1_mysqlcluster.yaml