This article provides an overview of Helm and how it can be used by DevOps teams to easily deploy Quantexa (and many other applications) in Kubernetes based deployment architectures. It outlines the many benefits that Helm provides to make repeatable, production ready deployments. It also covers how the Quantexa Helm Chart is provided, and the “open” nature of the chart to allow our customer flexibility in it’s use.
TL-DR - You should use the Quantexa provided Helm chart to deploy the Quantexa Platform into Kubernetes as this will make your life easier!
What is Helm?
Helm is effectively a Package Manager for Kubernetes. It allows applications to be easily installed into a Kubernetes cluster in a pre-defined, versioned, configuration as code driven, best practice deployment pattern.
The central concept of Helm is the Helm Chart which is the “recipe” for deploying the application at hand. These charts are comprised of a set of YAML files, which look similar to raw Kubernetes manifests, but support templating and therefore the application of deploy-time parameterisation and feature switching.
They are particular useful for making the installation of multi-container deployments, such as the Quantexa Application Tier, a much easier and repeatable task yielding an operationally ready set of services.
When should I use Helm to deploy Quantexa?
For any of our customers using Kubernetes, using our Quantexa Helm Chart is the recommended way to deploy the Quantexa Application Tier to their clusters. In this section we outline the key benefits this provides, and some potential considerations. However, it would be rare for us to identify cases where the chart should not be used, at least in part, to achieve a more best practice, operationally ready deployment.
Pros of using Helm
Many of the benefits of using Helm are universal across all deployments, we’ve highlighted these here and drawn out some of the more important ones for Quantexa users:
- Allows the use of best practice deployment patterns which have been proven to work, to allow reproducible deployments and easy environment promotions.
- Specific deployment configurations per environment are possible through the use of different Helm Chart “values” changing various settings within the constraints and pre-defined patterns whilst using a single Helm Chart.
- Simple mechanism to roll-out and roll-back which can be easily integrated into CI/CD pipeline.
- Allows customers to use a given piece of software in the manner intended by the provider. For Quantexa, our chart encapsulates how our Application Tier should be deployed for optimal experience.
- Charts allow for complex underlying interactions between multiple pods and changes to such interactions during software upgrade to be abstracted away from the developer/deployer. (For example, in our Quantexa’s recent upgrade to migrate from Akka based to gRPC based intra-service communication Helm chart users would have adopted this change without specific consideration).
- Best practice Kubernetes resource configuration settings are easy to apply. For example, for Quantexa our Helm Chart makes it easy for customers to:
- Seamlessly allow our etcd service discovery to leverage the headless services needed for replication and hence achieve highly-available Quantexa deployments
- Mount application configuration at run-time via ConfigMap resources allowing deployment characteristics to be modified without re-building containers where possible.
- Safely inject the range of Secrets needed to secure sensitive information used by our Quantexa applications.
- Easily leverage “second-order” settings for container that allow use of features needed for a more scalable, operational ready deployment such as annotations, labels, nodeSelectors, PodDistruptionBudgets etc.
- For Quantexa customers using our Helm chart allows us to provide the richest Product Support experience in the even that you encounter any challenges during deployment or its use in production.
Enterprise Readiness Considerations
Quantexa recognizes that many of our customers have many enterprise grade requirements to meet. Often in such organizations, Kubernetes cluster administrators may have applied specific cluster security settings or have specific Kubernetes deployment standards and patterns they want to enforce. This means that there is not always a “one size fits all” solution to how a given application can be deployed to Kubernetes.
As with most software providers, Quantexa’s approach here is to try to build for most of this common configurations with the large range of parameterization options that Helm provides. This allows different feature switches to be activated by a given customer as needed. We also provide the source (configuration as code) for our Helm chart to our customers and encourage them to re-use as much as possible whilst adapting it if they have specific requirements.
It’s also worth noting that Helm version 3 made a significant improvement to the security model of how Helm interacted with Kubernetes. In previous versions, Helm required elevated permissions to operate, now Helm uses the permissions of the user or service account interacting with Kubernetes which allow the use of fine-grained RBAC to achieve security best practice. So for teams who initially turned away from Helm for this reason it’s definitely worth revisiting.
The Quantexa Helm Chart
Quantexa provide our customers with the following access to our Helm Chart, these are accessible to any developer who has access to our GitHub in our quantexa-external organisation:
- in its pre-packaged form in a Helm Repository;
- as a full set of source YAML files for adaptation.
Where possible our customers should seek to use the first of these options as it has configuration options supporting many common use cases. We welcome feedback and suggestions and additional features that customers think should be included.
Read more about this on our documentation site: Introduction to Quantexa App Tier Helm Chart
The Quantexa Helm Chart deploys all Quantexa Application Tier components in their best practice configuration. This includes:
- Standardised deployment model (ie defined Kubernetes resource types)
- Recommended resource settings
- ConfigMap and Secret mounting standards
- Prometheus metrics for monitoring
- Log exporting for Rest API requests
- High Availability
- Application fault tolerance
- Self healing
- Rolling upgrades
- Istio compatibility for service mesh based security
This chart is used regularly within Quantexa to run a variety of our own deployments and as such is effectively “battle tested”.
The Quantexa Helm Chart also includes references to open source Kubernetes deployments of etcd and postgres (for use in development settings only) - these are both optional and customers may wish to supply their own.
What does it not contain?
Our Helm chart only deploys the application tier for Quantexa, our (Spark based) batch components have alternative deployment methodologies.
Other than the exceptions of etcd and postgres noted above, the Quantexa Helm Chart does not provide third-party dependencies. For example, a customer would need to provide Elasticsearch, a supported RDBMS and any operational tooling such as Prometheus, Grafana and Airflow themselves alongside if needed.
Extending and Contributing
To allow customers flexibility to adapt the Quantexa Helm Chart to their needs, particularly enterprise customers with potentially very specific security requirements, we encourage people to take the source YAML files of the chart and fork it to meet their needs.
Where features are identified as being widely applicable, we encourage our customers to submit features requests to our Product Management team who will facilitate in the prioritisation of these features onto the Quantexa Platform roadmap.
Micro-services Architecture Considerations
When designing new cloud-native / Kubernetes native solutions from scratch it has been common recently to aim for a pure micro-services architecture. Whilst, these architectures bring many benefits, for them to be universally applied within a cluster, this would usually require very strong control and homogeneity across all workload deployment patterns. This is typically only true where you are responsible for the development of all of those workloads themselves. Whereas in a cluster where many COTS products are use this is a harder pattern to rigidly enforce.
Two specific considerations for the Quantexa Helm chart people should be aware of are as follows:
- We aim for stateless deployments where possible but i) we do make use of StatefulSet resources to provide headless services with stable unique network identifiers (not to actually provide state), ii) etcd, by default, requires a stateful deployment, whilst this can be worked around if required we recommend not making this stateless in this instance.
- Quantexa has a micro-services architecture, but currently (to support legacy non-Kubernetes deployment patterns) it is common to bundle multiple services into a single application. We also have some highly intensive services due to the complexity of the entity resolution we perform. For these reasons it is required to provide the ability to use “non-micro” resource allocations, e.g. 8vCPU requests is not uncommon so clusters cannot limit workloads to very small requests eg a 2vCPU limit would be insufficient.
Future development - the Quantexa Kubernetes Operator
Increasingly software providers are looking beyond Helm Charts where they are providing potentially highly complex distributed software platforms. Whilst a Helm Chart provides and excellent foundation to create and manage Kubernetes resources, where an applications' architecture gets very complex and potentially needs some bespoke handling to achieve lifecycle management (for example supporting fully rolling upgrades). It also helps further simplify the deployment and management of the Quantexa Application Tier for DevOps teams, as the Kubernetes Operator itself takes on much more of this responsibility. In such instances, then a Kubernetes Operator may provide great flexibility to implement custom logic in this regard. Quantexa is currently under-going a research project to assess the viability of an Operator based deployment model - watch this space…
