Instalarea unui chart dintr-un repository public

În practică, multe aplicații au deja chart-uri Helm pregătite, publicate în diferite repository-uri Helm (similare cu depozitele de pachete). Un repository Helm este o sursă de unde putem încărca chart-uri oficiale sau create de comunitate. Un exemplu popular este repository-ul Bitnami, care oferă chart-uri actualizate pentru o varietate de aplicații (servere web, baze de date, sisteme de monitorizare, etc.). De asemenea, Artifact Hub este un catalog central unde se pot găsi chart-uri Helm publice de la multiple organizații, asemănător cu Docker Hub (dar pentru chart-uri Helm).

Pentru a utiliza un repository Helm, mai întâi trebuie să îl adăugăm local cu comanda helm repo add. Vom adăuga repository-ul Bitnami și apoi vom instala un chart simplu din acesta, pentru a vedea cum funcționează:

$ helm repo add bitnami https://charts.bitnami.com/bitnami
"bitnami" has been added to your repositories

$ helm search repo nginx
NAME                            	CHART VERSION	APP VERSION	DESCRIPTION                                       
bitnami/nginx                   	22.2.3       	1.29.3     	NGINX Open Source is a web server that can be a...
bitnami/nginx-ingress-controller	12.0.7       	1.13.1     	NGINX Ingress Controller is an Ingress controll...
bitnami/nginx-intel             	2.1.15       	0.4.9      	DEPRECATED NGINX Open Source for Intel is a lig...

Am adăugat repository-ul bitnami și apoi am căutat în el chart-uri care conțin termenul "nginx". Rezultatul ne arată, printre altele, chart-ul bitnami/nginx (versiunea chart 22.2.3, care corespunde aplicației NGINX v1.29.3). Vom instala acest chart Bitnami pentru Nginx într-un release nou, numit my-nginx:

$ helm install my-nginx bitnami/nginx
NAME: my-nginx
LAST DEPLOYED: Sat Nov  1 11:48:13 2025
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: nginx
CHART VERSION: 22.2.3
APP VERSION: 1.29.3

** Please be patient while the chart is being deployed **
...

Bitnami descarcă automat versiunea de chart necesară și instalează resursele incluse. În câteva momente, ar trebui să avem un al doilea server Nginx rulând în cluster, gestionat prin Helm. Putem verifica astfel:

$ kubectl get pods -l app.kubernetes.io/instance=my-nginx
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-66db75d4d-fvrmh   1/1     Running   0          21s

Acest pod este instanța Nginx instalată de chart-ul Bitnami. Putem analiza și serviciul asociat:

$ kubectl get svc -l app.kubernetes.io/instance=my-nginx
NAME       TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
my-nginx   LoadBalancer   10.96.243.85   <pending>     80:30628/TCP,443:32380/TCP   31s

Observăm că implicit, chart-ul Bitnami tot un ClusterIP a creat (fără LoadBalancer). Dacă dorim să accesăm și acest Nginx, putem folosi aceeași metodă cu kubectl port-forward pe serviciul my-nginx. În general, multe chart-uri au parametri configurabili pentru a schimba service.type în NodePort sau LoadBalancer; de exemplu, Bitnami Nginx permite setarea service.type. Într-un mediu local ca al nostru, dacă am seta service.type=NodePort, am putea accesa Nginx-ul Bitnami prin NodePort-ul alocat, însă tot ar trebui să ne asigurăm că portul respectiv este expus în afara containerului Docker al clusterului, deoarece Kind nu mapează automat NodePort-urile pe host. Astfel, chiar și pentru aceste aplicații instalate din chart-uri publice, port-forward-ul rămâne o soluție rapidă.

Am văzut astfel cum se poate adăuga un repository și instala un chart existent. În practică, vom găsi chart-uri pentru majoritatea aplicațiilor cunoscute, ceea ce ne scutește de efortul de a scrie toate șabloanele YAML. Tot ce trebuie să facem este să configurăm valorile potrivite (prin values.yaml sau --set/--values la instalare) și să lansăm instalarea. Am putea, de exemplu, să instalăm un întreg stack LAMP (Linux, Apache, MySQL, Perl/PHP/Python), MEAN (MongoDB, Express.js, Angular, Node.js), etc. folosind chart-urile disponibile public.

Observație

În mediile de Cloud reale (precum cluster-ele Kubernetes de pe AWS, Azure, GCP), serviciile de tip LoadBalancer vor obține automat un IP public sau DNS prin intermediul cloud provider-ului, iar Ingress-urile vor funcționa dacă există un controller de Ingress instalat. În mediul local Kind, aceste facilități nu sunt disponibile în mod implicit. Unele chart-uri concepute pentru cloud pot părea "blocate" pe Kind (de exemplu, un serviciu stă în Pending așteptând un LoadBalancer extern). Soluția este să adaptăm valorile chart-ului pentru mediul local: de exemplu, să folosim ClusterIP/NodePort în loc de LoadBalancer și/sau să instalăm un ingress controller manual dacă dorim testarea ingress-urilor. În laboratorul de față, am evitat aceste complicații folosind port-forward, dar este important de reținut dacă veți folosi Kind și pentru alte aplicații.