Wallaroo Enterprise Comprehensive Install Guide: Amazon Web Services EKS

How to set up Wallaroo Enterprise in AWS EKS via eksctl

AWS Cluster for Wallaroo Enterprise Instructions

The following steps are guidelines to assist new users in setting up their AWS environment for Wallaroo. Feel free to replace these with commands with ones that match your needs.

  • AWS Prerequisites

To install Wallaroo in your AWS environment based on these instructions, the following prerequisites must be met:

  • Register an AWS account: https://aws.amazon.com/ and assign the proper permissions according to your organization’s needs.
  • The Kubernetes cluster must include the following minimum settings:
    • Nodes must be OS type Linux with using the containerd driver.
    • Role-based access control (RBAC) must be enabled.
    • Minimum of 4 nodes, each node with a minimum of 8 CPU cores and 16 GB RAM. 50 GB will be allocated per node for a total of 625 GB for the entire cluster.
    • RBAC is enabled.
    • Recommended Aws Machine type: c5.4xlarge. For more information, see the AWS Instance Types.
  • Installed eksctl version 0.101.0 and above.
  • IMPORTANT NOTE
    • Organizations that intend to stop and restart their Kubernetes environment on an intentional or regular basis are recommended to use a single availability zone for their nodes. This minimizes issues such as persistent volumes in different availability zones, etc.
    • Organizations that intend to use Wallaroo Enterprise in a high availability cluster are encouraged to follow best practices including using separate availability zones for redundancy, etc.

Taints and Labels Requirements

Nodepools created in Wallaroo require the following taints and labels. For nodepools with AI Accelerators, GPUs, ARM support, etc, see the Custom Taints and Labels Guide for how to set up nodepools with the proper taints and labels.

NodepoolTaintsLabelsDescription
defaultN/Awallaroo.ai/node-purpose: generalFor general Wallaroo services. No taints are applied to this nodepool to allow any process not assigned with a deployment label to run in this space.
persistentwallaroo.ai/persistent=true:NoSchedulewallaroo.ai/node-purpose: persistentFor Wallaroo services with a persistentVolume settings, including JupyterHub, Minio, etc.
pipelines-x86wallaroo.ai/pipelines=true:NoSchedulewallaroo.ai/node-purpose: pipelinesFor deploying pipelines for default x86 architectures. The taints and label must be applied to any nodepool used for model deployments.

The specific nodepool names may differ based on your cloud services naming requirements; check with the cloud services provider for the nodepool name requirements and adjust as needed.

EKSCTL Based Instructions

These commands make use of the command line tool eksctl which streamlines the process in creating Amazon Elastic Kubernetes Service clusters for our Wallaroo environment.

The following are used for the example commands below. Replace them with your specific environment settings:

  • AWS Cluster Name: wallarooAWS

Create an AWS EKS Cluster

The following eksctl configuration file is an example of setting up the AWS environment for a Wallaroo cluster, including the static and adaptive nodepools. Note that the sample eksctl YAML file includes additional options for ARM and GPU based nodepools. Adjust these names and settings based on your organizations requirements.

Nodepool instance types that include multiple types provision each instance in the order provided. The sample lists used are set to provision each instance type by lowest cost first to provide additional savings. For example, he sample nodepool pipelines-x86 includes the following instance types:

instanceTypes:
    - c7i.2xlarge
    - c7a.2xlarge
    - c6i.2xlarge
    - c6a.2xlarge

This would provision first the c7i.2xlarge instance type, then the c7a.2xlarge if the additional resources are needed, etc.

This sample YAML file can be downloaded from here:wallaroo_enterprise_aws_install.yaml

Or copied from here:

# yaml-language-server: $schema=https://raw.githubusercontent.com/weaveworks/eksctl/main/pkg/apis/eksctl.io/v1alpha5/assets/schema.json
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: wallarooAWS # change to your cluster name
  region: us-west-2 # change to your region
  version: "1.29"

addons:
  - name: aws-ebs-csi-driver

# create the required IAM roles and kubernetes service account for the cluster-autoscaler
iam:
  withOIDC: true
  serviceAccounts:
  - metadata:
      name: cluster-autoscaler
      namespace: kube-system
    wellKnownPolicies:
      autoScaler: true

# ONLY use if you want to reuse existing VPC and subnet.
# The VPC and subnets have many requirements https://eksctl.io/usage/vpc-configuration/#use-existing-vpc-other-custom-configuration
# vpc:
#   id: "vpc-11111"
#   subnets:
#     private:
#       us-west-2a:
#           id: "subnet-0ff156e0c4a6d300c"
#       us-west-2c:
#           id: "subnet-0426fb4a607393184"
#     public:
#       us-west-2a:
#           id: "subnet-0153e560b3129a696"
#       us-west-2c:
#           id: "subnet-009fa0199ec203c37"

managedNodeGroups:
  - name: general
    instanceSelector:
      vCPUs: 8
      memory: 16GiB 
      gpus: 0
      cpuArchitecture: x86_64
    minSize: 1
    maxSize: 3
    desiredCapacity: 1
    labels:
      wallaroo.ai/node-purpose: general
    iam:
      withAddonPolicies:
        autoScaler: true # add iam role for cluster-autoscaler; any nodegroup that should autoscale needs this and below
    propagateASGTags: true # add the labels and taints as appropriate autoscaling groups for cluster-autoscaler
  - name: persistent
    instanceSelector:
      vCPUs: 8
      memory: 16GiB 
      gpus: 0
      cpuArchitecture: x86_64
    desiredCapacity: 1
    minSize: 1
    maxSize: 3
    iam:
      withAddonPolicies:
        autoScaler: true
    propagateASGTags: true
    labels:
      wallaroo.ai/node-purpose: persistent
    taints:
      - key: wallaroo.ai/persistent
        value: "true"
        effect: NoSchedule
    availabilityZones:
      - us-west-2c
  - name: pipelines-x86
    instanceTypes:
    - c7i.2xlarge
    - c7a.2xlarge
    - c6i.2xlarge
    - c6a.2xlarge
    desiredCapacity: 2
    minSize: 2
    maxSize: 3
    iam:
      withAddonPolicies:
        autoScaler: true
    propagateASGTags: true
    labels:
      wallaroo.ai/node-purpose: pipelines
    taints:
      - key: wallaroo.ai/pipelines
        value: "true"
        effect: NoSchedule
  # Example GPU pool - not default
  # - name: pipelines-v100
  #   instanceTypes:
  #   - p3.8xlarge
  #   desiredCapacity: 0
  #   minSize: 0
  #   maxSize: 1
  #   volumeSize: 100 # particularly important for large models
  #   iam:
  #     withAddonPolicies:
  #       autoScaler: true
  #   propagateASGTags: true
  #   labels:
  #     wallaroo.ai/node-purpose: pipelines
  #     wallaroo.ai/accelerator: v100
  #   taints:
  #     - key: wallaroo.ai/pipelines
  #       value: "true"
  #       effect: NoSchedule
  #     - key: nvidia.com/gpu
  #       value: "v100"
  #       effect: NoSchedule
  # Example A100 GPU pool - not default
  # - name: pipelines-a100
  #   instanceTypes:
  #   - p4d.24xlarge
  #   desiredCapacity: 0
  #   minSize: 0
  #   maxSize: 1
  #   volumeSize: 100 # particularly important for large models
  #   iam:
  #     withAddonPolicies:
  #       autoScaler: true
  #   propagateASGTags: true
  #   labels:
  #     wallaroo.ai/node-purpose: pipelines
  #     wallaroo.ai/accelerator: a100
  #   taints:
  #     - key: wallaroo.ai/pipelines
  #       value: "true"
  #       effect: NoSchedule
  #     - key: nvidia.com/gpu
  #       value: "a100"
  #       effect: NoSchedule
  # Example ARM pipeline pool - not default
  # - name: pipelines-ARM
  #   instanceTypes:
  #   - m7g.2xlarge
  #   - m6g.2xlarge
  #   desiredCapacity: 0
  #   minSize: 0
  #   maxSize: 1
  #   iam:
  #     withAddonPolicies:
  #       autoScaler: true
  #   propagateASGTags: true
  #   labels:
  #     wallaroo.ai/node-purpose: pipelines
  #   taints:
  #     - key: wallaroo.ai/pipelines
  #       value: "true"
  #       effect: NoSchedule

  # Example ARM conversion pool - not default
  # - name: general-ARM
  #   instanceTypes:
  #   - m7g.2xlarge
  #   - m6g.2xlarge
  #   desiredCapacity: 0
  #   minSize: 0
  #   maxSize: 1
  #   iam:
  #     withAddonPolicies:
  #       autoScaler: true
  #   propagateASGTags: true
  #   labels:
  #     wallaroo.ai/node-purpose: general

Create the Cluster

Create the cluster with the following command, which creates the environment and sets the correct Kubernetes version.

eksctl create cluster -f wallaroo_enterprise_aws_install.yaml

During the process the Kubernetes credentials will be copied into the local environment. To verify the setup is complete, use the kubectl get nodes command to display the available nodes as in the following example:

kubectl get nodes
NAME                                           STATUS   ROLES    AGE     VERSION
ip-192-168-21-253.us-east-2.compute.internal   Ready    <none>   13m     v1.23.8-eks-9017834
ip-192-168-30-36.us-east-2.compute.internal    Ready    <none>   13m     v1.23.8-eks-9017834
ip-192-168-38-31.us-east-2.compute.internal    Ready    <none>   9m46s   v1.23.8-eks-9017834
ip-192-168-55-123.us-east-2.compute.internal   Ready    <none>   12m     v1.23.8-eks-9017834
ip-192-168-79-70.us-east-2.compute.internal    Ready    <none>   13m     v1.23.8-eks-9017834
ip-192-168-37-222.us-east-2.compute.internal   Ready    <none>   13m     v1.23.8-eks-9017834

Add Cluster Autoscaler for AWS

Cluster autoscaling is added with the Cluster Autoscaler on AWS. This is a required step.

The following is a condensed procedure for adding autoscaler support to the cluster; refer to the Cluster Autoscaler on AWS guide for full details.

To add autoscaler support to an existing Kubernetes cluster in AWS:

  1. Download the autoscaler cluster example cluster-autoscaler-autodiscover.yaml.

  2. Update the line (currently on line 165) - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME> and change <YOUR CLUSTER NAME> to the name of the cluster name.

  3. Run the following command with kubectl from an account with administrative access over the cluster.

    kubectl apply -f cluster-autoscaler-autodiscover.yaml
    

Once the process is complete, autoscaling is added to the cluster.

Install Wallaroo

Wallaroo installations are available via two methods:

  • kots based installations.
  • helm based installations.

Kubernetes Client Software Prerequisites

Before installing or upgrading Wallaroo, the administrative node managing the Kubernetes cluster will require these tools.

  • kubectl
    • For Kots based installs:
      • kots Version 1.107.2

    • For Helm installs:
      • helm: Install Helm
      • krew: Install Krew
      • krew preflight and krew support-bundle. Install with the following commands:
        • kubectl krew install support-bundle
        • kubectl krew install preflight

The following are quick guides for installing kubectl for different operating systems. For more details, see the instructions for your specific environment.

kubectl Install For Deb Package based Linux Systems

For users running a deb based package system such as Ubuntu Linux, the following commands will install kubectl and kots into the local system. They assume the user has sudo level access to the system.

  1. Update the apt-get repository:

    sudo apt-get update
    
  2. Install the prerequisite software apt-transport-https, ca-certificates, and curl.

    sudo apt-get install -y \
        apt-transport-https \
        ca-certificates curl
    
  3. Download the install the Google Cloud repository key:

    sudo curl -fsSLo \
        /usr/share/keyrings/kubernetes-archive-keyring.gpg \
        https://packages.cloud.google.com/apt/doc/apt-key.gpg
    
  4. Install the Google Cloud repository into the local repository configuration:

    echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" \
        | sudo tee /etc/apt/sources.list.d/kubernetes.list
    
  5. Update the apt-get repository, then install kubectl:

    sudo apt-get update
    
    sudo apt-get install -y kubectl
    
  6. Verify the kubectl installation:

    kubectl version --client
    
kubectl Install For macOS Using Homebrew

To install kubectl on a macOS system using Homebrew:

  1. Issue the brew install command:

    brew install kubectl
    
  2. Verify the installation:

    kubectl version --client
    

Kots Based Install of Wallaroo

Wallaroo kots based installations are broken up into two formats:

  • Automated Install: Variables are passed to the installation process to auto-set the password, license file, and other settings before beginning the installation configuration process.
  • Interactive Install: All parts of the installation process are performed through the browser interface.

Kots Install Guides

kots Quick Install Guide

The following are quick guides for installing kots for different operating systems. For more details, see the instructions for your specific environment.

  • IMPORTANT NOTE

    As of this time, Wallaroo requires kots version 1.107.2. Please verify that version is installed before starting the Wallaroo installation process.

  1. Install curl.

    1. For deb based Linux systems, update the apt-get repository and install curl:

      sudo apt-get update
      sudo apt-get install curl
      
    2. For macOS based systems curl is installed by default.

  2. Install kots by downloading the script and piping it into the bash shell:

    curl https://kots.io/install/1.107.2 | REPL_USE_SUDO=y bash
    

For instructions on updating the kots version for the Wallaroo Ops installation, see Updating KOTS.

Manual Kots Install

A manual method to install KOTS is:

  1. Download from https://github.com/replicatedhq/kots/releases/tag/v1.107.2. Linux and MacOS are supported.

  2. Unpack the release

  3. Rename the kots executable to kubectl kots.

  4. Copy the renamed kubectl kots to anywhere on the PATH.

  5. Next, verify successful installation.

    ~ kubectl kots version
    
    Replicated KOTS 1.107.2
    

Automated Kots Wallaroo Install

To automatically install Wallaroo into the namespace wallaroo, specify the administrative password and the license file during the installation as in the following format with the following variables:

  • NAMESPACE: The namespace for the Wallaroo Enterprise install, typically wallaroo.
  • LICENSEFILE: The location of the Wallaroo Enterprise license file.
  • SHAREDPASSWORD: The password of for the Kots Administrative Dashboard.
kubectl kots install wallaroo/2024-1 -n $NAMESPACE --license-file $LICENSEFILE --shared-password $SHAREDPASSWORD

For example, the following settings translate to the following install command:

  • NAMESPACE: wallaroo.
  • LICENSEFILE: myWallaroolicense.yaml
  • SHAREDPASSWORD: snugglebunnies
kubectl kots install wallaroo/2024-1 -n wallaroo --license-file myWallaroolicense.yaml --shared-password wallaroo

Interactive Kots Wallaroo Install

The Interactive Install process allows users to adjust the configuration settings before Wallaroo is deployed. It requires users be able to access the Kots Administrative Dashboard through a browser, typically on port 8800.

  • IMPORTANT NOTE: Users who install Wallaroo through another node such as in the single node installation can port use SSH tunneling to access the Kots Administrative Dashboard. For example:

    ssh IP -L8800:localhost:8800
    
  1. Install the Wallaroo Enterprise Edition using kots install wallaroo/2024-1, specifying the namespace to install Wallaroo into. For example, if wallaroo is the namespace, then the command is:

    kubectl kots install wallaroo/2024-1 --namespace wallaroo
    
  2. Wallaroo Enterprise Edition will be downloaded and installed into your Kubernetes environment in the namespace specified. When prompted, set the default password for the Wallaroo environment. When complete, Wallaroo Enterprise Edition will display the URL for the Admin Console, and how to end the Admin Console from running.

    • Deploying Admin Console
    • Creating namespace ✓
    • Waiting for datastore to be ready ✓
        Enter a new password to be used for the Admin Console: •••••••••••••
      • Waiting for Admin Console to be ready ✓
    
    • Press Ctrl+C to exit
    • Go to http://localhost:8800 to access the Admin Console
    

To relaunch the Kots Administrative Dashboard and make changes or updates, use the following command:

kubectl kots admin-console --namespace wallaroo
Initial Wallaroo Config

Once Wallaroo has been installed for the first time, we can perform initial configuration.

  1. If Wallaroo Edition has not started, launch it with the following command:

    ❯ kubectl kots admin-console --namespace wallaroo
      • Press Ctrl+C to exit
      • Go to http://localhost:8800 to access the Admin Console
    
  2. Enter the Wallaroo Admin Console address into a browser. You will be prompted for the default password as set in the step above. Enter it and select Log in.

    Wallaroo Admin Console Initial Login
  3. Upload your license file. If the license file was already selected from the Automated installation, this step is skipped.

    Wallaroo Admin Upload License
  4. The Wallaroo Admin Console will run the preflight checks to verify that all of the minimum requirements are not met. This may take a few minutes. If there are any issues, Wallaroo can still be launched but may not function properly. When ready, select Continue.

    Wallaroo Admin Preflight Successful
  5. The Configure Wallaroo page will be displayed which allows you to customize your Wallaroo environment. The following are the minimum required settings.

    1. Networking Configuration: Set whether the Wallaroo instance is available from outside the Kubernetes cluster, or only from within it.
      1. Ingress Mode for Wallaroo Endpoints:
        1. None: Services are local to the Kubernetes cluster. kubectl-port forward or some other means is required to access them. If all work will be done in-cluster, select this option.
        2. Internal: An internal cloud load balancer and associated resources are created. Network users outside the Kubernetes cluster – but on the same internal network – can connect directly using DNS names, and do not need to use port forward or related configurations.
        3. External: An external, Internet-facing cloud load balancer, public IP, and associated resources are created. This is highly discouraged. Public DNS is also required. This is the default for Wallaroo Community Edition.
          1. Enable external URL inference endpoints: Creates pipeline inference endpoints. For more information, see Model Endpoints Guide.
    2. DNS
      1. DNS Prefix (Optional): The domain name prefix for your Wallaroo instance.
      2. DNS Suffix (Mandatory): The domain name suffix for your Wallaroo instance.
    3. TLS Certificates
      1. Use custom TLS Certs: Checked
      2. TLS Certificate: Enter your TLS Certificate (.crt file).
      3. TLS Private Key: Enter your TLS private key (.key file).
    Wallaroo DNS Records
  6. Once complete, scroll to the bottom of the Config page and select Deploy.

  7. At this point, continue to Required Installation Configurations for the required configuration settings.

Custom Tolerations and Node Selectors Configuration

By default, the following taints and labels are applied to nodepools used for Wallaroo installations.

NodepoolTaintsLabelsDescription
defaultN/Awallaroo.ai/node-purpose: generalFor general Wallaroo services. No taints are applied to this nodepool to allow any process not assigned with a deployment label to run in this space.
persistentwallaroo.ai/persistent=true:NoSchedulewallaroo.ai/node-purpose: persistentFor Wallaroo services with a persistentVolume settings, including JupyterHub, Minio, etc.
pipelines-x86wallaroo.ai/pipelines=true:NoSchedulewallaroo.ai/node-purpose: pipelinesFor deploying pipelines for default x86 architectures. The taints and label must be applied to any nodepool used for model deployments.

The specific nodepool names may differ based on your cloud services naming requirements; check with the cloud services provider for the nodepool name requirements and adjust as needed.

For organizations that use custom Kubernetes taints and labels for their nodepools, the tolerations and node selectors for Wallaroo services will have to be modified to match. For full details, see the Custom Taints and Labels Guide.

To modify the tolerations and node selector labels to match the taints and labels set for the nodepools:

  1. From the Kots Administrative Dashboard, select Config
  2. Update each of the following as needed:
    1. Node Affinities:

      1. Node affinity type key: Verify that the node affinity key matches the label for the nodepools.

      2. Engine affinity value: Set the engine affinity - the affinity used for pipeline deployment - to match the label.

        Node Affinity
    2. Taints and Tolerations. Set the custom tolerations to match the taints applied to the nodepools, and the node selectors to match the labels used for the nodepools.

    3. Node Selectors: Update the node selector to match the custom nodepools labels for each service.

      Kots Custom Tolerances and Node Selectors

Helm Based Installation of Wallaroo

Installation Client Helm Requirements

The following software is required for the client with administrative access to the Kubernetes cluster that will host Wallaroo via Helm.

  • For Helm installs:
    • helm: Install Helm
    • krew: Install Krew
    • krew preflight and krew support-bundle. Install with the following commands:
      • kubectl krew install support-bundle
      • kubectl krew install preflight

The following details how to install Wallaroo via helm.

Wallaroo Provided Data

Members of the Wallaroo support staff will provide the following information:

  • Wallaroo Container Registration Login: Commands to login to the Wallaroo container registry.
  • Preflight verification command: The commands to verify that the Kubernetes environment meets the requirements for the Wallaroo install.
  • Install Wallaroo Command: Instructions on installations into the Kubernetes environment using Helm through the Wallaroo container registry.

The following steps are used with these command and configuration files to install Wallaroo Enterprise via Helm.

Registration Login

The first step in the Wallaroo installation process via Helm is to connect to the Kubernetes environment that will host the Wallaroo Enterprise instance and login to the Wallaroo container registry through the command provided by the Wallaroo support staff. The command will take the following format, replacing $YOURUSERNAME and $YOURPASSWORD with the respective username and password provided.

helm registry login registry.replicated.com --username $YOURUSERNAME --password $YOURPASSWORD

Preflight Verification

Preflight verification is performed with the following command format. The variables $LICENSE_CHANNEL and $VERSION is supplied by your Wallaroo support representative.

helm template oci://registry.replicated.com/wallaroo/$LICENSE_CHANNEL/wallaroo --version $VERSION | kubectl preflight -

For example, the $LICENSE_CHANNEL=2024-1 of ee and the $VERSION=2024.1.0-5097

helm template oci://registry.replicated.com/wallaroo/2024-1/wallaroo --version 2024.1.0-5097 | kubectl preflight -

This displays the Preflight Checks report.

Preflight check example

The following commands are available:

  • s: Save the report to a text file as the file preflight-checks-results-DATETIME.txt. For example: preflight-checks-results-2024-03-19T13_30_41.txt.
  • q: Exit the preflight report.
  • Up Arrow or Down Arrow: Scroll through the preflight elements and view the report details.

The following example shows a successful preflight test.

Preflight Checks Preflight Checks

Check PASS
Title: Required Kubernetes Version
Message: Your cluster meets the recommended and required versions of Kubernetes.

------------
Check PASS
Title: Container Runtime
Message: Containerd container runtime was found.

------------
Check PASS
Title: Check Kubernetes environment.
Message: GKE is a supported distribution

------------
Title: Cluster CPU Resources
Message: 

------------
Check PASS
Title: Cluster Resources
Message: Cluster resources are satisfactory

------------
Check PASS
Title: Every node in the cluster must have at least 12Gi of memory
Message: All nodes have at least 12 GB of memory capacity

------------
Check PASS
Title: Every node in the cluster must have at least 8 cpus allocatable.
Message: All nodes have at least 8 CPU capacity

------------

Prepare Helm Installation

The following instructions detail how to install Wallaroo Enterprise via Helm for Kubernetes cloud environments such as Microsoft Azure, Amazon Web Service, and Google Cloud Platform.

Helm Network Configuration

apilb.serviceType and edgelb.serviceType settings have the following effects depending on whether they are installed on single node Linux installations, or part of a cloud Kubernetes installation.

SettingSingle Node LinuxCloud Kubernetes
Internal Only ConnectionsClusterIPClusterIP
External ConnectionsNodePortLoadBalancer

Refer to the instructions for environment host for details on IP address allocation and support.

With the preflight checks and prerequisites met, Wallaroo can be installed via Helm through the following process:

  1. Create namespace. By default, the namespace wallaroo is used:

    kubectl create namespace wallaroo
    
  2. Set the new namespace as the current namespace:

    kubectl config set-context --current --namespace wallaroo
    
  3. Set the TLS certificate secret in the Kubernetes environment:

    1. Create the certificate and private key. It is recommended to name it after the domain name of your Wallaroo instance. For example: wallaroo.example.com. For production environments, organizations are recommended to use certificates from their certificate authority. Note that the Wallaroo SDK will not connect from an external connection without valid certificates. For more information on using DNS settings and certificates, see the Wallaroo DNS Integration Guide.

    2. Create the Kubernetes secret from the certificates created in the previous step, replacing $TLSCONFIG with the name of the Kubernetes secret, with the certificate file $TLSCERT and the private key $TLSKEY. Store the secret name for a the step Configure local values file.

      kubectl create secret tls $TLSCONFIG --cert=$TLSCERT --key=$TLSKEY
      

      For example, if $TLSCONFIG is cust-cert-secret with the certificate $TLSCERT is fullchain.pem and key $TLSKEY is privkey.pem, then the command would be translated as

      kubectl create secret tls cust-cert-secret --cert=fullchain.pem --key=privkey.pem
      

Default Helm Installation Settings

A default Helm install of Wallaroo contains various default settings. The local values file overwrites values based on the organization needs. The following represents the minimum mandatory values for a Wallaroo installation using certificates and the default LoadBalancer for a cloud Kubernetes cluster. The configuration details below is saved as values.yaml for these examples.

Note the following required settings:

  • domainPrefix and domainSuffix: Used to set the DNS settings for the Wallaroo instance. For more information, see the Wallaroo DNS Integration Guide.
  • custTlsSecretName: Specify the Kubernetes secret created in the previous step. External connections through the Wallaroo SDK require valid certificates.
  • apilb: Sets the apilb service options including the following:
    • serviceType: LoadBalancer: Uses the default LoadBalancer setting for the Kubernetes cloud service the Wallaroo instance is installed into. Replace with the specific service connection settings as required.
    • external_inference_endpoints_enabled: true: This setting is required for performing external SDK inferences to a Wallaroo instance. For more information, see the Wallaroo Model Endpoints Guide
    • kubernetes_distribution: The cloud provider used. Each cloud provider has their own methods of handling storage classes, LoadBalancers (LB), etc. The following values are available; if your selected provider or distribution is not on the list, contact your Wallaroo Support representative for more options.
      • aks: Microsoft Azure Kubernetes Service
      • eks: Amazon Elastic Kubernetes Service
      • gke: Google Kubernetes Engine
      • oke: Oracle Cloud Infrastructure Container Engine for Kubernetes
      • kurl: On premise aka stand alone Linux installations.
    • ingress_mode: How the Wallaroo instance is reached through the Kubernetes network settings. Options include:
      • internal (Default): An internal cloud load balancer and associated resources are created. Network users outside the Kubernetes cluster – but on the same internal network – can connect directly using DNS names, and do not need to use port forward or related configurations.
      • external: An external, Internet-facing cloud load balancer, public IP, and associated resources are created. This is highly discouraged. Public DNS is also required. This is the default for Wallaroo Community Edition.
      • none: Services are local to the Kubernetes cluster. kubectl-port forward or some other means is required to access them. If all work will be done in-cluster, select this option.
  • dashboard: The name displayed when users login to the Wallaroo Ops center Dashboard. For example, “My Company” or “Sales Division”, etc.

The following example shows the minimum required options.

This example shows the uncommented keys for the minimum required settings and additional commented optional settings. For full details on helm values for Wallaroo installations, see the Wallaroo Helm Reference Guides.

domainPrefix: "" # optional if using a DNS Prefix
domainSuffix: "wallaroo.example.com"

custTlsSecretName: cust-cert-secret

apilb:
  serviceType: LoadBalancer
  external_inference_endpoints_enabled: true
  ingress_mode: internal # internal (Default), external,or none

dashboard:
  clientName: "Wallaroo Helm Example" # Insert the name displayed in the Wallaroo Dashboard

kubernetes_distribution: ""   # Required. One of: aks, eks, gke, oke, or kurl.

# The nodeSelector and tolerations for all components
# This does not apply to nats, fluent-bit, or minio so needs to be applied separately
# nodeSelector:
#   wallaroo.ai/reserved: true

# tolerations:
# - key: "wallaroo.ai/reserved"
#   operator: "Exists"
#   effect: "NoSchedule"

# To change the pipeline taint or nodeSelector, 
# best practice is to change engine, enginelb, and engineAux 
# together unless they will be in different pools.
# engine:
#   nodeSelector:
#     wallaroo.ai/node-purpose: pipelines
#   tolerations:
#     - key: "wallaroo.ai/pipelines"
#       operator: "Exists"
#       effect: "NoSchedule"

# enginelb:
#   nodeSelector:
#     wallaroo.ai/node-purpose: pipelines
#   tolerations:
#     - key: "wallaroo.ai/pipelines"
#       operator: "Exists"
#       effect: "NoSchedule"

# engineAux:
#   nodeSelector:
#     wallaroo.ai/node-purpose: pipelines
#   tolerations:
#     - key: "wallaroo.ai/pipelines"
#       operator: "Exists"
#       effect: "NoSchedule"

# For each service below, adjust the disk size and resources as required.
# If the nodeSelector or tolerations are changed for one service, 
# the other services nodeSelector and tolerations **must** be changed to match
#
#
# plateau:
#   diskSize: 100Gi
#   resources:
#     limits:
#       memory: 4Gi
#       cpu: 1000m
#     requests:
#       memory: 128Mi
#       cpu: 100m
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"

# Jupyter has both hub and lab nodeSelectors and tolerations
# They default to the same persistent pool, but can be assigned to different ones
# jupyter:
#   nodeSelector:                 # Node placement for Hub administrative pods
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"
#   labNodeSelector:              # Node placement for Hub-spawned jupyterlab pods
#     wallaroo.ai/node-purpose: persistent
#   labTolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"
#   memory:
#     limit: "4"                  # Each Lab - memory limit in GB
#     guarantee: "2"              # Each Lab - lemory guarantee in GB
#   cpu:
#     limit: "2.0"                # Each Lab - fractional CPU limit
#     guarantee: "1.0"            # Each Lab - fractional CPU guarantee
#   storage:
#     capacity: "50"              # Each Lab - disk storage capacity in GB

# minio:
#   persistence:
#     size: 25Gi
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#   - key: wallaroo.ai/persistent
#     operator: "Exists"
#     effect: "NoSchedule"
#   resources:
#     requests:
#       memory: 1Gi

# postgres:
#   diskSize: 10Gi
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"
#   resources:
#     limits:
#       memory: 2Gi
#       cpu: 500m
#     requests:
#       memory: 512Mi
#       cpu: 100m

# Prometheus has the usual persistent options, but also a retention size
# The the size on disk and time can be configured before removing it.
# prometheus:
#   storageRetentionSizeGb: "10"        # Retain this much data, in GB.
#   storageRetentionTimeDays: "15"     # When to remove old data. In days.
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule" 
#   resources:
#     limits:
#       memory: 6Gi
#       cpu: 2000m
#     requests:
#       memory: 512Mi
#       cpu: 100m

# nats:
#   podTemplate:
#     merge:
#       spec:
#         nodeSelector: 
#           wallaroo.ai/node-purpose: persistent
#         tolerations:
#         - key: "wallaroo.ai/persistent"
#           operator: "Exists"
#           effect: NoSchedule

# wallsvc:
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"

persistentVolume Settings

Wallaroo services that have a persistentVolume have the following default nodeSelector label and tolerations:

  • nodeSelector
    • Label: wallaroo.ai/node-purpose
    • Value: persistent
  • tolerations
    • Key: wallaroo.ai/persistent
    • Operator: “Exists”
    • Effect: “NoSchedule”

For example:

nodeSelector:
  wallaroo.ai/node-purpose: persistent
tolerations:
  - key: wallaroo.ai/persistent
    operator: "Exists"
    effect: "NoSchedule"

If the nodeSelector or tolerations are changed for any service with a persistentVolume, all other services must be edited to match.

For additional information on taints and tolerations settings, see the Taints and Labels Guide.

Install Wallaroo with Helm

Additional Helm Installation Settings

This example shows additional optional settings. For full details on helm values for Wallaroo installations, see the Wallaroo Helm Reference Guides.

domainPrefix: "" # optional if using a DNS Prefix
domainSuffix: "wallaroo.example.com"

custTlsSecretName: cust-cert-secret

apilb:
  serviceType: LoadBalancer
  external_inference_endpoints_enabled: true
  ingress_mode: internal # internal (Default), external,or none

dashboard:
  clientName: "Wallaroo Helm Example" # Insert the name displayed in the Wallaroo Dashboard

kubernetes_distribution: ""   # Required. One of: aks, eks, gke, oke, or kurl.

# The nodeSelector and tolerations for all components
# This does not apply to nats, fluent-bit, or minio so needs to be applied separately
# nodeSelector:
#   wallaroo.ai/reserved: true

# tolerations:
# - key: "wallaroo.ai/reserved"
#   operator: "Exists"
#   effect: "NoSchedule"

# To change the pipeline taint or nodeSelector, 
# best practice is to change engine, enginelb, and engineAux 
# together unless they will be in different pools.
# engine:
#   nodeSelector:
#     wallaroo.ai/node-purpose: pipelines
#   tolerations:
#     - key: "wallaroo.ai/pipelines"
#       operator: "Exists"
#       effect: "NoSchedule"

# enginelb:
#   nodeSelector:
#     wallaroo.ai/node-purpose: pipelines
#   tolerations:
#     - key: "wallaroo.ai/pipelines"
#       operator: "Exists"
#       effect: "NoSchedule"

# engineAux:
#   nodeSelector:
#     wallaroo.ai/node-purpose: pipelines
#   tolerations:
#     - key: "wallaroo.ai/pipelines"
#       operator: "Exists"
#       effect: "NoSchedule"

# For each service below, adjust the disk size and resources as required.
# If the nodeSelector or tolerations are changed for one service, 
# the other services nodeSelector and tolerations **must** be changed to match
#
#
# plateau:
#   diskSize: 100Gi
#   resources:
#     limits:
#       memory: 4Gi
#       cpu: 1000m
#     requests:
#       memory: 128Mi
#       cpu: 100m
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"

# Jupyter has both hub and lab nodeSelectors and tolerations
# They default to the same persistent pool, but can be assigned to different ones
# jupyter:
#   nodeSelector:                 # Node placement for Hub administrative pods
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"
#   labNodeSelector:              # Node placement for Hub-spawned jupyterlab pods
#     wallaroo.ai/node-purpose: persistent
#   labTolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"
#   memory:
#     limit: "4"                  # Each Lab - memory limit in GB
#     guarantee: "2"              # Each Lab - lemory guarantee in GB
#   cpu:
#     limit: "2.0"                # Each Lab - fractional CPU limit
#     guarantee: "1.0"            # Each Lab - fractional CPU guarantee
#   storage:
#     capacity: "50"              # Each Lab - disk storage capacity in GB

# minio:
#   persistence:
#     size: 25Gi
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#   - key: wallaroo.ai/persistent
#     operator: "Exists"
#     effect: "NoSchedule"
#   resources:
#     requests:
#       memory: 1Gi

# postgres:
#   diskSize: 10Gi
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"
#   resources:
#     limits:
#       memory: 2Gi
#       cpu: 500m
#     requests:
#       memory: 512Mi
#       cpu: 100m

# Prometheus has the usual persistent options, but also a retention size
# The the size on disk and time can be configured before removing it.
# prometheus:
#   storageRetentionSizeGb: "10"        # Retain this much data, in GB.
#   storageRetentionTimeDays: "15"     # When to remove old data. In days.
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule" 
#   resources:
#     limits:
#       memory: 6Gi
#       cpu: 2000m
#     requests:
#       memory: 512Mi
#       cpu: 100m

# nats:
#   podTemplate:
#     merge:
#       spec:
#         nodeSelector: 
#           wallaroo.ai/node-purpose: persistent
#         tolerations:
#         - key: "wallaroo.ai/persistent"
#           operator: "Exists"
#           effect: NoSchedule

# wallsvc:
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"

persistentVolume Settings

Wallaroo services that have a persistentVolume have the following default nodeSelector label and tolerations:

  • nodeSelector
    • Label: wallaroo.ai/node-purpose
    • Value: persistent
  • tolerations
    • Key: wallaroo.ai/persistent
    • Operator: “Exists”
    • Effect: “NoSchedule”

For example:

nodeSelector:
  wallaroo.ai/node-purpose: persistent
tolerations:
  - key: wallaroo.ai/persistent
    operator: "Exists"
    effect: "NoSchedule"

If the nodeSelector or tolerations are changed for any service with a persistentVolume, all other services must be edited to match.

For additional information on taints and tolerations settings, see the Taints and Tolerations Guide.

Install Wallaroo with Helm

Additional Helm Installation Settings

This example shows additional optional settings. For full details on helm values for Wallaroo installations, see the Wallaroo Helm Reference Guides.

domainPrefix: "" # optional if using a DNS Prefix
domainSuffix: "wallaroo.example.com"

custTlsSecretName: cust-cert-secret

apilb:
  serviceType: LoadBalancer
  external_inference_endpoints_enabled: true
  ingress_mode: internal # internal (Default), external,or none

dashboard:
  clientName: "Wallaroo Helm Example" # Insert the name displayed in the Wallaroo Dashboard

kubernetes_distribution: ""   # Required. One of: aks, eks, gke, oke, or kurl.

# The nodeSelector and tolerations for all components
# This does not apply to nats, fluent-bit, or minio so needs to be applied separately
# nodeSelector:
#   wallaroo.ai/reserved: true

# tolerations:
# - key: "wallaroo.ai/reserved"
#   operator: "Exists"
#   effect: "NoSchedule"

# To change the pipeline taint or nodeSelector, 
# best practice is to change engine, enginelb, and engineAux 
# together unless they will be in different pools.
# engine:
#   nodeSelector:
#     wallaroo.ai/node-purpose: pipelines
#   tolerations:
#     - key: "wallaroo.ai/pipelines"
#       operator: "Exists"
#       effect: "NoSchedule"

# enginelb:
#   nodeSelector:
#     wallaroo.ai/node-purpose: pipelines
#   tolerations:
#     - key: "wallaroo.ai/pipelines"
#       operator: "Exists"
#       effect: "NoSchedule"

# engineAux:
#   nodeSelector:
#     wallaroo.ai/node-purpose: pipelines
#   tolerations:
#     - key: "wallaroo.ai/pipelines"
#       operator: "Exists"
#       effect: "NoSchedule"

# For each service below, adjust the disk size and resources as required.
# If the nodeSelector or tolerations are changed for one service, 
# the other services nodeSelector and tolerations **must** be changed to match
#
#
# plateau:
#   diskSize: 100Gi
#   resources:
#     limits:
#       memory: 4Gi
#       cpu: 1000m
#     requests:
#       memory: 128Mi
#       cpu: 100m
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"

# Jupyter has both hub and lab nodeSelectors and tolerations
# They default to the same persistent pool, but can be assigned to different ones
# jupyter:
#   nodeSelector:                 # Node placement for Hub administrative pods
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"
#   labNodeSelector:              # Node placement for Hub-spawned jupyterlab pods
#     wallaroo.ai/node-purpose: persistent
#   labTolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"
#   memory:
#     limit: "4"                  # Each Lab - memory limit in GB
#     guarantee: "2"              # Each Lab - lemory guarantee in GB
#   cpu:
#     limit: "2.0"                # Each Lab - fractional CPU limit
#     guarantee: "1.0"            # Each Lab - fractional CPU guarantee
#   storage:
#     capacity: "50"              # Each Lab - disk storage capacity in GB

# minio:
#   persistence:
#     size: 25Gi
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#   - key: wallaroo.ai/persistent
#     operator: "Exists"
#     effect: "NoSchedule"
#   resources:
#     requests:
#       memory: 1Gi

# postgres:
#   diskSize: 10Gi
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"
#   resources:
#     limits:
#       memory: 2Gi
#       cpu: 500m
#     requests:
#       memory: 512Mi
#       cpu: 100m

# Prometheus has the usual persistent options, but also a retention size
# The the size on disk and time can be configured before removing it.
# prometheus:
#   storageRetentionSizeGb: "10"        # Retain this much data, in GB.
#   storageRetentionTimeDays: "15"     # When to remove old data. In days.
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule" 
#   resources:
#     limits:
#       memory: 6Gi
#       cpu: 2000m
#     requests:
#       memory: 512Mi
#       cpu: 100m

# nats:
#   podTemplate:
#     merge:
#       spec:
#         nodeSelector: 
#           wallaroo.ai/node-purpose: persistent
#         tolerations:
#         - key: "wallaroo.ai/persistent"
#           operator: "Exists"
#           effect: NoSchedule

# wallsvc:
#   nodeSelector:
#     wallaroo.ai/node-purpose: persistent
#   tolerations:
#     - key: "wallaroo.ai/persistent"
#       operator: "Exists"
#       effect: "NoSchedule"

persistentVolume Settings

Wallaroo services that have a persistentVolume have the following default nodeSelector label and tolerations:

  • nodeSelector
    • Label: wallaroo.ai/node-purpose
    • Value: persistent
  • tolerations
    • Key: wallaroo.ai/persistent
    • Operator: “Exists”
    • Effect: “NoSchedule”

For example:

nodeSelector:
  wallaroo.ai/node-purpose: persistent
tolerations:
  - key: wallaroo.ai/persistent
    operator: "Exists"
    effect: "NoSchedule"

If the nodeSelector or tolerations are changed for any service with a persistentVolume, all other services must be edited to match.

For additional information on taints and tolerations settings, see the Taints and Tolerations Guide.

Install Wallaroo with Helm

  1. Install Wallaroo: The Wallaroo support representative will provide the installation command for the Helm install that will use the Wallaroo container registry. This assumes that the preflight checks were successful. This command uses the following format:

    helm install $RELEASE $REGISTRYURL --version $VERSION--values $LOCALVALUES.yaml
    

    Where:

    1. $RELEASE: The name of the Helm release. By default, wallaroo.
    2. $REGISTRYURL: The URl for the Wallaroo container registry service.
    3. $VERSION: The version of Wallaroo to install. For this example, 2024.1.0-5097.
    4. $LOCALVALUES: The .yaml file containing the local values overrides. For this example, values.yaml.

    For example, for the registration wallaroo the command would be:

    helm install wallaroo oci://registry.replicated.com/wallaroo/2024-1/wallaroo --version 2024.1.0-5097 --values values.yaml
    

    If any required elements are missing from the values.yaml file, an error is displayed. For example, leaving out the kubernetes_distribution field returns the following:

    Warning - kubernetes_distribution must be set in user provided values.yaml
    

    Upon successful installation, notes are published indicating the installed version, where to find documentation, etc.:

    NOTES:
    .
    
    Welcome to Wallaroo 2024.1.0
    
    1. Deployment Information:
      Name:             2024.1.0
      Release notes:    https://docs.wallaroo.ai/wallaroo-release-notes/wallaroo-release-202401
      Version:          v2024.1.0-5187
    
    2. Accessing Wallaroo
      Documentation:    https://docs.wallaroo.ai
      Dashboard:        https://jeffwill.wallaroocommunity.ninja
      Jupyterhub:       https://jeffwill.jupyter.wallaroocommunity.ninja
      Auth management:  https://jeffwill.keycloak.wallaroocommunity.ninja
    
    3. Useful Commands:
    
      - Helm tests are available by using: `helm test wallaroo`.
    
      - External load balancer hostname can be found by using:
    
          kubectl get svc api-lb-ext -n wallaroo  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
    
      - List Wallaroo namespaces, including pipeline deployments, but not including the main `wallaroo` namespace:
    
          kubectl get namespaces -l wallaroo-managed=true
    
      - In order to change any helm values:
    
          helm upgrade --install wallaroo oci://registry.replicated.com/wallaroo/uat-latest/wallaroo --version v2024.1.0-5187 --values $LOCALVALUES_YAML
    
     4. Uninstall:
    
      1. To uninstall/delete the Wallaroo deployment, run:
    
        kubectl delete ns wallaroo && kubectl delete \
          all,secret,configmap,clusterroles,clusterrolebindings,storageclass,crd \
          --selector app.kubernetes.io/part-of=wallaroo --selector kots.io/app-slug=wallaroo
    
      2. To delete all pipelines, run:
    
        kubectl delete ns -l wallaroo-managed=true
    .
    
  2. Verify the Installation: Once the installation is complete, verify the installation with the helm test $RELEASE command. A condensed display uses egrep to show only the test suite and phase status as follows. Replace wallaroo with the name of the helm release used.

    helm test wallaroo | egrep 'SUITE:|Phase:
    TEST SUITE:     wallaroo-fluent-bit-test-connection
    Phase:          Succeeded
    TEST SUITE:     nats-test-request-reply
    Phase:          Succeeded
    TEST SUITE:     wallaroo-wallaroo-test-connections-hook
    Phase:          Succeeded
    TEST SUITE:     wallaroo-test-objects-hook
    Phase:          Succeeded
    

    The following will show the full helm test output with notes.

    helm test wallaroo
    

    which displays the following:

    NAME: wallaroo
    LAST DEPLOYED: Fri May 17 14:00:04 2024
    NAMESPACE: wallaroo
    STATUS: deployed
    REVISION: 2
    TEST SUITE:     wallaroo-fluent-bit-test-connection
    Last Started:   Fri May 17 14:04:48 2024
    Last Completed: Fri May 17 14:04:51 2024
    Phase:          Succeeded
    TEST SUITE:     nats-test-request-reply
    Last Started:   Fri May 17 14:04:43 2024
    Last Completed: Fri May 17 14:04:48 2024
    Phase:          Succeeded
    TEST SUITE:     jefftest-wallaroo-test-connections-hook
    Last Started:   Fri May 17 14:04:24 2024
    Last Completed: Fri May 17 14:04:31 2024
    Phase:          Succeeded
    TEST SUITE:     jefftest-wallaroo-test-objects-hook
    Last Started:   Fri May 17 14:04:31 2024
    Last Completed: Fri May 17 14:04:43 2024
    Phase:          Succeeded
    NOTES:
    .
    
    Welcome to Wallaroo 2024.1.0
    
    1. Deployment Information:
      Name:             2024.1.0
      Release notes:    https://docs.wallaroo.ai/wallaroo-release-notes/wallaroo-release-202401
      Version:          v2024.1.0-5187
    
    2. Accessing Wallaroo
      Documentation:    https://docs.wallaroo.ai
      Dashboard:        https://jeffwill.wallaroocommunity.ninja
      Jupyterhub:       https://jeffwill.jupyter.wallaroocommunity.ninja
      Auth management:  https://jeffwill.keycloak.wallaroocommunity.ninja
    
    3. Useful Commands:
    
      - Helm tests are available by using: `helm test wallaroo`.
    
      - External load balancer hostname can be found by using:
    
          kubectl get svc api-lb-ext -n wallaroo  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
    
      - List Wallaroo namespaces, including pipeline deployments, but not including the main `wallaroo` namespace:
    
          kubectl get namespaces -l wallaroo-managed=true
    
      - In order to change any helm values:
    
          helm upgrade --install wallaroo oci://registry.replicated.com/wallaroo/uat-latest/wallaroo --version v2024.1.0-5187 --values $LOCALVALUES_YAML
    
     4. Uninstall:
    
      1. To uninstall/delete the Wallaroo deployment, run:
    
        kubectl delete ns wallaroo && kubectl delete \
          all,secret,configmap,clusterroles,clusterrolebindings,storageclass,crd \
          --selector app.kubernetes.io/part-of=wallaroo --selector kots.io/app-slug=wallaroo
    
      2. To delete all pipelines, run:
    
        kubectl delete ns -l wallaroo-managed=true
    .
    

At this point, the installation is complete and can be accessed through the fully qualified domain names set in the installation process above. Verify that the DNS settings are accurate before attempting to connect to the Wallaroo instance. For more information, see the Wallaroo DNS Integration Guide.

To add the initial users if they were not set up through Helm values, see the Wallaroo Enterprise User Management guide.

Required Installation Configurations

Once installed, the following actions are required settings are required to complete the setup process process.

DNS Services Integration

DNS services integration is required for Wallaroo Enterprise to provide access to the various supporting services that are part of the Wallaroo instance. These include:

  • Simplified user authentication and management.
  • Centralized services for accessing the Wallaroo Dashboard, Wallaroo SDK and Authentication.
  • Collaboration features allowing teams to work together.
  • Managed security, auditing and traceability.

The following guide is for standard DNS services.

Once integrated, users can access the following services directly from a URL starting with the suffix domain - this is the domain name where other DNS entries are appended to. For example, if the suffix domain is sales.example.com, then the other services would be referenced by https://api.sales.sample.com, etc.

Note that even when accessing specific Wallaroo services directly that the user must still be authenticated through Wallaroo.

ServiceDNS EntryDescription
Wallaroo Dashboardsuffix domainProvides access to a user interface for updating workspaces, pipelines, and models. Also provides access to the integrated JupyterHub service.
JupyterHubjupyterhubAllows the use of Jupyter Notebooks and access to the Wallaroo SDK.
APIapiProvides access to the Wallaroo API.
KeycloakkeycloakKeycloak provides user management to the Wallaroo instance.

Connections to Wallaroo services are provided as https://service.{suffix domain}. For example, if the domain suffix is wallaroo.example.com then the URLs to access the various Wallaroo services would be:

  • https://wallaroo.example.com
  • https://jupyter.wallaroo.example.com
  • https://api.wallaroo.example.com
  • https://keycloak.wallaroo.example.com

Prerequisites

  • Install Wallaroo Enterprise into a qualified environment. For more details, see the Wallaroo Install Guides and the Wallaroo Enterprise Install Guides.
  • Determine whether your organization will use a prefix or not as detailed above.
  • Generate or update the the SSL Certificates
  • Have access to internal corporate DNS configurations that can be updated. A subdomain for the Wallaroo instance will be created through this process.
  • Have the IP address for the Wallaroo instance.
  • Install kubectl into the Kubernetes cluster administrative node.

Wallaroo IP Address Retrieval Methods

The first step is to retrieve the IP address that is set to the DNS services.

Retrieve LoadBalancer IP with kubectl

For most organizations that install Wallaroo into a cloud based Kubernetes cluster such as Microsoft Azure, AWS, etc the external IP address is tied to Wallaroo LoadBalancer service. This can be retrieved with the kubectl command as follows:

  1. Retrieve the external IP address for your Wallaroo instance LoadBalancer. For example, this can be performed through the following kubectl command:

    kubectl get svc api-lb-ext -n wallaroo -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
    34.83.140.98
    

    Verify that the IP address is the one that is used either for clusters in an internal or external mode.

    An alternative to this command to show all services is the following:

    kubectl get svc  -A
    

    Example Result:

    kubectl get svc  -A
    NAMESPACE     NAME                      TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                         AGE
    default       kubernetes                ClusterIP      10.25.64.1     <none>          443/TCP                         50d
    gmp-system    alertmanager              ClusterIP      None           <none>          9093/TCP                        50d
    gmp-system    gmp-operator              ClusterIP      10.25.70.18    <none>          8443/TCP,443/TCP                50d
    kube-system   default-http-backend      NodePort       10.25.67.38    <none>          80:31378/TCP                    50d
    kube-system   kube-dns                  ClusterIP      10.25.64.10    <none>          53/UDP,53/TCP                   50d
    kube-system   metrics-server            ClusterIP      10.25.67.8     <none>          443/TCP                         50d
    wallaroo      alertconfig               ClusterIP      10.25.67.141   <none>          9094/TCP                        2m30s
    wallaroo      alertmanager              ClusterIP      10.25.77.167   <none>          9093/TCP                        2m30s
    wallaroo      api-lb                    ClusterIP      10.25.79.188   <none>          8080/TCP                        2m31s
    wallaroo      api-lb-admin              ClusterIP      10.25.70.0     <none>          9901/TCP                        2m31s
    wallaroo      api-lb-ext                LoadBalancer   10.25.69.9     34.83.140.98    80:30715/TCP,443:32664/TCP      2m31s
    wallaroo      dashboard                 ClusterIP      10.25.72.14    <none>          4567/TCP                        2m31s
    wallaroo      edge-lb                   LoadBalancer   10.25.69.175   35.247.14.253   8081:32744/TCP,8443:30087/TCP   2m31s
    wallaroo      wallsvc                   ClusterIP      10.25.75.74    <none>          3040/TCP                        2m30s
    

    Some cloud providers may provide multiple external IP addresses for the api-lb service. For some services such as Oracle, this is typically a 10 net address, with the second IP address being the actual external address. Verify the IP address before changing DNS settings.

Other Methods

For organizations that install Wallaroo other methods, such as Air Gap or Single Node Linux may find the kubectl get svc api-lb-ext command only returns the internal IP address.

Depending on the instance, there are different methods of acquiring that IP address. The links below reference difference sources.

Refer to your Wallaroo support representative if further assistance is needed.

DNS Entries

Create DNS the following entries based on the list above for the Wallaroo instance’s IP address. Select the cloud environment used for DNS services.

AWS Setup

The following settings are used with AWS EKE clusters through Route 53. For more information, see Enabling DNS resolution for Amazon EKS cluster endpoints.

Set the following domain names for the Wallaroo instance.

For AWS Clusters:

  1. Suffix Domain: CN (CNAME) record referring to the AWS EKS cluster endpoint. For example: wallaroo.example.com.
  2. api: CN (CNAME) record referring to the AWS EKS cluster endpoint. For example: api.wallaroo.example.com.
  3. jupyter: CN (CNAME) record referring to the AWS EKS cluster endpoint. For example: jupyter.wallaroo.example.com.
  4. keycloak: CN (CNAME) record referring to the AWS EKS cluster endpoint. For example: keycloak.wallaroo.example.com.

For clusters managed by other cloud services:

  1. Suffix Domain: A record, NS (Name Server) record, SOA (Start Of Authority) record. For example: wallaroo.example.com
  2. api: CN (CNAME) record referring to the cluster endpoint. For example: api.wallaroo.example.com.
  3. jupyter: CN (CNAME) record referring to the cluster endpoint. For example: jupyter.wallaroo.example.com.
  4. keycloak: CN (CNAME) record referring to the cluster endpoint. For example: keycloak.wallaroo.example.com.
Azure Setup

The following settings are used with Microsoft Azure DNS Records. For more information, see Manage DNS records and record sets by using the Azure portal.

  1. Suffix Domain: A record, NS (Name Server) record, SOA (Start Of Authority) record. For example: wallaroo.example.com
  2. api: CN (CNAME) record referring to the cluster endpoint. For example: api.wallaroo.example.com.
  3. jupyter: CN (CNAME) record referring to the cluster endpoint. For example: jupyter.wallaroo.example.com.
  4. keycloak: CN (CNAME) record referring to the cluster endpoint. For example: keycloak.wallaroo.example.com.
GCP Setup

The following settings are used with Google Cloud Platform DNS Records. For more information, see GCP Add, modify, and delete records.

  1. Suffix Domain: A record, NS (Name Server) record, SOA (Start Of Authority) record. For example: wallaroo.example.com
  2. api: CN (CNAME) record referring to the cluster endpoint. For example: api.wallaroo.example.com.
  3. jupyter: CN (CNAME) record referring to the cluster endpoint. For example: jupyter.wallaroo.example.com.
  4. keycloak: CN (CNAME) record referring to the cluster endpoint. For example: keycloak.wallaroo.example.com.
Oracle Setup

The following settings are used with Oracle Cloud Platform DNS Records. For more information, see Configuring DNS Servers for Kubernetes Clusters.

  1. Suffix Domain: A record, NS (Name Server) record, SOA (Start Of Authority) record. For example: wallaroo.example.com. IMPORTANT NOTE: Oracle OKE clusters have two IP addresses for the load balancer endpoint. Use the public IP address, not the internal 10-net address.
  2. api: CN (CNAME) record referring to the cluster endpoint. For example: api.wallaroo.example.com.
  3. jupyter: CN (CNAME) record referring to the cluster endpoint. For example: jupyter.wallaroo.example.com.
  4. keycloak: CN (CNAME) record referring to the cluster endpoint. For example: keycloak.wallaroo.example.com.
Other DNS Services

Set the following domain names for the Wallaroo instance.

  1. Suffix Domain: A record, NS (Name Server) record, SOA (Start Of Authority) record. For example: wallaroo.example.com
  2. api: CN (CNAME) record referring to the Suffix Domain. For example: api.wallaroo.example.com.
  3. jupyter: CN (CNAME) record referring to the Suffix Domain. For example: jupyter.wallaroo.example.com.
  4. keycloak: CN (CNAME) record referring to the Suffix Domain. For example: keycloak.wallaroo.example.com.

Edge Observability Enablement

For organizations that deploy Wallaroo pipelines on edge devices as Wallaroo Servers, see the DNS settings from the Edge Deployment Registry Guide.

Setup Users

User management is managed through the Wallaroo Dashboard, via the Platform Admin Dashboard page. See the Wallaroo User Management for full guides on setting up users, identity providers, and other user configuration options.

The following is an abbreviated guide on setting up new Wallaroo users.

The process includes the following steps:

Obtain the User Admin Credentials

Obtaining the admin User Credentials

The standard Wallaroo installation creates the user admin by default and assigns them a randomly generated password. The admin user credentials are obtained which may be obtained directly from Kubernetes with the following commands, assuming the Wallaroo instance namespace is wallaroo.

  • Retrieve Keycloak Admin Username

    kubectl -n wallaroo \
    get secret keycloak-admin-secret \
    -o go-template='{{.data.KEYCLOAK_ADMIN_USER | base64decode }}'
    
  • Retrieve Keycloak Admin Password

    kubectl -n wallaroo \
    get secret keycloak-admin-secret \
    -o go-template='{{.data.KEYCLOAK_ADMIN_PASSWORD | base64decode }}'
    

Create a New User with the Admin Role

Creating users is managed through the Platform Admin Dashboard. The following steps are used to create an initial user with the role admin.

  1. Access the Wallaroo Dashboard through the DNS name set up in the DNS Services Integration step. For example, if the DNS name of the Wallaroo Ops center is wallaroo.example.com, the Wallaroo Dashboard is available at https://wallaroo.example.com.
  2. Login with the username admin and the password retrieved in Obtaining the admin User Credentials.
  3. Select Create Users and enter the following:
    1. User Email: The email address for the user. This must be in the valid email address format.
    2. Assign Type: Select Admin.
    3. Password: Enter the user’s password. This user password be sent to the new user.
    4. Temporary or Permanent:
      1. Temporary: The user will be forced to change their login password upon their next login (Recommended).
      2. Permanent: The user will keep their password.
  4. Create any additional users as needed. When finished, select the Wallaroo icon drop down and select Logout.

At this point, users can log in to Wallaroo Dashboard with their provided identities. For guides on setting up Single Sign-On (SSO) and other features, see Wallaroo User Management for full guides on setting up users, identity providers, and other user configuration options.