Sari la conținutul principal

Validarea și instalarea release-ului

Înainte de instalare separăm trei niveluri de verificare: validarea chart-ului, inspectarea YAML-ului randat și observarea resurselor create în cluster.

1. Validarea statică​

Rulați:

helm lint charts/ticketing --strict

Rezultatul așteptat este:

1 chart(s) linted, 0 chart(s) failed

helm lint verifică structura chart-ului, metadatele, schema valorilor și o parte dintre erorile de templating.

2. Randarea fără instalare​

Generați manifestele local:

helm template ticketing charts/ticketing \
  --namespace cc-lab4 \
  > rendered.yaml

Inspectați câteva elemente:

grep '^kind:' rendered.yaml
grep 'image:' rendered.yaml
grep 'replicas:' rendered.yaml

Ar trebui să vedeți, printre altele, un Secret, un ConfigMap, două Services, un Deployment, un StatefulSet și Pod-ul folosit de testul Helm.

Date sensibile

helm template, helm get manifest și modurile debug pot afișa conținutul Secret-urilor randate. În laborator parola este fictivă, deci nu distribuiți astfel de ieșiri atunci când lucrați cu date reale.

3. Instalarea​

Instalați chart-ul ca release numit ticketing:

helm upgrade --install ticketing charts/ticketing \
  --namespace cc-lab4 \
  --create-namespace \
  --wait \
  --timeout 3m

Am folosit upgrade --install în loc de install: aceeași comandă poate crea release-ul dacă lipsește sau îl poate actualiza dacă există deja.

Opțiunea --wait face comanda să aștepte resursele Ready, iar --timeout limitează așteptarea. Statusul deployed înseamnă că manifestele au fost acceptate și condițiile urmărite de Helm au fost îndeplinite.

Inspectarea release-ului​

helm list -n cc-lab4
helm status ticketing -n cc-lab4
helm get values ticketing -n cc-lab4 --all

Comparați perspectiva Helm cu perspectiva Kubernetes:

kubectl get deployments,statefulsets,pods,services,pvc -n cc-lab4
kubectl get pods -n cc-lab4 \
  -l app.kubernetes.io/instance=ticketing --show-labels

Starea așteptată este:

  • două Pod-uri pentru ticketing-api
  • un Pod ticketing-postgresql-0
  • un PVC în starea Bound
  • toate containerele în starea Ready.

Accesarea API-ului​

Porniți port-forward într-un terminal:

kubectl port-forward service/ticketing-api -n cc-lab4 8080:80

În alt terminal:

curl http://localhost:8080/livez
curl http://localhost:8080/readyz
curl http://localhost:8080/info

Creați și listați un tichet:

curl -X POST http://localhost:8080/tickets \
  -H 'Content-Type: application/json' \
  -d '{"title":"Instalare cu Helm","priority":"high","reporter":"student"}'

curl http://localhost:8080/tickets

Testul chart-ului​

Chart-ul conține un Pod marcat cu hook-ul helm.sh/hook: test. Acesta apelează endpoint-ul /readyz prin Service-ul intern:

helm test ticketing -n cc-lab4 --logs

Testul trebuie să se termine cu PASSED.

Diagnostic rapid​

Dacă instalarea nu se termină, nu repetați imediat comanda. Inspectați cauza:

helm status ticketing -n cc-lab4
kubectl get pods -n cc-lab4
kubectl get events -n cc-lab4 --sort-by=.metadata.creationTimestamp

Pentru ImagePullBackOff, verificați că imaginea și tag-ul sunt publice:

docker pull ghcr.io/cloud-computing-upb/lab4:1.0.0

Pentru un Pod Running, dar 0/1, inspectați readiness și logurile:

kubectl logs deployment/ticketing-api -n cc-lab4 --tail=100
kubectl logs ticketing-postgresql-0 -n cc-lab4 --tail=100