Helm is a tool that streamlines installing and managing Kubernetes applications. Think of it like yum and homebrew for Kubernetes. Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. helm provide commands to install, run, update deployments and services.

CONCEPT OF TILLERS

Tiller, the server portion of Helm, typically runs inside of your Kubernetes cluster. But for development, it can also be run locally, and configured to talk to a remote Kubernetes cluster.

In Helm v3 tiller is gone, and there is only Helm client.

UNDERSTANDING HELM CHARTS

Helm uses a packaging format called charts. 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 or a full web app stack with HTTP servers, databases, caches, and so on.

Templates generate manifest files, which are YAML-formatted resource descriptions that Kubernetes can understand. We'll look at how templates are structured, how they can be used.

To build a helm chart helm create is the command. It creates the base template of YAML files and the base template can be modified in the way you want and you can find Kubernetes-ready app at helm-hub and can push you own created helm chart.

Because we are using GKE helm and kubectl is already setup and ready to use otherwise, needs to setup by installing. Deployment and Services of Google Kubernetes Engine are the features which are getting used in in the setup.

development .yaml contains all the details of development and service.yaml contains the details which expose the development and these files are getting their values like image, tag, and ports from value.yaml.

Few tags from *value.yaml*

replicaCount: 1

image:
  repository: gcr.io/project-for-video/project-for-video
  pullPolicy: Always
  # Overrides the image tag whose default is the chart appVersion.
  tag: "latest"

containerPort: 3100
readinessProbe: /
livenessProbe: /

serviceAccount:
  name: "project-for-video-dev"

service:
  type: LoadBalancer
  port: 80
  targetPort: 3100
  nodePort: 30001

Namespaces are intended for use in environments with many users spread across multiple teams, or projects. ... Namespaces are a way to divide cluster resources between multiple users (via resource quota). In future versions of Kubernetes, objects in the same **namespace will have the same access control policies by default.

DEPLOY CHART TO GKE

1. Create helm chart with helm create {name of chart} command

2. Updates the values in value.yaml. Update the name, image, image tag, container-port, service port, and internal port(target port)

3. Push it to the separate repository with separate branches like dev for dev-environment and prod for prod-environment
   prod branch

dev branch

1. Create namespaces kubectl create namespace {NAMESPACE}

2. Clone repository on cloud.

   1. Install chart.(from both branches dev and prod because the ports are different) helm install {name-of-chart} {address-of-chart} --namespace {NAMESPACE}

3. Test (postman to check the response)

IMPORTANT COMMANDS

• helm cerete {NAME OF CHART}
• helm delete {NAME OF CHART}
• helm update{NAME OF CHART}
• helm rollback It only updates if there is any change in chart
• kubectl get namespace --all
• kubectl create namespace
• kubectl delete namespace