↓ Skip to main content
Samarthya
Samarthya
Kubernetes

Helm Charts: Packaging

·2 mins
Technical Helm K8s
Table of Contents

Every software cycle includes packaging; which essentially describes how the software written is packaged and shared.

For the software built for Containers Helm is a popular choice of packaging the scripts.

root@master> helm version
version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"clean", GoVersion:"go1.13.12"}
Helm is a tool for managing Kubernetes packages called charts.

Helm enables management of applications built for Kubernetes. It helps you define, install, and upgrade even the most complex Kubernetes application.

Helm
#

It allows you to

  • Create new charts from scratch
  • Package charts into chart archive (tgz) files
  • Interact with chart repositories where charts are stored
  • Install and uninstall charts into an existing Kubernetes cluster
  • Manage the release cycle of charts that have been installed with Helm

It has two components

  1. Client executable
    • Command line client for end users.
  2. Helm Library
    • It provides the logic for executing all Helm operations and interfaces with the Kubernetes API server.
    • The library uses the Kubernetes client library to communicate with Kubernetes.
The Helm client and library is written in the Go programming language.

Three basic concepts for, Helm (from helm.sh)

  1. The chart is a bundle of information necessary to create an instance of a Kubernetes application.
  2. The config contains configuration information that can be merged into a packaged chart to create a releasable object.
  3. A release is a running instance of a chart, combined with a specific config.

Charts
#

A chart is a collection of files that describe a related set of Kubernetes resources.

The chart name is derived from the directory name. E.g. A chart describing WordPress would be stored in a wordpress/ directory.

Chart.yml
#

apiVersion: v1
name: opendistro-es
# Chart version
version: 1.9.0
description: 'Open Distro for Elasticsearch'
engine: gotpl
kubeVersion: ^1.10.0-0
maintainers:
- email: derek.heldt-werle@viasat.com
  name: Derek Heldt-Werle
- email: kalvin.chau@viasat.com
  name: Kalvin Chau
sources:
- https://pages.git.viasat.com/ATG/charts
# Open Distro for Elasticsearch version
appVersion: 1.9.0

When the chart above is used the package opendistro-es-1.9.0.tgz will be generated.

References
#

Author
Samarthya
Engineer, learner, tinkerer. This is my trophy shelf of everyday work and leisure.

Related

Deployments: K8S

Deployments: K8S

·1 min
Technical Deployments K8s
A declarative way of maintaining the desired state. Continuing my example from the last blog --- # Pod deployment apiVersion: apps/v1 kind: Deployment metadata: name: go-server-deployment spec: replicas: 2 selector: matchLabels: app: my-go-server template: metadata: labels: app: my-go-server spec: containers: - name: go-server image: samarthya/epserver:2.0 resources: limits: memory: "256Mi" cpu: "1024m" env: - name: SERVERPORT value: "9090" ports: - containerPort: 9090 # Reference - https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ In my deployment, I have two replicas configured, which can be increased to three using the command like the one below.
NetworkPolicy: K8S

NetworkPolicy: K8S

·2 mins
Technical K8s Networkpolicy
How can a pod communicate with the other pod? The answer to this question is through a network policy. Network Policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints.
Probes: K8S

Probes: K8S

·5 mins
Technical K8s Probes
In this blog we will be talking about Liveness, Readiness and Startup probes of a container. A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. — - Life without a service What is Kubelet? # Kubelet is a primary node agent that runs on every node. Works in term of PodSpec, that describes a POD (JSON or Yaml). Liveness Probe # It is used by kubelet to decide when to restart the container. periodSeconds defines when the kubelet check periodically. initialDelaySeconds specifies the initial wait before checking. I just created a single container pod that will run touch command to create a file and then it deletes that specific file after a delay, on which the livenessProbe is listening on and then once liveness fails we can check the container.