chapter1.tex (3917B)
1 Helm is a system for managing \Glspl{k8sResources} and being able to deliver a simple to deploy bundle to administrators using \Gls{k8s} similar to Docker Compose or Ansible. 2 3 It is one of the most used packaging systems in the \Gls{k8s} ecosystem and helps to provide a consistent \gls{ux} in the ecosystem. 4 5 \section{Helm as a packaging system} 6 Helm refers to itself as \enquote{The package manager for Kubernetes}\cite{helmauthorsHelm}. 7 This means it's main goal and design is centered around being able to package an application, deal with dependencies and versioning. 8 9 As a result of this Helm is a generic way to define an application deployment. 10 In doing that it shares similarities with systems like Ansible, nix and other packaging solutions in the Linux world. 11 In the typical Docker illustration style the Helm deployment would be a delivery which contains a given set of Containers which are delivered together to build a single big thing. 12 13 \section{Helm as a template engine} 14 As part of being a package manager for Kubernetes it has to deal with definitions written in pure YAML. 15 Therefore it features a powerful template engine which works similar to how Ansible's template engine works. 16 17 Under the hood this is achieved by using the Go template language\cite{helmauthorsTemplateFunctionsPipelines,thegoauthorsTemplatePackageText} as well as additional go functions provided to the users. 18 19 On top of the template language itself it also provides the option to print messages at the end of the installation or upgrade as well as nesting charts, having libraries for charts and using a global value context. 20 These are needed to provide consistent Helm charts across a company or set of related charts and to ensure a nice \gls{ux} for those deploying said chart. 21 22 \section{Features Helm gives us over pure \Glspl{k8sResources}} 23 Pure \Glspl{k8sResources} come with multiple downsides over Helm or similar packaging systems for \Gls{k8s}. 24 25 \Gls{k8s} brings no update management or atomic deployment management itself. 26 This means that an admin would need to ensure that they manually deploy each thing every time, possibly in the correct order and then has to ensure that it did not break. 27 If despite all efforts it did break you now end up with no easy way to rollback. 28 Ideally one has a VCS to go from but this might not be a safe operation either and may lead to new issues. 29 30 Helm on the other side brings two major things to the table. 31 It provides a way to manage the chart version independent of the product version. 32 This is called the \emph{version} of the Helm package, while the version of the product is called \enquote{\emph{appVersion}} in Helm. 33 Helm also provides you with a history of deployments. 34 This list tracks if a deployment is in progress, successful, failed or rolled back. 35 Due to this list Helm allows you to seamlessly \emph{rollback} to any prior deployment you made.\footnote{While a \emph{rollback} is possible it is not possible to jump forward afterwards} 36 Additionally to the manual rollback Helm has the feature of atomic updates, which automatically will roll back to the last successful deployment version in case of invalid templates, values\footnote{Only syntactic errors} or failures to roll out the deployment within the given timeout period. 37 38 Beyond the managing of versions and updates Helm also provides a way to share and therefor depend on other charts. 39 To do this Helm has it's own Chart-repository setup or can use regular \gls{oci} repositories. 40 Using these repositories it allows then to define dependencies on existing Helm charts. 41 This is especially useful to fulfill the goal of having a single deployable bundle for an application. 42 For example an API server might want to bundle a PostgreSQL Helm chart as a dependency. 43 Instead of then defining it themselves it can depend on existing Charts and provide a consistent experience for consumers in the ecosystem.