It is best to use a managed Kubernetes service. EKS in AWS or similar would be preferable for most companies, given the inherent cost and complexity in trying to manage Kubernetes clusters and nodes yourself. However, some firms may want to have their operations team control their infrastructure and their deployed containers. There are some options if this is the case, two of them being Helm Charts and Kubernetes Operators.
Day 0
After deploying a K8s cluster, and providing IAM and RBAC access, engineers will need an OS for the application stack, a database for the application, a load balancer for the containers and a reverse proxy for security (amongst many other components). This is termed Day 0 Operations. So what do you do?
In this use case the Kubernetes cluster can be considered a platform or as an OS; with Helm as the tool which enables users to install an application on that Kubernetes cluster. Helm is a packaging format that works well with simple applications like stateless microservices and REST APIs with states stored externally in say Postgres or Aurora.
Day 1 plus
The application stack and number of containers grow, as the team becomes more experienced and end user requirements change. More complex logic around state and user management develop. Such complexity creates challenges for authoring the Helm charts-templatized YAML manifests and at some point it is time to adopt the powerful operator pattern supported in Kubernetes.
Helm Charts
Helm is an open-source project created by DeisLabs and donated to the Cloud Native Computing Foundation, which now maintains it. Helm is a package manager designed specifically for Kubernetes and improves the management of the YAML manifests required to create Kubernetes projects.
At the heart of Helm is the packaging format called charts. Each chart comprises one or more Kubernetes manifests — and a given chart can have child charts and dependent charts, as well. Thus, Helm can tackle the complexities of dependency management for a Kubernetes project. Rather than an IT admin simply listing the files to install via kubectl, a single command can install an entire application, and Helm will pull the required dependencies and apply the manifests.
Charts enable IT admins to version manifest files, like with Python packages or NuGet libraries. IT admins can install specific chart versions, which keeps specific configurations for the infrastructure as code. Helm charts can be shared across an organization by hosting them on a private repository, using multiple cloud services, such as GitHub pages, JFrog Artifactory or using cloud storage back ends.
Helm also retains a release history of all deployed charts, so IT teams can go back to a previous release if something goes wrong.
Kubernetes Operators
KO automate mundane common tasks and are built into the platform and used by administrators. They are akin to scripts or a configuration management tool such as Chef or Puppet. They can be used with Helm Charts, it is not necessarily an either, or decision.
There are some use cases where the application’s complex requirements are difficult to express in YAML manifests using templates (this is somewhat rare). But if there are such applications your organization does need to support, teams should use Kubernetes operators. Operators enable IT teams to encapsulate this knowledge of running applications via general-purpose programming languages like Go, Python and Java, and run it natively on the Kubernetes platform.
KO’s targets SRE or site-reliability-engineering teams, to manage the runbooks that orchestrate the deployment of a complex application, along with automating mundane tasks for the Kubernetes platform. An IT admin can define the resources in Kubernetes and publish logic — via an operator — that can handle CRUD operations for the custom resource. These custom resources can model a complex application or a standard templatized application; the operators maintain the resource’s lifecycle.
There are several available frameworks that facilitate operator development:
Kubernetes operators vs. Helm
On a very high level, both Helm charts and Kubernetes operators do the same thing, more or less, but their adoption depends on various conditions such as cluster adoption, team maturity and application requirements.
For teams just beginning to run Kubernetes clusters that want to deliver simple applications to users, packaging these applications via Helm charts provides benefits for simpler templatized YAML manifests. Helm charts enable the IT ops team to package, version and share the applications with their dependencies, which enables rapid application delivery. Authoring Helm charts requires familiarity with YAML and uses the Go template engine along with the Sprig template library.
As teams and the Kubernetes cluster usage matures, there might be mundane tasks and complicated requirements for applications to run. This is the point at which the IT ops team should add Kubernetes operators to the mix. And authoring Kubernetes operators means that the team must maintain this codebase over time.
In general, Helm charts are most useful when first setting up a Kubernetes cluster to deploy simple applications. Helm charts can handle the install-update-delete lifecycle for the applications deployed to the cluster.
Operators come in handy when teams want to implement a complex, custom configuration or deploy a special application that involves a lot of operational expertise.
