Installation using Helm¶
Helm is a package manager for Kubernetes, and is the preferred way to install and deploy Ververica Platform. In Helm a package is called a Chart, and it contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. Charts are essentially just a collection of Templates and some input Values, which Helm refers to as Manifests that are then rendered into Kubernetes resources.
Before continuing, please read the documentation about the Ververica Platform Docker images and take any necessary action.
You must have a working Kubernetes environment, an installation of the
helm CLI tool, and a
healthy “Tiller” pod—Helm’s server-side component—running on your cluster. Setting up Helm is
not covered by this guide, so please refer to the Helm documentation for further information.
If your Kubernetes cluster is enabled with RBAC, you may get an “access denied” error when trying to use Helm. If this is the case, make sure you have created a service account and role binding according to the documentation.
If you plan to use the Ververica Docker registry, or any other private registry requiring authentication, it’s important to keep this in mind when installing Application Manager. Currently in this scenario you must install Application Manager to a Namespace that has an imagePullSecret configured and bound to the default ServiceAccount for that Namespace. In addition to this you must also reference this imagePullSecret at install time so Helm will add it to the custom ServiceAccount that Application Manager uses by default.
To verify that your environment is prepared, the following commands should complete without error:
$ kubectl get pods $ helm list
If you are working in a Kubernetes namespace that is not the default specified in your local Kubernetes configuration file, you can specify the namespace in the above command as follows:
$ kubectl --namespace my-namespace get pods
Similarly, if you set up Helm to use a non-default namespace for its Tiller pod, you can specify it in the above command as follows:
$ helm --tiller-namespace my-tiller-namespace list
Overriding chart values¶
Helm provides several options for setting and overriding the values in a chart. These consist of the following:
-f, --values valueFilesspecify values in a YAML file or a URL (can specify multiple)
--set stringArrayset values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
--set-file stringArrayset values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2)
--set-string stringArrayset STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
For the Ververica Platform charts the two methods we’ll cover here are
--values. Specifically using
--set-file we can specify a key/option to set and a file to obtain the contents/value from. This is the preferred method of specifying the license file for Application Manager, like so
Notes about the Ververica Platform chart default values:
- If no license file is referenced, Application Manager will operate in a limited trial mode, with its capabilities restricted.
- By default, the chart uses the Docker registry hosted by Ververica. To specify your own registry, override the appropriate image/registry values for the respective chart component. (See Ververica Platform Docker Images)
- By default, the chart will create and manage persistent volumes for the components that
require them. For this to work, your Kubernetes installation must have a default StorageClass
configured. You can use any existing PersistentVolumeClaims that you might have by using the respective
*.persistentVolume.existingClaim: ""options for each of the components.
- If your Kubernetes installation uses role-based access control (RBAC), you must specify either
appmanager.rbac.create: true(default) or reference an existing ServiceAccount that you manage using the
Helm is fortunate to have an offline templating option, this is useful for debugging charts, and as a kind of dry-run/preview mode. Using the following command, you can render a Helm chart and see what it would create in your Kubernetes cluster (the target Helm chart can be either the .tar.gz archive you downloaded, or the resulting folder if you extracted it, both are valid):
$ helm template --debug daplatform
Similarly you can preview this with a custom values specified also:
$ helm template --debug daplatform --set-file appmanager.license=license_file $ helm template --debug daplatform --values values.yaml
--debug flag to
helm template exposes several important pieces of information:
USER-SUPPLIED VALUES: as the name suggests, these are any values provided by the user, using any of the methods outlined above. This is useful for seeing how Helm has interpreted your input if it’s not behaving as you expected.
COMPUTED VALUES: this is a combination of the user-supplied values, and the defaults, showing what will be used in the Helm charts ultimately. This is useful for seeing what other values are being set (defaults), and what you can change/override without having to resort to extracting the Helm release and inspecting the raw yaml files directly. Although this is a valid option when needed. This is a good source of information for creating your own
MANIFEST: this is a default section not specific to the
--debugoutput and shows the manifests/kubernetes resources in yaml format that Helm will create. This can help to contextualize the various values in the
COMPUTEDvalues sections above.
The output of
helm template will contain the string
RELEASE-NAME in many places. This is a special Helm variable, which will be replaced by Helm when you install the Chart. It is determined by the
--name parameter, which we recommend setting to
daplatform, or dynamically set by Helm if not specified.
Completing the installation using Helm¶
With the included Helm chart (named
daplatform-1.3.4.tgz) and the
values.yaml file generated in
the previous step, complete the installation using
helm install. To install into the Kubernetes
my-namespace and call the release
$ helm install \ --namespace my-namespace \ --name daplatform \ --set-file appmanager.license=path/to/the/license_file \ daplatform-1.3.4.tgz