Installation#

Overview#

Mission Control consists of a Java backend server accessed via a web front end. Data is stored in a PostgreSQL database. Mission Control has to run on the same cluster and infrastructure used for Starburst Enterprise platform (SEP) installation it controls.

Installation#

Mission Control can be run on any Kubernetes cluster, including Azure Kubernetes Service AKS, Google Kubernetes Engine GKE and Amazon AWS EKS. It can also be run on other Kubernetes deployments, and managed by your infrastructure team or from other public providers.

Requirements#

The installation uses the Helm and requires the same initial setup and configuration as the other Helm charts.

For setting up Mission control with Helm on your cluster follow steps:

  • Establish access to the Helm chart repository and the Docker registry. Ensure you have access to the starburst-mission-control and starburst-presto-helm-operator charts.

  • To configure Mission Control, specify the properties in a values.yaml file. Refer to the configuration section for the supported configuration properties.

  • Ensure your Helm/kubectl configuration points at the correct cluster with kubectl cluster-info.

  • Proceed on to use to use helm install to deploy the charts.

Installation with Helm#

Deploy and start the SEP with the Helm operator:

Note

Remember to adjust the values.yaml file by providing the Docker registry credentials.

Warning

If you upgrade from 345-e or earlier, remember to uninstall the old operator first, and ensure that all related objects are deleted, including CRD.

helm install --version 350.2.0 --values values.yaml --generate-name starburstdata/starburst-presto-helm-operator

Deploy and start the Mission Control server:

helm upgrade --install --version 350.2.0 --values values.yaml starburst-mission-control starburstdata/starburst-mission-control

After a short while everything is up and running. Confirm the details of the service with kubectl.

kubectl get service/mission-control

Once the server is up and running, take note of the server URL or IP, and proceed to log in and get started.

Mission Control can now manage your data sources and clusters. It replaces the traditional management of configuration files.

Configuration#

Mission Control is automatically configured with reasonable default values as part of the installation process on Kubernetes.

Override default values or set advanced configuration properties in the values.yaml file in the Helm chart. More details on these properties are outlined in the following sub-sections.

Any changes you make require a restart of Mission Control.

Memory allocation and additional JVM properties#

missioncontrol:
  memoryAllocation: 1G
  additionalJvmConfig: |
    -XX:+HeapDumpOnOutOfMemoryError
    -XX:+UseGCOverheadLimit
    -XX:+ExitOnOutOfMemoryError
  allowInsecureHttp: false

Note

The default values expose.type: "clusterIp" and missioncontrol.allowInsecureHttp: false do not allow external access to the Mission Control WebUI. You need to secure the access by configuring TLS encryption through a load balancer or ingress, or by enabling insecure HTTP access with missioncontrol.allowInsecureHttp: true.

Authentication#

For authentication you can choose one of the following:

  • none - Mission Control manages its own users

    authentication:
      type: none
    
  • google - Mission Control integrates with Google authentication

    authentication:
      google:
        clientId: 1234567890-example.apps.googleusercontent.com
        clientSecret: SuperSecureSecret
        hostedDomain: starburstdata.com
    

Registry credentials#

Use this section to provide your credentials to connect to an authenticated Docker registry.

registryCredentials:
  enabled: true
  registry: harbor.starburstdata.net
  username: example_username
  password: SuperSecurePassword

Database#

Use this section to configure the database backend for Mission Control.

Warning

Mission Control 350.1.0 and higher requires the PostgreSQL 11 or later as it uses stored procedures.

There are three types of databases available:

  • embedded - use an in-memory database. It is destroyed when Mission Control is shut down. This makes it suitable for quick demo/trial scenarios.

    database:
      type: "embedded"
      embedded:
        user: "na"
        password: "na"
    
  • internal - provisions a PostgreSQL database in the cluster. You can provide either an existing persistent volume claim or a specification for a new persistent volume claim for storing the data.

    database:
      type: "internal"
      internal:
        image:
          repository: "library/postgres"
          tag: "11.3"
          pullPolicy: "IfNotPresent"
        volume:
          persistentVolumeClaim:
            storageClassName:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 2Gi
        resources:
          requests:
            memory: 1Gi
            cpu: 2
          limits:
            memory: 1Gi
            cpu: 2
        port: 5432
        databaseName: missioncontrol
        user: mission_control_admin
        password: McPass123
    
  • external - use an external PostgreSQL database. This is typically used for normal day to day usage. This option only requires the connection details for the database.

    database:
      type: "external"
      external:
        port: 5432
        host: database.example.com
        databaseName: mcdb
        user: example_db_user
        password: SuperSecurePassword