Kubernetes.

Kubernetes is an open-source container orchestration platform that automates deploying, scaling and managing containerized applications. Google originally developed it, and the Cloud Native Computing Foundation (CNCF) now maintains it.

It is needed because managing hundreds or thousands of containers by hand is impractical. Kubernetes does that work for you:

• It restarts failed containers and replaces unhealthy instances, which keeps applications highly available.
• It scales applications with demand and spreads traffic across the instances.
• It packs containers onto nodes by their resource requests, which leaves less capacity sitting idle.
• Its rolling updates let a new version go out with zero downtime.

A Pod is the smallest and simplest Kubernetes unit: one or more containers that share a network namespace and storage. It is the smallest deployable unit because the scheduler places Pods, not containers, and the IP address belongs to the Pod.

Its containers:

• share one IP address and port space, and reach each other on localhost
• can mount the same volumes
• are scheduled together onto the same node
• start and stop together as an atomic unit

That suits tightly coupled containers, such as an app and its log shipper.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: web-container
    image: nginx:1.20
    ports:
    - containerPort: 80

A container runs one application process, while a Pod is the Kubernetes unit that wraps one or more containers with shared networking and storage.

A container is an isolated process, created from a container image, with its own filesystem and resource limits. Outside Kubernetes it also gets its own network stack. Kubernetes never schedules a container on its own, though. It schedules Pods, the smallest deployable unit.

Inside a Pod, the containers share one IP address and port space and can mount the same volumes. That lets a sidecar, a helper such as a log shipper or proxy, run next to the main container and reach it over localhost.

The usual Pod holds one container. Extra containers join it only when they must run and scale together.

Helm is the package manager for Kubernetes, much as apt is for Ubuntu or npm is for Node.js. It bundles an application's Kubernetes manifests into a reusable package called a chart.

One application needs many YAML files that differ per environment, and Helm manages them as one unit.

• Charts use Go templates, so one chart takes different values for dev, staging and production.
• Each install is a release with a stored history, so you can upgrade, roll back or uninstall it as one unit.
• A chart declares the charts it depends on, such as a database, and Helm installs them together.
• Charts are versioned and shared through repositories, so an application is portable across clusters and environments.

Helm has three concepts, charts, releases and repositories, plus one client, the helm CLI:

1. The Helm client handles chart development, repository management and release operations. It talks directly to the Kubernetes API server.
2. A chart is a package of manifest templates, metadata and default values, stored locally or in a repository.
3. A release is one deployed instance of a chart, with its own name and values. Helm keeps its history for upgrades and rollbacks.
4. A repository stores and shares charts. It can be public or private, and Artifact Hub lists charts from many public ones.

Installing one chart twice creates two separate releases.

A Helm chart is a package containing all the resource definitions needed to run an application on Kubernetes, written as templates plus default values.

mychart/
  Chart.yaml          # Chart metadata
  values.yaml         # Default configuration values
  charts/             # Dependency charts
  templates/          # Kubernetes manifest templates
    deployment.yaml
    service.yaml
    ingress.yaml
    _helpers.tpl      # Template helpers
  .helmignore         # Files to ignore during packaging

• Chart.yaml holds the chart's name, version and description, and it lists the chart's dependencies.
• values.yaml holds the defaults the templates render with.
• templates/ holds the Kubernetes manifest templates.
• charts/ holds the charts this one depends on.
• A README.md, when present, documents how to use the chart.

Charts are portable and reusable across environments, because you set the configuration through values.

You pass your own values with --set flags or values files at install or upgrade time. Helm merges them over the chart's defaults in a fixed order of precedence, highest first:

1. --set on the command line wins over everything.
2. A custom values file passed with --values, or its short form -f.
3. When you pass several -f files, a later file overrides an earlier one.
4. The chart's own values.yaml supplies the defaults and has the lowest precedence.

helm install myapp ./mychart --set replicaCount=5 --set image.tag=2.0

helm install myapp ./mychart --values custom-values.yaml

helm install myapp ./mychart -f values.yaml -f production-values.yaml

A custom values file only needs the keys you want to change:

replicaCount: 3
image:
  repository: myapp
  tag: "v2.1.0"
service:
  type: LoadBalancer
resources:
  limits:
    memory: "512Mi"
    cpu: "500m"

Helm merges maps deeply, so setting image.tag keeps the default image.repository. Arrays are replaced whole, so to change one item you pass the full list.