mycluster.yaml

#
# The header of the application manifest uses the same signature as a Kubernetes
# resource.
#
apiVersion: cluster.gravitational.io/v2
kind: Cluster
metadata:
  # The cluster name as shown to the end user, must be a single alphanumeric word
  name: MyCluster

  # Cluster version, must be in SemVer format (http://semver.org/)
  resourceVersion: 1.2.3-alpha.1

  # Free-form verbose description of the Cluster Image
  description: |
    Description of the Cluster Image

  author: Alice <[email protected]>

# The base image to use. To see the list of available base images, execute:
# $ tele ls --all
# If not specified, the latest version of Kubernetes will be used.
baseImage: "gravity:6.0.0"

# Release notes is a freestyle HTML field which will be shown as part of the
# install/upgrade of the cluster.
#
# In this case "tele build" will look for "notes.html" file in the same directory as
# manifest. To specify an absolute path: "file:///home/user/notes.html"
releaseNotes: file://notes.html

# You can add your logo in order to white-label the installer. You can either reference the URL
# of a hosted image or you can inline-encode it using url(data:image/png;base64,xxxx..) format.
logo: http://example.com/logo.png

# Endpoints are used to define exposed Kubernetes services. This can be your application
# URL or an API endpoint.
#
# Endpoints are shown to the cluster user at the end of the installation.
endpoints:
  - name: "Control Panel"
    description: "The admin interface of the application"
    # Kubernetes selector to locate the matching service.
    selector:
      app: nginx
    protocol: https

  # This endpoint will be used as a custom post-install step, see below
  - name: "Setup"
    # Name of Kubernetes service that serves the web page with this install step
    serviceName: setup-helper
    # This endpoint will be hidden from the list of endpoints generally shown to a user
    hidden: true

# Providers allow you to override certain aspects of cloud and generic providers configuration
providers:
  generic:
    # Network section allows to specify networking type;
    # vxlan - (Default) use flannel for overlay network
    # wireguard - use wireguard for overlay network
    network:
      type: vxlan

#
# Use the section below to customize the cluster installer behavior
#
installer:
  # The end user license agreement (EULA). When set, a user will be presented with 
  # the EULA text before the start of the installation and forced to accept it.
  # This capability is often used when cluster images are used to distribute downloadable
  # enterprise software.
  eula:
    source: file://eula.txt

  # If the installation flavors are defined, a cluster user will be presented with a 
  # prompt and the cluster flavor will be selecte based on their answer.
  #
  # A "cluster flavor" consists of a name and a set of server profiles, along with the 
  # number of servers for every profile.
  #
  # The example below declares two flavors: "small" and "large", based on how many page 
  # views per second the cluster user wants to serve.
  #
  flavors:
    prompt: "How many requests per second will you need?"

    # This text will appear on the right-hand side during "capacity" step
    description: file://flavors-help.txt

    # The default flavor
    default: small

    # List of flavors:
    items:
      - name: "small"
        # UI label which installer will use to label this selection
        description: "Up to 250 requests/sec"

        # This section describes the minimum required quantity of each server type (profile)
        # for this flavor:
        nodes:
          - profile: worker
            count: 3
          - profile: db
            count: 2

      - name: "large"
        description: "More than 250 requests/sec"
        nodes:
          - profile: worker
            count: 5
          - profile: db
            count: 3

  # If additional installation UI screens are needed, they can be packaged as Kubernetes
  # services and you can list their Kubernetes endpoint names below:
  setupEndpoints:
    - "Setup"

# The node profiles section describes the system requirements of the application. The
# requirements are expressed as 'server profiles'.
#
# Gravity will ensure that the provisioned machines match the system requirements
# for each profile.
#
# This example uses two profiles: 'db' and 'node'. For example it might make sense to
# restrict 'db' profile to have at least 8 CPU and 32GB of RAM.
nodeProfiles:
  - name: db
    description: "Cassandra Node"

    # These labels will be applied to all nodes of this type in Kubernetes
    labels:
      role: "db"

    # Requirements allow you to specify the requirements servers of this profile should
    # satisfy, all of these are optional
    requirements:
      cpu:
        min: 8

      ram:
        # Other supported units are "B" (bytes), "kB" (kilobytes) and "MB" (megabytes)
        min: "32GB"

      # Supported operating systems, name should match "ID" from /etc/os-release
      os:
        - name: centos
          versions: ["7"]

        - name: rhel
          versions: ["7.2", "7.3"]

      # This section allows to run custom pre-flight checks on a node before
      # allowing cluster installation to continue (scripts must return 0 for success)
      # Stdout/stderr output from pre-flight check scripts will be mirrored in 
      # the installation log.
      customChecks:
        - description: Custom check
          script: |
              #!/bin/bash
              # inline script goes here

        - description: Custom checks defined in external file
          script: file://checks.sh

      volumes:
        # This setting tells the installer to ensure that /var/lib/logs directory
        # exists and offers at least 512GB of space:
        - path: /var/lib/logs
          capacity: "512GB"

        # A volume defined like this allows to address variations of different
        # filesystem layouts in Linux distributions (note skipIfMissing attribute)
        - path: /path/to/centos/file
          name: centos-specific-library
          targetPath: /path/to/container
          skipIfMissing: true

        # This example shows how to mount volumes into containers using a shell
        # file pattern:
        - name: wildcard-volume
          path: /path/to/dir-???
          targetPath: /path/inside/container/dir-???

        # This setting tells the installer to request an external mount for /var/lib/data
        # and mount it as /var/lib/data into containers as well
        - name: app-data
          path: /var/lib/data
          targetPath: /var/lib/data
          capacity: "512GB"
          filesystems: ["ext4", "xfs"]
          minTransferRate: "50MB/s"
          # Create the directory on host if it doesn't exist (default is 'true')
          createIfMissing: true
          # UID and GID set linux UID and GID on the directory if specified
          uid: 114
          gid: 114
          # Unix file permissions mode to set on the directory
          mode: "0755"
          # Recursive defines a recursive mount, i.e. all submounts under specified path
          # are also mounted at the corresponding location in the targetPath subtree
          recursive: false

      # This setting makes sure specified devices from host are made available
      # inside Gravity container
      devices:
          # Device(-s) path, treated as a glob
        - path: /dev/nvidia*
          # Device permissions as a composition of 'r' (read), 'w' (write) and
          # 'm' (mknod), default is 'rw'
          permissions: rw
          # Device file mode in octal form, default is '0666'
          fileMode: "0666"
          # Device user ID, default is '0'
          uid: 0
          # Device group ID, default is '0'
          gid: 0

      network:
        minTransferRate: "50MB/s"
        # Request these ports to be available
        ports:
          - protocol: tcp
            ranges:
              - "8080"
              - "10000-10005"

  - name: worker
    description: "General Purpose Worker Node"
    labels:
      role: "worker"
    requirements:
      cpu:
        min: 4
      ram:
        min: "4GB"

# If license is enabled, a user will be asked to enter a correct license to be able
# to create a cluster from this image
license:
  enabled: true

# 
# This section allows to configure the runtime behavior of a Kubernetes cluster
#
systemOptions:
  docker:
    # Storage backend used, supported: "overlay", "overlay2" (default)
    storageDriver: overlay
    # List of additional command line args to provide to docker daemon
    args: ["--log-level=DEBUG"]

  # Etcd section allows to customize etcd
  etcd:
    # List of additional command line args to provide to etcd daemon
    args: ["-debug"]

  # Kubelet section allows to customize kubelet
  kubelet:
    # List of additional command line args to provide to kubelet daemon
    args: ["--system-reserved=memory=500Mi"]
    hairpinMode: "promiscuous-bridge"


#
# This section allows to disable pre-packaged system extensions that
# Gravitational includes into the base images by default (see below for more information).
#
extensions:
  # This setting will not install system logging service and hide "logs tab" 
  # in the cluster UI
  logs:
    disabled: false

  # This setting will not install system monitoring application and hide
  # Monitoring tab in the cluster UI
  monitoring:
    disabled: false

  # This setting will not install the Tiller application
  catalog:
    disabled: false

# This section specifies the cluster lifecycle hooks, i.e. the ability to execute
# custom code in response to lifecycle events.
#
# Every hook is a name of a Kubernetes job.
#
hooks:
  # install hook is called right after the application is installed for the first time.
  install:
    # Job directive defines a Kubernetes job which can be declared inline here in the manifest
    # It will be created and executed:
    job: |
      apiVersion: batch/v1
      kind: Job
      metadata:
        name: db-seed
        namespace: default
      spec:
        template:
          spec:
            restartPolicy: OnFailure
            containers:
              - name: dbseed
                image: installer-hooks:latest

  # called after the application has been installed
  postInstall:
    # A Kubernetes job can also be specified via a separate YAML file
    # `post-install-hook.yaml` file located in the same directory as
    # this application bundle manifest
    job: file://post-install-hook.yaml

  # called when uninstalling the application
  uninstall:

  # called before uninstall is launched
  preUninstall:

  # called before adding a new node to the cluster
  preNodeAdd:

  # called after a new node has need added to the cluster
  postNodeAdd:

  # called before a node is removed from the cluster
  preNodeRemove:

  # called after a node has been removed from the cluster
  postNodeRemove:

  # called when updating the application
  update:

  # called after successful application update
  postUpdate:

  # called when rolling back after an unsuccessful update
  rollback:

  # called after successful rollback
  postRollback:

  # called every minute to check the application status (visible in Control Panel)
  status:

  # called after the application license has been updated
  licenseUpdated:

  # used to start the application
  start:

  # used to stop the application
  stop:

  # used to retrieve application specific dump for debug reports
  dump:

  # triggers application data backup
  backup:

  # restores application state from backup
  restore:

  # install a custom CNI network plugin during cluster installation
  networkInstall:

  # update a custom CNI network plugin during cluster upgrade
  networkUpdate:

  # rollback a custom CNI network plugin during cluster rollback
  networkRollback: