Showing posts with label Kubernetes. Show all posts

Helm vs Kubectl — What, Why, and When to Use Each

☸️ Helm vs Kubectl — What, Why, and When to Use Each

If you work with Kubernetes, you will almost always use both kubectl and Helm — but for different purposes.

The confusion usually comes from thinking they do the same thing.
They don’t.

🧠 One-Line Summary (Remember This)

kubectl manages Kubernetes resources directly
Helm manages Kubernetes applications as packages

🧩 High-Level Picture

Photo Credit: Internet


Helm ───► generates Kubernetes YAML ───► kubectl ───► Kubernetes API Server

👉 Helm uses Kubernetes
👉 kubectl talks directly to Kubernetes

1️⃣ What Is `kubectl`?

🔹 Definition

kubectl is the official Kubernetes command-line tool to interact with a cluster.

It:

creates resources
updates resources
deletes resources
inspects cluster state

🔹 What `kubectl` Works With

Pods
Deployments
Services
ConfigMaps
Secrets
Nodes
Namespaces

🔹 Common `kubectl` Commands


kubectl get pods
kubectl describe pod my-pod
kubectl apply -f deployment.yaml
kubectl delete service my-service
kubectl logs my-pod
kubectl exec -it my-pod -- bash

🔹 When to Use `kubectl`

✅ Debugging
✅ Inspecting cluster state
✅ One-off changes
✅ Day-to-day operations
✅ Troubleshooting production issues

2️⃣ What Is Helm?

🔹 Definition

Helm is a package manager for Kubernetes.

It lets you:

package multiple Kubernetes resources together
version them
deploy them consistently

🔹 Helm Manages Applications, Not Just Resources

An application may include:

Deployment
Service
ConfigMap
Secret
HPA
Ingress

👉 Helm treats all of this as one unit (a chart).

🔹 Helm Terminology (Important)

Term	Meaning
Chart	Kubernetes application template
Release	Installed instance of a chart
Values	Configuration inputs
Repository	Chart storage

🔹 Common Helm Commands


helm install myapp ./my-chart
helm upgrade myapp ./my-chart
helm rollback myapp 1
helm list
helm uninstall myapp

🔹 When to Use Helm

✅ Installing applications
✅ Managing complex deployments
✅ Handling multiple environments (dev, stage, prod)
✅ Versioning and rollback
✅ CI/CD pipelines

3️⃣ Key Difference: Resource vs Application

Aspect	kubectl	Helm
Level	Resource-level	Application-level
YAML	Raw YAML	Templated YAML
Versioning	❌ No	✅ Yes
Rollback	❌ Manual	✅ Built-in
Reusability	Low	High
Environment config	Manual	Values files

4️⃣ Real-World Example (This Makes It Click)

❌ Without Helm (kubectl only)


kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f configmap.yaml
kubectl apply -f ingress.yaml

Problems:

Hard to track versions
No rollback
YAML duplication across environments

✅ With Helm


helm install order-service ./order-chart -f values-prod.yaml

Benefits:

One command
Versioned release
Easy rollback
Clean environment separation

5️⃣ How They Work Together (Very Important)

👉 Helm does NOT replace kubectl
👉 They are complementary

Typical Workflow


helm install myapp ./chart
kubectl get pods
kubectl logs myapp-pod
kubectl exec -it myapp-pod -- bash

Helm:

deploys the app

kubectl:

observes
debugs
operates

6️⃣ CI/CD Perspective (Real Industry Usage)

In CI/CD Pipelines

Stage	Tool
Deploy	Helm
Upgrade	Helm
Rollback	Helm
Debug	kubectl
Health check	kubectl

7️⃣ Common Confusions (Cleared)

❓ Can Helm work without kubectl?

❌ No — Helm ultimately uses the Kubernetes API (like kubectl).

❓ Can kubectl replace Helm?

❌ No — kubectl has:

no templating
no versioning
no rollback

❓ Do I need both?

✅ Yes — almost always.

8️⃣ Mental Model (Easy to Remember)

kubectl = screwdriver (low-level tool)
Helm = toolbox with instructions (high-level tool)

🎯 Interview-Ready Answer

kubectl is used to manage and debug individual Kubernetes resources, while Helm is used to package, version, and deploy complete Kubernetes applications. Helm simplifies complex deployments, and kubectl is used for inspection and troubleshooting.

📝 One-Line Takeaway

Use Helm to deploy applications.
Use kubectl to operate and debug the cluster.

Kubernetes Deployment Using Helm — A Complete Beginner-Friendly Guide

Deploying applications directly with raw Kubernetes YAML files quickly becomes repetitive and error-prone.
This is exactly where Helm helps — a package manager for Kubernetes that simplifies deployments, promotes reusability, and standardizes configurations.

In this blog, we’ll understand:

What is Helm?
Helm chart folder structure
How templates work
How values.yaml makes your deployment configurable
Deployment + Service example for a backend API
Helm commands to deploy your application

🧭 1. What Is Helm?

Helm is Kubernetes’s package manager, similar to:

apt (Ubuntu)
yum (CentOS)
Homebrew (macOS)

A Helm chart packages all Kubernetes YAML files into a reusable structure.

Instead of maintaining multiple YAMLs per environment (dev, QA, prod), Helm allows:

✔ Configuration overrides
✔ Templates
✔ Versioning
✔ Easy upgrades (helm upgrade)
✔ One-line deployment

🗂️ 2. Helm Chart Structure Explained

When you create a Helm chart using:


helm create myservice

Helm generates the following structure:


myservice/
│
├── Chart.yaml           # Chart metadata (name, version, description)
├── values.yaml          # Default configuration values (overridable)
│
├── templates/           # Kubernetes YAML templates
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── hpa.yaml
│   ├── _helpers.tpl     # Helper functions
│   └── NOTES.txt        # Instructions after deployment
│
└── charts/              # Dependency charts (optional)

🧩 3. Key Components Inside the Chart

✔ Chart.yaml

Metadata about the chart:


apiVersion: v2
name: myservice
description: A backend API service
version: 0.1.0
appVersion: "1.0"

✔ values.yaml

All environment-specific configuration goes here.

Example:


replicaCount: 2

image:
  repository: myregistry/myservice
  tag: "1.0.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

resources:
  limits:
    cpu: "500m"
    memory: "512Mi"

env:
  APP_ENV: "prod"
  LOG_LEVEL: "info"

You will override these per environment (dev/prod).

🛠️ 4. Templates — How Helm Injects Values

Inside templates/deployment.yaml, Helm uses Go template syntax:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myservice.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ include "myservice.name" . }}
  template:
    metadata:
      labels:
        app: {{ include "myservice.name" . }}
    spec:
      containers:
        - name: myservice
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.port }}
          env:
            - name: APP_ENV
              value: "{{ .Values.env.APP_ENV }}"
            - name: LOG_LEVEL
              value: "{{ .Values.env.LOG_LEVEL }}"

Helm replaces {{ ... }} during deployment.

🌐 5. Service (Expose Your Endpoint)

If your backend API runs on http://service:8080/api/v1/hello,
you need a Kubernetes Service.

Example service.yaml:


apiVersion: v1
kind: Service
metadata:
  name: {{ include "myservice.fullname" . }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
      protocol: TCP
  selector:
    app: {{ include "myservice.name" . }}

This exposes your API internally inside the cluster.

🌍 6. Optional: Ingress (Expose to Internet)

If you want the service available via a domain like:


https://api.mycompany.com/myservice

You need an ingress:


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ include "myservice.fullname" . }}
spec:
  rules:
    - host: api.mycompany.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: {{ include "myservice.fullname" . }}
                port:
                  number: {{ .Values.service.port }}

📝 7. How to Deploy the Service Using Helm

1. Create your chart


helm create myservice

2. Update values.yaml

Your image, port, replicas, env variables.

3. Deploy to Kubernetes


helm install myservice ./myservice

4. Upgrade after modifying values


helm upgrade myservice ./myservice

5. Uninstall


helm uninstall myservice

📦 8. Passing Environment-Specific Values

dev-values.yaml


replicaCount: 1
image:
  tag: "1.0-dev"

prod-values.yaml


replicaCount: 4
image:
  tag: "1.0-prod"

Deploy using:


helm install myservice -f prod-values.yaml .

🧱 9. How the Application Endpoint Is Exposed

Let’s say your application exposes:


GET /api/v1/status
PORT = 8080

Then:

Container exposes → 8080
Deployment uses → containerPort: 8080
Service exposes → port: 8080
Ingress exposes → domain route

Flow:


Client → Ingress → Service → Pod → Application Endpoint

🧭 10. Text Diagram — Deployment Flow


                   ┌───────────────────────┐
                   │     Ingress (Optional)│
                   └────────────┬──────────┘
                                │
                   ┌────────────▼──────────┐
                   │     Service (ClusterIP)│
                   └────────────┬──────────┘
                                │
                 ┌──────────────▼──────────────┐
                 │       Deployment              │
                 └──────────────┬──────────────┘
                                │
                 ┌──────────────▼──────────────┐
                 │           Pods               │
                 │    (Running your API)        │
                 └──────────────────────────────┘

🎯 Summary

Concept	Description
Helm	Package manager for Kubernetes
Chart	Folder containing Kubernetes templates
values.yaml	Environment-specific variables
deployment.yaml	Deploy your app container
service.yaml	Exposes your app to the cluster
ingress.yaml	(Optional) Public access endpoint

👍 Final Thoughts

Helm makes Kubernetes deployments:

✔ Consistent
✔ Repeatable
✔ Versioned
✔ Easy to override for multiple environments

You only maintain one chart, and override the configuration for dev/staging/prod.

Kubernetes Deployment Using Helm — A Complete Beginner-Friendly Guide

When deploying applications to Kubernetes, engineers quickly face challenges:

Too many YAML files
Repeated configurations across environments
Manual updates during releases
Hard-to-maintain deployments

Helm solves all of these.

Helm is the package manager for Kubernetes that allows you to deploy applications using reusable, templated, and version-controlled charts.

In this guide, we’ll learn:

What Helm is
Why Helm is used
Helm chart folder structure
How Deployment, Service, and Ingress work together
How to write Helm templates
How to deploy a service using Helm

Let’s get started.

1. What Is Helm?

Helm is a package manager for Kubernetes — similar to apt, yum, or Homebrew.

A Helm chart contains all the Kubernetes YAML files (Deployment, Service, Ingress, ConfigMaps, etc.) packaged into a single reusable template.

✔ Helm solves real problems:

Problem	Helm Solution
Too many YAML files	One reusable chart
Duplicate configs across environments	`values.yaml` overrides
Manual edits	Template-based automation
Risky updates	Versioned upgrades (`helm upgrade`)

Instead of maintaining dozens of YAML files, you maintain only one chart + environment-specific values.

2. Helm Chart Folder Structure

When you run:


helm create myservice

Helm generates this structure:


myservice/
│
├── Chart.yaml            # Chart metadata
├── values.yaml           # Default config values (overridable)
│
├── templates/            # All Kubernetes YAML templates
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── hpa.yaml
│   ├── _helpers.tpl      # Helper functions
│   └── NOTES.txt
│
└── charts/               # Dependencies (optional)

Let’s break these down.

3. Key Files Explained

✔ Chart.yaml

Metadata about the service:


apiVersion: v2
name: myservice
version: 0.1.0
description: My Backend Service
appVersion: "1.0"

✔ values.yaml

This file holds your environment-specific configuration.


replicaCount: 2

image:
  repository: myregistry/myservice
  tag: "1.0.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

env:
  APP_ENV: "prod"
  LOG_LEVEL: "info"

You can override these for dev, QA, prod using:


helm install myservice -f values-prod.yaml .

4. Deployment — Template Example

templates/deployment.yaml uses Helm templating:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myservice.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ include "myservice.name" . }}
  template:
    metadata:
      labels:
        app: {{ include "myservice.name" . }}
    spec:
      containers:
        - name: myservice
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.port }}
          env:
            - name: APP_ENV
              value: "{{ .Values.env.APP_ENV }}"

Helm replaces {{ ... }} placeholders with values during installation.

5. Service — Internal Load Balancer

service.yaml exposes the Pods inside the cluster:


apiVersion: v1
kind: Service
metadata:
  name: {{ include "myservice.fullname" . }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
  selector:
    app: {{ include "myservice.name" . }}

This allows other services inside the cluster to reach your API.

6. Ingress — External Access

If you want the service accessible from the internet:


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ include "myservice.fullname" . }}
spec:
  rules:
    - host: api.mycompany.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: {{ include "myservice.fullname" . }}
                port:
                  number: {{ .Values.service.port }}

Ingress uses an Ingress Controller (NGINX, Traefik, AWS ALB) to route HTTP/HTTPS traffic.

7. How Deployment, Service, and Ingress Are Connected

This is one of the most important concepts and often misunderstood.

Connection Breakdown

Component	Role
Deployment	Creates and manages Pods
Service	Maps stable IP to Pods & load balances
Ingress	Maps external domain/path to Service

Flow Diagram


Client → Ingress → Service → Pods (via Deployment)

Detailed Flow Description

Deployment creates Pods with label:
```
app: myservice
```
Service selects Pods using:
```
selector:
  app: myservice
```
Ingress forwards external HTTP traffic to the Service:
```
backend:
  service:
    name: myservice
```

Text Diagram


                       ┌───────────────────────┐
                       │       Ingress         │
                       │  (HTTP/HTTPS Router)  │
                       └───────────▲───────────┘
                                   │
                       ┌───────────┴───────────┐
                       │       Service         │
                       │   (Load Balancer)     │
                       └───────────▲───────────┘
                                   │
                       ┌───────────┴───────────┐
                       │      Deployment        │
                       └───────────▲───────────┘
                                   │
                       ┌───────────┴───────────┐
                       │         Pods           │
                       └────────────────────────┘

8. Installing the Helm Chart

Install


helm install myservice ./myservice

Upgrade


helm upgrade myservice ./myservice

Uninstall


helm uninstall myservice

9. Using Environment-Specific Overrides

dev-values.yaml


replicaCount: 1
image:
  tag: "1.0-dev"

prod-values.yaml


replicaCount: 4
image:
  tag: "1.0-prod"

Deploy:


helm install myservice -f prod-values.yaml .

Conclusion

Helm is an essential tool for real-world Kubernetes deployments.
It simplifies your deployment workflow by providing:

✔ Reusable templates
✔ Environment-specific configurations
✔ Clean separation of logic and values
✔ Version-controlled releases
✔ Easy upgrades and rollbacks

How Deployment, Service, and Ingress Work Together in Kubernetes

When you deploy an application in Kubernetes, three key components work together to expose your API to users:

Deployment → Creates and manages your Pods
Service → Provides stable network access to the Pods
Ingress → Provides external access (HTTP/HTTPS) to the Service

Understanding how these three connect is essential for deploying any microservice.

1. Deployment → Creates Pods

A Deployment manages your application Pods:

Ensures the right number of replicas
Performs rolling updates
Restarts Pods if they crash

Example:


Deployment  
   └── Pod (application)
   └── Pod (application)
   └── Pod (application)

Each Pod has its own IP, which changes when pods restart.
That’s why we cannot access Pods directly — the IPs are not stable.

2. Service → Stable Access to Pods

A Service (usually ClusterIP) sits in front of the Pods:

Provides a fixed stable IP inside the cluster
Load-balances requests to the Pods
Selects Pods using labels

Example:


selector:
  app: myservice

Any Pod with this label becomes part of the service.

3. Ingress → External Access via HTTP/HTTPS

A Service is only accessible inside the cluster.
If you need external access, you create an Ingress resource.

Ingress:

Maps URLs/domains → to services
Works through an Ingress Controller (nginx, traefik, AWS ALB)
Supports TLS/SSL

Example:


https://api.mycompany.com/myservice → service → pods

Full Connectivity Flow (Simple Diagram)


          ┌──────────────────────────────────┐
          │             Client                │
          │    (Browser / Mobile / API)       │
          └──────────────────┬────────────────┘
                             │ HTTP/HTTPS
                             ▼
                 ┌─────────────────────┐
                 │      Ingress        │
                 │  (Domain & Routing) │
                 └───────────┬─────────┘
                             │
                             ▼
                 ┌───────────────────────┐
                 │        Service         │
                 │ (Stable ClusterIP LB)  │
                 └──────────┬────────────┘
                            │
              ┌─────────────┴───────────────┐
              ▼                               ▼
     ┌─────────────────┐            ┌─────────────────┐
     │      Pod 1      │            │     Pod 2       │
     │ (Your backend)  │            │ (Your backend)  │
     └─────────────────┘            └─────────────────┘

🔁 Step-by-Step Request Flow

1️⃣ A user calls:


https://api.mycompany.com/status

2️⃣ Ingress receives the request

Matches a rule:


paths:
  - path: /
    backend:
      service:
        name: myservice
        port:
          number: 8080

3️⃣ Ingress forwards to Service

This is internal routing.

4️⃣ Service load balances to Pods

Based on labels.

5️⃣ Pod handles the request

Returns response → Service → Ingress → Client.

🧩 How They Connect in YAML

Deployment → Pods


metadata:
  labels:
    app: myservice

Service selects Pods


selector:
  app: myservice

Ingress sends traffic to Service


backend:
  service:
    name: myservice
    port:
      number: 8080

This label-chain is how they connect.

Text Diagram of Logical Mapping


Deployment → Pods (labeled "app=myservice")
                ▲
                │ label selector
                ▼
          Service (ClusterIP)
                ▲
                │ Ingress backend
                ▼
             Ingress

If labels don’t match → service will have 0 pods → no traffic.

Why Kubernetes Uses All 3 Layers?

Component	Purpose
Deployment	Run & manage your application containers
Service	Stable network endpoint inside cluster + load balancing
Ingress	Public HTTP/HTTPS access + routing +