Helm Concepts: Difference between revisions
(→TODO) |
|||
| Line 109: | Line 109: | ||
* If I rely on a dependency referred from an external [[#Repository|Helm repository]], and the repository exposes newer versions, can I still rely on the fact that the old version is still available? I might not want to upgrade to the "latest", but keep using a version I tested with and was proven stable. | * If I rely on a dependency referred from an external [[#Repository|Helm repository]], and the repository exposes newer versions, can I still rely on the fact that the old version is still available? I might not want to upgrade to the "latest", but keep using a version I tested with and was proven stable. | ||
</font> | </font> | ||
==Dependency Operations== | ==Dependency Operations== | ||
Revision as of 21:33, 28 August 2019
Internal
Overview
Chart
A chart is a Helm package and a package format, the Kubernetes equivalent of a yum RPM file or a Homebrew formula. A chart contains all resource definitions necessary to deploy and run an application inside Kubernetes, arranged in a specific layout. A chart may be used to deploy a simple application, or a full web application stack with multiple dependencies, such as HTTP servers, database, caches and so on.
Chart Name
A chart is identified by its name in repositories. Examples: "nginx" or "postgresql". For custom charts, the name of the chart is specified in the name field of the Chart.yaml metadata file.
Chart Versioning
Chart.yaml carries two version fields: the chart version (version) and the application version (appVersion).
Every chart must have a SemVer 2 version specified as the version field of the Chart.yaml metadata file. Packages exposed by repositories, as well as. packages generated by helm package are identified by their name and their version. For example, the chart archive of an "nginx" package whose version filed is "1.2.3" will be named "nginx-1.2.3.tgz". Helm also uses the version number as release marker. Many other Helm tools, such as the CLI and the Tiller server use the version information. It is assumed that the version number in the chart package name matches the version field in Chart.yaml. A mismatch will cause errors.
The appVersion field is intended to carry an informal application version, not necessarily SemVer 2, and is not related to the version field. This field is informational, and has no impact on chart version calculations.
Chart Archive
A chart archive is a chart in a packaged format (see helm package). The chart repositories expose chart archives.
Chart Installation
Charts are installed into a target Kubernetes cluster and turned into releases with helm install. The installation is an asynchronous process, the Helm client does not wait until all resources are running before it exits, this is because charts may require large Docker images that take long to install in the cluster. Without additional input, a chart will be installed with the default configuration, but custom configuration changes can be applied during the installation process.
The default option for the helm install command is to install from the default repository. However, the chart may come from other sources: a different repository, a local file, an unpacked chart directory or a URL.
Chart Configuration
Charts may, and usually will, expose configuration options. To see what configuration options are available for a chart use helm inspect values. Any available configuration options can be overridden by providing a YAML-formatted file that is then passed during installation with the helm install -f|--values flag.
Default Configuration
Chart Layout
This section describes a typical chart directory tree. The top level directory is the chart name, without the version information.
archaeopteryx | |- Chart.yaml |- values.yaml |- requirements.yaml |- LICENSE |- README.md |- .helmignore |- charts +- templates | |- NOTES.txt |- _helpers.tpl |- deployment.yaml |- service.yaml | ... +- tests
charts/ Directory
The 'charts' directory contains any manually-managed charts upon which this chart depends. For a discussion on dependencies, see the Dependencies section.
templates/ Directory
The 'templates' directory contains templates that, when combined with values, will generated Kubernetes manifest files.
Developing Custom Charts
The development of a custom chart could start with helm create, which is a command that creates a standard chart directory layout along with some common files typically used in a chart. The command provides just a basic example and is not meant to cover all Kubernetes resources. While a chart is being developed, the syntactic consistency can be checked with helm lint. Then the chart is ready for delivery, it can be packaged with helm package.
TODO: https://helm.sh/docs/developing_charts/.
Chart Operations
Dependencies
Applications, with the exception of the most trivial, usually depend on other runtime components, such as web servers, caches, databases, etc. Helm provides a mechanisms to formally specify and managed these dependencies.
There are two ways to specify dependencies:
- Dynamically by specifying a dependency chart's name, version and repository in requirements.yaml.
- Manually by bringing the chart archive in the charts/ sub-directory of our chart and manage it manually.
The preferred method to manager dependencies is the dynamic one: declare the dependencies in requirements.yaml. Manual dependency management might be needed in specific cases, though.
The dependencies declared in requirements.yaml can get aliases.
Dependency Selective Loading
All dependencies declared in requirements.yaml are loaded by default. However, tags and conditions can be used to perform selective loading. Conditions are YAML paths specified in values.yaml that can be declared to be 'true' or 'false'. Tags are list of labels associated with a specific dependency. The tags can be enabled or disabled in values.yaml by specifying the tag and a boolean value. Also, the helm instal --set parameter can be used to alter tag and condition values at installation time.
TODO: https://helm.sh/docs/developing_charts/#tags-and-condition-resolution.
Importing Child Values
TODO: https://helm.sh/docs/developing_charts/#importing-child-values-via-requirements-yaml
TODO
- Clarify the need for helm dependency update in case of dynamic dependencies. What happens if we don't do it.
- If I rely on a dependency referred from an external Helm repository, and the repository exposes newer versions, can I still rely on the fact that the old version is still available? I might not want to upgrade to the "latest", but keep using a version I tested with and was proven stable.
Dependency Operations
Repository
A repository is a place where charts are collected and shared. The charts are exposed in an archived format. A repository must expose an index.yaml in its root. When Helm is installed, it is pre-configured with a default repository. New repositories an be added. Repositories can be searched for charts with helm search. Because chart repositories change frequently, it is recommended to update the local cache.
Repository URL
The repository URL represents the endpoint of a Helm repository - the endpoint's root must contain an index.yaml file.
Default Repository
When Helm is installed, it is pre-configured to look into the official Helm Charts GitHub repository, named "stable".
Repository Operations
Template
Release
A release is a running instantiation of a chart, to which a specific config was applied. Whenever a chart is installed, a new release is created. One chart can be installed multiple times into the same cluster, and each can be independently managed and upgraded. Each release has its own release name.
When a new version of a chart is released, or when the configuration of a release must be changes, the release can be upgraded with helm upgrade. Helm tries to perform the least invasive upgrade, and only upgraded things that changed since the last release. If something fails during the upgrade, a rollback can be performed with helm rollback.
Releases can be of course uninstalled, or deleted with helm delete. Helm keeps a history of deleted releases, which can be retrieved with helm list --deleted.
Release Name
If not specified, release names are generated (e.g. "happy-panda"). To specify a release name, use helm install --name. Helm keeps records of deleted releases, so a release name first used by a deleted release cannot be re-used (unless --replace is used).
Release Revision
A release version (revision) is incremental. Every time an install, upgrade or rollback happens, the revision number is incremented by 1, and the first revision is always 1. The revision numbers for a certain release can be inspected with helm history. A release revision can be used during a rollback.
Release Marker
The package version is included in the release marker.
Release Operations
Runtime
The Helm Client
The client is responsible for managing charts.
The Tiller Server
The server is responsible for managing releases.
Tiller stores release information in ConfigMaps in the namespace where it is running. It could be configured to use a storage backend that uses Secrets for storing release information. More here. It could also be configured to use an SQL storage backend for storing release information. More here.
TODO: