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
Create helm chart with
helm create {name of chart}
commandUpdates the values in
value.yaml
. Update the name, image, image tag, container-port, service port, and internal port(target port)Push it to the separate repository with separate branches like dev for dev-environment and prod for prod-environment
prod branch
Create namespaces
kubectl create namespace {NAMESPACE}
-
Clone repository on cloud.
- Install chart.(from both branches dev and prod because the ports are different)
helm install {name-of-chart} {address-of-chart} --namespace {NAMESPACE}
- Install chart.(from both branches dev and prod because the ports are different)
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
Top comments (0)