🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

📚 धडा 11 — Helm, Kustomize आणि environments: एक recipe, अनेक वर्गखोल्या

📍 तुम्ही इथे आहात: 12 पैकी धडा 11 · मागील: lesson-10-rollback-history · पुढील: lesson-12-secrets-and-compare

📦 या ब्रँचमध्ये काय आहे

धडे 01–10, आणि त्यासोबत GitOps एका namespace मधल्या एका app च्या पलीकडे कसे वाढते: templates (Helm / Kustomize), प्रत्येक environment च्या values, आणि app-of-apps pattern.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळेत आता तीन वर्गखोल्या आहेत ज्या जवळजवळ सारख्या दिसायला हव्यात: सरावाची खोली (dev), रंगीत तालमीची खोली (staging), आणि मोठा रंगमंच (prod). 🚪🚪🚪

आराखड्याचा अध्याय तीनदा copy करणे हा सापळा आहे — एका copy मधली टायपिंगची चूक दुरुस्त करा, बाकी दोन विसरा, आणि खोल्या हळूहळू एकमेकांशी असहमत होतात (copy-paste drift!).

त्यापेक्षा चांगले: रिकाम्या जागा असलेली एक recipe लिहा 📚:

"___ खुर्च्या, projector: ___, posters: ___"

…आणि तीन छोटी भरायची पाने: सरावाची खोली = 1 खुर्ची; तालीम = 2; मोठा रंगमंच = 5 खुर्च्या + झगमगीत दिवे. एक recipe, तीन भरलेली पाने, तीन खोल्या. Recipe एकदा दुरुस्त करा → तिन्ही खोल्या सुधारतात.

Helm = रिकाम्या जागा असलेल्या recipes ({{ .Values.replicas }}) + values files.
Kustomize = एक पूर्ण नमुना खोली (base) + छोटी "फरकांची" पाने (overlays: "base सारखीच, पण 5 खुर्च्या").

आणि जेव्हा तुमच्याकडे दहा apps × तीन खोल्या असतात? इतर पानांची यादी करणारे एक मुख्य पान लिहा 📖 — असे Application ज्याच्या अध्यायात आणखी Application files आहेत. Robot च्या हातात एकच पान द्या; बाकीची तो स्वतः शोधतो. हेच app-of-apps — संपूर्ण platforms एकाच kubectl apply मधून कसे उभे राहतात.

🗺️ आकृती

flowchart LR
    recipe["📚 one recipe<br/>Helm chart / Kustomize base<br/>replicas: ___ image: ___"]
    dev["📝 values-dev<br/>replicas: 1"]
    stg["📝 values-staging<br/>replicas: 2"]
    prod["📝 values-prod<br/>replicas: 5 + HPA"]
    rdev["🚪 dev room"]
    rstg["🚪 staging room"]
    rprod["🚪 prod room"]
    master["📖 app-of-apps<br/>one page lists all pages"]
    recipe -->|"1"| dev --> rdev
    recipe --> stg --> rstg
    recipe --> prod --> rprod
    master -.->|"2 one Application each"| rdev
    master -.-> rstg
    master -.-> rprod

❓ काय

ArgoCD sources स्वतःच render करतो: साधे YAML (आपण वापरले ते), Helm (source.helm.valueFiles), Kustomize (path: एखाद्या overlay कडे वळवा). Application चा आकार तोच, अध्यायाचा format वेगळा.
प्रत्येक env मधले promotion ही git ची क्रिया बनते: values-staging.yaml मध्ये image tag वाढवा, test करा, मग तोच बदल values-prod.yaml मध्ये PR ने आणा. Environments मधला फरक git मध्ये वाचता येतो.
App-of-apps: Application manifests च्या folder कडे निर्देश करणारे एक Application. Folder मधून एखादे leaf app delete करा → (prune सह) ते cluster मधून नाहीसे होते. एक पान सगळ्यांवर राज्य करते.
(आधुनिक भावंड: ApplicationSets lists/clusters/PRs वरून Applications तयार करतात — app-of-apps समजल्यावर त्याची ओळख करून घ्या.)

🤔 का

Copy-paste मुळेच config सडते. Templates + प्रत्येक env चे छोटे diffs हेतू ("prod म्हणजे base + 5 replicas + HPA") वाचता येईल आणि review करता येईल असा ठेवतात. आणि app-of-apps म्हणजे संपूर्ण platform चे disaster recovery इतकेच: ArgoCD install करा, एक file apply करा, थांबा. ☕

✅ खड्डा 3 बुजला. दहा clusters म्हणजे आता CI मध्ये दहा keys नाहीत: प्रत्येक cluster त्याचा स्वतःचा robot चालवतो जो तीच वही pull करतो (किंवा एकच robot अनेक सांभाळतो — धडा 06 मधली तडजोड), आणि app-of-apps मुळे नवा cluster आणखी एका pipeline ने नव्हे, तर एका file मधून उभा राहतो.

🔧 कसे (या repo चा एक Kustomize आराखडा)

k8s/
├── base/                    # the recipe: deployment + service + ns
│   └── kustomization.yaml
└── overlays/
    ├── dev/kustomization.yaml       # replicas: 1
    └── prod/kustomization.yaml      # replicas: 5

दोन Applications, path: k8s/overlays/dev विरुद्ध .../prod आणि destination namespace सोडून अगदी सारखी. (हे course चा घरी करायचा सराव म्हणून ठेवले आहे — लागणारे प्रत्येक tool तुमच्याकडे आहे.)

🧪 करून पाहा (2 मिनिटांत Kustomize अनुभवा, ArgoCD ची गरज नाही)

mkdir -p /tmp/kdemo/base /tmp/kdemo/prod
cp k8s/deployment.yaml k8s/service.yaml /tmp/kdemo/base/
printf 'resources: [deployment.yaml, service.yaml]\n' > /tmp/kdemo/base/kustomization.yaml
printf 'resources: ["../base"]\nreplicas: [{name: hello-school, count: 5}]\n' > /tmp/kdemo/prod/kustomization.yaml

kubectl kustomize /tmp/kdemo/base | grep replicas     # → 2 (the recipe)
kubectl kustomize /tmp/kdemo/prod | grep replicas     # → 5 (base + one fill-in line!)

✅ तपासा — तुम्हाला काय दिसायला हवे

kubectl kustomize /tmp/kdemo/base | grep replicas → replicas: 2; /prod साठी तसेच → replicas: 5. Prod overlay फक्त दोन ओळींचा आहे; बाकी सगळे recipe मधून वारसा म्हणून येते.

🧹 स्वच्छता

rm -rf /tmp/kdemo. Cluster वर काहीही apply केले नव्हते.

⚠️ नेहमीच्या चुका

"सध्यापुरते" म्हणून प्रत्येक environment साठी manifest folder copy-paste करणे — महिन्याभरात copies एकमेकांपासून drift होतात
प्रत्येक environment साठी एक git branch — promotion म्हणजे merge-conflicts चे यंत्र बनते; एकाच branch वर folders/overlays वापरा
प्रत्येक child commit होण्याआधीच parent वर prune: true असलेले app-of-apps — commit न झालेले child delete होते
secrets असलेल्या Helm values files (धडा 12)

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: खरे platforms म्हणजे Kustomize overlays वर (किंवा प्रत्येक environment च्या values असलेल्या Helm charts वर) app-of-apps किंवा ApplicationSets, आणि एक tag बदलणाऱ्या PRs ने promotion. मग संपूर्ण cluster ची desired state फक्त एका git clone च्या अंतरावर असते — disaster-recovery plan म्हणजे kubectl apply -f root-app.yaml.

⏭️ पुढे

शेवटचा एक ड्रॅगन: secrets — एकमेव गोष्ट जी वहीत उघडपणे राहता कामा नये — आणि त्यासोबत शेवटचे push-विरुद्ध-pull गुणपत्रक.

git checkout lesson-12-secrets-and-compare

📚 Lesson 11 — Helm, Kustomize & environments: one recipe, many classrooms

📍 You are here: Lesson 11 of 12 · Previous: lesson-10-rollback-history · Next: lesson-12-secrets-and-compare

📦 What's in this branch

Lessons 01–10, plus how GitOps scales past one app in one namespace: templates (Helm / Kustomize), per-environment values, and the app-of-apps pattern.

🧒 Explain like I'm 5

The school now has three classrooms that should look almost the same: the practice room (dev), the dress-rehearsal room (staging), and the big stage (prod). 🚪🚪🚪

Copying the plan chapter three times is a trap — fix a typo in one copy, forget the other two, and the rooms slowly disagree (copy-paste drift!).

Better: write one recipe with blanks 📚:

"___ chairs, projector: ___, posters: ___"

…and three small fill-in pages: practice room = 1 chair; rehearsal = 2; big stage = 5 chairs + fancy lights. One recipe, three fill-ins, three rooms. Fix the recipe once → all three rooms improve.

Helm = recipes with blanks ({{ .Values.replicas }}) + values files.
Kustomize = a full example room (base) + small "differences" pages (overlays: "same as base, but 5 chairs").

And when you have ten apps × three rooms? Write a master page that lists the other pages 📖 — an Application whose chapter contains more Application files. Hand the robot ONE page; it discovers the rest itself. That's app-of-apps — how whole platforms bootstrap from a single kubectl apply.

🗺️ Diagram

flowchart LR
    recipe["📚 one recipe<br/>Helm chart / Kustomize base<br/>replicas: ___ image: ___"]
    dev["📝 values-dev<br/>replicas: 1"]
    stg["📝 values-staging<br/>replicas: 2"]
    prod["📝 values-prod<br/>replicas: 5 + HPA"]
    rdev["🚪 dev room"]
    rstg["🚪 staging room"]
    rprod["🚪 prod room"]
    master["📖 app-of-apps<br/>one page lists all pages"]
    recipe -->|"1"| dev --> rdev
    recipe --> stg --> rstg
    recipe --> prod --> rprod
    master -.->|"2 one Application each"| rdev
    master -.-> rstg
    master -.-> rprod

❓ What

ArgoCD renders sources natively: plain YAML (what we've used), Helm (source.helm.valueFiles), Kustomize (point path: at an overlay). Same Application shape, different chapter format.
Per-env promotion becomes a git operation: bump the image tag in values-staging.yaml, test, then PR the same bump into values-prod.yaml. The diff between environments is readable in git.
App-of-apps: an Application pointing at a folder of Application manifests. Delete a leaf app from the folder → (with prune) it vanishes from the cluster. One page rules them all.
(Modern cousin: ApplicationSets generate Applications from lists/ clusters/PRs — meet it after app-of-apps makes sense.)

🤔 Why

Copy-paste is how config rots. Templates + tiny per-env diffs keep the intent ("prod is base + 5 replicas + HPA") readable and reviewable. And app-of-apps means disaster recovery for an entire platform is: install ArgoCD, apply one file, wait. ☕

✅ Gap 3 closed. Ten clusters no longer mean ten keys in CI: each cluster runs its own robot pulling the same book (or one robot manages many — lesson 06's trade-off), and app-of-apps means a new cluster bootstraps from one file, not one more pipeline.

🔧 How (a Kustomize sketch of THIS repo)

k8s/
├── base/                    # the recipe: deployment + service + ns
│   └── kustomization.yaml
└── overlays/
    ├── dev/kustomization.yaml       # replicas: 1
    └── prod/kustomization.yaml      # replicas: 5

Two Applications, identical except path: k8s/overlays/dev vs .../prod and the destination namespace. (Left as the course's take-home exercise — you have every tool needed.)

🧪 Try it (feel Kustomize in 2 minutes, no ArgoCD needed)

mkdir -p /tmp/kdemo/base /tmp/kdemo/prod
cp k8s/deployment.yaml k8s/service.yaml /tmp/kdemo/base/
printf 'resources: [deployment.yaml, service.yaml]\n' > /tmp/kdemo/base/kustomization.yaml
printf 'resources: ["../base"]\nreplicas: [{name: hello-school, count: 5}]\n' > /tmp/kdemo/prod/kustomization.yaml

kubectl kustomize /tmp/kdemo/base | grep replicas     # → 2 (the recipe)
kubectl kustomize /tmp/kdemo/prod | grep replicas     # → 5 (base + one fill-in line!)

✅ Verify — what you should see

kubectl kustomize /tmp/kdemo/base | grep replicas → replicas: 2; the same for /prod → replicas: 5. The prod overlay is two lines; everything else is inherited from the recipe.

🧹 Clean up

rm -rf /tmp/kdemo. Nothing was applied to the cluster.

⚠️ Common mistakes

copy-pasting the manifest folder per environment "for now" — the copies drift from each other within a month
one git branch per environment — promotion becomes a merge-conflict machine; use folders/overlays on one branch
app-of-apps with prune: true on the parent before every child is committed — an uncommitted child gets deleted
Helm values files with secrets in them (lesson 12)

🏭 Why this matters in production: real platforms are app-of-apps or ApplicationSets over Kustomize overlays (or Helm charts with per-environment values), promoted by PRs that change one tag. The whole cluster's desired state is then a git clone away — the disaster-recovery plan is kubectl apply -f root-app.yaml.

⏭️ Next

One last dragon: secrets — the one thing that must NOT live plainly in the book — plus the final push-vs-pull scorecard.

git checkout lesson-12-secrets-and-compare

← Previousrollback history Next →secrets and compare

This page is the lesson's README from the lesson-11-helm-kustomize-envs branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.