สรุป Helm essential course — day2

โดยหัวข้อหลักๆ มีดังนี้

• Helm — life cycle management
• Helm — Environment
• Helm — chart repository-
• Helm — cli additional options

Helm — Life cycle management

TL;DR — จริงๆ แล้ว life cycle management ของ helm คือการเล่นกับ helm chart ตัวนั้นๆ ทั้งในด้านการติดตั้ง chart [1], การดูตัว relase [2], การดูตัว revision [3], การ upgrade chart version [4] และสุดท้ายเป็นการลบ chart [5] เพื่อจะเข้าใจและเรียนรู้ถึงลักษณะและคุณสมบัติของ chart ของ application นั้นๆ เพื่อให้แน่ใจว่าเราสามารถนำ chart นั้นไปใช้ในงานจริง / production ได้

จากเดิมเมื่อ chapter ที่แล้ว (day 1) ที่ช่วงท้ายๆ ของบทความจะมี activity ที่ให้ลองเล่นกับ chart เดี่ยว chapter นี้เราจะมา deep drive กันมากขึ้น ลุย…

[1] Helm install

$ helm install <release_name> <chart_repo> --version <version_number>

เป็นการลง chart ที่ต้องการด้วยการกำหนดชื่อ release_name ซึ่งจะไปดึง chart มาจาก chart_repository (ซึ่งถูกเก็บใน Git, Nexus หรือ Chartmesuem) ตาม version_number ที่ระบุมาไว้ในเครื่องเรา (*ถ้าไม่ได้ระบุเลข version จะเป็นการดึงตัว latest นะ)

eg.

$ helm install nginx bitnami/nginx --version 16.0.6

ผลลัพธ์: เมื่อเรา install chart ลงมาซักตัว จะมีประมาณนี้

ซึ่งจะให้ข้อมูลแก่ client อย่างเราๆ มีน่าสนใจก็จะเป็นตัวชุด NOTES ที่เป็น CHART_NAME, CHART_VERSION, APP_VERSION ส่วนนี้ผู้สร้าง chart จะมีการ note ส่วนที่ไว้ในส่วน ซึ่งเราไปดูไฟล์ NOTES ได้จาก git repository ของ chart นั้น แล้วเลือก tag version ที่ต้องการ จากนั้นไฟล์จะอยู่ที่ template/NOTE.txt

📌 ส่วนนึงเลยที่ต้องทำความเข้าใจให้ดีคือ chart version เป็น version ของตัว chart ซึ่งจะไม่ใช่ version ของตัว application นั่นแปลว่าถ้าเราอยากลง application version ไหน เราก็ต้องไปดูก่อนว่า application version นั้นมันอยู่ที่ chart version ไหน เราก็เลือก chart version ให้ถูก เพื่อที่จะได้ application version ที่ต้องการ เช่น การ install chart ด้วย chart version 16.0.6 จะได้ application nginx ที่เป็น version 1.25.5 … ถ้าเราอยากได้ nginx version 1.27.1 เราก็จะต้อง install ตัว chart ที่ version 18.1.14 นั่นเอง

install nginx chart version 18.1.14 เพื่อต้องการใช้ nginx version 1.27.1

*ซึ่งการ install เราสามารถ install chart เดียวกัน แต่ใช้คนละชื่อ release และ version กันได้นะ ส่วนการจัดการ chart ไม่ว่าจะเป็นการ upgrade, roll back หรือ delete ก็จะแยกกันแบบอิสระ ไม่ขึ้นต่อกันเลย.

install multiple nginx chart with different release name and verison

[2] Helm list

//list สามารถย่อได้ด้วย ls
$ helm ls

เป็นการดู relase ทั้งหมดที่เราได้ลงไป

ผลลัพธ์: จะได้ลิสของ relase มา ซึ่งจะได้ข้อมูล: ชื่อ relase, name space ที่ลงบน kubernetes, revision number ที่ใช้ล่าสุด, chart version และ application (nginx) version

info of each release

[3]Helm history

$ helm history <relase_name>

เป็นการดู revision ของ release ตัวนั้นๆโดยเฉพาะ เช่น อยากทราบว่า “ที่ release ชื่อ nginx มี revision อยู่ 3 อัน มีอะไรบ้าง”

eg.
$ helm history nginx

ผลลัพธ์: เราได้ทำคำสั่งไป 3 อย่างกับตัว relase นี้ นั่นคือ:

• revision 1 : เราได้ install
• revision 2 : เราได้ upgrade chart นี้ไปยัง version 17.0.0
• revision 3 : version ล่าสุดของ chart ตัวนี้ ที่เรากำลังใช้คือ 17.3.2

*status: supereded คือ status ในอดีตที่สำเร็จไปแล้ว, deployed คือ status ปัจจุบันที่ได้ทำเสร็จไปแล้ว

[4] Helm upgrade

$ helm upgrade <release_name> <chart_repo> --version <version number>

เป็นการ upgrade version ของ chart ไปเป็น version ที่ต้องการ

🚨 ขอย้ำอีกซักรอบว่า การ upgrade version ด้วย command นี้ไม่ใช่การ upgrade version ของ application นะ แต่เป็นการ upgrade ไปยัง version chart ที่จะถือ version ของ application นั้น … ดังนั้นก่อนที่จะลงก็ควรอ่าน document เสียก่อน ซึ่งสามารถเข้าไปอ่านได้ที่ artifacthub.io นะ

eg. 
$ helm upgrade nginx bitnami/nginx --version 17.3.2

ผลลัพธ์: สามารถ upgrade chart ไปยัง version 17.3.2 ที่มี nginx application เป็น version 1.26.1 ได้

[5] Helm rollback

$ helm rollback <relase_name> <revision_number>

เป็นการย้อนกลับ version ของ chart ที่เราต้องการ โดยจะย้อยกลับผ่าน revision number ที่มีอยู่ (โดยสามารถดูได้จาก helm history)

eg.
$ helm rollback nginx 1

ผลลัพธ์: เมื่อใช้ rollback 1 => ตัว revision ก็จะนับต่อไปเป็น 4 ไม่ได้ถูกถอยกลับไปเป็น 1 นะ แต่ให้สังเกตที่ version จะถูก rollback กลับไปใช้ version ของเลข revision

helm rollback

*ส่วนนี้ถ้ามีการ upgrade และ rollback ในหลายๆครั้งเข้า อาจะเกิดปัญหาการสับสนเลข revision ได้ซึ่งก็เป็น cons หนึ่งของเจ้าตัว helm โดย solution จะเป็นพวกการทำ rollout plan และมีการทำ ADR

[6] Helm uninstall

$ helm uninstall <release_name>

เป็นการถอน release นั้นออกไปเลย ซึ่งอย่างที่รู้กันว่าตัว release จะถูกไปเก็บอยู่ที่ secret ของ kubernetes

secret of each release

แปลว่าการที่เรา uninstall ไปก็จะเท่ากับว่าเป็นการสั่งลบไฟล์ secret ไปด้วย

eg.
$ helm uninstall nginx3

ผลลัพธ์: เมื่อเราลบ release ตัว secret ของ release นั้น ก็จะหายไปด้วย

🤹🏻‍♂️ Activity สนุกๆ หลังเรียน โจทย์: “เดิมถ้าตอนนี้ release เราอยู่ที่ revision 2 ให้ลอง upgrade ไปเป็น revision 3 จากนั้นลบ revision 3 ทิ้ง แล้ว upgrade อีกรอบ ดูผลลัพธ์ว่าจะได้เป็น revision อะไร”

🤔ขอเดาคำตอบ: คิดว่าจะสร้างตัว revision 3 ขึ้นมา เพราะมันน่าจะวิ่งไปเช็คก่อนว่าหลังจากลบแล้ว revision number สูงสุดเป็นเลขอะไร แล้วเมื่อ upgrade น่าจะไปสร้างเพิ่มด้วยเลขถัดไป

มา implement กัน:

1.โอเครตอนนี้ผมมี revision ถึง 3 แล้ว

2.ทำการลบ revision 3 ทิ้ง โดยผมจะเข้าไปลบที่ secret v3 ของ kubernetes และเช็ค history จะเห็นว่า เหลือ 2 revision แล้ว

3. ทำการ helm upgrade เป็น version latest แล้วมาดูผลลัพธ์กัน

🙌🏻 เย้เป็นไปตามการคาดเดา …จาก activity นี้ทำให้เห็นว่าจริงๆแล้ว เราสามารถตัดเปะแก้ไข revision ได้ แต่ถ้าติด revision ไหนออกแล้ว จะไม่สามารถ rollback กลับไปได้นะ และการสร้าง revision จะสร้างแบบ increment โดยจะวิ่งไปเช็คเลข revision ล่าสุดก่อน แล้วจะเพิ่มขึ้นอีก 1

🚩 สรุปส่วน life cycle management ของ Helm:

ถ้าเรามามองเป็นภาพ เราอาจมองว่าการเล่ยกับ helm เหมือนกับ stack ได้

[1] การ install => ใส่ (push) ของลงกล่อง stack: โดยเราสามารถมีได้หลายกล่อง (หลาย release) แต่ละกล่องเราใส่ของได้แตกต่างกัน (หลาย version) และแต่ละกล่องไม่ได้ซ้อนหรือทับกัน(ไม่ได้ขึ้นตรงต่อกัน)

[2] การ list => เราสามารถดูชื่อกล่องแต่ละกล่องได้(release_name) และรู้ได้ว่าตอนนี้ของที่ใส่อยู่ในกล่องล่าสุดเป็นลำดับที่เท่าไร(revision_number) และรู้ info ของกล่องล่าสุด

[3] การดู history => เราสามารถดูรายกล่องได้ว่า ในกล่องนั้นๆ มีของอยู่กี่ชิ้น(revision number) และแต่ละชิ้นมี info เป็นยังไงบ้าง (chart_version และ application version)

[5] การ upgrade => ก็เหมือนเราเติมของใหม่(new_chart_version) เข้ามายังกล่องนั้นๆ เสมือนกับการเรียงลำดับกล่องส่าสุดใหม่

[6] การ delet => ก็เป็นกับการทำลายกล่องนั้นทิ้ง(ลบ relase) ของที่อยู่ข้างในนั้นก็จะถูกทำลายทิ้งทั้งหมด (ลบ revision)

Helm — Environment

ข้อมูลของตัว helm จะถูกเก็บ และสามารถเรียกมาดูข้อมูลได้ด้วย

$ helm env

ผลลัพธ์: เราก็จะได้ตัวแปล env (สังเกตุได้ว่าเป็นพิมพ์ใหญ่ทั้งหมด) ซึ่งมีตัวน่าสนใจอยู่ 2 ตัวคือ

• HELM_REPOSITORY_CACHE เป็น path folder ของตัว repository

/Users/<machine_user>/Library/Caches/helm/repository (aka “local cache repo” )ที่จะอยู่ในเครื่อง (local machine)โดยจะเป็นที่เก็บไฟล์ <repo_name>-index, <repo_name>-chart.text และพวก zip file ที่เป็น version

เดี๋ยว 2 ตัวนี้จะได้ใช้ในหัวข้อถัดไป (helm command)

• HELM_REPOSITORY_CONFIG เป็น path file ของ config repository

/Users/nutx/Library/Preferences/helm/repositories.yaml (aka “local config repo”) เป็นตัวไฟล์หลักที่จะเก็บอยู่ในเครื่อง (local machine) ซึ่งจะให้ข้อมูลของแต่ละ chart: ชื่อ, url ของ chart repository

Helm chart Repository

การ interact กับตัว chart repository เราก็จัดการเกี่ยวกับการค้นหา repo ที่เรามีอยู่ ที่ได้ลงไว้แล้วใน local machine [1] หรือจะไปหาจากบน chart repository cloud[2] , การลิสตัว repo ได้ลงไว้ [3], การเพิ่ม หรือโหลดตัว repo [4], การ upgrade verion ของตัว repo ที่มีอยู่ [5] และการลบ repo นั้นๆทิ้ง [6] ไป deep drive กันต่อ …

[1] Helm search repo

$ helm search repo <repo_name>

จะเป็นการค้นหาตัว repoโดยวิ่งไปเช็คดูที่ <repo_name>-index.yml ที่อยู่ที่ local cache repo และจะคืนน่ากลับมา

*คำว่า local หมายถึงในเครื่องเรานะ

background search (local) repo process

eg.
$ helm search repo nginx

เจอตัว nginx เพราะ เราได้ repo add ไปก่อนหน้า

แต่ถ้าเราไม่เคย add repo ในเครื่องเราเลย ก็จะไม่เจอ

eg.
$ helm search repo crane

[2] Helm search hub

$ helm search hub <name>

จะเป็นการค้นหา repo เหมือนกับตัวก่อนหน้า แต่จะต่างคำสั่งนี้จะวิ่งไปหาที่ Artifact hub.io (on cloude), ซึ่งจะรวมทุกๆ chart อยู่บนนั้น โดยดึงมาจากหลาย source ไม่ว่าจะเป็น Git เจ้าต่างๆ, Nexus หรือ Chart museum

background search hub repo process

eg.
$ helm search hub prometheus

จะเจอ chart มากมายของผู้สร้าง chart ที่นำมาฝากไว้ที่ artifact hub

[3] Helm repo list

// list ย่อเป็น ls ได้
$ helm repo ls

จะวิ่งไปอ่านค่าที่ local config repo จะเป็นการค้นหาตัว repoโดยวิ่งไปเช็คดูที่ <repo_name>-index.yml ที่อยู่ที่ และจะคืนน่ากลับมาลิสให้

background list repo process

[4] Helm repo add

$ helm repo add <repo_name> <repo_url>

การเพิ่ม repo จะมี process แบ่งออกเป็น 2 ทางหลักๆคือ

1. )จะวิ่งไปเช็คก่อนที่ local config repo ว่ามี repo ชื่อนี้หรือยัง ถ้าไม่มีจะเพิ่ม config เข้าไป

2.) จะวิ่งไปเช็คที่ local cache repo ว่ามีไฟล์ <repo_name>-index.yml และไฟล์ chart.txt อยู่ไหม ถ้าไม่มีจะไป fetch ที่ artifacthub.io ให้

background add repo process

🤔 ซึ่งถ้าย้อนๆกลับไปแรกเลย จะสังเกตุว่า ก่อนที่เราจะ helm install … ได้ เราจะต้อง helm repo add … ก่อน นั่นเอง อารมณ์เหมือนกับเราจะสร้าง docker container ได้ เราจะต้องไปโหลดตัว docker image มาก่อน

[5] Helm repo update

$ helm repo update <repo_name>

* ถ้าไม่ได้ระบุ repo_name จะเป็นการ update ทุก repo ที่มีนะ

การอัพเดตตัว repo จะมี process แบ่งออกเป็น 2 ทางหลักๆคือ

1.) วิ่งไปอ่านค่าที่อยู่ใน local config repo

2.) ด้วยค่าจากข้อ 1 วิ่งไปเช็คกับไฟล์ <repo_name>-index.yml และ chart.txt ที่ local cache repo แล้วไปเช็คกับที่ artifcatehub ถ้า version ตำ่กว่าจะ fetch version ใหม่ / สูงกว่าลงมา

background update repo process

📝NOTE: โดยส่วนใหญ่แล้ว ตอนที่เรา helm repo add เราอาจจะได้ version เก่ามา ซึ่งควรจะต้อง helm update ตามด้วยทุกครั้งนะ

[6] Helm repo remove

// remove ย่อเป็น rm ได้
$ helm repo rm <repo_name>

การ remove repo จะวิ่งไปลบทั้ง 2 ที่ ทั่ง local cache repo และ local config repo ออกไป

eg.
$ helm repo rm bitnami

background remove repo process

result after remove bitnami repo

ซึ่งเราจริงแล้วๆ มีอีกทางเลือกที่จะสามารถ remove repo ได้ด้วย ซึ่งเป็นท่า manually ไปลบ repo ได้ด้วยเหมือนกัน โดยใช้ rm -rf ไปลบไฟล์ <repo_name>-index.yml, chart.txt ที่ local cache repo และ ลบ config ที่อยู่ในไฟล์ repository.yml ที่ local config repo นะ

📝NOTE: การลบที่ repo จะไม่กระทบใดๆ กับ release นะ เพราะมันเก็บข้อมูลแยกที่กัน:

• เกี่ยวกับ repo จะเก็บอยู่ที่ local (เครื่องของเราเอง)
• แต่ตัว release จะถูกเก็บที่ secret บน kubernetes

🚩 สรุปส่วน Helm Repository:

การจัดการ helm ในส่วนของ repository จะเป็นการจัดการกับ config และไฟล์บน local (เครื่องของเรา) ซะส่วนมาก ซึ่งถ้าบนเครื่องของเรา ไม่มีข้อมูลจริงๆ จะวิ่งไป interact กับ artifact hub หรือ chart repository บน cloud เพื่อให้เราได้ chart ที่เราต้องการ โดยตัว chart repo หลักการจะคล้ายๆกับตัว docker image ที่ ก่อนที่เราจะสร้างเป็น container ได้ (ใน helm คือ install แล้วสร้างเป็น release) เราก็จะต้อง pull image ลงมาจาก image registry ซะก่อน (ใน helm ก็คือ helm repo add) และตัว helm repo ก็มีการจัดการ life cycle เหมือนกันครบ ไม่ว่าจะเป็นการ serach เพื่อค้นหาในระดับ local และ explore บน cloude, การ list ดู repo ที่มีอยู่บนเครื่อง, การเพิ่ม repo ที่ต้องการจากการ add, การ update ตัว repo ที่มีอยู่ให้เป็น version ใหม่ หรือสูงขึ้น และสุดท้ายเป็นการถอดการติดตั้ง repo ด้วยการ remove

Helm — cli additional options

// --dependencry จะช่วยเราในตอนที่เราต้องการ update sub-chart หรือเป็น dependency ที่ chart หลักใช้
$ helm install <release_name> --dependency-update

// -- atomic จะมาช่วยเราในตอนที่เรา upgrade แล้ว fail, มันจะ rollback เฉพาะตัวที่ไม่ได้ให้เรา
$ helm upgrade <release_name> --atomic


// --cleanup-on-fail จะมาช่วยเราในตอนที่เรา rollback แล้ว fail 
$ helm rollback <release_name> <revision_number> --cleanup-on-fail

// --<STATUS> จะช่วยเราตอนที่เราอยากดูลิสของ status นั้นๆ เช่น
// --deploy: ลิสตัวที่ deploy สำเร็จแล้ว
// --pending: ลิสตัวที้กำลัว pending รอ deploy อยู่
// --failed: ลิสตัวที่ deploy แล้ว fail


$ helm ls--<STATUS>

eg.
$ helm ls --pending

curiosity gap

เมื่อได้ยิน topic ที่จะเรียนในครั้งนี้เป็นหัวข้อ helm life-cycle management, helm repo ที่ลืมไปเลยว่า helm มีการจัดการ repo ของตัวมันเองด้วย ก็งงละว่าทำไมตอนแรกเราถึง helm install เลยไม่ได้ จะต้องไป helm repo add มาก่อน และ Keyword ระหว่างเรียน ไม่ว่าจะเป็น chart hook ส่วนนี้จะไปเตรียมตัวเพิ่ม เพื่อที่จะได้เรียนใน day 3 หรือ day 4 | ส่วน curiosity gap ของ day1 พอกลับไปดูแล้วจริงๆฝั่งผมมีการทำ gitops (ArgoCD) มาช่วยจัดการ การ deployment และ sync helm อีกชั้นหนึ่ง คิดว่าเมื่อเรียนครั้งถัดไป (day 3) จะมองเห็นภาพชันขึ้น ในการสร้าง custome helm chart และไปต่อยอดกับ gitops

สำหรับ chapter นี้ ก็จบกันไว้เท่านี้ก่อน เจอกัน chapter ต่อไปครับ (day3)