Learninghelm

In general, Helm core maintainers suggest storing configuration in values.yaml files (note that the filename does not need to be "values"), only using–set when absolutely necessary.

Both helm install and helm upgrade provide a–values flag that points to a YAML file with value overrides:

In Helm 3, naming has been changed. Now instance names are scoped to Kubernetes namespaces. We could install two instances named mysite as long as they each lived in a different namespace.

There is a second flag that can be used to add individual parameters to an install or upgrade. The–set flag takes one or more values directly.

When working with namespaces and Helm, you can use the–namespace or-n flags to specify the namespace you desire.

$ helm repo add bitnami https://charts.bitnami.com/bitnami "bitnami" has been added to your repositories The helm repo add command will add a repository named bitnami that points to the URL https://charts.bitnami.com/bitnami.

At its core, a semantic version has three numerical components and an optional stability marker (for alphas, betas, and release candidates). Here are some examples: v1.0.0 v3.3.2 v2.4.22-alpha.2

You can also override these settings with environment variables (HELM_KUBECONTEXT) and command-line flags (–kube-context).

The usual sequence of commands for installing this way is as follows: $ curl-fsSL-o get_helm.sh \ https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 $ chmod 700 get_helm.sh $ ./get_helm.sh The preceding commands fetch the latest version of the get_helm.sh script, and then use that to find and install the latest version of Helm 3.

A chart contains a file called Chart.yaml that describes the chart. It has information about the chart version, the name and description of the chart, and who authored the chart. A chart contains templates as well. These are Kubernetes manifests (like we saw earlier in this chapter) that are potentially annotated with templating directives. We will cover these in detail in Chapter 5. A chart may also contain a values.yaml file that provides default configuration. This file contains parameters that you can override during installation and upgrade.

Package management is typically confined to implementing three verbs: install, upgrade, and delete. Configuration management is a higher-order concept that focuses on managing an application or applications over time. This is sometimes called "day-two ops."

operations in Helm are namespace-sensitive.

A Deployment describes an application as a collection of identical pods. The Deployment is composed of some top-level configuration data as well as a template for how to construct a replica pod.

the Helm chart version increments separately from the Helm version. So Helm v2 used Helm Charts v1, and Helm v3 uses Helm Charts v2.

Many tools like Helmfile, Flux, and Reckoner have filled in details in the larger configuration management story.

Pods are linked to configuration objects (like ConfigMap or Secret) using volumes.

Most frequently, a pod only has one container. But sometimes they have containers that do some preconfiguration for the main container, exiting before the main container comes online. These are called init containers. Other times, there are containers that run alongside the main container and provide auxiliary services. These are called sidecar containers. These are all considered part of the same pod.

Eventually, Kubernetes will either succeed in creating the user's desired environment or will arrive at the conclusion that it cannot realize the user's desires.

Google created an open source sibling to its internal Borg platform, and named this technology Kubernetes (the Greek word for a ship's captain).

a container provides a useful way of packaging up the runtime environment for a single program so that the executable is guaranteed to have all of its dependencies satisfied when it is moved from one host to another.

A Secret is structurally similar to a ConfigMap, except that the values in the data section must be Base64 encoded.

Helm interacts directly with the Kubernetes API server. For that reason, Helm needs to be able to connect to a Kubernetes cluster. Helm attempts to do this automatically by reading the same configuration files used by kubectl (the main Kubernetes command-line client). Helm will try to find this information by reading the environment variable $KUBECONFIG.

A Service is a persistent network resource (sort of like a static IP) that persists even if the pod or pods attached to it go away.

A Pod describes what configuration the container or containers need (such as network ports or filesystem mount points). Configuration information in Kubernetes may be stored in ConfigMaps or, for sensitive information, Secrets. And the Pod's definition may then relate those ConfigMaps and Secrets to environment variables or files within each container. As Kubernetes sees those relationships, it will attempt to attach and configure the configuration data as described in the Pod definition:

A pod can have one or more containers.

But Kubernetes' design is that we think declaratively. We tell the scheduler (Kubernetes) what our desired state is, and Kubernetes takes care of converting that declarative statement into its own internal procedures. Installing a container on Kubernetes, then, is more a matter of saying, "I want this container running on this port with this amount of CPU and some storage mounted at this location on the filesystem." Kubernetes works behind the scenes to wire everything up according to our declaration of what we want.

A registry uses up to three pieces of information to identify a particular image: Name An image name can range from simple to complex, depending on the registry that stores the image: nginx, servers/nginx, or example.com/servers/nginx. Tag The tag typically refers to the version of the software installed (v1.2.3), though tags are really just arbitrary strings. The tags latest and stable are often used to indicate "the most recent version" and "the most recent production-ready version," respectively. Digest Sometimes it is important to pull a very specific version of an image. Since tags are mutable, there is no guarantee that at any given time a tag refers to exactly a specific version of the software. So registries support fetching images by digest, which is a SHA-256 or SHA-512 digest of the image's layer information.

Package managers aren't just for sharing and consuming others' software, however. They are often an integral part of other systems, such as DevOps tooling, and they are used as a building block.

In Kubernetes, a namespace is an arbitrary grouping mechanism that defines a boundary between the things inside the namespace and the things outside.