Laboratorul 4 - Împachetarea și versionarea aplicațiilor Kubernetes cu Helm
În Laboratorul 3 am descris separat, prin manifeste Kubernetes, toate componentele aplicației Ticketing API: Deployment, Services, ConfigMap, Secret, StatefulSet și stocare persistentă. Configurația funcționa, dar era legată de un singur namespace și conținea valori repetate în mai multe fișiere.
În acest laborator păstrăm aceeași aplicație și transformăm manifestele într-un chart Helm reutilizabil. Vom instala o instanță a chart-ului, vom modifica valorile fără să edităm șabloanele, vom urmări istoricul release-ului și vom reveni controlat la o revizie anterioară.
Vom lucra cu repository-ul Cloud-Computing-UPB/lab4, care conține aplicația, manifestele de referință și chart-ul complet.
Obiective
La finalul laboratorului veți putea:
- să explicați diferența dintre chart, release și revision
- să identificați structura unui chart Helm
- să separați șabloanele Kubernetes de valorile specifice unui mediu
- să folosiți funcții helper, valori și condiții în template-uri
- să validați un chart cu
helm lint,values.schema.jsonșihelm template - să instalați și să inspectați un release
- să realizați un upgrade atomic și un rollback
- să rulați un test Helm și să împachetați chart-ul
- să explicați ce resurse sunt șterse și ce date rămân după
helm uninstall.
📄️ Modelul Helm și cerințe
De ce avem nevoie de Helm
📄️ Repository-ul și clusterul local
Obținerea codului
📄️ De la manifeste la chart
Ce parametrizăm
📄️ Chart-ul Ticketing API și PostgreSQL
Chart-ul gestionează o aplicație cu două componente: API-ul stateless și baza
📄️ Validarea și instalarea release-ului
Înainte de instalare separăm trei niveluri de verificare: validarea chart-ului,
📄️ Values, upgrade și rollback
Un chart devine reutilizabil atunci când îi putem schimba configurația fără să
📄️ Împachetare și chart-uri publice
Împachetarea chart-ului
📄️ Dezinstalare și curățare
Dezinstalarea release-ului
📄️ Concluzii și diagnostic
Ce am obținut