Helm | - 0 views
-
A chart is a collection of files that describe a related set of Kubernetes resources.
-
A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
-
Charts are created as files laid out in a particular directory tree, then they can be packaged into versioned archives to be deployed.
- ...170 more annotations...
-
A chart is organized as a collection of files inside of a directory.
-
values.yaml # The default configuration values for this chart
-
charts/ # A directory containing any charts upon which this chart depends.
-
templates/ # A directory of templates that, when combined with values, # will generate valid Kubernetes manifest files.
-
version: A SemVer 2 version (required)
-
apiVersion: The chart API version, always "v1" (required)
-
Every chart must have a version number. A version must follow the SemVer 2 standard.
-
non-SemVer names are explicitly disallowed by the system.
-
When generating a package, the helm package command will use the version that it finds in the Chart.yaml as a token in the package name.
-
the appVersion field is not related to the version field. It is a way of specifying the version of the application.
-
appVersion: The version of the app that this contains (optional). This needn't be SemVer.
-
If the latest version of a chart in the repository is marked as deprecated, then the chart as a whole is considered to be deprecated.
-
deprecated: Whether this chart is deprecated (optional, boolean)
-
one chart may depend on any number of other charts.
-
dependencies can be dynamically linked through the requirements.yaml file or brought in to the charts/ directory and managed manually.
-
the preferred method of declaring dependencies is by using a requirements.yaml file inside of your chart.
-
A requirements.yaml file is a simple file for listing your dependencies.
-
The repository field is the full URL to the chart repository.
-
you must also use helm repo add to add that repo locally.
-
helm dependency update and it will use your dependency file to download all the specified charts into your charts/ directory for you.
-
When helm dependency update retrieves charts, it will store them as chart archives in the charts/ directory.
-
Managing charts with requirements.yaml is a good way to easily keep charts updated, and also share requirements information throughout a team.
-
All charts are loaded by default.
-
The condition field holds one or more YAML paths (delimited by commas). If this path exists in the top parent’s values and resolves to a boolean value, the chart will be enabled or disabled based on that boolean value.
-
The tags field is a YAML list of labels to associate with this chart.
-
all charts with tags can be enabled or disabled by specifying the tag and a boolean value.
-
The --set parameter can be used as usual to alter tag and condition values.
-
Conditions (when set in values) always override tags.
-
The first condition path that exists wins and subsequent ones for that chart are ignored.
-
The keys containing the values to be imported can be specified in the parent chart’s requirements.yaml file using a YAML list. Each item in the list is a key which is imported from the child chart’s exports field.
-
specifying the key data in our import list, Helm looks in the exports field of the child chart for data key and imports its contents.
-
the parent key data is not contained in the parent’s final values. If you need to specify the parent key, use the ‘child-parent’ format.
-
To access values that are not contained in the exports key of the child chart’s values, you will need to specify the source key of the values to be imported (child) and the destination path in the parent chart’s values (parent).
-
To drop a dependency into your charts/ directory, use the helm fetch command
-
A dependency can be either a chart archive (foo-1.2.3.tgz) or an unpacked chart directory.
-
name cannot start with _ or .. Such files are ignored by the chart loader.
-
a single release is created with all the objects for the chart and its dependencies.
-
Helm Chart templates are written in the Go template language, with the addition of 50 or so add-on template functions from the Sprig library and a few other specialized functions
-
When Helm renders the charts, it will pass every file in that directory through the template engine.
-
Chart developers may supply a file called values.yaml inside of a chart. This file can contain default values.
-
Chart users may supply a YAML file that contains values. This can be provided on the command line with helm install.
-
When a user supplies custom values, these values will override the values in the chart’s values.yaml file.
-
Template files follow the standard conventions for writing Go templates
-
{{default "minio" .Values.storage}}
-
Values that are supplied via a values.yaml file (or via the --set flag) are accessible from the .Values object in a template.
-
pre-defined, are available to every template, and cannot be overridden
-
the names are case sensitive
-
Release.Name: The name of the release (not the chart)
-
Release.IsUpgrade: This is set to true if the current operation is an upgrade or rollback.
-
Release.Revision: The revision number. It begins at 1, and increments with each helm upgrade
-
Chart: The contents of the Chart.yaml
-
Files: A map-like object containing all non-special files in the chart.
-
Files can be accessed using {{index .Files "file.name"}} or using the {{.Files.Get name}} or {{.Files.GetString name}} functions.
-
.helmignore
-
access the contents of the file as []byte using {{.Files.GetBytes}}
-
Any unknown Chart.yaml fields will be dropped
-
Chart.yaml cannot be used to pass arbitrarily structured data into the template.
-
A values file is formatted in YAML.
-
A chart may include a default values.yaml file
-
be merged into the default values file.
-
The default values file included inside of a chart must be named values.yaml
-
accessible inside of templates using the .Values object
-
Values files can declare values for the top-level chart, as well as for any of the charts that are included in that chart’s charts/ directory.
-
Charts at a higher level have access to all of the variables defined beneath.
-
lower level charts cannot access things in parent charts
-
Values are namespaced, but namespaces are pruned.
-
the scope of the values has been reduced and the namespace prefix removed
-
Helm supports special “global” value.
-
a way of sharing one top-level variable with all subcharts, which is useful for things like setting metadata properties like labels.
-
If a subchart declares a global variable, that global will be passed downward (to the subchart’s subcharts), but not upward to the parent chart.
-
global variables of parent charts take precedence over the global variables from subcharts.
-
helm lint
-
A chart repository is an HTTP server that houses one or more packaged charts
-
Any HTTP server that can serve YAML files and tar files and can answer GET requests can be used as a repository server.
-
Helm does not provide tools for uploading charts to remote repository servers.
-
the only way to add a chart to $HELM_HOME/starters is to manually copy it there.
-
Helm provides a hook mechanism to allow chart developers to intervene at certain points in a release’s life cycle.
-
Execute a Job to back up a database before installing a new chart, and then execute a second job after the upgrade in order to restore data.
-
Hooks are declared as an annotation in the metadata section of a manifest
-
Hooks work like regular templates, but they have special annotations
-
pre-install
-
post-install: Executes after all resources are loaded into Kubernetes
-
pre-delete
-
post-delete: Executes on a deletion request after all of the release’s resources have been deleted.
-
pre-upgrade
-
post-upgrade
-
pre-rollback
-
post-rollback: Executes on a rollback request after all resources have been modified.
-
crd-install
-
test-success: Executes when running helm test and expects the pod to return successfully (return code == 0).
-
test-failure: Executes when running helm test and expects the pod to fail (return code != 0).
-
Hooks allow you, the chart developer, an opportunity to perform operations at strategic points in a release lifecycle
-
Tiller then loads the hook with the lowest weight first (negative to positive)
-
Tiller returns the release name (and other data) to the client
-
If the resources is a Job kind, Tiller will wait until the job successfully runs to completion.
-
if the job fails, the release will fail. This is a blocking operation, so the Helm client will pause while the Job is run.
-
If they have hook weights (see below), they are executed in weighted order. Otherwise, ordering is not guaranteed.
-
good practice to add a hook weight, and set it to 0 if weight is not important.
-
The resources that a hook creates are not tracked or managed as part of the release.
-
leave the hook resource alone.
-
To destroy such resources, you need to either write code to perform this operation in a pre-delete or post-delete hook or add "helm.sh/hook-delete-policy" annotation to the hook template file.
-
Hooks are just Kubernetes manifest files with special annotations in the metadata section
-
One resource can implement multiple hooks
-
no limit to the number of different resources that may implement a given hook.
-
When subcharts declare hooks, those are also evaluated. There is no way for a top-level chart to disable the hooks declared by subcharts.
-
Hook weights can be positive or negative numbers but must be represented as strings.
-
sort those hooks in ascending order.
-
Hook deletion policies
-
"before-hook-creation" specifies Tiller should delete the previous hook before the new hook is launched.
-
By default Tiller will wait for 60 seconds for a deleted hook to no longer exist in the API server before timing out.
-
Custom Resource Definitions (CRDs) are a special kind in Kubernetes.
-
The crd-install hook is executed very early during an installation, before the rest of the manifests are verified.
-
A common reason why the hook resource might already exist is that it was not deleted following use on a previous install/upgrade.
-
Helm uses Go templates for templating your resource files.
-
two special template functions: include and required
-
include function allows you to bring in another template, and then pass the results to other template functions.
-
The required function allows you to declare a particular values entry as required for template rendering.
-
If the value is empty, the template rendering will fail with a user submitted error message.
-
When you are working with string data, you are always safer quoting the strings than leaving them as bare words
-
Quote Strings, Don’t Quote Integers
-
when working with integers do not quote the values
-
env variables values which are expected to be string
-
to include a template, and then perform an operation on that template’s output, Helm has a special include function
-
The above includes a template called toYaml, passes it $value, and then passes the output of that template to the nindent function.
-
Go provides a way for setting template options to control behavior when a map is indexed with a key that’s not present in the map
-
The required function gives developers the ability to declare a value entry as required for template rendering.
-
The tpl function allows developers to evaluate strings as templates inside a template.
-
Rendering a external configuration file
-
(.Files.Get "conf/app.conf")
-
Image pull secrets are essentially a combination of registry, username, and password.
-
Automatically Roll Deployments When ConfigMaps or Secrets change
-
configmaps or secrets are injected as configuration files in containers
-
a restart may be required should those be updated with a subsequent helm upgrade
-
The sha256sum function can be used to ensure a deployment’s annotation section is updated if another file changes
-
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
-
helm upgrade --recreate-pods
-
"helm.sh/resource-policy": keep
-
resources that should not be deleted when Helm runs a helm delete
-
this resource becomes orphaned. Helm will no longer manage it in any way.
-
create some reusable parts in your chart
-
In the templates/ directory, any file that begins with an underscore(_) is not expected to output a Kubernetes manifest file.
-
by convention, helper templates and partials are placed in a _helpers.tpl file.
-
The current best practice for composing a complex application from discrete parts is to create a top-level umbrella chart that exposes the global configurations, and then use the charts/ subdirectory to embed each of the components.
-
SAP’s Converged charts: These charts install SAP Converged Cloud a full OpenStack IaaS on Kubernetes. All of the charts are collected together in one GitHub repository, except for a few submodules.
-
Deis’s Workflow: This chart exposes the entire Deis PaaS system with one chart. But it’s different from the SAP chart in that this umbrella chart is built from each component, and each component is tracked in a different Git repository.
-
YAML is a superset of JSON
-
any valid JSON structure ought to be valid in YAML.
-
As a best practice, templates should follow a YAML-like syntax unless the JSON syntax substantially reduces the risk of a formatting issue.
-
There are functions in Helm that allow you to generate random data, cryptographic keys, and so on.
-
a chart repository is a location where packaged charts can be stored and shared.
-
A chart repository is an HTTP server that houses an index.yaml file and optionally some packaged charts.
-
Because a chart repository can be any HTTP server that can serve YAML and tar files and can answer GET requests, you have a plethora of options when it comes down to hosting your own chart repository.
-
It is not required that a chart package be located on the same server as the index.yaml file.
-
A valid chart repository must have an index file. The index file contains information about each chart in the chart repository.
-
The Helm project provides an open-source Helm repository server called ChartMuseum that you can host yourself.
-
$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com
-
A repository will not be added if it does not contain a valid index.yaml
-
add the repository to their helm client via the helm repo add [NAME] [URL] command with any name they would like to use to reference the repository.
-
Helm has provenance tools which help chart users verify the integrity and origin of a package.
-
Integrity is established by comparing a chart to a provenance record
-
The provenance file contains a chart’s YAML file plus several pieces of verification information
-
Chart repositories serve as a centralized collection of Helm charts.
-
Chart repositories must make it possible to serve provenance files over HTTP via a specific request, and must make them available at the same URI path as the chart.
-
We don’t want to be “the certificate authority” for all chart signers. Instead, we strongly favor a decentralized model, which is part of the reason we chose OpenPGP as our foundational technology.
-
The Keybase platform provides a public centralized repository for trust information.
-
A chart contains a number of Kubernetes resources and components that work together.
-
A test in a helm chart lives under the templates/ directory and is a pod definition that specifies a container with a given command to run.
-
The pod definition must contain one of the helm test hook annotations: helm.sh/hook: test-success or helm.sh/hook: test-failure
-
helm test
-
nest your test suite under a tests/ directory like <chart-name>/templates/tests/