Kubernetes : Generic

Overview of Installing on a Generic Kubernetes Engine

Although we’ve written specific installation instructions for some of the most commonly used Kubernetes engines on the market, OpenSquiggly can be installed on any Kubernetes system of your choice. You just need to specify the appropriate values when installing the Helm chart to control the various resources that the Helm chart creates.

If you’re installing on a supported cloud provider, you can skip this section and go to the section for your target cloud provider.

In this section we’ll walk you through the process of installing OpenSquiggly on an unlisted Kubernetes system.

Parameter Simplification

A primary goal of our Helm charts is to simplify and minimize the number of settings you need to specify to get OpenSquiggly running. Though we have quite a few potential settings you can use, we hope that you don’t need to read and understand the entire list of settings to get a basic instance running.

Toward that end, we have the cloudType setting that provides appropriate default values for that particular flavor of Kubernetes. For any specific cloudType, you can always replicate an equivalent configuration using cloudType=other and specifying additional parameters.

As you can see from the above table, using an unlisted flavor of Kubernetes is simply a matter of determining which storageProvisioner the Kubernetes engine provides, along with any customized disk parameters (the diskSkuName and diskType).

Persistent Volumes, Claims, & Storage Classes

OpenSquiggly needs a persistent volume (PV), which it gets by asking a persistent volume claim (PVC) to give it one. A PVC can be configured to dynamically provision a new PV on request, or it can be configured to serve up an already existing PV.

If the PVC is going to dynamically provision a new PV, then it needs to know needs to know what StorageClass class it should use, and the StorageClass in turn needs to know what Storage Provisioner it should use. Our Helm chart provides switches that can control what resources are needed depending on what you want.

In the following table, we assume you are using Helm to install an OpenSquiggly release named releasename such as with the following command:

helm install releasename opensquiggly/allinone --set cloudType=other,...other parameters to set go here as shown below...

Creating a Custom Storage Class

There are limits to OpenSquiggly’s Helm charts for creating storage classes. They don’t have the ability to apply custom annotations or to apply any other parameters to the StorageClass except skuname and type.

In this case, you can always create the StorageClass yourself using a custom manifest file, and then pass the name of the StorageClass to the Helm chart using the useExistingStorageClass parameter.

Here is a template for creating a StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
allowVolumeExpansion: true
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    kubernetes.io/cluster-service: "true"
  name: your-storageclass-name-here
parameters:
  skuname:   # For Azure SSD, enter Premium_LRS
  type:      # For Google SSD, enter pd-ssd
provisioner: storageprovisioner-name-here
reclaimPolicy: Retain    # Enter Retain or Delete (Retain recommended)
volumeBindingMode: WaitForFirstConsumer

Save the above template to filename.yaml, fill in the parameters as appropriate, and run the command:

kubectl apply -f filename.yaml

We always recommend using a reclaimPolicy of Retain to prevent accidental deletion of your data in the event you uninstall the Helm chart.

List of All Helm Chart Values