Values, upgrade și rollback
Un chart devine reutilizabil atunci când îi putem schimba configurația fără să
duplicăm sau să edităm template-urile. Pentru acest experiment folosim
overlay-ul values-scale.yaml:
config:
appVersion: "1.1.0-demo"
api:
replicaCount: 3
Valorile din al doilea fișier suprascriu numai cheile corespunzătoare din
values.yaml.
Previzualizarea noii configurații
Înainte de upgrade, randați combinația de valori:
helm template ticketing charts/ticketing \
--namespace cc-lab4 \
--values charts/ticketing/values.yaml \
--values charts/ticketing/values-scale.yaml \
> rendered-scale.yaml
Verificați diferențele importante:
grep 'replicas:' rendered-scale.yaml
grep 'APP_VERSION:' rendered-scale.yaml
Upgrade atomic
Aplicați noua configurație:
helm upgrade ticketing charts/ticketing \
--namespace cc-lab4 \
--values charts/ticketing/values.yaml \
--values charts/ticketing/values-scale.yaml \
--rollback-on-failure \
--wait \
--timeout 3m
--rollback-on-failure cere ca upgrade-ul să fie considerat un tot: dacă noile resurse nu
devin funcționale în intervalul dat, Helm revine automat la revizia anterioară.
Urmăriți rezultatul:
kubectl rollout status deployment/ticketing-api -n cc-lab4
kubectl get pods -n cc-lab4 \
-l app.kubernetes.io/component=api
Acum trebuie să existe trei replici API.
Dacă sesiunea de port-forward s-a oprit, porniți-o din nou:
kubectl port-forward service/ticketing-api -n cc-lab4 8080:80
Verificați versiunea raportată:
curl http://localhost:8080/info
Valoarea trebuie să fie 1.1.0-demo. Imaginea aplicației a rămas 1.0.0; am
schimbat configurația raportată de aplicație, nu binarul din container.
Istoricul release-ului
helm history ticketing -n cc-lab4
helm get values ticketing -n cc-lab4
După instalare și upgrade ar trebui să existe cel puțin două revizii:
- revizia 1: instalarea cu valorile implicite
- revizia 2: configurația cu trei replici.
Rollback
Reveniți la prima revizie:
helm rollback ticketing 1 \
--namespace cc-lab4 \
--wait \
--timeout 3m
Verificați:
helm history ticketing -n cc-lab4
kubectl get deployment ticketing-api -n cc-lab4
curl http://localhost:8080/info
curl http://localhost:8080/tickets
Rollback-ul creează o revizie nouă care reproduce configurația reviziei 1. Deployment-ul revine la două replici, iar tichetul creat anterior rămâne în PostgreSQL.
Helm revine la manifestele și valorile unei revizii, dar nu readuce automat baza de date la un snapshot anterior. Migrarea și rollback-ul schemei sau al datelor trebuie proiectate separat.
Ordinea de precedență
Pentru cheile folosite aici, ordinea relevantă este:
values.yaml al chart-ului < fișiere -f/--values, în ordine < --set
Pentru configurații reproductibile preferăm fișiere versionate. --set este
util pentru experimente scurte, de exemplu:
helm template ticketing charts/ticketing --set api.replicaCount=4